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
Next revisionBoth sides next revision
docs:guide-user:services:vpn:ipsec:strongswan:firewall [2018/09/23 23:15] – Tags vgaeteradocs:guide-user:services:vpn:strongswan:firewall [2020/10/05 21:16] – ↷ Links adapted because of a move operation tmomas
Line 4: Line 4:
 :!: This page is about strongswan. The old racoon documentation can be found [[docs:guide-user:services:vpn:ipsec:racoon:firewall|here]]. :!: This page is about strongswan. The old racoon documentation can be found [[docs:guide-user:services:vpn:ipsec:racoon:firewall|here]].
  
-When configuring firewalls, tunnels and zones we always have to keep security in mind. First rule should be: Everything that is not allowed explicitly should be denied automatically. This article provides an easy but quite powerful security concept for your IPsec VPN setup. If you missed the [[docs:guide-user:services:vpn:ipsec:strongswan:basics|basics]] please have look over there first.+When configuring firewalls, tunnels and zones we always have to keep security in mind. First rule should be: Everything that is not allowed explicitly should be denied automatically. This article provides an easy but quite powerful security concept for your IPsec VPN setup. If you missed the [[docs:guide-user:services:vpn:strongswan:basics|basics]] please have look over there first.
  
 ===== Preface ===== ===== Preface =====
- +In the following chapters you will find a detailed description of how to setup firewall rules for IPsec VPN connections. The experienced reader may notice that nowhere iptables IPsec policy rules are used (-m policy --pol ipsec). The reason for that is a special VPN scenario where both tunnel ends use [[docs:guide-user:services:vpn:strongswan:overlappingsubnets|overlapping IP addresses]]. In this case we have do use source NAT (network address translation) rules. **SNAT is only available in the POSTROUTING nat table**. At this late firewall stage the system will discover for the first time that the packet has to pass the IPsec tunnel. Any ipsec policy based filter before will ignore the packet. 
-In the following chapters you will find a detailed description of how to setup firewall rules for IPsec VPN connections. The experienced reader may notice that nowhere iptables IPsec policy rules are used (-m policy --pol ipsec). The reason for that is a special VPN scenario where both tunnel ends use [[docs:guide-user:services:vpn:ipsec:strongswan:overlappingsubnets|overlapping IP addresses]]. In this case we have do use source NAT (network address translation) rules. **SNAT is only available in the POSTROUTING nat table**. At this late firewall stage the system will discover for the first time that the packet has to pass the IPsec tunnel. Any ipsec policy based filter before will ignore the packet. +
  
 ===== Zones ===== ===== Zones =====
Line 18: Line 17:
   * VPN and WAN in the same zone needs fine granular rules to ensure that packets won't reach an unallowed target.   * VPN and WAN in the same zone needs fine granular rules to ensure that packets won't reach an unallowed target.
  
-**Conclusion: Create a new zone and call it vpn.** It is not required to assign an interface to it. If you want to rename the zone to something else you have to adapt parameter **zone** in [[docs:guide-user:services:vpn:ipsec:strongswan:basic|/etc/config/ipsec]].+**Conclusion: Create a new zone and call it vpn.** It is not required to assign an interface to it. If you want to rename the zone to something else you have to adapt parameter **zone** in [[docs:guide-user:services:vpn:strongswan:basic|/etc/config/ipsec]].
  
 ===== Default Rules ===== ===== Default Rules =====
- 
 We could build our own VPN firewall ruleset with iptables but why not go with LuCI. The interface should be flexible enough to build rules for our new OpenWrt IPsec enhanced router. The basic "Deny All" configuration can be achieved in the upper two panels. You should start with something like that: We could build our own VPN firewall ruleset with iptables but why not go with LuCI. The interface should be flexible enough to build rules for our new OpenWrt IPsec enhanced router. The basic "Deny All" configuration can be achieved in the upper two panels. You should start with something like that:
  
Line 52: Line 50:
  
 ===== VPN Rule Orders ===== ===== VPN Rule Orders =====
- 
 Rules for the VPN zone require special considerations especially if you want to edit them with LuCI. Think of the IP address/interface overlap. Your routers default outgoing interface is normally the WAN connection. Every packet that does not match your internal network will leave there. But with active security profiles in the kernel packets e.g. to the remote VPN subnet 192.168.10.0/24 will go out through the WAN interface too. Of course they will be encrypted in advance. A simple rule "Allow all LAN Zone to WAN Zone" matches any packet to one of the remote VPN networks. Placed at the wrong position on top of the list it may conflict with other VPN specific rules that follow.  Rules for the VPN zone require special considerations especially if you want to edit them with LuCI. Think of the IP address/interface overlap. Your routers default outgoing interface is normally the WAN connection. Every packet that does not match your internal network will leave there. But with active security profiles in the kernel packets e.g. to the remote VPN subnet 192.168.10.0/24 will go out through the WAN interface too. Of course they will be encrypted in advance. A simple rule "Allow all LAN Zone to WAN Zone" matches any packet to one of the remote VPN networks. Placed at the wrong position on top of the list it may conflict with other VPN specific rules that follow. 
  
Line 82: Line 79:
  
 ===== Incoming VPN Packets ===== ===== Incoming VPN Packets =====
- 
 Now that outgoing packets are covered by new policies we take care about the other direction. This is much easyier than before. The forward chain misses the jump into zone_vpn_forward chain as LuCI once again left it out due to missing associated interfaces. Without an interface we cannot insert the link directly but have to do subnet checkings in a new layer in between. As the picture shows we jump along the chains forward -> zone_VPN_forward (new) -> zone_vpn_forward (existing). Now that outgoing packets are covered by new policies we take care about the other direction. This is much easyier than before. The forward chain misses the jump into zone_vpn_forward chain as LuCI once again left it out due to missing associated interfaces. Without an interface we cannot insert the link directly but have to do subnet checkings in a new layer in between. As the picture shows we jump along the chains forward -> zone_VPN_forward (new) -> zone_vpn_forward (existing).
  
Line 98: Line 94:
  
 ===== NAT Translation ===== ===== NAT Translation =====
- 
 Some of our interfaces will run in masquerade mode. The source address of packets that will leave through these interfaces will be translated to the interface address itself. This is an unwanted contrast to VPN networks where IP addresses are usually untouched. Maybe sometime later we will have look at overlapping VPN subnets. This time our challenge lies in the NAT POSTROUTING chain. For each interface that you flagged with masquerading in LuCI a rule is inserted there. When taking no action something like this will happen. Some of our interfaces will run in masquerade mode. The source address of packets that will leave through these interfaces will be translated to the interface address itself. This is an unwanted contrast to VPN networks where IP addresses are usually untouched. Maybe sometime later we will have look at overlapping VPN subnets. This time our challenge lies in the NAT POSTROUTING chain. For each interface that you flagged with masquerading in LuCI a rule is inserted there. When taking no action something like this will happen.
  
Line 113: Line 108:
  
 ===== Firewall integration ===== ===== Firewall integration =====
- 
 To enable custom firewall rules we hook up with the default firewall mechanism. Ensure that firewall user scripts are loaded and reloaded everytime we (re)start the OpenWrt firewall. Verify/adapt the following lines in /etc/config/firewall To enable custom firewall rules we hook up with the default firewall mechanism. Ensure that firewall user scripts are loaded and reloaded everytime we (re)start the OpenWrt firewall. Verify/adapt the following lines in /etc/config/firewall
  
Line 135: Line 129:
 /etc/firewall.ipsec  /etc/firewall.ipsec 
 </code> </code>
-===== VPN Firewall Script ===== 
  
 +===== VPN Firewall Script =====
 Finally we have a look at the script. It injects all the additionally required settings according to  Finally we have a look at the script. It injects all the additionally required settings according to 
-[[docs:guide-user:services:vpn:ipsec:strongswan:basic|/etc/config/ipsec]] into the OpenWrt firewall. Save it as **/etc/ipsec/firewall.sh** and put a calling line into **/etc/firewall.user** so it gets loaded automatically. **REMARK: This script only enables VPN firewall rules that have been set in the LUCI web interface. There is no guarantee that manually implemented rules in /etc/config/firewall will work!**+[[docs:guide-user:services:vpn:strongswan:basic|/etc/config/ipsec]] into the OpenWrt firewall. Save it as **/etc/ipsec/firewall.sh** and put a calling line into **/etc/firewall.user** so it gets loaded automatically. **REMARK: This script only enables VPN firewall rules that have been set in the LUCI web interface. There is no guarantee that manually implemented rules in /etc/config/firewall will work!**
  
 <code bash> <code bash>
Line 271: Line 265:
  
 ===== What's next ===== ===== What's next =====
- +With the firewall ready we can start our first IPSec VPN scenario. A [[docs:guide-user:services:vpn:strongswan:site2site|site to site]] connection.
-With the firewall ready we can start our first IPSec VPN scenario. A [[docs:guide-user:services:vpn:ipsec:strongswan:site2site|site to site]] connection. +
- +
-{{tag>VPN IPsec strongSwan}}+
  
  • Last modified: 2020/11/11 09:58
  • by vgaetera