General Computing
vpn raspberry-pi gateway wireguard firewalld
Updated Mon, 29 Aug 2022 07:56:49 GMT

firewalld: forward traffic as a wireguard VPN gateway


I have setup a pi running Pi OS 11 as a VPN gateway for my local network using Wireguard & Nftables, that all works fine.

However, I wish to switch over to firewalld to be compatible with docker without using iptables.

What I have so far is this:

  • internal zone: eth0
  • external zone: wg0

I cannot figure out how to get firewalld to forward traffic between eth0 & wg0. With raw nftables I just have the following, my forward chain drops by default:

nft insert rule inet firewall forward iifname "eth0" oifname "wg0" accept
nft insert rule inet firewall forward iifname "wg0" oifname "eth0" ct state related,established accept

But I cannot find out how to conditionally forward between interfaces, as the above rules.

I do not want eth0 in the external zone with wg0 as I want internet access kill-switched if the VPN goes down, plus it sort of goes against the whole idea of zones no? eth0 is just for the LAN & wg0 is for external connectivity.




Solution

With firewalld 0.9 and newer, you use firewalld policy objects to control cross-zone forwarding (prior to firewalld 0.9, there wasn't a way to do this).

If you have eth0 bound to your internal zone, and wg0 bound to your external zone, you could use the following series of commands to create a new custom policy, internal2external, and use the policy to accept all new connections forwarded from eth0 to wg0:

firewall-cmd --runtime-to-permanent
firewall-cmd --permanent --new-policy=internal2external
firewall-cmd --permanent --policy=internal2external --set-target=ACCEPT
firewall-cmd --reload
firewall-cmd --policy=internal2external --add-ingress-zone=internal
firewall-cmd --policy=internal2external --add-egress-zone=external

(Firewalld automatically adds blanket rules to accept all established/related forwarded connections, so you don't need to set up anything separately for the reverse path if it only needs to forward already-established connections.)





Comments (3)

  • +0 – That looks interesting! So i gather the setting of an ingress/egress zone is what dictates the direction of allowed new connections? So if, for example, I wanted two way new I could either create a second policy with the ingress and egress swapped, or can you have multiple zones as ingress & egress in a single policy? — Jun 13, 2022 at 19:35  
  • +0 – Yes, ingress/egress settings dictate the direction, but you can add multiple ingress & egress zones to the same policy (eg to use the same policy for both directions). — Jun 14, 2022 at 18:27  
  • +0 – Great! that looks like exactly what I was looking for, thanks! — Jun 15, 2022 at 16:30  


External Links

External links referenced by this document: