Regarding the firewall rules added by wg-quick (on Linux)
Tom Yan
tom.ty89 at gmail.com
Fri Jun 17 16:13:25 UTC 2022
Hi all
I have a few doubts on the firewall rules added by wg-quick.
First of all, is there a reason that the fwmark-restoring rule is
unconditional? Shouldn't it consist of a connmark match (like the
fwmark-saving rule does on the fwmark)?
The next one is, what is the remaining rule intended to prevent
exactly? From the commit message the purpose seems to be "bogus
injected packets". I mean, was that referring to the fact that Linux
does not have a strong address/interface binding concept, that
normally / by default you can reach a host using IP assigned on any of
its interfaces, regardless of whether the interface is the one
connecting it the source host? And if so, is there wireguard-specific
security implication in it that has led to the introduction of the
rule?
Although I'm not entirely clear on its purpose yet, allow me to also
suggest in this email that perhaps we can use something like this
instead for nft:
ip daddr $WG_ADDRESS iifname != { "lo", "$WG_INTERFACE" } drop
Alternatively, if it is desired that the rules used for nft and
iptables should be more "coherent" to each other, allow me to also
suggest something like this:
-d $WG_ADDRESS ! -i lo -m addrtype ! --dst-type LOCAL --limit-iface-in -j DROP
which should be equivalent, AFAICT, to this in nft:
ip daddr $WG_ADDRESS iifname != "lo" fib daddr . iif type != local drop
Although it's very unlikely that it can be an issue in reality, it at
least seems to me that --src-type LOCAL does not necessarily imply -i
lo. I mean like while the replies could hardly go back to the
"original" / initiating host, but some host could actually send
packets with a source address that is a LOCAL address of this host,
and I don't suppose ! --src-type LOCAL will help filter those.
Sorry if this is all a bit too much of a "niche".
Regards,
Tom
More information about the WireGuard
mailing list