How to Use WireGuard With UFW

On Endpoint A, first check the status of UFW. If you haven’t set it up yet, this is what you’ll see:

If it’s inactive, that’s fine — we’ll set up our rules first, and then activate it.

If you’re connected to Endpoint A through SSH, your first rule should be one that continues to allow the use of that SSH connection (if you’re accessing Endpoint A physically, however, just skip this). Run the following command on Endpoint A to see the IP address of the host from which you’re SSH’d in:

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 command to continue to allow this connection once we start up the firewall:

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 rule.

For the second rule, we’ll allow any host to connect to Endpoint A via WireGuard (which is listening on UDP port 51821 on Endpoint A). Run the following command:

Now start up UFW and check its status:

UFW is now up and running, and will prevent any connection to Endpoint A other than through WireGuard (or directly through SSH from 192.168.1.2). Additionally, UFW will prevent any new inbound connections to Endpoint A even when accessed through WireGuard — all connections through the WireGuard tunnel have to be initiated by Endpoint A (for example, if a web server was running on Endpoint A at TCP port 80, no 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).

On Endpoint B, do the same thing. First check the status of UFW:

If you’re connected to Endpoint B through SSH, add a rule to allow your current SSH connection to be maintained. Run the following command on Endpoint B to see the IP address of the host from which you’ve SSH’d in:

In this case I’ve SSH’d into Endpoint B (10.0.0.2) through the WireGuard tunnel from Endpoint A (10.0.0.1). So I’d run the following command to continue to allow this connection once I start up UFW:

Now add a second rule to allow any host to connect to Endpoint B over WireGuard (which is listening on UDP port 51822 on Endpoint B):

And on Endpoint B only, add a third rule to allow any host to access the web server running on Endpoint B (listening on TCP port 80) over WireGuard (where the WireGuard interface name is wg0 on Endpoint B):

Now start up UFW and check its status:

UFW is now up and running on Endpoint B, and will prevent any connection to Endpoint B other than through WireGuard (or directly through SSH from 10.0.0.1). Additionally, UFW will prevent any new inbound connections to Endpoint B through WireGuard, except to TCP port 80 (the web server running on Endpoint B).

You can test this out by trying to access Endpoint B’s TCP port 80 from Endpoint A:

You should see the HTML of Endpoint B’s homepage printed. If you start up another web server running on Endpoint B at say TCP port 8080 (run python3 -m http.server 8080 for a temporary server serving the contents of the current directory), you won’t be able to access it from Endpoint A (or anywhere else):

You won’t see anything printed for the above (the command will “hang” — kill it by pressing the control-C key combination).

On Endpoint A, first check the status of UFW. If you haven’t set it up yet, this is what you’ll see:

If it’s inactive, that’s fine — we’ll set up our rules, and then activate it.

If you’re connected to Endpoint A through SSH, your first rule should be to continue to allow that SSH connection (if you’re accessing Endpoint A physically, you can skip this rule). Run the following command on Endpoint A to see the IP address of the host from which you’re SSH’d in:

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 command to continue to allow this connection once we start up the firewall:

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 rule.

For the second rule, we’ll allow any host to connect to Endpoint A via WireGuard (which is listening on UDP port 51821 on Endpoint A). Run the following command:

Now, for the third rule, we’ll allow any kind of access from any host, as long as it goes through WireGuard (wg0 is our WireGuard interface name on Endpoint A):

Start up UFW and check its status:

UFW is now up and running on Endpoint A, and will prevent any connection to Endpoint A other than through WireGuard (or directly through SSH from 192.168.1.2).

On Endpoint B, do the same thing. First check the status of UFW:

If you’re connected to Endpoint B through SSH, add a rule to allow your current SSH connection. Run the following command on Endpoint B to see the IP address of the host from which you’ve SSH’d in:

In this case I’ve SSH’d into Endpoint B (192.168.200.22) remotely from 198.51.100.1. So I’d run the following command to continue to allow this connection once I start up UFW:

