Problem:
I want to establish an IPsec tunnel to a remote office, but the local network there conflicts with the local network at the central office. How can i solve this problem without changing the network on either side?
Solution:
This is possible to solve by address translating the network on both sides to something else when these networks need to talk to each other. Lets say that the conflicting network is 192.168.30.0/24, we create a “fake” network that only exists between these 2 sites. So instead of connecting to the remote host 192.168.30.50 we connect to 172.16.1.50. This modification can be done automatically.
How to accomplish this.
Example:
Main Office Network/IPs:
- Local Network: 192.168.30.0/24
- External IP: 1.1.1.1
Remote Office Network/IPs:
- Local Network: 192.168.30.0/24
- External IP: 2.2.2.2
Main Office IPsec:
- Name: Stockholm_IPsec
- Local Network: 172.16.1.0/24
- Remote Network: 172.16.2.0/24
- Remote Endpoint: 2.2.2.2
- Keep "Add route statically" enabled
Main Office route:
- [core] 172.16.1.0/24
Remote Office IPsec:
- Name: Gothenborg_IPsec
- Local Network: 172.16.2.0/24
- Remote Network: 172.16.1.0/24
- Remote Endpoint: 1.1.1.1
- Keep "Add route statically" enabled
Remote Office route:
- [core] 172.16.2.0/24
Main Office Policy Outbound:
- Action:Allow
Interface:Lan
Network:"Lan_net"
Destination Interface:Stockholm_IPsec
Destination Network:"Fake_Remote_Network"
Service:All-Services
Source Translation:Sat
Address Action:Transposed
Base IP Address:172.16.1.0
Main Office Policy Inbound:
- Action:Allow
Interface:Stockholm_IPsec
Network:"Fake_Remote_Network"
Destination Interface:any
Destination Network:"Fake_Local_Network"
Service:All-Services
Source Translation:Nat
Address Action:Outgoing Interface Address
Destination Translation:Sat
Address Action:Transposed
Base IP Address:192.168.30.0
Note: You can not select i.e 172.16.1.0/24 as Source or destination network on the SAT rule’s address translation tab, you need to type 172.16.1.0 and it will translate correctly from the correct source IP and destination IP. 192.168.30.50 becomes 172.16.1.50 etc.
Note-2: The reason why we [Core] route the 172.16.x.x network is because this network will not exist behind any physical interface. It exists in the Core only (so to speak).
The same rules but the other way around on the remote office.
This enables the same network to still exist on both sides, when clients want to connect to hosts on beyond the IPsec tunnel they use the 172.16.x.x address instead of 192.168.x.x and thus we have bypassed the problem and there is no need to change the local network on either side.
Example flow:
Host 192.168.30.93 on the Main office wants to reach an FTP server on the Remote Office. This FTP server has the IP 192.168.30.55 on the remote office. Host 192.168.30.93 then connects to 172.16.2.93 which will traverse the IPsec tunnel then address translated from 172.16.2.93 to 192.168.30.93 in order to match the machine on the remote office local network.
Related articles
11 Jan, 2023 ipsec core vpn
24 Mar, 2023 core ipsec ippool dhcp
12 Apr, 2023 core proxyarp arp ipsec routing
18 Mar, 2024 core certificate oneconnect ipsec vpn
21 Feb, 2023 ipsec certificate windows ca core
22 Mar, 2021 core ipsec routing
18 Mar, 2024 core incontrol certificate oneconnect ipsec vpn
16 Apr, 2024 core routing ospf ipsec
17 Jun, 2021 core ipsec routing
8 Mar, 2023 core l2tp ipsec
20 Feb, 2023 core vpn ipsec
4 Aug, 2023 core ipsec troubleshoot ike
14 Apr, 2021 core license ipsec
8 Sep, 2020 core ipsec rules access
29 Mar, 2023 ipsec core windows vpn l2tp
5 Apr, 2023 ipsec core
16 Sep, 2020 vpn ipsec ikev2 windows howto dh
7 Dec, 2022 ipsec ike troubleshoot core
14 Dec, 2022 core ipsec
5 Apr, 2023 core nps ipsec radius legacy
14 Mar, 2023 core ipsec vpn ikev2 certificate
23 Aug, 2022 core ipsec license memory
15 Mar, 2023 core ipsec ipv6
23 Aug, 2022 core connections ipsec memory
13 Feb, 2023 ipsec core routing failover
28 Mar, 2023 dhcp ipsec core