Overlapping subnets with IPsec solution test: Difference between revisions
Added a new site before implementing it to the original. Changed routing steps |
No edit summary |
||
| (8 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
==Introduction== | ==Introduction== | ||
This article provides an extensive configuration example with details on how to solve overlapping subnets when using IPsec. | This article provides an extensive configuration example with details on how to solve overlapping subnets when using IPsec. | ||
| Line 11: | Line 10: | ||
'''Configuration scheme''': | '''Configuration scheme''': | ||
[[File: | [[File:IPsec overlapping subnets Topology version2.png|border]] | ||
==Router configuration== | ==Router configuration== | ||
| Line 22: | Line 21: | ||
====RUT1 configuration==== | ====RUT1 configuration==== | ||
---- | ---- | ||
[[File: | [[File:RUT1 configuration IPsec Overlapping subnets with IPsec solution.png|border|1100x1100px]][[File:RUT1 IPsec connection settings.png|border|1100x1100px]] | ||
[[File: | |||
#'''Enable''' instance. | #'''Enable''' instance. | ||
#'''Remote endpoint''' (Only one side of IPsec needs to have it configured) | #'''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). | #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 | #Select '''Type''' to tunnel | ||
#Write '''Local subnet '''(an IP address/Subnet mask of the router on which the IPsec instance is configured). | #Write '''Local subnet '''(an IP address/Subnet mask of the router on which the IPsec instance is configured). | ||
| Line 33: | Line 31: | ||
====RUT2 configuration==== | ====RUT2 configuration==== | ||
---- | ---- | ||
[[File: | [[File:RUT2 configuration IPsec.png|border|1100x1100px]][[File:RUT2 IPsec connection settings.png|border|1100x1100px]] | ||
[[File: | |||
#'''Enable''' instance. | #'''Enable''' instance. | ||
#Add '''Remote endpoint''' | #Add '''Remote endpoint''' | ||
| Line 44: | Line 41: | ||
====Check IPsec tunnel status==== | ====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 ''' | 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: | ||
<pre>root@ | <pre>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</pre> | |||
===Firewall configuration=== | ===Firewall configuration=== | ||
| Line 73: | Line 94: | ||
===Routing update=== | ===Routing update=== | ||
---- | ---- | ||
To have permanent static route, you | 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==== | ====RUT1 Routing Table Configuration==== | ||
----[[File:IPsec overlapping subnets RUT1 Routing Table.png|border|1100x1100px]] | ----[[File:IPsec overlapping subnets RUT1 Routing Table border.png|border|1100x1100px]] | ||
After creating the table by | 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 | * '''Interface:''' lan | ||
| Line 83: | Line 104: | ||
* '''IPv4-Gateway:''' 192.168.1.1 | * '''IPv4-Gateway:''' 192.168.1.1 | ||
[[File:IPsec overlapping subnets RUT1 Routing Table configuration.png|border|1100x1100px]] | [[File:IPsec overlapping subnets RUT1 Routing Table configuration border.png|border|1100x1100px]] | ||
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 '''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. | 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. | ||
[[File:IPsec overlapping subnets RUT1 Routing Rule configuration.png|border]] | [[File:IPsec overlapping subnets RUT1 Routing Rule configuration border.png|border|1100x1100px]] | ||
====RUT2 Routing Table Configuration==== | ====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 | 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: | ||
[[File:IPsec overlapping subnets RUT2 Routing Table configuration.png|border|1100x1100px]] | [[File:IPsec overlapping subnets RUT2 Routing Table configuration.png|border|1100x1100px]] | ||
| Line 97: | Line 118: | ||
===Testing the solution=== | ===Testing the solution=== | ||
---- | ---- | ||
Now that everything is configured, we can begin testing our 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. | |||
[[File:IPsec overlapping subnets RUT1 Ping test.png|border]] | |||
====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. | |||
[[File:IPsec overlapping subnets RUT2 Ping test.png|border]] | |||
Latest revision as of 10:32, 31 January 2025
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.