Then add a second rule to allow any host to connect to Endpoint B over WireGuard (which is listening on UDP port 51822 on Endpoint B):

And now add a third rule to allow any kind of access from any host over WireGuard (wg0 is our WireGuard interface name on Endpoint B):

Now start up UFW and check its status:

UFW is now up and running on Endpoint B, and will prevent any connection to Endpoint B other than through WireGuard (or directly through SSH from 198.51.100.1).

The original WireGuard Hub and Spoke Configuration guide, in the “Configure Routing on Host C” section, directs you to to add the following line in the WireGuard configuration on Host C:

This enables Host C to forward packets from Endpoint A to Endpoint B (or any other hosts). Since we’re using UFW, you can omit this line from your WireGuard configuration, and instead edit the /etc/ufw/sysctl.conf file on Host C (as root) to uncomment the following lines (ie remove the existing # at the start of the lines so they look like the following):

On Host C, check the status of UFW:

If you’re connected to Host C through SSH, your first rule should be to continue to allow that SSH connection (if you’re accessing Host C physically, you can skip this rule). Run the following command on Host C to see the IP address of the host from which you’re SSH’d in:

192.168.30.33 is the IP address of Host C on its own LAN (running SSH on TCP port 22); 192.168.30.1 is the host from which I’ve SSH’d. Run the following command to continue to allow this connection once we start up the firewall:

For the second rule, we’ll allow any host to connect to Host C via WireGuard (which is listening on UDP port 51823 on Host C) by running the following command:

Now for our third rule, we’ll allow any host connected to Host C via WireGuard (where wg0 is the name of the WireGuard interface on Host C) to use that connection to access the web server running on Endpoint B (listening on TCP port 80 of Endpoint B):

Note that for UFW rules like this, which allow the local host to forward packets from one external host to another, the rule starts with the route keyword (ufw route allow …​); whereas UFW rules that apply to packets directed at the local host itself, don’t (ufw allow …​).

Now start up UFW and check its status:

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

You can test this out by trying to access Endpoint B’s TCP port 80 from Endpoint A:

You should see the HTML of Endpoint B’s homepage printed. If you start up another web server on Endpoint B running at TCP port 8080 (run python3 -m http.server 8080 for a temporary server serving the contents of the current directory), you won’t be able to access it from Endpoint A (or anywhere else):

You won’t see anything printed for the above command (the command will “hang” — kill it by pressing the control-C key combination).

Similarly, if you start up a web server on Endpoint A (with python3 -m http.server 8080), you won’t be able to access it from Endpoint B:

Again, you won’t see anything printed. Only if you add additional UFW rules to Host C (like ufw route allow in on wg0 proto tcp to 10.0.0.1 port 8080) would you be able to access the web server on Endpoint A.

On Endpoint A, first check the status of UFW. If you haven’t set it up yet, this is what you’ll see:

If it’s inactive, that’s fine — we’ll set up our rules first, and then activate it.

If you’re connected to Endpoint A through SSH, your first rule should be one that continues to allow the use of that SSH connection (if you’re accessing Endpoint A physically, however, just skip it). Run the following command on Endpoint A to see the IP address of the host from which you’re SSH’d in:

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 command to continue to allow this connection once we start up the firewall:

If you want to allow any host on the Endpoint A’s 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 rule.

For the second rule, we’ll allow any host to connect to Endpoint A via WireGuard (which is listening on UDP port 51821 on Endpoint A) by running the following command:

And for the third rule, we’ll allow all access over WireGuard (where the WireGuard interface name is wg0 on Endpoint A):

Now start up UFW and check its status:

UFW is now up and running on Endpoint A, and will prevent any connection to Endpoint A other than through WireGuard (or directly through SSH from 192.168.1.2).

On Endpoint B, check the status of UFW:

If you’re connected to Endpoint B through SSH, add a rule to allow SSH access from the Site B LAN:

Next, add a rule to allow any host on the LAN to connect to TCP port 80:

Now start up UFW and check its status:

UFW is now up and running on Endpoint B, and will allow only connections from the Site B LAN to TCP port 80 (or to TCP port 22 for SSH).

In the original WireGuard Point to Site Configuration guide, the “Configure Routing on Host β” section directs you to to add some lines to the WireGuard configuration of Host β to turn on IP forwarding and IP masquerading. But since we’re using UFW, you can omit these lines from your WireGuard configuration, and instead edit the configuration of UFW.

First, edit the /etc/ufw/sysctl.conf file on Host β (as root) and uncomment the following lines:

Then edit the /etc/ufw/before.rules file (or if you’re using IPv6 addresses, the etc/ufw/before6.rules file) to add the following block after the existing COMMIT line at the end of the file:

But be sure to replace eth0 in the above with the actual network interface name that connects Host β to the Site B LAN (if it’s not in fact eth0). If you don’t know what that interface name is, run ip -brief address show on Host β to show the list of interfaces:

If you already had UFW up and running before you made these changes, restart UFW with the command sudo systemctl restart ufw.

On Host β, check the status of UFW:

If you’re connected to Host β through SSH, add a rule to allow SSH access from the Site B LAN:

Next, add a rule to allow any host to connect to Host β via WireGuard (which is listening on UDP port 51822 on Host β):

Then add a rule to allow any host connected to Host β via WireGuard (wg0 is the name of the WireGuard interface on Host β) to use that connection to access the web server running on Endpoint B (listening on TCP port 80 of Endpoint B):

Note that for UFW rules like this, which allow the local host to forward packets from one external host to another, the rule starts with the route keyword (ufw route allow …​); whereas UFW rules that apply to packets directed at the local host itself, don’t (ufw allow …​).

Now start up UFW and check its status:

UFW is now up and running on Host β, and will prevent any connection to Host β other than through WireGuard (or directly through SSH from the Site B LAN, 192.168.200.0/24). Additionally, UFW will prevent Host β from being used to forward new connections between hosts, except through WireGuard to TCP port 80 of the web server running on Endpoint B (192.168.200.22).

You can test this out by trying to access Endpoint B’s TCP port 80 from Endpoint A:

You should see the HTML of Endpoint B’s homepage printed. If you start up another web server on Endpoint B running at TCP port 8080 (run python3 -m http.server 8080 for a temporary server serving the contents of the current directory), you won’t be able to access it from Endpoint A:

You won’t see anything printed for the above command (the command will “hang” — kill it by pressing the control-C key combination).

If you want the reverse of the above example, like the scenario described by the WireGuard Point to Site With Port Forwarding guide, which allows Endpoint B (in the local site) to connect to a web server on Endpoint A (the remote “point”), you would have to edit the /etc/ufw/before.rules file on Host β to allow port forwarding (also known as Destination Network Address Translation, or DNAT).

To enable port forwarding for this example, edit the *nat block in /etc/ufw/before.rules that we added above to also include the following PREROUTING lines:

Unlike the POSTROUTING rule, which applies to any packets forwarded out the Site B LAN interface on Host β, this PREROUTING rule (the line beginning -A PREROUTING -i …​) applies specifically to just this one example case, where we want to forward packets originally destined for TCP port 80 of Host β itself on to Endpoint A (10.0.0.1). For every additional port we want to forward on Host β, we’d have to add an additional PREROUTING rule to /etc/ufw/before.rules with the specific port to forward, and destination to forward it to.

We also have to add a separate UFW rule for each forwarded port. For this specific example, add a UFW rule on Host β to allow it to forward packets to TCP port 80 on Endpoint A (10.0.0.1):

Then restart UFW and check its status:

Test it by trying to access TCP port 80 on Host β from Endpoint B (Host β will now forward its TCP port 80 to Endpoint A):

You should see the HTML of Endpoint A’s homepage printed.

On Endpoint A, first check the status of UFW. If you haven’t set it up yet, this is what you’ll see:

Unless you’re connected to Endpoint A through SSH, the only thing you need to do on Endpoint A is just start up UFW. If you are connected to Endpoint A through SSH, however, first run the following command to continue to allow SSH access to Endpoint A from the Site A LAN (192.168.1.0/24 — a range that includes 192.168.1.0-192.168.1.255):

Now start up UFW and check its status:

So now UFW is up and running on Endpoint A, and will prevent any new inbound connections to Endpoint A (except through SSH directly from the Site A LAN). Endpoint A will still be able to make new outbound connections, however — like to initiate new connections to the web server running on Endpoint B.

On Endpoint B, check the status of UFW:

If you’re connected to Endpoint B through SSH, add a rule to allow SSH access from the Site B LAN:

Next, add a couple of rules to allow any host in either LAN (Site A or Site B) to connect to TCP port 80:

Now start up UFW and check its status:

UFW is now up and running on Endpoint B, and will only allow connections to TCP port 80 from the Site A and B LANs (or to TCP port 22 for SSH from the Site B LAN).

In the original WireGuard Site to Site Configuration guide, the “Configure Routing” section directs you to to add some lines to the WireGuard configuration of Host α and Host β to turn on IP forwarding. But since we’re using UFW, you can omit these lines from your WireGuard configuration, and instead edit the configuration of UFW.

On both Host α and Host β, edit the /etc/ufw/sysctl.conf file (as root) to uncomment the following lines:

If you already have UFW up and running before you make this change, restart UFW with the command sudo systemctl restart ufw.

On Host α, check the status of UFW:

If you’re connected to Host α through SSH, add a rule to allow SSH access from the Site A LAN:

Next, add a rule to allow any host to connect to Host α via WireGuard (which is listening on UDP port 51821 on Host α):

Then add a rule to allow new connections destined for Site B (192.168.200.0/24) through the WireGuard tunnel to Host β:

In our example scenario, the only cross-site connection we need to allow is the connection from Endpoint A to Endpoint B over HTTP. If that’s the only connection you actually need to enable, you could adjust the above rule in a number of different ways to make it more restrictive. Most restrictively, you could prevent any host in Site A other than Endpoint A from connecting to any host in Site B other than Endpoint B (and allow Endpoint A to connect only to TCP port 80 of Endpoint B):

Or you could allow any host in Site A to connect just to Endpoint B (but no other hosts in Site B) over HTTP (and no other ports):

Or you could allow just Endpoint A (but no other hosts from Site A) to connect to any host in Site B:

Alternatively, if you wanted a reverse of this connection, for example to allow one particular host in Site B (say an Endpoint BBB with IP address 192.168.200.123) to be able to connect to one particular host in Site A (say Endpoint AAA, a mail server with IP address 192.168.1.45, listening on TCP port 25), you could allow that one specific connection to be initiated from Site B to Site A with the following rule:

Or you could allow any host in Site B to access Endpoint AAA:

Or you could allow Endpoint BBB to access any host in Site A:

Or you could just allow any host in Site B to initiate connections to any host in Site A:

Note that for UFW rules like this, which allow the local host to forward packets from one external host to another, the rule starts with the route keyword (ufw route allow …​); whereas UFW rules that apply to packets directed at the local host itself, don’t (ufw allow …​).

Also note that UFW automatically adds firewall rules to allow forwarding packets back from already-established connections (like if Endpoint A sends an HTTP request to Endpoint B, the HTTP response back from Endpoint B to Endpoint A would be part of an established connection, and not count as a new connection). So you only need to set up UFW rules to allow (or disallow) the initiation of new connections between one host and another.

So if the only route rule we used from the above was the first one, ufw route allow to 192.168.200.0/24, it would enable any host in Site A to initiate a new connection to any host in Site B (eg allow a browser running on a host in Site A to make an HTTP request to a web server running on a host in Site B), but it wouldn’t allow any host in Site B to initiate a new connection to any host in Site A (eg wouldn’t allow a browser running on a host in Site B to make an HTTP request to a web server running on a host in Site A).

With that one route rule from above in place, let’s start up UFW and check its status:

UFW is now up and running on Host α, and will prevent direct connections to it other than through WireGuard (or through SSH from the Site A LAN). But it will still allow new connections to be forwarded from Site A to Site B (allowing Endpoint A to browse the web server running on Endpoint B) — just not from Site B to Site A (prohibiting random connections from being initiated from hosts in Site B to hosts in Site A).

On Host β, check the status of UFW:

If you’re connected to Host β through SSH, add a rule to allow SSH access from the Site B LAN:

Next, add a rule to allow any host to connect to Host β via WireGuard (which is listening on UDP port 51822 on Host β):

Then add a rule to allow new outgoing connections destined for Site A (192.168.1.0/24) through the WireGuard tunnel to Host α:

And correspondingly, add a rule to allow new incoming connections to Site B (192.168.200.0/24) from the WireGuard tunnel with Host α:

Now start up UFW and check its status:

UFW is now up and running on Host β, and will prevent direct connections to it other than through WireGuard (or through SSH from the Site B LAN). It will, however, allow any new connections to be forwarded from Site A to Site B, and vice versa.

You can test this out by trying to access Endpoint B’s TCP port 80 from Endpoint A:

You should see the HTML of Endpoint B’s homepage printed. If you start up another web server on Endpoint B running at TCP port 8080 (run python3 -m http.server 8080 for a temporary server serving the contents of the current directory), you won’t be able to access it from Endpoint A:

You won’t see anything printed for the above command (the command will “hang” — kill it by pressing the control-C key combination).

Similarly, if you start up a web server on Endpoint A (with python3 -m http.server 8080), you won’t be able to access it from Endpoint B:

Again, you won’t see anything printed. Only if you add additional UFW rules 1) to Endpoint A, to allow new connections to it (like sudo ufw allow proto tcp to any port 8080), and 2) to Host α, to allow new connections to be forwarded through to Site A (like ufw route allow to 192.168.1.0/24), would you be able to access the web server running on Endpoint A.

