I'm locking down the egress of my Linux box, making OUTPUT chain default deny.
My wireguard peers are from the subnet 10.1.0.0/16
. Originally I thought I can just -A OUTPUT -d 10.1.0.0/16 -j ACCEPT
, and while that is needed, it is not sufficient in itself.
As confirmed by tracing, the physical UDP connection to the wireguard peer also needs allowing, which makes sense on second thought.
Now, I could go on and manually allow the wireguard port of the peer endpoints. But I wonder if there's some more automatic mechanism, that would relate the physical UDP packets to the already allowed tunnel packet, and automatically allow it?
WireGuard provides the means to handle this with iptables: by setting a firewall mark on the outgoing envelope packets. This is available through the low level
wg
command and thus also available withwg-quick
:wg-quick
provides an example to be used inPostUp
:For this problem's use case (which has an inverted logic since using a default drop policy and doesn't require to distinguish the local case) that would be something like this in the configuration file:
Or this rule can be added outside of WireGuard's configuration, probably using directly the WireGuard interface name (eg:
wg0
) instead of%i
and the firewall mark value 0xcafe in the rule rather than querying the value from WireGuard.If the peer roams, the rule will still be able to track it for outgoing envelope packets.
If, by "physical UDP" you mean traffic to the peer outside of the VPN tunnel then, no. While it is possible to associate traffic on different ports to the same address via iptables (port-knocking is a good example) in this case, the traffic flows inside and outside the tunnel are going to different IP addresses.