Re: Reflections on WireGuard Design Goals
On Fri, Aug 10, 2018, 3:16 PM em12345 wrote: > Hi, > > > From my point of view, the only thing which makes me uncomfortable about > > wireguard is the lack of any second authentication factor. Your private > > key is embedded in a plaintext file in your device (e.g. laptop), not > > even protected with a passphrase. > > Most VPN authentications are just authorizing the machine and not the > user sitting in front of that machine. > > > Anyone who gains access to that > > laptop is able to establish wireguard connections. > > > > Of course, it can be argued that the laptop holds other information > > which is more valuable that the wireguard key, therefore you should > > concentrate on properly securing the laptop itself (*). Furthermore, > > No matter how much keys, passwords or tokens have to be entered by the > user sitting in front of that machine, any other user already on that > machine, will gain sooner or later access to the tunnel. This user or > attacker doesn't even need to see/know wireguard's private key nor does > the attacker need root access. Think of a second user logged in on that > machine. > > It is definitely a bad idea to assume that the tunnel traffic of one > "client" (in terms of wg's client key pair) comes from a specific user. > Which also means that even multi factor VPN authentication still require > all services inside the tunnel to ask for user authentication. > It should me noted that it is possible to isolate the VPN access to a specific user if you assign login sessions to isolated network namespaces and place the wireguard interface within the user's namespace. -Reuben > ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Reflections on WireGuard Design Goals
Hello together, > In the absence of that, it would be nice if the private key which is > stored on the laptop were encrypted with a passphrase. Simplest option > may be to extend wg-quick so that the entire config file can be > pgp-encrypted. one can already do that via the wg-quick PostUp hook, check out the Arch Linux wiki: https://wiki.archlinux.org/index.php/ WireGuard#Store_private_keys_in_encrypted_form The example is using pass, switching it for direct GPG (or keepassxc or anything, really) should be easily possible. Considering that possibility, I don't think adding GnuPG directly into Wireguard would be a good idea. It would just add complexity for little to no benefit. Greetings, NIcolas Lenz ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Fedora package: missing the make dependency
I am sure I am using Fedora Server 28 (not rawhide). I installed a same version (Fedora Server 28 x64, with the default software selection) on VirtualBox just now, updated all dependencies (sudo dnf update), and then installed Wireguard. Same problem occurred. On Fri, Aug 10, 2018 at 10:17 AM Jason A. Donenfeld wrote: > That's pretty strange. Are you using rawhide or something where maybe > they've temporarily broken the devel packages? > ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Reflections on WireGuard Design Goals
Hi, > From my point of view, the only thing which makes me uncomfortable about > wireguard is the lack of any second authentication factor. Your private > key is embedded in a plaintext file in your device (e.g. laptop), not > even protected with a passphrase. Most VPN authentications are just authorizing the machine and not the user sitting in front of that machine. > Anyone who gains access to that > laptop is able to establish wireguard connections. > > Of course, it can be argued that the laptop holds other information > which is more valuable that the wireguard key, therefore you should > concentrate on properly securing the laptop itself (*). Furthermore, No matter how much keys, passwords or tokens have to be entered by the user sitting in front of that machine, any other user already on that machine, will gain sooner or later access to the tunnel. This user or attacker doesn't even need to see/know wireguard's private key nor does the attacker need root access. Think of a second user logged in on that machine. It is definitely a bad idea to assume that the tunnel traffic of one "client" (in terms of wg's client key pair) comes from a specific user. Which also means that even multi factor VPN authentication still require all services inside the tunnel to ask for user authentication. Emmanuel ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Reflections on WireGuard Design Goals
> > On 10/08/18 16:40, jungle Boogie wrote: >> If someone already has my ssh key, I'd revoke it - regardless if >> they had the password or not. Same with the WG key - shutdown the >> tunnel, remove the affected peer and start it back up. > > No need to interrupt the tunnel. > > # wg set peer remove > Dang, that's cool! That's for the info. ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Reflections on WireGuard Design Goals
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10/08/18 16:40, jungle Boogie wrote: > If someone already has my ssh key, I'd revoke it - regardless if > they had the password or not. Same with the WG key - shutdown the > tunnel, remove the affected peer and start it back up. No need to interrupt the tunnel. # wg set peer remove -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCgAdFiEEYKVBwe43zZh/jkxPivBzdIirMBIFAlttx3oACgkQivBzdIir MBJTWw//dL9Te/8nfr18EQQEmWXRqgS7A6QrXh5lrAjTlHAHuzbfM2sp+mt5ML50 fmEHlsVHZqM4rG4l1+KiSrUb6n7hlzoCO2bwh36U/tdysXgf20vM9XN4vyhvWMbN eOB6CNHfso02uMzx4TCAaK2ZcWnsqh1LvXceVwMQdJ6+E2FDpu637TYEiWJyIDPv u/q5Qq+qZspFiqDTpAJ/scdLq+4AxnzeELs/OblfRYbvE+Hkc9VsunxXJImXvcKx cN1NldPxwR+a4fWTvKgIqVReIKEggDl4OzYZk+wipFLRwQWASYW3aYQ+UeQEaUHa TQqkfZ6PqvivKLPC+Ih3DVHYd4Xa4t+zC/gVtQYgAauhqcqtpH1Y0ZISohIR9x/t 2GMxOZPg7Q6x05qf0bKdWPgdH+lcENW1HYEhj/cWrKaCAoKgKOnGsfgUNEdvRXMb i/RiLnJ5NH07sg4C/QRdVOXxx/TwBoEZPvgXUsxteadBc77LLOR4ERNVZ4zQrvhv JhhLeckOL9dmywPuvvO4sc/cOZCvb2kaYSDD1Tn4iJaqWZwWdA8HNnGyBnl14mMF 9ER5qzSA0L9QRDXhyBkv1+ekDmshBnpyj6PN7kBJ5cl9WVZXLjIsUWcte9YXfbIM MqwqhoGBdF0n5T41OP0zt4vT1DWLF9pGsOiUUq7GahpIXp1mPMo= =T+rR -END PGP SIGNATURE- ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Reflections on WireGuard Design Goals
On 10 August 2018 at 09:03, Brian Candler wrote: > On 10/08/2018 16:03, Roman Mamedov wrote: > > But I'd feel a lot happier if a second level of authentication were > required to establish a wireguard connection, if no packets had been > flowing for more than a configurable amount of time - say, an hour. It > would give some comfort around lost/stolen devices. > > Couldn't you just encrypt your home directory? Or even the root FS entirely. > Either of those should be a must on a portable device storing valuable > information. > > But by analogy, would you say that SSH keys and PGP keys don't need > protection by a passphrase? > If someone already has my ssh key, I'd revoke it - regardless if they had the password or not. Same with the WG key - shutdown the tunnel, remove the affected peer and start it back up. ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Reflections on WireGuard Design Goals
On Fri, 10 Aug 2018, 19:04 Brian Candler, wrote: > On 10/08/2018 16:03, Roman Mamedov wrote: > > But I'd feel a lot happier if a second level of authentication were > required to establish a wireguard connection, if no packets had been > flowing for more than a configurable amount of time - say, an hour. It > would give some comfort around lost/stolen devices. > > Couldn't you just encrypt your home directory? Or even the root FS entirely. > Either of those should be a must on a portable device storing valuable > information. > > But by analogy, would you say that SSH keys and PGP keys don't need > protection by a passphrase? > Yes, I will say so. I (almost) never use it, it is either too unsecure yet cumbersome, so I use separate devices (nFA), encrypted FS, etc. where needed. Or nothing at all. Kalin. ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Reflections on WireGuard Design Goals
On 10/08/2018 16:03, Roman Mamedov wrote: But I'd feel a lot happier if a second level of authentication were required to establish a wireguard connection, if no packets had been flowing for more than a configurable amount of time - say, an hour. It would give some comfort around lost/stolen devices. Couldn't you just encrypt your home directory? Or even the root FS entirely. Either of those should be a must on a portable device storing valuable information. But by analogy, would you say that SSH keys and PGP keys don't need protection by a passphrase? ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Reflections on WireGuard Design Goals
hello, just to say you, as a simple end user we are using wireguard since one year for our product, we have 10K tunnels deployed , wireguard is perfect for us, very simple, we can develop our specific code on top of if ( key management , ) so +1 for jason vision thanks for this piece of code Regards, Nicolas Le jeu. 9 août 2018 à 23:52, Jason A. Donenfeld a écrit : > > Hey list, > > For whatever reason, in the last several weeks, WireGuard been receiving a > considerable amount of attention, and with that comes various parties > interested in the project moving in this direction or in that direction. And > more generally, over the last year or so, we've seen a decent amount of > interest from different folks wanting to do different things with the project > and with the protocol. This inevitably leads to the question: what do we > actually want WireGuard to be, as a project, as a protocol, as a set of > implementations, as a design methodology, and so forth? I've had a pretty > clear idea about that, but I don't think I've ever tried to communicate > aspects of it in this context, so I thought here I'd highlight two important > design goals that motivate us. > > Firstly, WireGuard intends on continuing to have a minimal core, without a lot > of options and wild features and support for weird networking paradigms. Sure, > we want the core to be sufficiently flexible that you can build interesting > and complex things on top of it, but we don't want WireGuard itself to be > complicated. We enjoy our small understandable configuration files, an > interface that appears to be mostly stateless, and general ease of use. Even > from a cryptography and implementation perspective, the protocol is designed > to be implementable using simple algorithms and coding techniques. > > With that kind of minimalism naturally comes the temptation to add things. > Simply from the perspective of an interested engineer, it's appealing to > extend and hack on small manageable codebases and projects, since adding a > single feature here or there just isn't that hard. And after all, if you're > *just* adding *one* feature, it's only one, and that's not so bad, right? And > what about one more? This kind of temptation applies equally to features > inside implementations as it does to features inside the protocol. And I think > this temptation is a little bit dangerous, both because it's an obvious > slippery slope to bloat ("just one more feature can't hurt, right guys?"), and > because while individual features or protocol enhancements might be well > thought-out, it's often hard to think through them in the context of a fuller > system. > > Secondly, WireGuard is engineered slowly and carefully. It is a conservative > project. Programming is fun, and so I understand the appeal to, "move fast and > break things," or to ship new code hastily. Personally I've written plenty of > such codebases, and that's usually fun and exciting. Except WireGuard is > deeply security-oriented. Of course there will inevitably be scary bugs we > weren't able to prevent, but we're moving slow and carefully to try to > mitigate those to the fullest extent we can. We want each of the > implementations released by the WireGuard project to be secure, high assurance > software. > > This means that although you can probably get something mostly "working" in a > fairly short amount of time (an initial version of WireGuard took me > essentially a weekend), we're trying very hard not to throw junk over the > fence. Rather, we're doing pretty regular code reviews and have received some > great feedback from some scary-talented security researchers, and we expect > for this to continue. But indeed not all programmers share this perspective – > for a wide variety of motivations, both benign and opportunistic – and so we > definitely will (and have, in fact, already) see folks making things related > to WireGuard who don't share this type of methodology. > > Now I don't think these two motivating principles are particularly unique or > innovative. Other security-focused projects, like OpenBSD for example, seem to > be made of a somewhat similar mold. But these also certainly are not the > _norm_ for most projects out there. And as WireGuard accelerates in usage, I > expect we'll be facing this from a few angles: > > - Attempts at commercialization: There are many businesses who want to embrace > WireGuard and extend it in some particular direction or another, in order to > build products or sell services or the usual array of business > opportunities. Engineers working in these contexts often times are tempted > to extend minimal things in grotesque ways, and to push them to market with > deadlines unfavorable to high assurance methodologies. It's naturally and > understandably in the interest of businesses to attempt to steer the > WireGuard project in directions aligned with their goals, or even directly > hire WireGuard developers away from
Re: Reflections on WireGuard Design Goals
On Fri, 10 Aug 2018 14:35:14 +0100 Brian Candler wrote: > From my point of view, the only thing which makes me uncomfortable > about wireguard is the lack of any second authentication factor. Your > private key is embedded in a plaintext file in your device (e.g. > laptop), not even protected with a passphrase. Anyone who gains access > to that laptop is able to establish wireguard connections. > > Of course, it can be argued that the laptop holds other information > which is more valuable that the wireguard key, therefore you should > concentrate on properly securing the laptop itself (*). Furthermore, to > be able to talk to the wireguard kernel module you're already root, and > therefore have all sorts of malicious options available to you. etc etc > > But I'd feel a lot happier if a second level of authentication were > required to establish a wireguard connection, if no packets had been > flowing for more than a configurable amount of time - say, an hour. It > would give some comfort around lost/stolen devices. Couldn't you just encrypt your home directory? Or even the root FS entirely. Either of those should be a must on a portable device storing valuable information. -- With respect, Roman ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Reflections on WireGuard Design Goals
On Fri, Aug 10, 2018 at 02:35:14PM +0100, Brian Candler wrote: From my point of view, the only thing which makes me uncomfortable about wireguard is the lack of any second authentication factor. Your private key is embedded in a plaintext file in your device (e.g. laptop), not even protected with a passphrase. Anyone who gains access to that laptop is able to establish wireguard connections. I think one way of solving this is teaching the client-side tools to hook into the TPM. We still grab the key and store it in memory (as opposed to using TPM's crypto processing directly), but at least this way it's not lying around on disk somewhere, and it doesn't require changing anything about the protocol. I am hoping to hit up James Bottomley about it when I next see him -- he's already written quite a few tools that use TPM, including teaching GnuPG how to use it. :) But I'd feel a lot happier if a second level of authentication were required to establish a wireguard connection, if no packets had been flowing for more than a configurable amount of time - say, an hour. It would give some comfort around lost/stolen devices. I believe this is orthogonal to the design of the protocol, which is supposed to behave in a "stateless" fashion and resume transparently after even prolonged downtimes. We use 2-factor authentication with OpenVPN, and one of the most annoying aspects about it is the fact that you have to manually re-auth after each VPN blip. If you don't do it quickly enough, all your sessions get reset -- most horrible experience if you are hoping your ssh connection to a server doesn't get severed in the middle of a yum update. Whilst I appreciate that wireguard is symmetrical, a common use case is to have remote "clients" with a central "office". I'm thinking about a hook whereby the "office" side could request extra authentication when required - e.g. if it sees a connection from a wireguard public key which has been idle for more than a configurable amount of time, then it sends a challenge which requires (e.g.) a Yubikey to complete. I appreciate that it's not going to be straightforward, requiring the kernel module to talk to userland components at both ends. I think Wireguard's primary strength is its resilience to network blips and fast operation. We intend to use it for site-to-site connectivity across disjointed infrastructure where it will certainly operate much smoother than OpenVPN or ipsec. For admin-to-site connections we will continue to use OpenVPN or some combination thereof, until we figure out a straightforward way of "upgrading" access level of a wireguard connection. I suspect this is fairly easy with iptables and fwmark, but I need to test and streamline it. -K signature.asc Description: PGP signature ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Reflections on WireGuard Design Goals
On 10.08.2018 15:35, Brian Candler wrote: > Whilst I appreciate that wireguard is symmetrical, a common use case > is to have remote "clients" with a central "office". I'm thinking > about a hook whereby the "office" side could request extra > authentication when required - e.g. if it sees a connection from a > wireguard public key which has been idle for more than a configurable > amount of time, then it sends a challenge which requires (e.g.) a > Yubikey to complete. I appreciate that it's not going to be > straightforward, requiring the kernel module to talk to userland > components at both ends. It's reasonably easy to add that as a service on top of Wireguard, once you have an authenticated connection. The office can easily talk to an app on the mobile device when it notices a re-awakened stale connection (triggered by a firewall logging rule, for instance), exchange whatever crypto it requires, and only then allow packets other than those required for authenticating to flow through the interface (another simple firewall rule change). Adding a feature like this to the WG kernel itself would not be any more secure (and indeed add a significant amount of complexity which may exhibit exploitable bugs). It would also unnecessarily enshrine a particular 2FA scheme into wireguard. -- -- Matthias Urlichs signature.asc Description: OpenPGP digital signature ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Reflections on WireGuard Design Goals
Please excuse my brevity, phone typing here... On Fri, 10 Aug 2018, 16:36 Brian Candler, wrote: > Thanks for explaining the project background, and your very sensible > goals of simplicity and robustness. And thanks for releasing this > excellent piece of software. > > From my point of view, the only thing which makes me uncomfortable > about wireguard is the lack of any second authentication factor. Your > private key is embedded in a plaintext file in your device (e.g. > laptop), not even protected with a passphrase. Not always. You can generate it on the fly (say 1st boot, no config file), distribute it and be done. Or you can choose to protect it (e.g. pgp), may be even store it in a HSM. Or throw it (keep in RAM) and regenerate, if needed. Anyone who gains access > to that laptop is able to establish wireguard connections. > > Of course, it can be argued that the laptop holds other information > which is more valuable that the wireguard key, therefore you should > concentrate on properly securing the laptop itself (*). Furthermore, to > be able to talk to the wireguard kernel module you're already root, and > therefore have all sorts of malicious options available to you. etc etc > > But I'd feel a lot happier if a second level of authentication were > required to establish a wireguard connection, if no packets had been > flowing for more than a configurable amount of time - say, an hour. It > would give some comfort around lost/stolen devices. > And what do we do (count or not) keepalive traffic? Whilst I appreciate that wireguard is symmetrical, a common use case is > to have remote "clients" with a central "office". I'm thinking about a > hook whereby the "office" side could request extra authentication when > required - e.g. if it sees a connection from a wireguard public key > which has been idle for more than a configurable amount of time, then it > sends a challenge which requires (e.g.) a Yubikey to complete. I > appreciate that it's not going to be straightforward, requiring the > kernel module to talk to userland components at both ends. > That is way overcomplicated... And how did you solve your key distribution in such scenario BTW? (hint: the functionality you request is part of key handling, i.e. NOT part of wg, AFAIK). The office end can expire any user key and request sidechannel (additional, 2FA or more) authentication via the established link. Who says wg tunnel should be to the network core? Use a standard firewall, plug a RADIUS even, or script your way on top of wg. Feel free to provide a clean interface to wg and documentation and people who want that functionality will use the code. Is there anything (e.g. design-level) that prevents that? Or functionality that is lacking at the core? > > In the absence of that, it would be nice if the private key which is > stored on the laptop were encrypted with a passphrase. Simplest option > may be to extend wg-quick so that the entire config file can be > pgp-encrypted. > Now that also is not 2FA, and yes it should be a few lines of scripting. Kalin. ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Reflections on WireGuard Design Goals
For whatever reason, in the last several weeks, WireGuard been receiving a considerable amount of attention, and with that comes various parties interested in the project moving in this direction or in that direction. And more generally, over the last year or so, we've seen a decent amount of interest from different folks wanting to do different things with the project and with the protocol. This inevitably leads to the question: what do we actually want WireGuard to be, as a project, as a protocol, as a set of implementations, as a design methodology, and so forth? I've had a pretty clear idea about that, but I don't think I've ever tried to communicate aspects of it in this context, so I thought here I'd highlight two important design goals that motivate us. Thanks for explaining the project background, and your very sensible goals of simplicity and robustness. And thanks for releasing this excellent piece of software. From my point of view, the only thing which makes me uncomfortable about wireguard is the lack of any second authentication factor. Your private key is embedded in a plaintext file in your device (e.g. laptop), not even protected with a passphrase. Anyone who gains access to that laptop is able to establish wireguard connections. Of course, it can be argued that the laptop holds other information which is more valuable that the wireguard key, therefore you should concentrate on properly securing the laptop itself (*). Furthermore, to be able to talk to the wireguard kernel module you're already root, and therefore have all sorts of malicious options available to you. etc etc But I'd feel a lot happier if a second level of authentication were required to establish a wireguard connection, if no packets had been flowing for more than a configurable amount of time - say, an hour. It would give some comfort around lost/stolen devices. Whilst I appreciate that wireguard is symmetrical, a common use case is to have remote "clients" with a central "office". I'm thinking about a hook whereby the "office" side could request extra authentication when required - e.g. if it sees a connection from a wireguard public key which has been idle for more than a configurable amount of time, then it sends a challenge which requires (e.g.) a Yubikey to complete. I appreciate that it's not going to be straightforward, requiring the kernel module to talk to userland components at both ends. In the absence of that, it would be nice if the private key which is stored on the laptop were encrypted with a passphrase. Simplest option may be to extend wg-quick so that the entire config file can be pgp-encrypted. Regards, Brian. (*) You could make a similar argument for ssh keys or pgp keys, saying there's no need to protect them with a passphrase if the host they are stored on is properly secured. I think many people would disagree. ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
[PATCH 1/1] Calculate inner checksums for all L4 protocols (was for TCP/UDP only).
- skb_checksum_setup can only handle TCP/UDP protocols under top level IP header, packets with other protocols (like GRE) are sent out by Wireguard with unfinished partial checksums which causes problems on receiving side (bad checksums). - skb_encrypt gets skb prepared by network stack, so there is no need to setup the checksum from scratch, but just perform hw checksum offload using software helper skb_checksum_help for packet which explicitly require it as denoted by CHECKSUM_PARTIAL. Signed-off-by: Andrejs Hanins --- src/send.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/send.c b/src/send.c index 3af7ef3..1d021ae 100644 --- a/src/send.c +++ b/src/send.c @@ -151,9 +151,9 @@ static inline bool skb_encrypt(struct sk_buff *skb, struct noise_keypair *keypai if (unlikely(skb_cow_head(skb, DATA_PACKET_HEAD_ROOM) < 0)) return false; - /* We have to remember to add the checksum to the innerpacket, in case the receiver forwards it. */ - if (likely(!skb_checksum_setup(skb, true))) - skb_checksum_help(skb); + /* Finalize checksum calculation for the inner packet, if required. */ + if (skb->ip_summed == CHECKSUM_PARTIAL && skb_checksum_help(skb)) + return false; /* Only after checksumming can we safely add on the padding at the end and the header. */ skb_set_inner_network_header(skb, 0); -- 2.17.1 ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
[PATCH 0/1] Fix broken inner checksums for non TCP/UDP protocols
Hi, I'm using GRE tunnel (transparent Ethernet bridging flavor) over Wireguard interface to be able to bridge L2 network segments. The typical protocol chain looks like this IP->GRE->EthernetHeader->IP->UDP. UDP here is the packet sent from the L2 network segment which is tunneled using GRE over Wireguard. Indeed, there is a checksum inside UDP header which is, as a rule, kept partially calculated while packet travels through network stack and outer protocols are added until the packet reaches WG device which exposes NETIF_F_HW_CSUM feature meaning it can handle checksum offload for all protocols. But the problem here is that skb_checksum_setup called from skb_encrypt handles only TCP/UDP protocols under top level IP, but in my case there is a GRE protocol there, so skb_checksum_help is not called and packet continues its life with unfinished (broken) checksum and gets encrypted as-is. When such packet is received by other side and reaches L2 networks it's seen there with a broken checksum inside the UDP header. The fact that Wireguard on the receiving side sets skb->ip_summed to CHECKSUM_UNNECESSARY partially mitigates the problem by telling network stack on the receiving side that validation of the checksum is not necessary, so local TCP stack, for example, works fine. But it doesn't help in situations when packet needs to be forwarded further (sent out from the box). In this case there is no way we can tell next hop that checksum verification for this packet is not necessary, we just send it out with bad checksum and packet gets dropped on the next hop box. I think the issue of the original code was the wrong usage of skb_checksum_setup, simply because it's not needed in this case. Instead, we can just rely on ip_summed skb field to see if partial checksum needs to be finalized or not. Note that many other drivers in kernel follow this approach. I'm not a kernel networking expert, but additional change (paranoid?) could be to call skb_checksum_setup followed by skb_checksum_help for packets which don't have CHECKSUM_PARTIAL in order to make sure we handle some buggy packets. This trick is done in checksum_setup from xen-netback. But I'm really not sure whether it's needed in Wireguard case... BR, Andrey Andrejs Hanins (1): Calculate inner checksums for all L4 protocols (was for TCP/UDP only). src/send.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- 2.17.1 ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard