Re: potentially disallowing IP fragmentation on wg packets, and handling routing loops better
Hi, Talking about my example with chained VPNs. It is a misconfiguration but not intentional, and no responsible administrator can solve this because client really has no way to tell a VPN provider what MTU he needs. Technically VP providers can make such interface for clients but none of four VPN providers I've tried during the last three years has this. Usually VPN providers just use a default ?wg-quick? MTU in their server configs. On the client side it is (2 local egress fragmentation), client knows both of the MTU values, but on the server side it already needs (3 path egress fragmentation). If I understand the terminology correctly. For a packet on the route: remote host -> VPN provider 1 -> VPN provider 2 -> client. An unecrypted packet comes form remote host, the VPN provider 1 just sends a bigger encrypted packet to the VPN provider 2 and even if it responds with ICMP Fragmentation Needed to the VPN provider 1, it will be ignored and would not be repeated in the unecrypted channel to remote host. So the remote host will never know why the packet was dropped and it will slow down PMTUD. How difficult it is and what security implications it will have if WireGuard do capture ICMP Fragmentation Needed responses and repeat them in unencrypted channel? On 07.06.2021 12:34, Jason A. Donenfeld wrote: Hey folks, There seems to be a bit of confusion about *which* stage of fragmentation would be affected by the proposal, so I drew some diagrams to help illustrate what I'm talking about. Please take a look: https://data.zx2c4.com/potential-wg-fragmentation-proposal.png 1) Ingress fragmentation would not be affected by this and is not relevant for this discussion. This is the case in which a computer gets a packet for forwarding out of the wireguard interface, and it's larger than the interface's mtu, so the computer fragments it before passing it onto that interface. I'm not suggesting any change in this behavior. 2) Local egress fragmentation WOULD be affected by this and is the most relevant thing in this discussion. In this case, a packet that gets encrypted and winds up being larger than the mtu of the interface that the encrypted packet will go out of gets fragmented. In this case, we could likely respond with an ICMP packet or similar in-path error. But keep in mind this whole situation is local: it usually will only happen out of misconfiguration. The best fix for the diagram I drew would be for the administrator to decrease the MTU of the wireguard interface to 1412. 3) Path egress fragmentation COULD be affected by this, but doesn't have to be. In this case, we simply set "don't fragment" on encrypted egress packets, which means they won't be fragmented by other computers along the path. So, of those concerned about this, which concerns are actually about (2) and (3)? Of those, which ones are about (2)? If you have concerns specifically about (2) that couldn't be fixed with reasonable system administration, I'd like to hear why and what the setup is that leads to that situation. As an aside, Roman asked about TTL. When tunneling, the outer packet header always must take the new TTL of the route to the tunnel endpoint, and not do anything with the potentially much smaller inner TTL. So with tunneling, you can't quite rely on the TTL to drop to zero as you'd wish. Hence, I'm interested in using the natural packet size expansion instead. Thanks for the discussion so far. I'm very interested to read clarifying points about applicability to case (2) (and to a lesser extent, about case (3)). Thanks, Jason
Re: potentially disallowing IP fragmentation on wg packets, and handling routing loops better
Hi, I've dig into the subject two years ago and only vague remember details. As far as I can recall there was a time when WireGuard set DF flag by default and there were two issues: 1) for security reasons WireGuard doesn't issue ICMP fragmentation required response in the unencrypted channel if an encrypted packed didn't fit and was dropped 2) there is no way client can tell the server of MTU limitation it has on its side Combining the two we have a situation in a chained wireguard VPN setup when MTU size is misconfigured on the server and the remote host wouldn't get any icmp to help with its PMTUD algorithm. The client can still set MSS in its TCP connection though. Again sorry if I missed or messed something, it was long ago and I don't remember details. On 06.06.2021 12:13, Jason A. Donenfeld wrote: Hi, WireGuard is an encrypted point-to-multipoint tunnel, where onion layering of packets via a single interface or multiple is a useful feature. This makes handling routing loops very hard to manage and detect. I'm considering changing and simplifying loop mitigation to a different strategy, but not without some discussion of its implications. Specifically the change would be to not allow IP fragmentation of the encrypted UDP packets. This way, in the case of a loop, eventually the packet size exceeds MTU, and it gets dropped: dumb and effective. Depending on how this discussion goes, a compromise would be to not allow fragmentation, but only for forwarded and kernel-generated packets, not not for locally generated userspace packets. That's more complex and I don't like it as much as just disallowing IP fragmentation all together. Pros: - It solves the routing loop problem very simply. - Usually when people are fragmenting packets like that, things become very, very slow anyway, and it'd be better to just stop working entirely, so that people adjust their MTU. - Is anybody actually relying on this? Cons: - Maybe people are running wireguard-over-gre-over-vxlan-over-l2tp-over-pppoe-over-god-knows-what-else, and this reduces the MTU to below 1280, yet they still want to put IPv6 through wireguard, and are willing to accept the performance implications. - Some people don't know how to fix their MTUs, and breaking rather than just becoming really slow isn't the best outcome there, maybe. - Maybe people are relying on this? Before anybody asks: we're not going to add a knob for this, simply by virtue of this being a decision with pros and cons. Please don't bring that up. I'd be very interested in opinions about this. Are there additional pros and cons? I know the matter has come up a few times on the list, mostly with people _wanting_ fragmentation (I've CCd a few people from those threads - Roman, I expect you to vigorously argue the pro-fragmentation stance ;-). but I'm not convinced the outcome of those threads was correct, other than, "yea, that's easy enough to enable." But on the other hand, maybe the cons are real enough we should rethink this. Please let me know thoughts and ideas. Thanks, Jason
Re: Ubuntu kernel >= 5.3.0-52.46 breaks DKMS build for wireguard-linux-compat >= 1.0.20200429, patch included
On 06.05.2020 19:22, Simon Deziel wrote: On 2020-05-05 12:03 a.m., Jason at zx2c4.com (Jason A. Donenfeld) wrote: Ahh, you're running -proposed, gotcha. So I guess I should wait until this hits the main repo. Any idea when they usually do that? The next kernel batch should land in -updates on May 18th. The detailed schedule is at https://kernel.ubuntu.com/ The broken kernel 5.3.0-53.47~18.04.1 was still pushed to 18.04 very recently, today or may be yesterday
Wireguard is broken by recent ubuntu 18.04 kernel update
The system is Ubuntu 18.04.4, and wireguard is broken in recent kernel update "5.3.0-53.47~18.04.1"... not sure why 18.04.1 is landed on 18.04.4 system # ip link add dev wg0 type wireguard Error: Unknown device type. And nothing is shown by "lsmod | grep wireguard' and "dmesg | grep wireguard" I've tried "apt install --reinstall wireguard" and "update-initramfs -u -k all" with no luck. Everything works fine with kernel 5.3.0-51
Re: [PATCH] Update Simplified Chinese translation
On 26.02.2020 6:59, Samuel Holland wrote: On 2/25/20 9:44 PM, Vasili Pupkin wrote: It seams that russian translation is very basic and not utilize quantity="two" and quantity="few" forms, without them some plurals reads odd. Do you need help fixing it or it is done on purpose? I don't think it was done on purpose; likely the translator was unaware of the additional options for quantity in tags. I am happy to merge patches improving the translation (which is really up to your judgement, since I don't speak any of these languages). Have you received the patch? ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: [PATCH] Update Simplified Chinese translation
On 26.02.2020 5:56, Samuel Holland wrote: On 2/25/20 2:13 AM, Eiji Tanioka wrote: Hi Samuel. I already translated in Japanese, but I didn't concern about plurals. Japanese doesn't have plurals, so does "values-ja/strings.xml" needs these fix? - remove plurals - add string resource that have same "name" attribute as plurals Resources that have tags in the untranslated XML should use in translations as well. However, the only tag inside them should be "other". (It should look like the Chinese translation did before this patch.) So the only thing to fix is removing the tags. It seams that russian translation is very basic and not utilize quantity="two" and quantity="few" forms, without them some plurals reads odd. Do you need help fixing it or it is done on purpose? ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Buggy MTU with Wireguard (attached pcapng)
The TCP connection MSS is set to 1460 bytes and also Don't fragment flag is set. The server selects this MSS as a frame size on its side and packet is dropped, probably. If you are using linux router try to use this command "iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu" or be careful to set MTU on all client machines adapters correctly. On 10.01.2020 1:05, alpha_one_x86 wrote: Hi, I have wireguard interface "veth", and my real interface "eth0". No bug with openvpn, but with wireguard on IPv4 for https, I have bug, see the attached file, the returned data is 3300byte, then Destination unreachable (Fragmentation needed). Bug into wireguard? How fix this? The ok.pcapng it's same https download do with openvpn. Cheers, ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: [PATCH] wg-quick: linux: add support for nft and prefer it
On 11.12.2019 1:09, Jason A. Donenfeld wrote: On Tue, Dec 10, 2019 at 11:03 PM Vasili Pupkin wrote: As far as I know both of them are maintained in the same repository and both use the same userspace library to interact with the kernel and down there all the rules are translated into BPF code which in turn is compiled into machine code by kernel BPF JIT compiler. "bpfilter" is a WIP, but that's not today how iptables or nftables work, at all. I'm not sure your statement about userspace is entirely correct either. May be it is a road map plan and there will be no difference in performance when it will be implemented then. I just recall an announcement somewhere so it is just a speculation from my side, sorry ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: [PATCH] wg-quick: linux: add support for nft and prefer it
On 10.12.2019 20:12, Roman Mamedov wrote: On Tue, 10 Dec 2019 17:54:49 +0100 "Jason A. Donenfeld" wrote: iptables rules and nftables rules can co-exist just fine, without any translation needed. Indeed if your iptables is symlinked to iptables-nft, then you'll insert nftables rules when you try to insert iptables rules, but it really doesn't matter much either way (AFAIK). I figured I'd prefer nftables over iptables if available because I presume, without any metrics, that nftables is probably faster and slicker or something. nftables is slower than iptables across pretty much every metric[1][2]. It only wins where a pathological case is used for the iptables counterpart (e.g. tons of single IPs as individual rules and without ipset). It is a disaster that it is purported to be the iptables replacement, just for the syntax and non-essential whistles such as updating rules in place or something. And personally I don't prefer the new syntax either. It's the systemd and pulseaudio story all over again, where something more convoluted, less reliable and of lower quality is passed for a replacement of stuff that actually worked, but was deemed "unsexy" and arbitrarly declared as deprecated. [1] http://www.diva-portal.org/smash/get/diva2:1212650/FULLTEXT01.pdf [2] https://developers.redhat.com/blog/2017/04/11/benchmarking-nftables/ As far as I know both of them are maintained in the same repository and both use the same userspace library to interact with the kernel and down there all the rules are translated into BPF code which in turn is compiled into machine code by kernel BPF JIT compiler. So identical rules should show exactly the same performance. nft syntax is odd and its curvy braces aren't easy to pass in command line, it is more difficult to delete rules from nft table, but it also allows to arrange rules into separate chains easier and also provide a native way to define sets which are then processed very efficiently as seen in [2]. Anyway netfilter infrastructure developers have chosen nft as replacement to iptables and it will slowly phase it out, but this will be a very slow process and it is already going for 10 years now, everything is written in iptables. I don't see a big problem. Just choose any of the console command present on the system and print warning if neither of them is found. wg-quick shows its log in console and these rules will not cause any problems in most setups anyway. If this is such an issue then it can be opted by a command line argument (i.e. use iptables, nft or none) but it is already an overshoot. Personally I don't even think that the issue should be fixed in wireguard. The weak host model affects any other network setups and all the other vpn's just as wireguard and even if wg-quick patch it somehow for wireguard interface the end system will still be open to attacks on other interfaces. The strong host model should be chosen as default by kernel developers or configured system wide by an administrator. Also.. what about other systems, windows, android etc? ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: [PATCH] wg-quick: linux: add support for nft and prefer it
On 10.12.2019 18:48, Jason A. Donenfeld wrote: restore '%s-I PREROUTING ! -i %s -d %s -m addrtype ! --src-type LOCAL -j DROP nftcmd '%sadd rule %s %s preraw iifname != %s %s daddr %s fib saddr type != local drop I am trying to understand the rulesets. When you check the type of the source address of the incoming packet its type just can't be local to our machine, it is the address of the sender. The source address of the packet can only be local if the packet was sent from the same machine. Isn't this part of the rule redundant? ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Regarding "Inferring and hijacking VPN-tunneled TCP connections"
On 06.12.2019 18:18, Jason A. Donenfeld wrote: But for the sake of wg-quick the filter can be enables for wireguard interface only to be sure it wouldn't break anything else How do you propose this works? That'd require adding -d, right? In that case we're back to more or less the original rule. If you do it with -i, then it fails to filter the bad packets that we want to be filtering. Actually it appears to be harder than I first think The -d option will let broadcast addresses to pass the rule. Is it a problem here? In the original bulletin authors talk about TCP. Testing for interface name doesn't make much sense either, as you said... ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Regarding "Inferring and hijacking VPN-tunneled TCP connections"
On 06.12.2019 19:12, Jordan Glover wrote:
But nft rule won't be visible from iptables tools like iptables-save,
right? This may be confusing for people who still use iptables for
setting up firewall on their systems.
Right. And for those using NFT, they will see a strange rule in their
default inet filter table. Also nft users may delete this table or its
input chain or alter the chain hook specification before calling
wg-quick and in this case the magic command will crash. So it should be
added to wireguard specific table instead of inet filter and this is
actually the only easy way to revert the ruleset in nft, you should
delete your table to revert the changes.
nft add table inet $table
nft add chain inet $table input {' type filter hook input priority 0;
policy accept; '}
nft add rule inet $table input fib daddr . iif type != { local,
broadcast, multicast } drop
and then:
nft delete table inet $table
when we are done.
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Regarding "Inferring and hijacking VPN-tunneled TCP connections"
On 06.12.2019 18:08, Jason A. Donenfeld wrote: On Fri, Dec 6, 2019 at 4:06 PM Jordan Glover wrote: On Thursday, December 5, 2019 8:24 PM, Jason A. Donenfeld wrote: If we can make nft coexistance work reliably, perhaps we can run the nft rule on systems where the nft binary simply exists. Will this work correctly on systems where nft binary exist but only iptables rules are used? That's what I meant by, "if we can make nft coexistance work reliably." Take a look at the table on the bottom of this page https://wiki.nftables.org/wiki-nftables/index.php/Troubleshooting#Question_4._How_do_nftables_and_iptables_interact_when_used_on_the_same_system.3F On my system their rules coexist fine. Both nftables and iptables are just high level interfaces to kernel netfilter hooks after all, if either of them drop the packet then the packet is dropped. It is also possible to write the same filter using iptables, not as easy and not as beautiful as nft though. Finally wireguard can do this directly interacting with netfilter as the last resort. I'd like if kernel developers reconsider the default system behavior on this... It is so stupid that the system expose all its IPs on all interfaces by default. But Linus don't like patches that break things and this will break some bad network setups, yes weak and insecure but still. ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Regarding "Inferring and hijacking VPN-tunneled TCP connections"
On 05.12.2019 23:24, Jason A. Donenfeld wrote:
Hey Vasili,
On Thu, Dec 5, 2019 at 8:50 PM Vasili Pupkin wrote:
Isn't it enough to just enforce Strong Host Model, i.e. a host won't
respond from it's IP that is not facing the interface. If a host is
connected to two subnets 10.1.x.x and 10.2.x.x and have two IP 10.1.0.1
and 10.2.0.1, it will just drop all the packets sent to 10.1.0.1 that
came from the interface 10.2.0.1 and vice verse. This model can be
emulated using the FIB lookup feature of NFT with this one liner:
nft add rule inet filter input fib daddr . iif type != { local,
broadcast, multicast } drop
this also works for both IP4 and IP6. This mode can be safely enabled on
most setups not breaking things. Enabling it is a good precaution
measure anyway and it is a shame that it is not widely assumed as
default and standard.
Doing the same with just iptables isn't easy and can't be accomplished
with one liner but nft perfectly coexist with iptables.
That actually appears to work pretty well in my quick bootleg setup.
Thanks. I'm adding William to the email chain -- perhaps he can try
this and report back with his attack rig?
If we can make nft coexistance work reliably, perhaps we can run the
nft rule on systems where the nft binary simply exists.
For cleanup, we'll need some way of marking that rule as belonging to
wg-quick(8) for our interface. The iptables magic currently uses
--comment for that.
There's also the issue with nft not having default table and chain
names. Perhaps it'd be cleanest to just ad a new table and chain with
a given name, and set that as a high priority input hook?
We'll also probably want to make this only apply to our interface, and
not others, if that's possible.
Any downsides I'm overlooking?
William -- you might want to subscribe to follow along better:
https://lists.zx2c4.com/pipermail/wireguard/2019-December/004679.html
https://lists.zx2c4.com/mailman/listinfo/wireguard
I've just figured out that the same effect can also be achieved with
iptables:
iptables -t filter -I INPUT -m addrtype --limit-iface-in ! --dst-type
LOCAL -j DROP
So it is very similar to your solution. It is not exactly the same to
nft oneliner, because it drops multicast and broadcast packets, this can
probably be fixed though the multiple -j jumps, I am not an expert in
this though:
iptables -t filter -N NOTLOCAL
iptables -t filter -I INPUT -m addrtype --limit-iface-in ! --dst-type
LOCAL -j NOTLOCAL
iptables -t filter -I NOTLOCAL -m addrtype --limit-iface-in ! --dst-type
MULTICAST -j DROP
It should also be dubbed with ip6tables command to also filter IP6 packets.
There can possibly be systems where only nftables is installed and there
is no iptables though.
In any case you can limit it to just one wireguard interface. It is a
good precaution measure to enable it systemwide and rule out the
CVE-2019-14899 completely and many other possible attacks. The weak host
model used in linux by default is literally weak and a good system
administrator should avoid it by all means. But for the sake of wg-quick
the filter can be enables for wireguard interface only to be sure it
wouldn't break anything else and in this case you can probably also
ignore multicasts and broadcasts.
One can possibly has a sophisticated firewall rule that only accept some
packets and his firewall will unintentionally dodge packets around our
rules and I don't see how this can be avoided.
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Regarding "Inferring and hijacking VPN-tunneled TCP connections"
Isn't it enough to just enforce Strong Host Model, i.e. a host won't
respond from it's IP that is not facing the interface. If a host is
connected to two subnets 10.1.x.x and 10.2.x.x and have two IP 10.1.0.1
and 10.2.0.1, it will just drop all the packets sent to 10.1.0.1 that
came from the interface 10.2.0.1 and vice verse. This model can be
emulated using the FIB lookup feature of NFT with this one liner:
nft add rule inet filter input fib daddr . iif type != { local,
broadcast, multicast } drop
this also works for both IP4 and IP6. This mode can be safely enabled on
most setups not breaking things. Enabling it is a good precaution
measure anyway and it is a shame that it is not widely assumed as
default and standard.
Doing the same with just iptables isn't easy and can't be accomplished
with one liner but nft perfectly coexist with iptables.
On 05.12.2019 22:13, Jason A. Donenfeld wrote:
Hey folks,
William unembargoed his nice vuln this week:
https://seclists.org/oss-sec/2019/q4/122
It appears to affect basically most common unix network stacks. This
isn't a WireGuard vulnerability, but rather something in the routing
table code and/or TCP code on affected operating systems. However, it
does affect us, since WireGuard exists on those affected OSes.
Some might chalk it up to just a configuration error, dismissing it as,
"well, if you configure your networking stack poorly, bad things will
happen," but I don't really buy that: the network setups affected by
this vulnerability are pretty much the norm everywhere.
And it turns out that we actually are in the business of properly
configuring people's networking stacks. Specifically, the tools we ship
come with the little bash script, wg-quick(8), which is a popular way of
automating some common tasks. We've started looking at kernel-level
mitigations within the Linux networking stack, but before those are
ready, I thought it would be prudent to put some first-level defenses
into wg-quick(8) itself.
For that reason, since November, wg-quick(8) has added a few iptables(8)
rules. I really dislike having wg-quick(8) grow any sort of dependency
on iptables(8) (and eventually on nftables(8)), but at the moment, I
don't see a viable alternative. Suggestions are welcome. In particular,
we're adding a rule that is something like:
iptables -t raw -I PREROUTING ! -i wg0 -d 10.182.12.8 -m addrtype !
--src-type LOCAL -j DROP
where wg0 is the WireGuard interface and 10.182.12.8 is the local IP of
the interface.
This says to drop all packets that are sent to that IP address that
aren't coming from the WireGuard interface. And it's done very early in
Netfilter, in the "raw" table. The researchers have confirmed that this
mitigates the issue.
Adding iptables(8) into wg-quick(8) has been predictably problematic,
and it'll probably be at least another snapshot until we get things
bug-free on all the different variations of the utility that distros
ship, but we'll get there. In the meantime, I'd certainly appreciate
patches to do the same with nftables(8), as well as some fresh thoughts
on how to accomplish this same thing _without_ the firewall. (In the
process of writing this email, for example, I had an idea regarding
ip-rule(8) that might work out, but I haven't tried yet.) We also have
some non-Linux operating systems to consider.
Feedback welcome.
Regards,
Jason
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
Tun interface do not route packets on Windows 7 (extended no-NAT)
In my setup I have a client running Win7, the tun interface allows to make connection from client to server but it only route packets back for some time and then broke. The client system is NOT behind the NAT and PersistentKeepalive=25 do not help, the issue is local and external network route encrypted packets as expected. Have tested it with wireshark. I have checked the tun adapter with RawCap tool (wireshark do not let you monitor tun interface on Win7) and decrypted packets sent by the server actually generated inside the tun interface on the client but aren't routed to the process nor processed any further, they stuck on OSI level 3. If I then ping server from client the tun interface revives but broke again after like 30 seconds of silence. The support for Win7 will be dropped later this year but it is still rather popular OS among users. ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Linux kernel 5 different behavior
On Mon, Aug 26, 2019 at 5:09 AM Jason A. Donenfeld wrote: > > Usage of fwmark is my current workaround. If the same user id of an > > outer packets is not a bug then ignore it. > > I can see arguments both ways. Do you recall off hand the last kernel > version that had the prior behavior? I'd like to try to find the > commit and read the rationale upstream. I see the difference now between 4.18.0 and 5.0.0 kernels, the closest I can get with readily compiled kernels on my distro. According to `iptables -t mangle -A OUTPUT -j LOG --log-uid` on kernel 4.18 outer packets have UID=0 if original packets were sent from system processes and do not have associated UID at all if original packets were sent by the user. On kernel 5.0 they always inherit UID. ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Linux kernel 5 different behavior
Usage of fwmark is my current workaround. If the same user id of an outer packets is not a bug then ignore it. On Sun, Aug 25, 2019 at 10:07 PM Jason A. Donenfeld wrote: > > On Sun, Aug 25, 2019 at 1:03 PM Vasili Pupkin wrote: > > Yes. On kernel version 4, outer packets (i.e. encrypted packets) are > > sent from privileged user > > account credentials so they pass the iptables sandbox. On kernel 5 > > they inherit owner id of the user who sent unencrypted packets. > > Can you use the `fwmark` option and adjust your rules to match on > !1234 or the like? ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Linux kernel 5 different behavior
Yes. On kernel version 4, outer packets (i.e. encrypted packets) are sent from privileged user account credentials so they pass the iptables sandbox. On kernel 5 they inherit owner id of the user who sent unencrypted packets. . On Sun, Aug 25, 2019 at 9:52 PM Jason A. Donenfeld wrote: > > Could you clarify? Do you mean that inner and outer packets were > marked differently in Linux < 5 but are now marked as belonging to the > same UID in Linux==5? ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Linux kernel 5 different behavior
In the newest kernel version, Wireguard encrypted packets are sent from the same user credentials as the user that created original packets. I have a firewall setup that limits programs run from a particular user to wireguard tun interface, it worked in kernel 4.18 and is broken in kernel 5.0. In the new kernel encrypted packets are also marked as owned by this user and routed to the tun interface generating a recursion. ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
