Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
| docs:guide-user:services:vpn:ipsec:strongswan:firewall [2018/03/04 16:04] – ↷ Links adapted because of a move operation | docs:guide-user:services:vpn:strongswan:firewall [2020/11/11 09:58] (current) – obsolete links vgaetera | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== IPsec Firewall ====== | ====== IPsec Firewall ====== | ||
| - | | For an overview over all existing Virtual private network (VPN)-related articles in the OpenWrt wiki, please visit [[docs: | + | 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: |
| - | + | ||
| - | :!: This page is about strongswan. The old racoon documentation can be found [[docs: | + | |
| - | + | ||
| - | 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: | + | |
| ===== 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: | |
| - | 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: | + | |
| ===== Zones ===== | ===== Zones ===== | ||
| - | |||
| As in many commercial firewall solutions OpenWrt works with zones. A zone is more or less a bunch of computers that reside in the same network. Common examples are WAN, LAN, WLAN, ... Why not introduce a new zone for computers behind tunnels. Here are two facts that should encourage the use of a new zone named VPN. | As in many commercial firewall solutions OpenWrt works with zones. A zone is more or less a bunch of computers that reside in the same network. Common examples are WAN, LAN, WLAN, ... Why not introduce a new zone for computers behind tunnels. Here are two facts that should encourage the use of a new zone named VPN. | ||
| Line 18: | Line 12: | ||
| * 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: | + | **Conclusion: |
| ===== 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 31: | Line 24: | ||
| * The router is allowed to send data into all zones (OUTPUT). | * The router is allowed to send data into all zones (OUTPUT). | ||
| * Sending data between zones is disabled (FORWARD). This will be achieved through firewall rules afterwards. | * Sending data between zones is disabled (FORWARD). This will be achieved through firewall rules afterwards. | ||
| - | |||
| ===== Tunnel Endpoints ===== | ===== Tunnel Endpoints ===== | ||
| - | |||
| To allow IPsec communications from a remote VPN Gateway the router must be able to terminate incoming connections. Three rules are required. | To allow IPsec communications from a remote VPN Gateway the router must be able to terminate incoming connections. Three rules are required. | ||
| Line 52: | Line 43: | ||
| ===== 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/ | Rules for the VPN zone require special considerations especially if you want to edit them with LuCI. Think of the IP address/ | ||
| Line 60: | Line 50: | ||
| ===== Outgoing VPN Packets ===== | ===== Outgoing VPN Packets ===== | ||
| - | |||
| Up to here it was easy. Now it is time for a deeper firewall inspection. A packet from zone SRC to any other zone will sometime pass the **zone_SRC_forward** chain. At this point the firewall checks the packets destination address and forwards or drops it. For each rule we created from SRC to somwhere else an entry has been placed into this chain. The chain sequence is analogous to the order of rules. A comparison of the following picture with the above ruleset should make it clear. | Up to here it was easy. Now it is time for a deeper firewall inspection. A packet from zone SRC to any other zone will sometime pass the **zone_SRC_forward** chain. At this point the firewall checks the packets destination address and forwards or drops it. For each rule we created from SRC to somwhere else an entry has been placed into this chain. The chain sequence is analogous to the order of rules. A comparison of the following picture with the above ruleset should make it clear. | ||
| Line 82: | Line 71: | ||
| ===== 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 90: | Line 78: | ||
| ===== Packets To The Device ===== | ===== Packets To The Device ===== | ||
| - | |||
| If we want to reach the device through a VPN tunnel we have to check the correctness of the INPUT chain. It branches into the input (lowercase!) chain where the system checks it for the different zones. The jump over to the vpn_zone | If we want to reach the device through a VPN tunnel we have to check the correctness of the INPUT chain. It branches into the input (lowercase!) chain where the system checks it for the different zones. The jump over to the vpn_zone | ||
| Line 98: | Line 85: | ||
| ===== 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 99: | ||
| ===== 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/ | 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/ | ||
| Line 135: | Line 120: | ||
| / | / | ||
| </ | </ | ||
| - | ===== 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: | + | [[docs: |
| <code bash> | <code bash> | ||
| Line 271: | Line 256: | ||
| ===== What's next ===== | ===== What's next ===== | ||
| - | + | With the firewall ready we can start our first IPSec VPN scenario. A [[docs: | |
| - | With the firewall ready we can start our first IPSec VPN scenario. A [[docs: | + | |