You can get the former at https://www.wireguard.com/install/ and learn about the latter at https://www.wintun.net/
Most likely that poster uses DPI sloppily to include simple blocking strategies, like hey, if we see two packets in a row between two (ip,port) pairs starting 01 00 00 00 going on way and then 02 00 00 00 going the other way, that could be WireGuard, let's block the rest of the data on that (ip,port) pair for a while.
However, am I missing something and actually there is something meaningful to inspect without having the keys?
If I'm not, what's your preferred way for people to sidestep that sort of blocking? Tweaking WireGuard to use different values would obviously work but it destroys the point of having a single specification.
That aligns with the DPI-related comments in the linked prior comment thread, which reference use of DPI for internet firewalling by various governments.
Also, as noted in that same comment thread, bypassing DPI is an un-goal of Wireguard.
Right, so then is your claim that there _is_ such information revealed in WireGuard? Because I don't see any.
If you do DPI for - say - TLS you get a strong fingerprint (JA3 is a popular thing for this) that lets you distinguish Google from Twitter, Firefox from Safari, or curl from Python's Requests, again without decrypting the traffic.
But where is the fingerprint in WireGuard? If I give you a tcpdump for 5 minutes of UDP traffic the most you can say is that some of it looks like WireGuard traffic. You might remember when we used to get this sort of useless diagnostic, "Over 4000 of these packets use port 80! This is web traffic". We did not call that "Deep Packet Inspection" because it wasn't deep and didn't in fact inspect the packets, just some metadata.
For example: https://ipoque.com/news-media/press-releases/2019/rohde-schw...
Edit: also, to clarify the note you had about port 80, that’s why I pointed out that DPI refers to layers beyond 3/4. “Hey these are TCP packets to port 80” is not DPI. “Hey, the contents of these packets match my signature for Wireguard traffic” is DPI.
From the Wireguard mailing list, there is an application layer fingerprint that is easy to detect.
The right analogy is "these packets went through these tubes".
Would you ever consider creating a mesh network manager (to replace horrors like Hamachi)? It could allow people to generate the keys conveniently/safely and connect servers/clients in a distributed, non-centralized manner easily.
Awesome work by the wireguard team
Once you blow past the warnings about compiling it on linux, it still failed to actually work in my testing. Fair enough.
It doesn't seem like it should be an insurmountable problem, but I'm a level or two from being able to make it work by sheer force of code.
I have a config right now on my other PC labelled "Old staging KEEP" which is this type of setup for OpenVPN, it's relying on a crappy out-of-box private CA setup, no passwords, shared private keys, it's likely vulnerable to key compromise attacks and a dozen other problems as configured.
Edited to add: Also, the reason I kept it, this config relies on hijacking public addresses. Some... person... took an OpenVPN config example with 172.16.0.0/16 addresses and it conflicted with the stupid WiFi NAT in their office, so they just changed the IP addresses to a public range nearby, apparently not realising (certainly not caring) that this means it's now randomly breaking other things too.
But for the typical end user this looks like it worked. Random drive-bys can't get in, spinning it up for the new frontend dev is easy, what's not to like? If it takes them five minutes to install & configure OpenVPN wrong, and an hour to install & configure WireGuard right, they will conclude WireGuard is harder, even if it might have taken them a week to get OpenVPN done right.
WireGuard asks so much less of you.
Overall TunSafe has been awesome apart from some minor annoyances - like laptops not auto-reconnecting sometimes after hibernating.