Overlapping subnets with IPsec solution test: Difference between revisions
Added a new site before implementing it to the original. Changed routing steps |
Added testing section, fixed grammar, added description why static route and route table are needed, changed ipsec status command to swanct since ipsec status is depreciated |
||
| 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 44: | Line 43: | ||
====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@RUTXR1:~# /etc/init.d/swanctl get_status | ||
Connection list: | |||
RUTXR1: IKEv2, no reauthentication, rekeying every 14400s | |||
local: %any | |||
remote: %any | |||
local pre-shared key authentication: | |||
remote pre-shared key authentication: | |||
RUTXR1_c: TUNNEL, rekeying every 3600s | |||
local: 192.168.3.0/24 | |||
remote: 192.168.4.0/24</pre> | |||
===Firewall configuration=== | ===Firewall configuration=== | ||
| Line 73: | Line 77: | ||
===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.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 85: | Line 89: | ||
[[File:IPsec overlapping subnets RUT1 Routing Table configuration.png|border|1100x1100px]] | [[File:IPsec overlapping subnets RUT1 Routing Table configuration.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.png|border]] | ||
| Line 91: | Line 95: | ||
====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 101: | ||
===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]] | |||
Revision as of 10:23, 24 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@RUTXR1:~# /etc/init.d/swanctl get_status
Connection list:
RUTXR1: IKEv2, no reauthentication, rekeying every 14400s
local: %any
remote: %any
local pre-shared key authentication:
remote pre-shared key authentication:
RUTXR1_c: TUNNEL, rekeying every 3600s
local: 192.168.3.0/24
remote: 192.168.4.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.
File:IPsec overlapping subnets RUT1 Routing Rule configuration.png
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.
