Firewalld not passing traffic between zones (WireGuard)

I have Rocky Linux 8.4 (Green Obsidian) aarch64 installed on my Raspberry Pi 3 model B, using an image supplied by a community member here. I enabled EPEL, but because of the Pi’s ARM arch I couldn’t use elrepo. As such, I added the jdoss/wireguard COPR repo to install wireguard-dkms.

Everything is working perfectly on the WireGuard side. I have the Pi set up as ‘server’ (in as much as WireGuard is actually P2P), and firewalld is enabled to provide masquerade for clients. Since the Public zone is default, both interfaces (eth0 and wg0) had been added to it, and clients are able to connect and use the Internet via WG/the Pi as you’d expect.

When I move the eth0 interface to another zone, such as Trusted or Home, the remote WireGuard clients stop having Internet access, and receive no data back from the Pi/server. They can ping the VPN server address ( but not the wider non-VPN LAN or Internet. Moving back the eth0 interface to Public alongside wg0 restores connectivity.

I am more used to running WireGuard on Debian and Arch, and as such don’t normally use firewalld. Can anyone help me out with some pointers please? I’m wondering if it’s because masquerade is only enabled on Public, but the traffic needs to hit Home (for example) to see my main network and the router out to the wider Internet? That doesn’t really make sense to me, however, as the whole point of masquerade on Public is to allow it to route out clients to other zones/interfaces.

Or perhaps there’s a setting related to inter-zone communication I haven’t read about yet, similar to how policies work in Shorewall? I did do a test run using Fedora 34 in a VM, before setting up the ‘real’ WG server on Rocky in production. On my Fedora VM, the traffic passes just fine even with the two interfaces in separate zones. On Rocky this isn’t the case.

Ideally, I want the two interfaces on separate zones. Since the WG server only needs to listen on its own port (51820/udp) and nothing else, that’s all the zone needs to allow (plus masquerade). My main eth0 interface on the other hand is connected to my physical LAN and needs to listen on other ports (including SSH, MDNS, DHCP etc). I’d rather not leave all those ports exposed on the WireGuard zone, but for now I’ve had to.

Thanks in advance for any pointers, help or support.

My /etc/wireguard/wg0.conf -

Address =
ListenPort = 51820
PrivateKey = (redacted)
#PublicKey = (redacted)
MTU = 1420

PublicKey = (redacted)
AllowedIPs =

PublicKey = (redacted)
AllowedIPs =

Output for firewall-cmd:

root@raspi > firewall-cmd --zone=public --list-ports

root@raspi > firewall-cmd --zone=public --list-services
cockpit ssh

root@raspi > firewall-cmd --get-active-zones
interfaces: wg0 eth0


Not really as clued up on firewalld as I should be (still using iptables, or letting cockpit manage the fw), but I think this maybe what you are after:

Thanks Tom.

Thank you for your reply, and apologies for the short delay coming back to you. I had a read of the link (and scanned the rest of the documentation), but unfortunately the link is about intra-zone forwarding. That is to say, forwarding between two interfaces in the same zone.

I’m asking about inter-zone (i.e. between two interfaces in separate zones). It must surely be possible, I’m just not very familiar with firewalld past the very basics. In Shorewall (for example) it’s as easy as adding the two zones in the policy config text file, like:

Source          Destination         Action
wireguard       trusted             allow,masquerade
trusted         wireguard           allow
public          trusted             block

I’ll keep digging. Thank you anyway. :slight_smile:

1 Like


@Rainmaker, Had any joy? If not I think this guide should get wireguard working as required:

Just been looking at this out of curiosity.

Thanks Tom.

Apologies. I didn’t see that you’d replied. I’ve been a bit tied up with another project, so for now I just have the wg0 and eth0 interfaces together in the Public zone. Given that the machine is in my LAN behind an OpenBSD router, it wasn’t urgent. I’ll get around to giving it a try and I’ll report back with results. :slight_smile:

1 Like