Tcpdump can be really helpful when troubleshooting firewall issues — you can use it to determine if packets are transiting in and out as expected from a given host. For example, with the Site to Site scenario, if you see no output when you try to connect from Endpoint A to Endpoint B (ie when running curl 192.168.200.22), try running the following command on each host on the path between Endpoint A and Endpoint B (ie Endpoint A, Host α, Host β, and Endpoint B):

While those commands are running, try connecting from Endpoint A to Endpoint B again. You should see each terminal running tcpdump print a series of lines that look like the following:

Lines with 192.168.1.11.36112 > 192.168.200.22.80 represent packets being sent to Endpoint B TCP port 80, and lines with 192.168.200.22.80 > 192.168.1.11.36112 represent packets being sent back from Endpoint B in response. If the tcpdump command on a host outputs only lines with the former, and none with the latter, it means only packets sent to Endpoint B are making it to the host — no packets on the return trip back from Endpoint B are. If the tcpdump command on a host doesn’t output anything, it means no packets are reaching the host, not even those on the first leg of the trip to Endpoint B.

If your UFW rules are not behaving an you expect, it may be the case that you also have other iptables rules in effect, outside of the rules that UFW generates. Try running sudo iptables-save to list all of your iptables rules.

This is what you should see with an empty UFW firewall (for UFW version 0.36):

Any rules not listed above (and not beginning with -A ufw) are not from UFW (unless you’ve made changes to the /etc/ufw/before.rules file, in which case you should see those changes in the output of iptables-save too).

Once you add UFW rules, you’ll see some additional iptables rules beginning with -A ufw-user-forward or -A ufw-user-input listed just above the bottom of the output (right above the lines beginning with -A ufw-user-limit). For example, in the Point to Point scenario, once you’ve configured UFW on Endpoint B, you’ll see the following additional lines listed when you run sudo iptables-save on Endpoint B:

As another example, with the Hub and Spoke scenario, once you’ve configured Host C, you’ll see the following additional lines when you run sudo iptables-save on Host C: