Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
docs:guide-user:services:vpn:ipsec:strongswan:overlappingsubnets [2018/09/23 23:18] – Tags vgaeteradocs:guide-user:services:vpn:strongswan:overlappingsubnets [2023/03/18 23:50] (current) – rephrase to use gender neutral language ryanc
Line 1: Line 1:
 ====== IPsec With Overlapping Subnets ====== ====== IPsec With Overlapping Subnets ======
-| For an overview over all existing Virtual private network (VPN)-related articles in the OpenWrt wiki, please visit [[docs:guide-user:services:vpn:overview]] | +One of the most common problems when establishing VPN tunnels are overlapping subnets. I.e. the IP adresses at least on one tunnel end conflict with the existing setup. Very often the firewall administrator is struggling with such a setup because special settings have to take place to create correct address translation for a clean solution. Hopefully this article will help the OpenWrt user to make it fuss-free. We assume you have read the [[basics|basics]] and the [[docs:guide-user:services:vpn:strongswan:firewall|firewall]] setup guide for IPsec.
-:!: This page is about strongswan. The old racoon documentation can be found [[..:racoon:overlappingsubnets|here]]. +
- +
-One of the most common problems when establishing VPN tunnels are overlapping subnets. I.e. the IP adresses at least on one tunnel end conflict with the existing setup. Very often the firewall administrator is struggling with such a setup because special settings have to take place to create correct address translation for a clean solution. Hopefully this article will help the OpenWrt user to make it fuss-free. We assume you have read the [[basics|basics]] and the [[docs:guide-user:services:vpn:ipsec:strongswan:firewall|firewall]] setup guide for IPsec.+
  
 ===== Real Life Example ===== ===== Real Life Example =====
- 
 So what is it all about. Let us start with a picture and some explanations. What do we have? So what is it all about. Let us start with a picture and some explanations. What do we have?
  
   * ACME company with internal subnet 10.1.2.0/24 has an existing tunnel to another company with subnet 192.168.2.0/24. The firewall therefore will route all packets with destination 192.168.2.1-192.168.2.254 into the existing tunnel.   * ACME company with internal subnet 10.1.2.0/24 has an existing tunnel to another company with subnet 192.168.2.0/24. The firewall therefore will route all packets with destination 192.168.2.1-192.168.2.254 into the existing tunnel.
-  * Our OpenWrt user at home has already a IPsec VPN connection too. The OpenWrt firewall protects his network 192.168.2.64/26 and routes all traffic to 10.1.0.0-10.1.3.254 towards the established tunnel to another company.+  * Our OpenWrt user at home has already a IPsec VPN connection too. The OpenWrt firewall protects their network 192.168.2.64/26 and routes all traffic to 10.1.0.0-10.1.3.254 towards the established tunnel to another company.
   * When establishing a new tunnel between home and ACME without address translation we would run into routing conflicts. E.g. if we want to reach the server 10.1.2.55 from home it could either be a machine in the ACME network or in the others company network.   * When establishing a new tunnel between home and ACME without address translation we would run into routing conflicts. E.g. if we want to reach the server 10.1.2.55 from home it could either be a machine in the ACME network or in the others company network.
  
Line 17: Line 13:
 What to do? Both firewall adminstrators have to choose IP address ranges for the new tunnel that do not overlap with the existing infrastructure. In our case: What to do? Both firewall adminstrators have to choose IP address ranges for the new tunnel that do not overlap with the existing infrastructure. In our case:
  
-  * The ACME administrator chooses to "hide" the remote home network behind the subnet 192.168.3.0/26. So when someone from ACME company wants to reach the newly conected home network he has to take on of those addresses instead of the real ones in range 192.168.2.64/26 +  * The ACME administrator chooses to "hide" the remote home network behind the subnet 192.168.3.0/26. So when someone from ACME company wants to reach the newly conected home network they have to take on of those addresses instead of the real ones in range 192.168.2.64/26 
-  * The same applies for the home user. He does not want to reach the ACME network with its real IP addresses but changes the target range to 10.1.4.0/24.+  * The same applies for the home user. They do not want to reach the ACME network with its real IP addresses but changes the target range to 10.1.4.0/24.
   * That means each of both sides determines the remote part of the tunnel subnets.   * That means each of both sides determines the remote part of the tunnel subnets.
  
Line 25: Line 21:
   * We cannot use the mailservers real address but have to choose 10.1.4.55 instead. You can see that the lower part of the IP will match the original address while the higher is taken from the translated subnet.   * We cannot use the mailservers real address but have to choose 10.1.4.55 instead. You can see that the lower part of the IP will match the original address while the higher is taken from the translated subnet.
   * The laptop sends a packet with header 192.168.2.77->10.1.4.55.   * The laptop sends a packet with header 192.168.2.77->10.1.4.55.
-  * The OpenWrt firewall has to translate the source address into one that can safely pass the tunnel. Again it will only translate the higher digits. The header will become 192.168.3.11->10.1.4.55. If not sure why 2.77 is converted to 3.11 you just have to check the last bits of the home netmask ...11000000. Only the last 6 bits will be retained. +  * The OpenWrt firewall has to translate the source address into one that can safely pass the tunnel. Again it will only translate the higher digits. The header will become 192.168.3.13->10.1.4.55. If not sure why 2.77 is converted to 3.13 you just have to check the last bits of the home netmask ...11000000. Only the last 6 bits will be retained. 
   * The packet is sent into the tunnel.   * The packet is sent into the tunnel.
-  * When it reaches the ACME firewall it will be translated again. This time the destination address will be mapped over to the real addresses. The header will be changed to 192.168.3.11->10.1.2.55+  * When it reaches the ACME firewall it will be translated again. This time the destination address will be mapped over to the real addresses. The header will be changed to 192.168.3.13->10.1.2.55
   * The answer packet of the mailserver will travel this chain backwards.    * The answer packet of the mailserver will travel this chain backwards. 
  
Line 34: Line 30:
  
 ===== Linux NAT ===== ===== Linux NAT =====
- 
 Now that we know where and how to change IP addresses we will make a short excursion into the Linux netfilter deeps. We have no real choices to implement the above explained translation rules. Now that we know where and how to change IP addresses we will make a short excursion into the Linux netfilter deeps. We have no real choices to implement the above explained translation rules.
  
-  * **Source address translation**: Required for outgoing packets. The firewall allows source address translation only in the POSTROUTING chain of the NAT table. This is the very last step of kernel packet mangling. This implies a feature and some trouble. All filter rules are applied before source translation. So they can be implemented with the original packets IP addresses. We have no burden to work on translated packets. On the other hand the firewall cannot know that the packet is routed into an IPsec tunnel before the translation takes place. As mentioned [[..:racoon:firewall#preface|here]] our firewall script already observes these quirks.  +  * **Source address translation**: Required for outgoing packets. The firewall allows source address translation only in the POSTROUTING chain of the NAT table. This is the very last step of kernel packet mangling. This implies a feature and some trouble. All filter rules are applied before source translation. So they can be implemented with the original packets IP addresses. We have no burden to work on translated packets. On the other hand the firewall cannot know that the packet is routed into an IPsec tunnel before the translation takes place. As mentioned [[..:ipsec:racoon:firewall#preface|here]] our firewall script already observes these quirks.  
-  * **Desintation address translation**: Required for incoming packets. The right place is the PREROUTING chain of the NAT table. The firewall will jump there before any filter chain is traversed. And again we have the possibility to build filter rules based on how we "see" our internal network topology - with the real local addresses.+  * **Destination address translation**: Required for incoming packets. The right place is the PREROUTING chain of the NAT table. The firewall will jump there before any filter chain is traversed. And again we have the possibility to build filter rules based on how we "see" our internal network topology - with the real local addresses.
   * **iptables module**: When most of us think about address translation in the kernel the SNAT and DNAT rules come into mind. If you dig into the documentation you will soon discover that they work well only on single addresses. If you provide address ranges these modules will apply some kind of randomness. So what we need is a 1:1 subnet mapping. The command of interest is **NETMAP**. It will replace the higher address bits of a IP address with a new subnet while keeping the lower bits. This will help us to stay deterministic and to keep number of firewall rules small.   * **iptables module**: When most of us think about address translation in the kernel the SNAT and DNAT rules come into mind. If you dig into the documentation you will soon discover that they work well only on single addresses. If you provide address ranges these modules will apply some kind of randomness. So what we need is a 1:1 subnet mapping. The command of interest is **NETMAP**. It will replace the higher address bits of a IP address with a new subnet while keeping the lower bits. This will help us to stay deterministic and to keep number of firewall rules small.
- 
  
 ===== OpenWrt Firewall Rules ===== ===== OpenWrt Firewall Rules =====
- 
 Once again we want to integrate the required rules nicely into the OpenWrt firewall concept. Let us start with the destination translation in the prerouitng chain. We want to translate the target IP of packets that come out of the tunnel into the matching ones of our internal subnet. OpenWrt automatically creates two chains for the VPN zone: zone_vpn_prerouting and prerouting_vpn. They are already linked correctly but have to be populated correctly. Just a source/destination address match paired with a NETMAP translation will do what is required. Have a look at the picture. Once again we want to integrate the required rules nicely into the OpenWrt firewall concept. Let us start with the destination translation in the prerouitng chain. We want to translate the target IP of packets that come out of the tunnel into the matching ones of our internal subnet. OpenWrt automatically creates two chains for the VPN zone: zone_vpn_prerouting and prerouting_vpn. They are already linked correctly but have to be populated correctly. Just a source/destination address match paired with a NETMAP translation will do what is required. Have a look at the picture.
  
Line 54: Line 47:
 ===== Configuration ===== ===== Configuration =====
  
-Nice to know, that the configuration is very simple. The [[basics#ike.daemon|ipsec]] and [[docs:guide-user:services:vpn:ipsec:strongswan:firewall#vpn.firewall.script|firewall]] scripts will take care of the required settings. You just have to add a **local_nat** configuration line into the tunnel section of your [[docs:guide-user:services:vpn:ipsec:strongswan:basic|/etc/config/ipsec]] file.+Nice to know, that the configuration is very simple. The [[basics#ike.daemon|ipsec]] and [[docs:guide-user:services:vpn:strongswan:firewall#vpn.firewall.script|firewall]] scripts will take care of the required settings. You just have to add a **local_nat** configuration line into the tunnel section of your [[docs:guide-user:services:vpn:strongswan:configuration|/etc/config/ipsec]] file.
  
 <code> <code>
Line 69: Line 62:
  
 ===== What's Next ===== ===== What's Next =====
- +OpenWrt as a central VPN gateway for [[docs:guide-user:services:vpn:strongswan:roadwarrior|road warriors]].
-OpenWrt as a central VPN gateway for [[docs:guide-user:services:vpn:ipsec:strongswan:roadwarrior|road warriors]]. +
- +
-{{tag>VPN IPsec strongSwan}}+
  
  • Last modified: 2023/03/18 23:50
  • by ryanc