Overlapping subnets with IPsec solution test

Introduction

This article provides an extensive configuration example with details on how to solve overlapping subnets when using IPsec.

Configuration overview and prerequisites

Prerequisites:

Two RUTxxx routers of any type (excluding RUT850)
A SIM card with a Public Static or Public Dynamic IP address for the IPsec server
An end device (PC, Laptop, Tablet, Smartphone) to configure the routers

Configuration scheme:

Router configuration

If you have familiarized yourself with the configuration scheme and have all of the devices in order, we can start configuring the routers using instructions provided in this section.

Basic tunnel

First of, lets configure a simple connection between two IPsec instances, i.e., RUT1 and RUT2.

RUT1 configuration

Enable instance.
Remote endpoint (Only one side of IPsec needs to have it configured)
Write Pre shared key (a shared password used for authentication between the peers. The value of this field must match on both instances).
Select Type to tunnel
Write Local subnet (an IP address/Subnet mask of the router on which the IPsec instance is configured).
Write Remote subnet

RUT2 configuration

Enable instance.
Add Remote endpoint
Write Pre shared key (a shared password used for authentication between the peers. The value of this field must match on both instances).
Select Type to tunnel
Write Local subnet (an IP address/Subnet mask of the router on which the IPsec instance is configured).
Write Remote subnet

Check IPsec tunnel status

If you've followed all the steps presented above, your configuration should be finished. But as with any other configuration, it is always wise to test the setup in order to make sure that it works properly. This can be verified by running /etc/init.d/swanctl get_status command in RUT CLI, you should see tunnel being installed between virtual networks:

root@RUTX50:~# /etc/init.d/swanctl get_status
strongSwan swanctl 5.9.14
uptime: 58 seconds, since Jan 31 08:14:33 2025
worker threads: 16 total, 11 idle, working: 4/0/1/0
job queues: 0/0/0/0
jobs scheduled: 3
IKE_SAs: 1 total, 0 half-open
loaded plugins: charon des sha1 md4 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pgp pem openssl pkcs8 xcbc kdf curl kernel-netlink socket-default connmark vici updown eap-identity eap-mschapv2 xauth-generic
Connection list:
RUT2: IKEv2, no reauthentication, rekeying every 14400s
  local:  %any
  remote: 192.168.2.124
  local pre-shared key authentication:
  remote pre-shared key authentication:
  RUT2_c: TUNNEL, rekeying every 3600s
    local:  192.168.4.0/24
    remote: 192.168.3.0/24
Security Association list:
RUT2: #1, ESTABLISHED, IKEv2, <Session ID>
  local  '192.168.2.145' @ 192.168.2.145[4500]
  remote '192.168.2.124' @ 192.168.2.124[4500]
  AES_CBC-128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536
  established 57s ago, rekeying in 13753s
  RUT2_c: #1, reqid 1, INSTALLED, TUNNEL-in-UDP, ESP:AES_CBC-128/HMAC_SHA1_96
    installed 58s ago, rekeying in 3325s, expires in 3903s
    in  12345678,      0 bytes,     0 packets
    out 12345678,      0 bytes,     0 packets
    local  192.168.4.0/24
    remote 192.168.3.0/24

Firewall configuration

After establishing IPsec tunnel it's necessary to map LAN network IP addresses to virtual IPsec network addresses, for this we'll use iptables NETMAP target. Insert these IPtables rules into WebUI -> Network -> Firewall -> Custom rules.

RUT1 Firewall configuration

iptables -t nat -I POSTROUTING -s 192.168.1.0/24 -d 192.168.4.0/24 -j NETMAP --to 192.168.3.0/24
iptables -t nat -I PREROUTING -s 192.168.4.0/24 -j NETMAP --to 192.168.1.0/24

RUT2 Firewall configuration

iptables -t nat -I POSTROUTING -s 192.168.1.0/24 -d 192.168.3.0/24 -j NETMAP --to 192.168.4.0/24
iptables -t nat -I PREROUTING -s 192.168.3.0/24 -j NETMAP --to 192.168.1.0/24

POSTROUTING rule checks if outgoing packet destination IP belongs to remote IPsec virtual IP range, if yes, it will change packet source IP from LAN IP to virtual IPsec IP. PREROUTING rule checks if incoming packet source IP belongs to remote IPsec virtual IP range, if yes, it will change incoming packet destination IP from virtual IPsec IP to LAN IP.

Now LAN to LAN communication should be possible between end devices but to enable RUT to RUT communication additionally it'll be needed to install route on each device.

Routing update

To have a permanent static route, you must create a Routing table and assign a route to both Routers. Navigate to WebUI -> Network -> Routing -> Policy Based Routing. Here, you type the ID and name of your Routing table. In this case, I will use "100" for ID and "Example" for Name. The static route will allow our routers to know how to get to the opposite network, and the routing table will organize everything without directly interfering with the main routing table.

RUT1 Routing Table Configuration

After creating the table by clicking Add, a new window will open with the routing table configuration. The next step is to create a Static IPv4 route. We need to set:

Interface: lan
Target: remote IPsec virtual network, in this case it is 192.168.4.0
IPv4-Netmask: 255.255.255.0
IPv4-Gateway: 192.168.1.1

After typing the information and applying it, we need to create a Routing rule so that the Router knows to use the table specified earlier. In this example, we need to go back to Policy Based Routing, where our new routing table is visible at the top. To create a Routing rule we simply click Add in the Routing Rules section. There is only one thing to change for the rule, the Routing Table should be set to the table created by us.

RUT2 Routing Table Configuration

The same steps should be performed as for RUT1, the only difference is during Static IPv4 Route configuration, the target is 192.168.3.0. It should look like on the attached image:

Testing the solution

Now that everything is configured, we can begin testing our solution. We will be using ping command to test the connection between the routers.

Testing from RUT1

From RUT1, we will ping the 192.168.4.1 address. Thanks to our configuration, RUT1 will ping this address from its own interface which has a 192.168.1.1 address. RUT2 will receive the ping and translate 192.168.4.1 address to 192.168.1.1 resulting in a successful test.

Testing from RUT2

From RUT2, we will ping the 192.168.3.1 address. Thanks to our configuration, RUT2 will ping this address from its own interface which has a 192.168.1.1 address. RUT1 will receive the ping and translate 192.168.3.1 address to 192.168.1.1 resulting in a successful test.