How to Use WireGuard With Firewalld

If you’re connected to Endpoint A through SSH, the first thing you should do is set up a zone (myadmin in this example) to allow the continued use of that connection from your local workstation (if you’re accessing Endpoint A physically, however, skip it). Run the following command on Endpoint A to see the IP address of the host from which you’re SSH’d in:

In this case, 192.168.1.11 is the IP address of Endpoint A on its own LAN (running SSH on TCP port 22); 192.168.1.2 is the host from which I’ve SSH’d. So run the following commands to continue to allow this connection once we start up the firewall zone for the local Ethernet interface:

If you want to allow any host on the LAN to be able to SSH into Endpoint A (not limited to just the host from which you’ve currently SSH’d), instead of 192.168.1.2 you could specify 192.168.1.0/24 (a range that includes 192.168.1.0-192.168.1.255) for the above.

The myadmin zone should now be active and filtering all connections from your SSH client (192.168.1.2). You can check this with the following command:

Now we’ll set up the main zone for Endpoint A’s local Ethernet interface. For this zone (mysite), configure firewalld to allow access to your WireGuard port (51821 in this example):

If you set up a special zone for administration, like the myadmin zone above, do the same thing for that zone too:

Now bind Endpoint A’s local Ethernet interface to the mysite zone. If you don’t know what that interface name is, run the following command on Endpoint A to show the list of interfaces:

In this case, the interface name is eth0. If you’re using NetworkManager to manage this interface, use nmcli to bind eth0 to mysite:

If you’re not using NetworkManager, run the following command to bind Endpoint A’s local Ethernet interface to the mysite zone (replace eth0 with the actual name of the interface, if not eth0):

At this point, the mysite zone should be active and filtering connections to the eth0 interface of Endpoint A. You can check this with the following command:

Now we’ll set up the mywg zone. Since we don’t want to accept any new inbound connections through the WireGuard interface on Endpoint A (only allow connections Endpoint A itself has initiated through WireGuard), we don’t need to do anything other than just bind the zone to the WireGuard interface. If you’re using NetworkManager to manage the WireGuard interface, use nmcli:

If you’re not using NetworkManager for WireGuard, run the following command to bind Endpoint A’s WireGuard interface to the mywg zone:

Now the mywg zone should be active and filtering connections to the wg0 interface of Endpoint A. You can check this with the following command:

And now the --get-active-zones command should report the following:

With this setup, firewalld will block any connections to Endpoint A other than through WireGuard (or directly through SSH from 192.168.1.2). Additionally, firewalld will block any new inbound connections to Endpoint A even when accessed through WireGuard — all connections through the WireGuard tunnel must be initiated by Endpoint A (for example, if a web server was running on Endpoint A at TCP port 80, no other host would be able to connect inbound to it, even through WireGuard; but Endpoint A would still be able to connect outbound through WireGuard to the web server running on Endpoint B).

If you’re connected to Endpoint B through SSH, set up the myadmin zone to allow the continued use of that connection from your local workstation (but if you’re accessing Endpoint B physically, skip it). Run the following command on Endpoint B to see the IP address of the host from which you’re SSH’d in:

In this case I’ve SSH’d into Endpoint B (192.168.200.22) remotely from 198.51.100.1. So run the following command to continue to allow this connection once we start up the firewall zone for the local Ethernet interface:

The myadmin zone should now be active and filtering all connections from your SSH client (198.51.100.1). You can check this with the following command:

Now we’ll set up the main zone for Endpoint B’s local Ethernet interface. For this zone (mysite), allow access to your WireGuard port (51822 in this example):

If you set up a special zone for administration, like the myadmin zone above, do the same thing for that zone too:

Now bind Endpoint B’s local Ethernet interface to the mysite zone. If you don’t know what that interface name is, run the following command on Endpoint B to show the list of interfaces:

In this case, the interface name is eth0. If you’re using NetworkManager to manage this interface, use nmcli:

If you’re not using NetworkManager, run this command to bind Endpoint B’s local Ethernet interface to the mysite zone (replace eth0 with the actual name of the interface, if not eth0):

At this point, the mysite zone should be active and filtering connections to the eth0 interface of Endpoint B. You can check this with the following command:

Now we’ll set up the mywg zone. With Endpoint B, we want to allow other hosts to initiate new connections to the HTTP server running on Endpoint B through WireGuard. So run the following command to enable this access:

Now we just need to bind the zone to the WireGuard interface. If you’re using NetworkManager to manage this interface, use nmcli:

If you’re not using NetworkManager, run the following command to bind Endpoint B’s WireGuard interface to the mywg zone:

Now the mywg zone should be active and filtering connections to the wg0 interface of Endpoint B. You can check this with the following command:

And the --get-active-zones command should report the following:

Firewalld is now up and running on Endpoint B, and will block any connections to Endpoint B other than through WireGuard (or directly through SSH from 198.51.100.1). Additionally, firewalld will block any new inbound connections to Endpoint B even through WireGuard, except to the web server running on Endpoint B.

First we’ll set up the main zone for Endpoint A’s public-facing Ethernet interface. For this zone (public), configure firewalld to allow access to your WireGuard port (51821 in this example):

Now bind Endpoint A’s public-facing Ethernet interface to the public zone. If you don’t know what that interface name is, run the following command on Endpoint A to show the list of interfaces:

In this case, the interface name is eth0. If you’re using NetworkManager to manage this interface, use nmcli to bind eth0 to public:

If you’re not using NetworkManager, run the following command to bind Endpoint A’s local Ethernet interface to the public zone (replace eth0 with the actual name of the interface, if not eth0):

At this point, the public zone should be active and filtering connections to the eth0 interface of Endpoint A. You can check this with the following command:

Note that because we’re using the predefined public zone, it comes with some additional services already unblocked, like the DHCPv6 client, mDNS, and SSH.

Now we’ll configure firewalld to accept all WireGuard connections to Endpoint A, by binding Endpoint A’s WireGuard interface to firewalld’s predefined trusted zone. If you’re using NetworkManager to manage the WireGuard interface, use nmcli:

If you’re not using NetworkManager for WireGuard, run the following command to bind Endpoint A’s WireGuard interface to the trusted zone:

Now the trusted zone should be active and accepting all connections to the wg0 interface of Endpoint A. You can check this with the following command:

And now the --get-active-zones command should report the following:

With this setup, firewalld will block all connections to Endpoint A other than through WireGuard (or through the other services enabled in the public zone, like SSH); and it will allow all connections through WireGuard.

Now we’ll set up the main zone for Endpoint B’s public-facing Ethernet interface. For this zone (public), configure firewalld to allow access to your WireGuard port (51822 in this example):

And bind Endpoint B’s public-facing Ethernet interface to the public zone. If you don’t know what that interface name is, run the following command on Endpoint B to show the list of interfaces:

In this case, the interface name is eth0. If you’re using NetworkManager to manage this interface, use nmcli to bind eth0 to public:

If you’re not using NetworkManager, run the following command to bind Endpoint B’s local Ethernet interface to the public zone (replace eth0 with the actual name of the interface, if not eth0):

At this point, the public zone should be active and filtering connections to the eth0 interface of Endpoint B. You can check this with the following command:

Note that because we’re using the predefined public zone, it comes with some additional services already unblocked, like the DHCPv6 client, mDNS, and SSH.

Now we’ll configure firewalld to accept all WireGuard connections to Endpoint B, by binding Endpoint B’s WireGuard interface to firewalld’s predefined trusted zone. If you’re using NetworkManager to manage the WireGuard interface, use nmcli:

If you’re not using NetworkManager for WireGuard, run the following command to bind Endpoint B’s WireGuard interface to the trusted zone:

Now the trusted zone should be active and accepting all connections to the wg0 interface of Endpoint B. You can check this with the following command:

And now the --get-active-zones command should report the following:

First we’ll set up the mywg zone. In this particular scenario, we want to enable Host C to forward specific connections from one WireGuard endpoint to another, and nothing else (including no direct access to Host C through WireGuard).

Because older versions of firewalld don’t have built-in support for forwarding connections destined for other hosts, we’ll use “direct” iptables rules to do the forwarding; and because on newer Linux distros, firewalld is typically configured to use the nftables backend, we’ll have to do some additional work to ensure that nftables doesn’t reject connections before our iptables rules can accept them.

So create the new mywg zone, and set its default target (what happens to connections not otherwise handled) to ACCEPT:

Note that the --reload command clears any non-permanent changes you have made, so use the --runtime-to-permanent command first if you have any temporary firewalld runtime changes you want to save before reloading.

Since we’ve just configured the mywg zone to accept all connections by default, next we’ll configure it to reject any connections attempted directly to Host C itself:

By setting a high priority number on these rich rules, you can easily override them later with other firewalld configuration settings — for example, if you wanted to allow SSH connections directly to Host C over WireGuard, you could enable it with a command like sudo firewall-cmd --zone=mywg --service=ssh.

Next, we’ll use firewalld’s --direct command to set up four iptables rules:

The first rule allows Host C to forward already-established connections (like the response to an HTTP request) coming back through the WireGuard tunnel. The second rule allows new TCP connections (like a new HTTP request) to be forwarded to port 80 of Endpoint B (10.0.0.2). The third rule rejects any other IPv4 connections from being forwarded through WireGuard; and the fourth rule does the same, but for IPv6 connections.

Note that if we ran the following iptables command directly, we’d get the same result (the advantage of doing this through firewalld is that firewalld will run the commands automatically for us when it starts up):

Finally, bind the mywg zone to the WireGuard interface. If you’re using NetworkManager to manage this interface, use nmcli:

If you’re not using NetworkManager, run the following command to bind Host C’s WireGuard interface to the mywg zone:

Now the mywg zone should be active and filtering connections to the wg0 interface of Host C. You can check this with the following command:

And you can check the direct iptables rules we added with the following command:

Now we’ll set up the zone for Host C’s public-facing Ethernet interface, public. For this zone, allow access to your WireGuard port (51823 in this example):

Next, bind Host C’s public-facing Ethernet interface to the public zone. If you don’t know what that interface name is, run the following command on Host C to show the list of interfaces:

In this case, the interface name is eth0. If you’re using NetworkManager to manage this interface, use nmcli:

If you’re not using NetworkManager, run this command to bind Host C’s local Ethernet interface to the public zone (replace eth0 with the actual name of the interface, if not eth0):

At this point, the public zone should be active and filtering connections to the eth0 interface of Host C. You can check this with the following command:

And the --get-active-zones command should report the following:

Firewalld is now up and running on Host C, and will block any connection to Host C other than through WireGuard (or through other services enabled in its public zone, like SSH). Additionally, Firewalld will prevent Host C from being used to forward new connections between any hosts in its WireGuard network, except new connections to TCP port 80 of the web server running on Endpoint B (10.0.0.2).

First we’ll set up the main zone for Endpoint A’s public-facing Ethernet interface. For this zone (public), configure firewalld to allow access to your WireGuard port (51821 in this example):

Now bind Endpoint A’s public-facing Ethernet interface to the public zone. If you don’t know what that interface name is, run the following command on Endpoint A to show the list of interfaces:

In this case, the interface name is eth0. If you’re using NetworkManager to manage this interface, use nmcli to bind eth0 to public:

If you’re not using NetworkManager, run the following command to bind Endpoint A’s local Ethernet interface to the public zone (replace eth0 with the actual name of the interface, if not eth0):

At this point, the public zone should be active and filtering connections to the eth0 interface of Endpoint A. You can check this with the following command:

Note that because we’re using the predefined public zone, it comes with some additional services already unblocked, like the DHCPv6 client, mDNS, and SSH.

Now we’ll set up the mywg zone. Since we don’t want to accept any new inbound connections through the WireGuard interface on Endpoint A (only allow connections Endpoint A itself has initiated through WireGuard), we don’t need to do anything other than just bind the zone to the WireGuard interface. If you’re using NetworkManager to manage the WireGuard interface, use nmcli:

If you’re not using NetworkManager for WireGuard, run the following command to bind Endpoint A’s WireGuard interface to the mywg zone:

Now the mywg zone should be active and filtering connections to the wg0 interface of Endpoint A. You can check this with the following command:

And now the --get-active-zones command should report the following:

With this setup, firewalld will block all new inbound connections to Endpoint A (other than through the services enabled in the public zone, like SSH), but still allow new connections to be established outbound through its Ethernet and WireGuard interfaces.

If you’re connected to Host β through SSH, set up the myadmin zone to allow the continued use of that connection from your local workstation (but if you’re accessing Host β physically, skip it). Run the following command on Host β to see the IP address of the host from which you’re SSH’d in:

In this case I’ve SSH’d into Host β (192.168.200.22) remotely from 198.51.100.1. So run the following command to continue to allow this connection once we start up the firewall zone for the public-facing Ethernet interface:

The myadmin zone should now be active and filtering all connections from your SSH client (198.51.100.1). You can check this with the following command:

Now we’ll set up the main zone for Host β’s public-facing Ethernet interface. For this zone (mypub), allow access to your WireGuard port (51822 in this example):

If you set up a special zone for administration, like the myadmin zone above, do the same thing for that zone too:

Now bind Host β’s public-facing Ethernet interface to the mypub zone. If you don’t know what that interface name is, run the following command on Host β to show the list of interfaces:

In this case, the public-facing Ethernet interface name is eth0. If you’re using NetworkManager to manage this interface, use nmcli:

If you’re not using NetworkManager, run the following command to bind Host β’s local Ethernet interface to the mypub zone (replace eth0 with the actual name of the interface, if not eth0):

At this point, the mypub zone should be active and filtering connections to the eth0 interface of Host β. You can check this with the following command:

Now we’ll set up the zone for Host β’s connection to the Site B LAN. For this zone (mysite), set up packet masquerading from our WireGuard VPN’s subnet (10.0.0.0/24):

Then associate the zone with the Site B LAN. If Host β doesn’t have a dedicated LAN interface (ie its public-facing Ethernet interface, which we bound to the mypub zone, is the same as its LAN interface), run the following command to bind the LAN’s subnet (in this example, 192.168.200.0/24) to the mysite zone:

Otherwise, if Host β does have a dedicated Ethernet interface to the Site B LAN, instead bind the interface itself to the zone. If you’re using NetworkManager to manage this interface, use nmcli:

If you’re not using NetworkManager, run the following command to bind Host β’s dedicated LAN interface to the mysite zone (replace eth1 with the actual name of the interface, if not eth1):

At this point, the mysite zone should be active and filtering connections to the 192.168.200.0/24 subnet (or the eth1 interface) of Host β. You can check this with the following command:

Now for the mywg zone. We just need to bind this zone to Host β’s WireGuard interface. If you’re using NetworkManager to manage this interface, use nmcli:

If you’re not using NetworkManager for WireGuard, run the following command to bind Host β’s WireGuard interface to the mywg zone:

Now the mywg zone should be active and filtering connections to the wg0 interface of Host β. You can check this with the following command:

And the --get-active-zones command should report the following:

Firewalld is now up and running on Host β, and will block any new inbound connections to Host β other than through WireGuard (or directly through SSH from 198.51.100.1); and it will forward connections from its WireGuard interface to the Site B LAN (192.168.200.0/24).

Before we further configure the internal zone, we’ll first set up the main zone for Host α’s public-facing Ethernet interface. For this zone (public), configure firewalld to allow access to your WireGuard port (51821 in this example):

Now bind Host α’s public-facing Ethernet interface to the public zone. If you don’t know what that interface name is, run the following command on Host α to show the list of interfaces:

In this case, the interface name is eth0. If you’re using NetworkManager to manage this interface, use nmcli to bind eth0 to public:

If you’re not using NetworkManager, run the following command to bind Host α’s local Ethernet interface to the public zone (replace eth0 with the actual name of the interface, if not eth0):

At this point, the public zone should be active and filtering connections to the eth0 interface of Host α. You can check this with the following command:

Note that because we’re using the predefined public zone, it comes with some additional services already unblocked, like the DHCPv6 client, mDNS, and SSH.

Now we’ll configure the predefined internal firewalld zone, which we’ll use for Host α’s connection to Site A, as well as to its WireGuard interface.

If your firewalld version is older than 0.9.0, and you’ve configured its internal zone to default to accepting all connections as directed above, run the following commands to explicitly reject any connections directed to Host α itself:

By setting a high priority number on these rich rules, all other firewalld configuration settings will override them — for example, the internal zone’s predefined configuration explicitly allows access to the SSH service, so these rich rules won’t block access to SSH.

If your firewalld version is 0.9.0 or newer, don’t add those rich rules; instead run the following command:

