Wg-quick Default Firewall Rules

These firewall rules are added to supplement the routes and policy rules that wg-quick adds to use the WireGuard interface for the default route (below shown for IPv4; for IPv6, wg-quick does the exact same thing but with IPv6 flags and addresses):

The first line above sets up a custom routing table, number 51820, and sets the default route for the table to use the wg0 interface. The second line adds a routing policy rule to use this new custom table for all packets that don’t have a mark (aka fwmark) of 51820.

In this “default route” mode, wg-quck also automatically configures WireGuard to add a mark of 51820 (0xca6c in hex) to all the encrypted packets it sends out, so this policy rule will apply to all packets that have not yet been processed by the WireGuard interface. (You can customize this mark to use a value other than 51820 via the FwMark setting on the interface’s config.)

The third line from above adds a routing policy rule to use the existing main routing table for everything except the default route. Because neither of the above policy rules has a specified priority, the rule from the third line is actually executed before the one from the second — so all routes in the main table, except for the default route, will continue to be used.

So the combination of these three lines switch the system from using the its primary physical network interface as the default route, to using the WireGuard interface instead.

So what do these firewall rules do? The first nftables rule prevents routing loops (and other hijinks) with packets sent directly to the WireGuard interface’s address from an external source other than through the WireGuard interface itself. In nftables, it’s applied via the prerouting hook of a custom filter chain, at the raw (-300) step (before connection tracking is applied):

This is the iptables equivalent (listed third in iptables rules from above):

In the above example, our WireGuard interface is wg0, and its address is 10.0.0.1. The destination address of a packet usually should be the WireGuard interface’s own address only if the packet itself just came through the WireGuard tunnel. If it came from some other source (not including the system itself), it can be safely dropped, since it’s either an accident or an attack.

If it’s not dropped, and the packet’s source is not included in one of the routes from the system’s main table, then any reply to the original packet (like an ICMP port-unreachable reply) would be sent through the WireGuard tunnel instead of back out the same interface from which the original packet came (thus potentially creating loops or other mischief).

The second and third nftables rules work in concert to copy the mark that WireGuard sets on outbound packets over to the inbound replies to those packets. The third rule listed actually is executed first in this sequence, so we’ll look at it first. In nftables, it’s applied via the postrouting hook of a custom filter chain, at the mangle (-150) step (after connection tracking, but before address translation):

This is the iptables equivalent (listed second in the iptables rules from above):

0xca6c is hex for 51820, so this rule copies the packet mark (aka “fwmark”) to the connection-tracking mark (aka “connmark”) for outgoing UDP packets that already have a packet mark of 51820. These marks are just arbitrary 32-bit values that have no predefined meaning to the system — they’re intended for use by sysadmins to write firewall and routing rules that track individual packets, or two-way connections, through different points in the system. The packet mark applies to just a single packet; whereas the connection-tracking mark applies to all packets tracked as part of a particular two-way connection.

The second nftables rule copies the connection-tracking mark on incoming UDP packets back to the packet mark. In nftables, it’s applied via the prerouting hook of a custom filter chain, at the mangle (-150) step (after connection tracking, before address translation):

This is the iptables equivalent (listed first in the iptables rules from above):

Copying the original mark from outgoing WireGuard packets to their inbound replies (and turning on the net.ipv4.conf.all.src_valid_mark sysctl parameter) prevents the ip -4 rule add not fwmark 51820 table 51820 policy rule that we discussed above from breaking reverse-path routing lookups on those inbound packets. This is particularly important if you have strict reverse-path filtering turned on for your system (as it would otherwise drop all inbound packets to your system).

You can check whether you have reverse-path filtering turned on with the following command:

A value of 1 is strict filtering (drop packets if the reverse path doesn’t match the forward path); a value of 2 is loose filtering (drop packets only if the reverse path isn’t reachable); and a value of 0 is no filtering.

To prevent wg-quick from adding any firewall rules — as well as any routes and policy rules — configure the interface’s Table setting to off:

You could alternatively configure wg-quick to set up the default route in a custom routing table without setting up any firewall rules or policy rules; in that case, configure Table to the number or name of the table (like Table = 123 or Table = foo). Note that if you use a name for the table, you must first manually add the number-to-name mapping for it to the /etc/iproute2/rt_tables config file:

If you disable these defaults, you will need to implement your own routes or policy rules. See the Routing All Your Traffic section of Routing guide on the WireGuard site for a few simple alternatives. Also see the How to Use WireGuard With Nftables or WireGuard Access Control With Iptables articles on this site for guides on how to set up firewall rules for WireGuard.