Site-to-Site IPsec VPN Guide on MTN Cloud
Site-to-Site VPN with Single LAN Interface — Configuration Guide. IPsec Tunnel Between Two Cloud Tenants.
Important
This guide must be followed on BOTH tenants. Where values differ between Tenant A and Tenant B, both are shown. Substitute your own IP addresses throughout.
Step 1 | Create Cloud Networks
Create the WAN Network (Public — Router Attached)
Navigation:Infrastructure → Networks → Create Network
- Set Group to your tenant group
- Give the network a descriptive Name
- Set a CIDR appropriate for your public subnet
- Attach a Gateway
- Attach this network to a Router that has a floating IP associated
- DHCP Server checked
- Click Save
Figure 1 — Create Network form showing the fields to configure for the private network
Create the LAN Network (Private/Router attached)
Navigation:Infrastructure → Networks → Create Network
- Set Group to your tenant group
- Give it a descriptive Name
- Set CIDR to your chosen private range (e.g. 10.10.40.0/24 for Tenant A, 192.168.19.0/24 for Tenant B)
- Input Gateway
- Check DHCP Server & override IP— IPs will be statically assigned
- Click Save
Figure 1 — Create Network form showing the fields to configure for the private LAN network
Attach the WAN Network to a Router
Navigation:Infrastructure → Network Routers → Add Network Router
Ensure your WAN network is connected to a router that routes to your public floating IP. Select the appropriate external network from your cloud provider’s public network pool.
Figure 2 — Adding a network router and selecting the external (public) network
Step 2 | Configure Security Group
Navigation:Infrastructure → Security Groups → Create Security Group
Create the Security Group
Create a new security group and configure the following ingress rules:
- TCP rules (ports 22, 443) and ICMP— set the source to the network of the public IP (i.e., the public IP’s subnet/CIDR range).
- UDP rules (ports 500, 4500, and 1194)— set the source to the public IP of the second site, which will be used to establish the tunnel.
Figure 3 — Security group ingress rules showing all required ports for VPN and management access
Note
Attach this security group to BOTH the MTN Cloud VPN instance and the Linux VM instances. The MTN Cloud VPN instance needs it for the VPN ports; the VMs need it so MTN Cloud VPN can forward traffic to them.
Step 3 | Deploy MTN Cloud VPN and Linux Instances
Navigation:Provisioning → Catalog → MTN VPN Services (MTN Cloud VPN)
Deploy the MTN Cloud VPN Instance
When provisioning the MTN Cloud VPN instance, attach BOTH networks you created in Step 1. The order matters — the WAN (router-attached) network must be the primary (eth0) interface.
- Primary interface (eth0 / WAN): Select the public network attached to your router
- Secondary interface (eth1 / LAN): Select the private LAN network with no router
- Attach the security group created in Step 2
- Note the private IP assigned to eth1 by the cloud platform — you will need this in Step 4
Figure 4 — MTN Cloud VPN instance Network tab showing eth0 (WAN) with public IP and eth1 (LAN) with private IP
Deploy the Linux VM
Deploy your Linux test VM with ONLY the private LAN network (no router). Do not attach a floating IP to your VMs — all external traffic routes through MTN Cloud VPN.
- Attach ONLY the private LAN network (eth0)
- Attach the same security group
- Note the private IP assigned by the platform
Warning
Do NOT attach the public (WAN) network to your Linux VMs. All internet and cross-tenant traffic must route through the MTN Cloud VPN firewall.
Step 4 | Configure MTN Cloud VPN LAN Interface
Navigation:MTN Cloud VPN GUI → Interfaces → LAN (vtnet1)
Access the MTN Cloud VPN GUI via the floating IP assigned to the WAN interface. Default credentials are admin / cloud. You will then configure the LAN interface with the static IP that was assigned to eth1 by the cloud platform. Refer to step 3.1.
Set LAN Interface IP
Navigate to Interfaces → LAN. Configure the following settings:
| Field | Value |
|---|---|
| IPv4 Configuration Type | Static IPv4 |
| IPv4 Address | IP assigned to eth1 during deployment (e.g. Refer to step 3.1) |
| IPv4 Upstream Gateway | None (CRITICAL — leave as None for LAN interfaces) |
Step 5 | Configure IPsec Phase 1
Navigation:MTN Cloud VPN GUI → VPN → IPsec → Tunnels → Add P1
Phase 1 establishes the IKE (Internet Key Exchange) session between the two MTN Cloud VPN instances. The settings on both tenants must match exactly, except that the identifiers and remote gateway IP will be swapped.
Phase 1 Settings
Click Add P1 on the Tunnels tab. Fill in the following fields:
| Field | Value |
|---|---|
| Key Exchange Version | IKEv2 |
| Internet Protocol | IPv4 |
| Interface | WAN |
| Remote Gateway | The floating IP of the REMOTE MTN Cloud VPN (other tenant) |
| Description | Tenant-Tenant (or any descriptive name) |
| Authentication Method | Mutual PSK |
| My Identifier | IP Address — enter YOUR floating IP |
| Peer Identifier | IP Address — enter the REMOTE floating IP (other tenant) |
| Pre-Shared Key | A long random string — MUST be identical on both Tenants |
| Encryption Algorithm | AES 128 bits |
| Hash Algorithm | SHA256 |
| DH Group | 14 (2048 bit) |
| Lifetime | 28800 seconds (8 hours) |
| NAT Traversal | Auto |
| Dead Peer Detection | Enabled, Delay: 10, Max Failures: 5 |
Important
The Pre-Shared Key must be identical character-for-character on both MTN Cloud VPN instances. Generate a strong random key (at least 32 characters) and copy it carefully to both tenants.
Step 6 | Configure IPsec Phase 2
Navigation:MTN Cloud VPN GUI → VPN → IPsec → Tunnels → Show Phase 2 Entries → Add P2
Phase 2 defines the encrypted data channel — what subnets are allowed through the tunnel, and which encryption algorithm protects the data. The Local and Remote networks must be the network base addresses (e.g. 10.10.40.0/24, NOT 10.10.40.47/24).
Phase 2 Settings
| Field | Tenant A Value | Tenant B Value |
|---|---|---|
| Mode | Tunnel IPv4 | Tunnel IPv4 |
| Local Network Type | Network | Network |
| Local Network Address | 10.10.40.0 / 24 | 192.168.19.0 / 24 |
| NAT/BINAT Translation | None | None |
| Remote Network Type | Network | Network |
| Remote Network Address | 192.168.19.0 / 24 | 10.10.40.0 / 24 |
| Protocol | ESP | ESP |
| Encryption Algorithms | AES 128-bit + AES128-GCM 128-bit | AES 128-bit + AES128-GCM 128-bit |
| Hash Algorithms | SHA256 | SHA256 |
| PFS Key Group | 14 (2048 bit) | 14 (2048 bit) |
| Lifetime | 3600 seconds (1 hour) | 3600 seconds (1 hour) |
After saving both Phase 1 and Phase 2, click Apply Changes. Then navigate to Status → IPsec and click Connect to initiate the tunnel. Both Phase 1 and Phase 2 should show as Established.
Critical
The Local Network and Remote Network addresses must be the SUBNET BASE addresses with the correct prefix length (e.g. 10.10.40.0/24). Using a host IP like 10.10.40.47/32 will cause Phase 2 to fail or traffic selectors to mismatch.
Step 7 | Configure Firewall Rules
WAN Firewall Rules
Navigation:MTN Cloud VPN GUI → Firewall → Rules → WAN tab
Add the following rules to the WAN tab. These allow the IPsec control and data traffic to reach MTN Cloud VPN from the internet.
| Protocol | Destination Port | Description |
|---|---|---|
| IPv4 ESP | Any | Allow ESP encrypted packets |
IPsec Firewall Rules
Navigation:MTN Cloud VPN GUI → Firewall → Rules → IPsec tab
These rules control traffic that has been decrypted from the IPsec tunnel. Add two rules to permit bidirectional traffic between both subnets.
| Action | Protocol | Source | Destination | Description |
|---|---|---|---|---|
| Pass | IPv4 Any | 10.10.40.0/24 | 192.168.19.0/24 | Allow Tenant A to Tenant B |
| Pass | IPv4 Any | 192.168.19.0/24 | 10.10.40.0/24 | Allow Tenant B to Tenant A |
Note
The IPsec rules control traffic coming FROM the remote tenant. On tenant A, the source will be (Tenant B’s subnet). On Tenant B, the source will be (Tenant A’s subnet). Use Protocol ‘Any’ not just TCP, so that ICMP and UDP traffic also passes. This should be done in both Tenants
Step 8 | Configure Routing Gateways
Navigation:MTN Cloud VPN GUI → System → Routing → Gateways
MTN Cloud VPN auto-creates gateway entries based on interface configuration. The critical requirement is that the LANGW (LAN gateway) entry must point to the MTN Cloud VPN’s own LAN IP address, else create a gateway.
Step 9 | Configure Linux VM Default Gateway
Set a Gateway
Navigation: VM Console
Log into the Linux VM console and add a route file. E.g., add a route entry pointing to the site A/site B MTN Cloud VPN LAN IP:
sudo ip route add <destination_network> via <gateway_ip> dev eth0
Step 10 | Allow Address Pairs on the Cloud Platform
Navigation:Cloud Platform → Networks → [LAN Network] → Ports → [MTN Cloud VPN eth1 Port] → Allowed Address Pairs
Add Allowed Address Pairs
On the LAN network port associated with MTN Cloud VPN’s eth1 (LAN) interface, add an allowed address pair for the entire LAN subnet. This tells the cloud platform to allow any IP within the subnet to be sourced from this port.
| Field | Value |
|---|---|
| Port | MTN Cloud VPN eth1 / LAN interface port |
| IP Address | The LAN subnet CIDR of the opposite tunnel |
Step 11 | Verify and Test the VPN Tunnel
Check Tunnel Status
Navigation:MTN Cloud VPN GUI → Status → IPsec
After applying all configuration, both Phase 1 and Phase 2 should show as Established. If they do not, click Connect to initiate.
| Status | Meaning |
|---|---|
| Established (green) | Tunnel is up and working correctly |
| Disconnected | Click Connect — if it fails, check Phase 1 settings match on both sides |
| No phase 2 policies | Phase 2 network addresses are wrong — check subnet base addresses |
Ping Test from MTN Cloud VPN
Navigation:MTN Cloud VPN GUI → Diagnostics → Ping
Test the tunnel from MTN Cloud VPN first to isolate whether the issue is in the tunnel or in the VM configuration:
- On Tenant A MTN Cloud VPN: Ping Tenant B VM — Source: LAN
- On Tenant B MTN Cloud VPN: Ping Tenant A VM — Source: LAN
- If MTN Cloud VPN can ping both VMs, the tunnel is working correctly
- If MTN Cloud VPN cannot ping, the issue is in the tunnel or firewall rules
Ping Test from VMs
Log into each VM and test cross-Tenant connectivity:
Site-to-Site VPN with Multiple LAN Interfaces and Multiple Phase 2 Entries
Create Network
Navigation:Infrastructure → Networks → Create Network
- Set Group to your tenant group
- Give it a descriptive Name
- Set CIDR to your chosen private range.
- Input the Gateway
- Check DHCP Server & Override IP— IPs will be statically assigned
- Click Save
- Attach router (public facing)/ leave un-attached (private)
Reconfigure
Navigation:Provisioning → VPN VM → Action → Reconfigure
- Click on Reconfigure
- Click the ‘+’ button besides Network
- Select the network
- Reconfigure
- Confirm the Interface is added
Add Interface
Navigation:VPN VM → Interface → Assignment
- Open VPN VM webgui
- Login with credentials
- Click on Interfaces
- Click on Assignments
- Add new Interface
- Edit new Interface
- Input IPV4 & GW
- Click ‘enable interface’ box
- Click on Save & Apply changes
Configure IPsec Phase 1
Note:when remote GW has not been used in any tunnel — see 5.1
Configure IPsec Phase 2
Note:when local & remote GW has been used, begin from phase 2. To create a new tunnel for the new network that was attached, use a network that hasn’t been used to create a tunnel before for local and remote — see 6.1.
LAN 2 Firewall Rules
Navigation:MTN Cloud VPN GUI → Firewall → Rules → LAN 2 tab
Add the following rules to the LAN 2 tab. These allow the IPsec control and data traffic to reach MTN Cloud VPN from the internet.
IPsec Firewall Rules
Navigation:MTN Cloud VPN GUI → Firewall → Rules → IPsec tab
These rules control traffic that has been decrypted from the IPsec tunnel. Add two rules to permit bidirectional traffic between both new subnets.
| Action | Protocol | Source | Destination | Description |
|---|---|---|---|---|
| Pass | IPv4 Any | 10.10.40.0/24 | 192.168.19.0/24 | Allow Tenant A to Tenant B |
| Pass | IPv4 Any | 192.168.19.0/24 | 10.10.40.0/24 | Allow Tenant B to Tenant A |
Note
The IPsec rules control traffic coming FROM the remote tenant. On tenant A, the source will be (Tenant B’s subnet). On Tenant B, the source will be (Tenant A’s subnet). Use Protocol ‘Any’ not just TCP, so that ICMP and UDP traffic also passes. This should be done in both Tenants
Configure Routing Gateways
Navigation:MTN Cloud VPN GUI → System → Routing → Gateways
MTN Cloud VPN auto-creates gateway entries based on interface configuration. The critical requirement is that the LANGW (LAN gateway) entry must point to the MTN Cloud VPN’s own LAN IP address, else create a gateway.
Set a Gateway
Navigation: VM via Console or SSH
Log into the Linux VM console and add a route. E.g., add a route entry pointing to the site A/site B MTN Cloud VPN LAN IP:
sudo ip route add <destination_network> via <gateway_ip> dev eth0
Allow Address Pairs on the Cloud Platform
Navigation:Cloud Platform → Networks → [LAN Network] → Ports → [MTN Cloud VPN eth1 Port] → Allowed Address Pairs (cidr of destination network and optional that of the LAN)
On the LAN network port associated with MTN Cloud VPN’s eth1 (LAN) interface, add an allowed address pair for the entire LAN subnet. This tells the cloud platform to allow any IP within the subnet to be sourced from this port.
| Field | Value |
|---|---|
| Port | MTN Cloud VPN eth1 / LAN interface port |
| IP Address | The LAN subnet CIDR of the opposite tunnel |
Check Tunnel Status
Navigation:MTN Cloud VPN GUI → Status → IPsec
After applying all configuration, both Phase 1 and Phase 2 should show as Established. If they do not, click Connect to initiate.
| Status | Meaning |
|---|---|
| Established (green) | Tunnel is up and working correctly |
| Disconnected | Click Connect — if it fails, check Phase 1 settings match on both sides |
| No phase 2 policies | Phase 2 network addresses are wrong — check subnet base addresses |
Ping Test MTN Cloud VPN
Navigation:MTN Cloud VPN GUI → Diagnostics → Ping
Test the tunnel from MTN Cloud VPN first to isolate whether the issue is in the tunnel or in the VM configuration:
- On Tenant A MTN Cloud VPN: Ping Tenant B VM — Source: LAN
- On Tenant B MTN Cloud VPN: Ping Tenant A VM — Source: LAN
- If MTN Cloud VPN can ping both VMs, the tunnel is working correctly
- If MTN Cloud VPN cannot ping, the issue is in the tunnel or firewall rules
Ping Test across the tunnel
Log into each VM and test cross-Tenant connectivity: