Firewalld Policy-Based Access Control for WireGuard

In the original How to Use WireGuard With Firewalld article, we covered how to set up the hub, Host C, as part of a hub-and-spoke scenario in the Firewalld Configuration on Host C section. In that section, we covered how to use firewalld’s public zone to allow public access to the hub’s WireGuard port (51823 in this example), and to set up a custom mywg zone to allow forwarding of WireGuard traffic between spokes (Endpoint A and Endpoint B).

For the custom mywg zone in the original article, we did add a bunch of rich rules and special direct rules to apply access control to the WireGuard network, such that it only allowed new connections to be initiated to the webserver on Endpoint B (10.0.0.2), and blocked everything else. With firewalld policies, however, we can greatly simplify this configuration, plus use more of firewalld’s built-in settings instead of complicated rich rules and direct rules.

So in this article, we’ll replace the mywg zone from the original article with a new, much simpler nuwg zone, and pair it with a new intrawg policy, with which we’ll apply access control.

First, on Host C, save any runtime changes you’ve made since you last saved them:

And delete your old mywg zone if you had previously added it:

Next, create the new nuwg zone:

And then create the new intrawg policy, setting it to reject new connections by default:

Then load the new zone and policy into the active runtime state:

Now we’ll add our access control rules, using firewalld’s rich rule syntax. In this case, we just need one rule, to grant access to Endpoint B’s webserver (10.0.0.2):

If we wanted to limit access even further, say to allow only Endpoint A to access Endpoint B’s webserver, we could instead write the rule this way, specifying the source address of Endpoint A (10.0.0.1) as well:

Or if the webserver on Endpoint B was running on a custom port, like say TCP port 8080, we could instead write the rule this way, specifying the custom port instead of the standard HTTP service definition:

To finish up the policy settings, we’ll apply it to traffic forwarded within the nuwg zone itself (with both ingress and egress connected to the same zone):

If you view the info for the intrawg policy, this is what you’ll see:

Now for the nuwg zone, simply bind the wg0 interface to it:

Unlike the complicated configuration settings for the mywg zone in the original article, this is all the configuration we need for the nuwg zone. If you view the info of the nuwg zone, this is what you’ll see:

If you haven’t already set up the Public Zone on Host C, as described in the original article, do that now. Then you’re ready to Test It Out!

If it’s working to allow Endpoint A to access the webserver at Endpoint B (and rejecting all other connections through the WireGuard network), save your configuration settings with the following command:

After running that command, you’ll find the configuration for the intrawg policy at /etc/firewalld/policies/intrawg.xml:

And the configuration for the nuwg zone at /etc/firewalld/zones/nuwg.xml:

In the original How to Use WireGuard With Firewalld article, we covered how to set up the site side of the connection, Host β, as part of a point-to-site with masquerading scenario in the Firewalld Configuration on Host β section. In that section, we covered how to set up four custom firewalld zones:

In this article, we’ll add a new policy to restrict access between the mywg zone and the mysite zone such that the only access allowed will be to the webserver on Endpoint B (192.168.200.22), and everything else will be blocked.

First, on Host β, save any runtime changes you’ve made since you last saved them:

Then create a new firewalld policy for the connection between the mywg and mysite zones, and set it to reject new connections by default:

And run the reload command to make those changes active:

Next we’ll add our access control rules, using firewalld’s rich rule syntax. In this case, we just need one rule, to grant access to Endpoint B’s webserver (192.168.200.22):

If we wanted to limit access even further, say to allow only Endpoint A to access Endpoint B’s webserver, we could instead write the rule this way, specifying the source address of Endpoint A (10.0.0.1) as well:

Or if the webserver on Endpoint B was running on a custom port, like say TCP port 8080, we could instead write the rule this way, specifying the custom port instead of the standard HTTP service definition:

To finish up the policy settings, connect the mywg and mysite zones to the new policy:

This new policy’s settings will now apply to all new connections initiated from the mywg zone (our WireGuard network) to the mysite zone (the Site B LAN). If you view the info of the new mywg2mysite policy, this is what you’ll see:

If you haven’t already set up the Mypub Zone on Host β, as described in the original article, do that now. Then you’re ready to Test It Out!

If it’s working to allow Endpoint A to access the webserver at Endpoint B (and rejecting all other connections through the WireGuard network), save your configuration settings with the following command:

After running that command, you’ll find the configuration for the new mywg2mysite policy at /etc/firewalld/policies/mywg2mysite.xml:

