Feature request: tag incoming packets

Feature request: tag incoming packets

[Matthias Urlichs]

[-- Attachment #1: Type: text/plain, Size: 1152 bytes --]

Hello,

the problem: given a wireguard interface with many peers, all with
different network addresses and whatnot. I want to do ingress traffic
accounting and some special filtering.

Adding an incoming filter that re-classifies all incoming packets to its
customer account seems like a lot of superfluous work, and the whole
thing seems somewhat fragile.

It'd be way nicer if wireguard had a per-peer netfilter tag which it
would simply set on all incoming packets from that peer. Examining that
in my netfilter tables would then cause no superfluous CPU load, and
updates to peer status would be atomic and not risk colliding with other
processes' update of nftables.

--
-- Matthias Urlichs


--
Matthias Urlichs
Executive Principal Solution Architect (Linux)

noris network AG
Thomas-Mann-Straße 16-20
90471 Nürnberg
Deutschland

Tel +49 911 9352 1717
Fax +49 911 9352 100
Email matthias.urlichs@noris.de

noris network AG - Mehr Leistung als Standard
Vorstand: Ingo Kraupa (Vorsitzender), Joachim Astel, Stefan Keller, Florian Sippel
Vorsitzender des Aufsichtsrats: Stefan Schnabel - AG Nürnberg HRB 17689

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2816 bytes --]

Re: Feature request: tag incoming packets

[Jason A. Donenfeld]

There is no need for this and WireGuard was designed to avoid needing
something like this. The AllowedIPs binding gives you a mapping
between source IP and peer public key.

So, if you have on wg0:

PublicKey = ABCD
AllowedIPs = 192.168.33.99/32

Then you can safely have a netfilter rule that says:

iptables -A INPUT -i wg0 -s 192.168.33.99/32 -j ACCEPT

You only need to match two things: the wireguard interface and the
source IP. The strong binding to the public key is the primary
security property that WireGuard gives you via cryptokey routing.