Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Next revisionBoth sides next revision | ||
| docs:guide-user:services:vpn:ipsec:strongswan:overlappingsubnets [2018/09/23 23:18] – Tags vgaetera | docs:guide-user:services:vpn:strongswan:overlappingsubnets [2020/11/11 09:57] – obsolete links vgaetera | ||
|---|---|---|---|
| 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: | + | 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: |
| - | :!: This page is about strongswan. The old racoon documentation can be found [[..: | + | |
| - | + | ||
| - | 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: | + | |
| ===== Real Life Example ===== | ===== Real Life Example ===== | ||
| Line 25: | Line 22: | ||
| * 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-> | * The laptop sends a packet with header 192.168.2.77-> | ||
| - | * 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-> | + | * 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-> |
| * 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-> | + | * 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-> |
| * The answer packet of the mailserver will travel this chain backwards. | * The answer packet of the mailserver will travel this chain backwards. | ||
| Line 37: | Line 34: | ||
| 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**: | + | * **Source address translation**: |
| * **Desintation address translation**: | * **Desintation address translation**: | ||
| * **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. | ||
| Line 54: | Line 51: | ||
| ===== Configuration ===== | ===== Configuration ===== | ||
| - | Nice to know, that the configuration is very simple. The [[basics# | + | Nice to know, that the configuration is very simple. The [[basics# |
| < | < | ||
| Line 69: | Line 66: | ||
| ===== What's Next ===== | ===== What's Next ===== | ||
| - | + | OpenWrt as a central VPN gateway for [[docs: | |
| - | OpenWrt as a central VPN gateway for [[docs: | + | |
| - | + | ||
| - | {{tag> | + | |