This command enables Host α to forward connections from one host to another within the internal zone, without allowing access to Host α itself (whereas the --set-target=ACCEPT command above allows both connection forwarding and direct access to Host α).

Regardless of your firewalld version, the next step is to associate the internal zone with the Site A LAN. If Host α doesn’t have a dedicated LAN interface (ie its public-facing Ethernet interface, which we bound to the public zone, is the same as its LAN interface), run the following command to bind the LAN’s subnet (in this example, 192.168.1.0/24) to the internal zone:

Otherwise, if Host α does have a dedicated Ethernet interface to the Site A LAN, instead bind the interface itself to the zone. If you’re using NetworkManager to manage this interface, use nmcli:

If you’re not using NetworkManager, run the following command to bind Host α’s dedicated LAN interface to the internal zone (replace eth1 with the actual name of the interface, if not eth1):

At this point, the internal zone should be active and filtering connections to WireGuard and the 192.168.1.0/24 subnet (or the eth1 interface) of Host α. You can check this with the following command:

The above is what you should see with firewalld version 0.9.0 and newer. Below is what you should see with older versions:

And the --get-active-zones command should report the following:

With this setup, firewalld will block all new public-facing connections to Host α (other than through the services enabled in the public zone, like SSH), as well as block internal connections to Host α itself (other than through the services enabled in the internal zone, like SSH), but forward connections freely between the Site A LAN and its WireGuard interface.

Before we further configure the internal zone, we’ll first set up the main zone for Host β’s public-facing Ethernet interface. For this zone (public), configure firewalld to allow access to your WireGuard port (51822 in this example):

Now bind Host β’s public-facing Ethernet interface to the public zone. If you don’t know what that interface name is, run the following command on Host β to show the list of interfaces:

In this case, the interface name is eth0. If you’re using NetworkManager to manage this interface, use nmcli to bind eth0 to public:

If you’re not using NetworkManager, run the following command to bind Host β’s local Ethernet interface to the public zone (replace eth0 with the actual name of the interface, if not eth0):

At this point, the public zone should be active and filtering connections to the eth0 interface of Host β. You can check this with the following command:

Note that because we’re using the predefined public zone, it comes with some additional services already unblocked, like the DHCPv6 client, mDNS, and SSH.

Now we’ll configure the predefined internal firewalld zone, which we’ll use for Host β’s connection to Site B, as well as to its WireGuard interface.

If your firewalld version is older than 0.9.0, and you’ve configured its internal zone to default to accepting all connections as directed above, run the following commands to explicitly reject any connections directed to Host β itself:

By setting a high priority number on these rich rules, all other firewalld configuration settings will override them — for example, the internal zone’s predefined configuration explicitly allows access to the SSH service, so these rich rules won’t block access to SSH.

If your firewalld version is 0.9.0 or newer, don’t add those rich rules; instead run the following command:

This command enables Host β to forward connections from one host to another within the internal zone, without allowing access to Host β itself (whereas the --set-target=ACCEPT command above allows both connection forwarding and direct access to Host β).

Regardless of your firewalld version, the next step is to associate the internal zone with the Site B LAN. If Host β doesn’t have a dedicated LAN interface (ie its public-facing Ethernet interface, which we bound to the public zone, is the same as its LAN interface), run the following command to bind the LAN’s subnet (in this example, 192.168.200.0/24) to the internal zone:

Otherwise, if Host β does have a dedicated Ethernet interface to the Site B LAN, instead bind the interface itself to the zone. If you’re using NetworkManager to manage this interface, use nmcli:

If you’re not using NetworkManager, run the following command to bind Host β’s dedicated LAN interface to the internal zone (replace eth1 with the actual name of the interface, if not eth1):

At this point, the internal zone should be active and filtering connections to WireGuard and the 192.168.200.0/24 subnet (or the eth1 interface) of Host β. You can check this with the following command:

The above is what you should see with firewalld version 0.9.0 and newer. Below is what you should see with older versions:

And the --get-active-zones command should report the following:

Firewalld is now up and running on Host β, and will block all new public-facing connections to Host β (other than through the services enabled in the public zone, like SSH), as well as block internal connections to Host β itself (other than through the services enabled in the internal zone, like SSH). It will, however, allow all new connections to be forwarded from Site A to Site B, and vice versa, through its WireGuard interface.