|For an overview over all existing Virtual private network (VPN)-related articles in the OpenWrt wiki, please visit overview|
This page is about strongswan. The old racoon documentation can be found 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 and the firewall setup guide for IPsec.
So what is it all about. Let us start with a picture and some explanations. What do we have?
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:
Let us look at the packet flow and see where address translation has to occur. Let us assume we want to reach ACME mailserver on address 10.1.2.55 from our laptop with address 192.168.2.77.
Conclusion: If you have IP conflicts in a new VPN setup first of all choose alternative addresses for packets that will pass the tunnel. Retain the subnet masks for both ends.
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.
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.
For outgoing packets we need source translation in the postrouting chain. A zone_vpn_nat chain already exists but is not linked correctly. Just place an ACCEPT rule into it for every non-natted IPsec tunnel and a NETMAP rule for every tunnel that requires address translation.
Nice to know, that the configuration is very simple. The ipsec and 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 /etc/config/ipsec file.
... config 'tunnel' 'acme_lan' option 'local_nat' '18.104.22.168/26' option 'remote_subnet' '192.168.10.0/24' option 'local_subnet' '192.168.2.64/26' option 'p2_proposal' 'g2_aes_sha1' ...
This will tell the system that the local subnet 192.168.2.64/26 will be translated to 192.168.3.0/26 inside the IPsec tunnel.
OpenWrt as a central VPN gateway for road warriors.