In the original How to Use WireGuard With Firewalld article, we covered how to set up each of the WireGuard site gateways, Host α and Host β, as part of a site-to-site scenario in the Firewalld Configuration on Host α and Firewalld Configuration on Host β sections. In each of those two sections, we covered how to used firewalld’s public zone to allow public access to the gateway’s WireGuard port (51821 for Host α and 51822 for Host β), and how to use firewalld’s internal zone to allow forwarding WireGuard traffic between the two sites (Site A and Site B).

When applying access control to a site-to-site scenario, usually you will configure each site individually to restrict inbound access to the site itself, but allow full access to the other site. That’s what we’ll do here.

So in this article, we’ll add two new zones, mywg and mysite, to each WireGuard gateway, with the WireGuard interface on each gateway bound to its mywg zone, and the gateway’s own local site bound to its mysite zone. Then we’ll add two policies, mywg2mysite and mysite2mywg, to control access from the WireGuard network to the local site, and vice versa. This will be very similar to the configuration for Masquerading above, but without doing any masquerading of packets sent from the WireGuard network to the local site (and with the addition of allowing new outbound connections to be initiated from the local site to the WireGuard network).

For this example, we’ll restrict access from Site A to Site B such that we only allow new connections to be initiated from endpoints in Site A to the Site B webserver at Endpoint B (192.168.200.22), and block everything else. We’ll just cover the configuration for Host β in this article, however; the configuration for Host α will be identical, except with no rich rules for access control (therefore allowing no new connections to be initiated from Site B to Site A).

So on Host β, save any runtime changes you’ve made since you last saved them:

Then create new mysite and mywg zones:

And then create a policy for connections sent from the mysite zone to the mywg zone, mysite2mywg; as well as a policy for connections sent from the mywg zone to the mysite zone, mywg2mysite:

Set the default target for the mysite2mywg policy to ACCEPT, to allow all new outbound connections from the local site to the WireGuard network:

But set the default target for the mywg2mysite policy to REJECT, to block all new inbound connections by default from the WireGuard network to the local site:

Then run the reload command to make those changes active:

Now we’ll add our access control rules, using firewalld’s rich rule syntax. In this case for Host β, we just need one rule, to grant access to Endpoint B’s webserver (192.168.200.22). We add our access control rules to the mywg2mysite policy, which will regulate inbound connections from the WireGuard Network to the local site:

If we wanted to limit access even further, say to allow only Endpoint A to access Endpoint B’s webserver, we could instead write the rule this way, specifying the source address of Endpoint A (192.168.1.11) as well:

Or if the webserver on Endpoint B was running on a custom port, like say TCP port 8080, we could instead write the rule this way, specifying the custom port instead of the standard HTTP service definition:

To finish up the policy settings, connect the mywg and mysite zones to the mywg2mysite policy:

And connect them in the opposite direction (local site outbound to WireGuard network) via the mysite2mywg policy:

Now if you view the info of the new mywg2mysite policy, this is what you’ll see:

And if you view the info of the mysite2mywg policy, this is what you’ll see:

Now for the zones: Remove the wg0 interface from the internal zone if you had previously added it:

And add the wg0 interface to our new mywg zone:

If you view the info of the mywg zone, this is what you’ll see:

If you had previously added the eth1 interface (or whatever interface connects to the local site) to the internal zone, remove it now:

Or if you had previously mapped the local site’s subnet (192.168.200.0/24 for Site B) to the internal zone, remove it:

Then bind the eth1 interface (or whatever is the name of the dedicated interface that connects to the local site) to the mysite zone:

Or if the host doesn’t have a dedicated interface for the local site, bind the local site’s subnet to the mysite zone instead:

Now you view the info of the mysite zone, you should see this (if you’ve bound the eth1 interface to it):

Or this, if you’ve bound the local site’s subnet to it:

If you haven’t already set up the Public Zone on Host β, as described in the original article, do that now. Set up Host α the same way (but without any rich rules for its mywg2mysite policy). Then Test It Out!

If it’s working to allow Endpoint A to access the webserver at Endpoint B (and rejecting all other connections through the WireGuard network), save your configuration settings with the following command:

After running that command, you’ll find the configuration for the new mysite2mywg policy at /etc/firewalld/policies/mysite2mywg.xml:

And the configuration for the new mywg2mysite policy at /etc/firewalld/policies/mywg2mysite.xml:

Plus the configuration for the mysite zone at /etc/firewalld/zones/mysite.xml:

And the configuration for the mywg zone at /etc/firewalld/zones/mywg.xml:

Following is a table of the firewalld versions packaged by some of the most popular Linux distributions as of April 2022. Version 0.9 is required to use policies:

You can also run the following command to check the version of firewalld installed on a particular host: