> In this section, Tremer argues that IPsec is not very hard to use after all — in contradiction to the experiences of most readers — and points out that you only need to specify your own public IP address, the public IP of your peer, the subnets you want to make available for each side, and a pre-shared key. After that, the VPN “is compatible with every vendor out there.”
> This is a surprising set of claims. First of all, that is not the only information needed to configure IPsec: critically, correct use of IPsec requires you to specify exactly which cipher suites you want to allow. This is an unanswerable question for anyone who is not a cryptography expert. The defaults are virtually never secure or cross-platform.
This is so true. I once configured a Sonicwall and Cisco router and even though all encryption settings for both phase 1 and phase 2 were exactly the same, the tunnel refused to come up with negotiation errors. I had to change ciphers on both sides before it worked. Vendor incompatibility is an absolute pain with IPsec and IKE.
What's also bad about IPsec is that most of its features are useless in the vast majority of use cases. Some are probably even actively harmful to try to use. For example, it's possible to use static encryption keys for a security association. That's not a good feature to have.
If you just want to set up a secure tunnel connecting two networks over an untrusted network, probably 95% of what IPsec can do won't be of any help to you at all, and will actively hinder you because you have to find the exact combination of settings that works for whatever two endpoints you want to join together.
>For example, it's possible to use static encryption keys for a security association.
That's not a feature per se, it's just a side effect of having pluggable mechanisms at each part of the protocol.
They allow IPSEC to be extensible - for example to support group SAs for GETVPN (Group VPN), used in a lot of encrypted networks in higher security environments. This is usually done on the CPE router. On very high security networks, a separate hardware encryption device is needed.
To implement something similar to GETVPN in wireguard would require an agent to constantly change the private and public key pairs for every peer relationship in the group.
I suppose I should have phrased my point differently. I think having that kind of a feature as a side-effect of how the whole thing works isn't particularly good for security and usability, though I understand why you might need the flexibility in some scenarios.
IPsec can certainly do fancy things when you really get serious about encrypting and authenticating everything and wireguard is not nearly ready tooling-wise to replace all of that, but the configurability also makes IPsec pretty unfriendly for solving simpler cases like just connecting two or more separate networks together or road-warrior client setups. I suspect people are excited about Wireguard largely because these cases are common enough that whatever actual reason IPsec has to be as flexible as it is is dwarfed by the pain it causes in simple cases.
As for group VPNs, maybe I'm misunderstanding something, but why would you need to be constantly changing Wireguard keys on nodes in the network, when you only need to distribute the public keys for all nodes that need to communicate? You only really need one keypair per node that's participating, and it's not really a problem for the public keys to be long-lived.
That's because unless you work with the secure plumbing of bits at scale and in complex environments, you don't run into the use cases where the flexibility of IPSEC makes sense. However a lot of network and security engineers do.
Regarding your last point, the whole idea of GETVPN is membership in a encryption group. This include joining the group and leaving the group (and what this entails), as well as distributing group keys. Witeguard just itself designed for this and it can't even be hacked on. Whereas extending IPSEC to support group semantics was relatively seamless.
I've done cross cloud connects where the cloud vendors are on the phone with me and eventually say "We really don't have any idea why the tunnels are not connecting". And that's when using Cisco VPN appliances, no less, following everyone's setup instructions to the letter.
Had the same problem with Verizon Medium Business in 2015. Turns out there was basically one guy who knew the internals of the (required) IPSec VPN, he couldn’t figure out why the tunnel wasn’t working and I gave up and switched to another provider.
Sounds like a real shitshow all around. Building IPSec tunnels between ASAs isn’t rocket science.
I would be worried about downstream issues with the security architecture, especially down the road when you pick up clients with compliance requirements.
I had one from Cisco to Meraki (who is owned by Cisco), they eventually gave up and told me to just buy another Cisco of the same model on the other side.
I work for a company that provides a product that tries to make IPsec a little easier and I can say like 80-85% of our support burden is helping our customers configure their ASAs, Junipers etc. to talk to our cloud based VPN concentrator/router/app firewall. We basically run people through a checklist [1] and it is non-trivial. IPsec can be a real pain.
Absolutely. The only IPsec software I’ve seen that will not make you run away gibbering in terror as if you’ve seen Chtulu is OpenBSD’s OpenIKEd, and while you can use it to make an IPsec VPN server for Apple iDevices without having to install third-party software, it doesn’t play nice with other IPsec software because of the lack of mandated ciphers.
A few years ago, since I work for a company that makes switches and routers, I decided that our cloud VPN would be IPSec-based. It was going to be simple, and would work equally well with software and devices.
Oh, boy. It's not just ciphers. If you look at software alone, compatibility between the various *swan flavors is not exactly a thing.And what about IKE? By far the most misunderstood, haphazardly implemented piece of the puzzle.
Ever tried to setup an IPSec VPN between a checkpoint gateway and a device from another vendor? Even their interoperability guide doesn’t cover half the things that can and will go wrong.
Back when I was supposed to connect our office to the new parent companies network via IPSec, I spent actual, full days on the phone with both the parent companies IT and our firewall vendor, until eventually we confirmed that some PFS variations are broken in one of the device, but others are not. And it's probably not economically feasible to fix. Debugging that involved going entirely nuts with wireshark, learning the IPSec spec to understand the phases going on, and so on, and so on. It's one of those projects that eventually make me question my very own skills.
With wireguard for our production datacenter site to site connections... it took about 2 days to have a fully automated installation and key management setup in ansible. About half a day was spent figuring out that our cloud provider filtered traffic not coming from the IP of a VM by default. And then everything just worked. And it's an easily extended mesh between datacenters. And wireguard even has usable logging about traffic.
But yes, the lesson is: IPSec without having endpoints from the same vendor with a vendor guarantee they will work together is absolute pain. It either works securely within the first few hours, or probably never. Yes I've been touched in a bad place by IPSec.
IPSec takes around 30 lines of config to setup using strongSwan and can be setup in minutes. But there are lots of footguns which makes it a bad protocol for non-experts to secure.
IPSec can be set up in minutes if you have a working config to copy and paste off of that matches what you're trying to do. Otherwise, expect hours of scratching your head trying to figure out why it's not doing what you want.
Source: I'm an infosec professional and general systems guy and I use IPSec at home with StrongSwan. It took me several hours to set it up and I still run into issues from time to time.
I also use IPSec at home (with Windows, Android, Linux and MacOS peers) with StrongSwan and it definitely didn't take me hours to set up. Fortunately, StrongSwan maintains an extensive database of virtually any supported configuration that can be used as a starting point https://www.strongswan.org/testresults.html
People in this thread point out that is not compatible between networking hardware vendor implementations, but if you just run a Strongswan responder on your own server a lot of this disappears. And yes, Windows/Linux/Mac are natively supported. Setting up a Windows peer is importing a certificate and two lines of PowerShell.
> Fortunately, StrongSwan maintains an extensive database of virtually any supported configuration that can be used as a starting point
You are confirming what I said: that it's only easy if you have something to copy and paste off of.
It took me hours because I was trying to do something less common, namely peer to peer transport mode between LAN hosts with rules to exclude SSH access and multicasts. That this was a less common config is no excuse for the amount of prodding and debugging I had to do until I figured out what magical set of policies did what I want.
"The long-term option is to reconsider why you need that legacy VPN concentrator in the first place. WireGuard is open source, can run in a pure software virtual machine [...]"
I think the answer to this is that companies prefer to buy "boxes" over running their own infrastructure. Sure, under the hood it's the exact same thing, but Cisco can market a nice grey box with a logo to your manager and you can't market a Linux kernel tool.
Why buy a VPN concentrator when you can run OpenVPN or IPSec in a VM? Easy, because the VPN concentrator is plug and play after setup and you don't need to worry about those pesky updates (you should worry but updates are rarely provided anyway).
From my point of view, WireGuard and IPsec/OpenVPN serve two entirely different markets. Wireguard is there for the companies running their own Linux infrastructure already, providing the tools for quick and dirty VPNs with no cost and barely any complexity. IPsec and to some extent OpenVPN is there for the companies thinking in boxes (the VPN box, the web server box, the Cisco box, the firewall box) who don't care about how the VPN works as long as they can pay someone else to make the box and as long as it works with their existing devices.
Before WireGuard, most articles writing about the kind of thing WireGuard is good at would recommend setting up OpenVPN. And truth be told, OpenVPN is pretty good at this sort of thing, it's just complex to properly understand because of its complexity. IPsec is left over to the professionals, bridging offices together rather than making servers talk to each other securely. You can do a lot of what IPsec offers through WireGuard, but you can do everything WireGuard offers through IPsec. Whether your want to use that complexity or not is your own choice, but I don't think there's a real answer to be found here.
Because of this I think many people are talking past each other without realizing it. "VPN" can mean many things to many people. To people watching a lot of Youtube, it's for pirating movies or watching foreign Netflix. For people working with legacy/prebuilt IT, it's how WFH is done together with some strange Cisco product. To Linux/OpenBSD engineers, it's just a network layer with many different applications. To corporate, it's the button you press to make the accounting report go brrrr when you're on the road. Arguments for one use case easily fall flat for all the others.
>I think the answer to this is that companies prefer to buy "boxes" over running their own infrastructure. Sure, under the hood it's the exact same thing, but Cisco can market a nice grey box with a logo to your manager and you can't market a Linux kernel tool.
This is spot on. Companies prefer it because it comes with a support contract and defined SLAs.*
The vast majority of companies that don't actively develop infra or software, aren't going to invest in support for OSS . (Think retail companies). They want to buy a solution and that means all of the solution, including support and who they can blame when it catastrophically fails.*
*These may be meaningless most of the time if its a suitably complex problem.
** Also they may just not equipped to actually hire and build the infra in a meaningful way.*
VPNs are a funny old thing and it's great to see a new tool to add to the toolbox.
IPSEC is quite hard to deal with. For starters you have to understand that IPSEC was designed quite a while back and not only to shuffle TCP/IP (or UDP/IP). Nor is bog standard IPSEC "routing" in the IP sense. Those Phase 2 thingies are "selectors" - they look for attributes in a packet (generally left and right IP subnets) and then take action. Those selectors could be SPX/IPX addresses instead or people's family names if that makes sense for the system.
Now, your P1 is the auth bit. It can accept many (err several) mechanisms but in general its PSK or certs. Then there is the identification thing - you pass your ID (which can be "lol, anyone, I'm pretty!")
P1: You say Hi and state your ID and if you get a response with an ID then you try to authenticate. You send your methods and they send theirs. You pick an intersection of your offering and theirs and give it a go. With luck you get it right and you now have a relationship between you and the other end. That relationship is called a Security Association (SA)
P2: This is called the Security Policy (Database). Network packets are inspected by the IPSEC engine looking for certain characteristics. In general it is IP subnet pairs - it doesn't have to be - remember IPSEC had much bigger goals than just IP.
You send data and the other end decrypts it.
I have not really done IPSEC justice here because it is quite beautiful as a standard. It is quite complete and the vendors and implementations have really fucked up. It is understandable in some cases because encryption does have a cost.
In the end IPSEC is still the most employed VPN standard and also the worst understood. Sad really.
I recently set up my NAS, phone, and 2 machines with Tailscale and am delighted with the results. I'm no networking guru, but have been doing web-related things for a living since 1998, and Tailscale is hands-down the most straightforward way I've ever encountered to connect my devices securely. Intuitive UX, WireGuard under the hood, highly recommended.
Yeah - Tailscale came up a few weeks ago on here. I took 20 minutes to set up my entire home network (ok, maybe 30) - but got my pihole, windows server, phones, and everything else online in minutes.
And then it has been reliable and stayed online. I can now easily RDP into my Windows Machine from my iPad from anywhere.
I had set up OpenVPN and wireguard for home network use, but Tailscale blows it away. And it's free for limited use.
Honestly I thought the last post about Tailscale was filled with people astroturfing there were so many positive comments. But yeah - it's good. Really good. And it "just works".
And the custom DNS is also awesome for RDP'ing and ssh'ing to devices by name on the network (e.g. ssh user@MacBook) can just work from an iPad.
I keep seeing Tailscale come up and I’m sure the UX is great but I’m not really sure I get the value-add compared to normal WireGuard on a cheap VPC. Like it took like 30 minutes to have a WG server and profiles for all my devices. Scanned a few QR codes and now all my devices can all mutually talk to one another.
Sure it’s not fancy P2P with lots of NAT busting tricks but the upside is that it always works. And I don’t need a fancy privacy preserving relay because I’m the relay!
Automating all that stuff I’m sure is worth the price of admission for large deployments but for personal stuff I don’t get it.
For me it’s not about a privacy preserving relay, it’s about getting back to my Windows Desktop from my iPad from anywhere with a cell connection.
I use tech in my job constantly, so at home I want the minimum number of parts that can break and things to keep updated. Tailscale authenticates with google, and allows me to check in every few months and be fine. I don’t want to have to maintain another VPC instance at home.
It’s really easy, there’s a free tier, it gives you mesh P2P, it sets up DNS on all your devices, Google/GitHub SSO, a nice little Mac menu bar widget, etc etc. It just makes life nicer. Adding a new VPS or whatever device is just “tailscale up” and clicking the auth link. I love it!
There's a free software self-hostable server called "Headscale" somewhere on Github (not that I've used it). I saw a comment somewhere that Tailscale approved of it.
I wonder whether a smaller company of experts(?) whose business is focussed on this is any more vulnerable than an established one with huge resources.
> Someday, WireGuard will need to be upgraded to support a second cipher suite. When this happens, users will be able to configure it peer-by-peer to allow one cipher suite or the other, or both, exactly as they would with any other VPN.
Is that accurate? I thought they explicitly said that this is not the case, that instead a V2 would still have just the one protocol?
In any case it's a non-problem, as you simply migrate by setting up V2 on a different port, and migrate client by client.
I'd say better this that having "cipher agility" like with IPSec.
During design of IPSec, someone was advocating for the "NULL cipher" which is essentially no-encription where the use case was "debugging". Tie in cipher agility with the NULL cypher, and you've got yourself an awesome downgrade attack
“Set up a new service and migrate all your clients” sounds _worse_ than “update the centrally managed config for existing clients” though? I’m only dealing with double-digit numbers of devices, and this “non-problem” sounds like a nightmare...
You are in fact unlikely to ever have to upgrade the WireGuard protocol under any kind of duress. But ciphersuite negotiation has itself been a source of protocol vulnerabilities, and those are vulnerabilities you'll never have to think about with WireGuard.
Not for larger enterprises - simply because this is how they ALREADY do things. You setup new thing on new place, and 5 years later hope you can turn off version 1.
You would be surprised at how LITTLE updating and reconfiguring of systems that are working big enterprises want to do. And this is doubly so in the VPN space which is a mindfield already of troubleshooting when users call and complain (98% user error, but the 2% config / ip exhaustion or whatever bites you and so once folks have a working setup they really don't want to mess with it).
This comment thread is for people who don't think IPSec/IKEv2 is the worst invention on the planet and want to share life saving stories about it.
This will inevitably be downvoted, but (almost) everytime I see IPSec/IKEv2 mentioned there's a bunch of people puking all over it. Of course, it has a lot of options and configurations and you can fu*k things up, you have to study it a bit, like a brain surgeon has to read some books and do some practice. But once done that, it is a beautiful piece of protocol, excuse my language. It's fast, stable, it auto-reconnects, not to mention MOBIKE, it is simply state-of-the-art. I guess not everybody can drive the Formula 1 car of the VPN protocols. ;-o
IPSec/IKEv2 is not breaking anything, maybe it just won't setup a tunnel. Maybe a better analogy: We don't say the same thing about for example a piano: "it should only be able to be used correctly". You have to study and practice a bit before you can play a somewhat decent piece, without study no piano play. The same for IPSec/IKEv2, without study no tunnel. Every VPN protocol needs a bit of study, maybe some protocol a bit more than the other. We have a Dutch saying: "Als een boer niet kan zwemmen ligt het aan zijn zwembroek", which translates to something like: "If a farmer can't swim it's because of his swimming trunks".
If you want out-of-the-box VPN solutions, you go to a VPN provider and download their apps. ;-o
But there's no value in IPsec being like a piano. Continuing the analogue, nearly everyone would be playing the exact same handful of songs in the exact same way and if they don't, they're doing it wrong. Why on earth do you have to learn to play an instrument like that?
You don't want core pieces of security technology to have room for creativity.
Yes, I guess the analogy has its limits. (-:
The only point I'm trying to make is that no VPN protocol is an out-of-the-box solution. And mind you, I'm talking about the protocol, the out of the box solution "Tailscale" is not a protocol for example, it's an app with WireGuard at its core with added proprietary functionality to make it work out-of-the-box. WireGuard as a protocol is possibly the easiest to setup, IPSec/IKEv2 might be the most challenging to setup. On the other hand WireGuard has limited capabilities, IPSec/IKEv2 has a bit more. More capabilities for IPSec/IKEv2 comes with more study and practice.
Then it's you breaking things because of lack of understanding, not IPSec/IKEv2. The same way no dishwasher is going to break plates, unless you throw them in with force yourself.
You missed the point. It shouldn’t be so easy to configure it incorrectly so it breaks security. A dishwasher shouldn’t have buttons that combine to break your dishes.
Your defense of “you don’t understand it” is exactly the problem. That’s an argument in support of my point, not against it.
Okay, how about a different analogy then. Seatbelts.
Wireguard is a seatbelt where you plug the latch plate into the buckle, it lets out an audible "click" and you're secured. If you fail to secure it properly, the latch plate will not be held by the buckle and will retract. It will be immediately obvious that you aren't secured and the car will refuse to move until the problem is resolved.
IPSec is a seatbelt where the process of putting the latch plate into the buckle requires adjusting several knobs on the buckle to the correct setting depending on your specific size and weight and then placing the latch plate into the buckle at the _exact_ right angle. The settings of these knobs and the angle required differs slightly or significantly between manufacturers as well as model years.
With the IPSec seatbelt, failing to perform these steps correctly often results in the buckle failing to engage and the car failing to start. But sometimes it also results in the buckle letting out a "click" and appearing to be latched while not being properly engaged and able to protect you in a crash. This counts as buckled as far as the car is concerned though and it's happy to let you drive this way.
Well what if I _want_ to drive around with only the appearance of a seatbelt without the safety of it, huh? Wireguard won't let me do that!
Sure, there are _very_ specific situations where IPSec is the only option to implement what we need. Great, I'm glad it exists to cover off those use cases.
But when everyone's getting the common case wrong in subtle and dangerous ways, the answer isn't "well, it's as complicated as brain surgery get good scrub" (I can't imagine how you think that's a defense of IPSec.). It's possible to design a system that allows a secure tunnel _without_ the complexity and massive number of footguns (see: wireguard). For most use cases, that makes IPSec defective by design.
If GM designed their cars to have as many buttons and knobs as a 747 cockpit, they would never make it to market. Manufacturers have been forced to recall vehicles for much less[0].
By all means, continue to use it, but expecting people to learn brain surgery to set up a secure tunnel is and should be a non-starter.
Why study something outdated when there is a newer, modern and a lot more sane alternative out there?
I can understand if you now have years worth of expertise you are invested in defending. It's selfish, but I understand your position. For anyone else? Suggesting they invest in IPSec vs. something more modern is just nuts.
Ok, you're not the first one blaming me for defending or gatekeeping, even calling me selfish, so I guess I need to clarify myself a bit: I love WireGuard, Tailscale does a great job making it even more "user" friendly and I'm nowhere suggesting to invest in IPSec instead of something "modern" (or do you mean something invented not longer than 3 years ago?). You're missing my point, putting words in my mouth and you seem to not know what you're talking about if you think for example WireGuard is an alternative for IPSec/IKEv2, because in a lot of cases it's not. You're even calling IPSec/IKEv2 outdated. There's a difference between the protocol and the configured crypto algorithms. If the configured algorithm is outdated, configure a modern one. If that's not possible in your device supporting IPSec/IKEv2, vote with your money and don't buy from that manufacturer. Don't blame IPSec/IKEv2 for it.
Unless there is an alternative it can't be outdated, per definition. WireGuard is not an alternative in many cases. But I get your point, it might have design mistakes (or implementations we would have done different today, while I think you are talking about IKEv1, not IKEv2), but no IPSec/IKEv2 server is left open for scriptkiddies to break, it's receiving updates when bugs are found and in this sense not outdated too. Unless you're using outdated crypto algorithms, but that's up to you. The NSA possibly has capabilities to break IPSec/IKEv2 anytime they want, but that's something we don't know about WireGuard either. If that's the case with WireGuard, it has design flaws too or bugs which aren't found yet. It's better to know about a design flaw and mitigate against it, then not knowing about it and not being able to mitigate against it.
This sounds like network security gatekeeping to me. Tailscale and others are trying to make things easier for most people while preserving high security. This is a noble effort IMO.
I mean, the exact opposite is also true? The Wireguard camp is always essentially claiming that everyone not using Wireguard is incompetent and should feel bad for not understanding how it is better, and this post to me felt like "let's make some space for people to say something good about IPsec actually solving a problem for them".
IPSec is based on tens of RFCs with optional features (such as dpd in IKEv1) and more knobs than a boeing 747 cockpit. You get companies as big as AT&T setting up IKEv1 with pre-shared keys and weak crypto in 2021 by default as that’s their template offering for site-to-sites.
BUT the interoperability (when it works) and the native stack implementations (Android, iOS, Windows, MacOS) though nice for admins, is only owing to it’s prevalence in enterprise rather than any superiority as a standard.
So who is to blame? AT&T for incompetence while implementing the old IKEv1 version, or IPSec/IKEv2 for apparently not being able to be attractive enough for AT&T?
I'm using IPSec for my homelab/roadwarrior setup, and that's explicitly because Linux, macOS, and iOS can all use it right out of the box without any "apps" to install.
The only gripe I have is that StrongSwan is not a particularly easy piece of software to set up and debug when your tunnels suddenly go pear-shaped. I'd say they are a textbook example on how to screw things up when introducing a whole new set of daemons and configuration format, while a multi-year body of knowledge and corner cases exists only for the old format.
End-user experience with "enterprise" VPNs (GlobalProtect currently) leaves me much more trusting of WireGuard and OpenSSH, despite the Enterprise thinking SSH is too insecure to use without the VPN.
Early on, I looked at the GlobalProtect client we were supposed to use on GNU/Linux (x86 only, amongst other things). I found it linked a well-obsolete openssl (I don't recall the CVE count), and was even unlawful because it violated the openssl licence conditions. Then I see the CVEs on these things. People who use them find the proprietary clients keep breaking with no notice for no apparent reason. Openconnect has just worked through all that when I've had to use GP rather than WireGuard. (Openconnect also allowed me to use Cisco's corporate VPN to test the Linux-based stuff they tried to sell us and insisted I had to use an MS Windows machine to connect. Thank you OC maintainers!)
I used to use IPFire (the Linux distribution for routers mentioned in the original article), since then I switched my router to plain Debian, allowing me to use Wireguard. This is so much simpler than fiddling with the VPN settings in the IPFire UI.
Not a big fan of tailscale (where this article comes from).
I love the idea of Mesh VPN. They are amazing and they also add a lot of security on local networks as well (by encrypting traffic even if devices are on the same physical network).
But they take fully open-source WireGuard and make a closed service around it (the client apps are open source but the configuration servers that coordinate everything are not).
And then in addition to requiring you to trust them, they also outsource authentication to yet another party (for personal accounts you can choose Google, Microsoft or Github (a.k.a. Microsoft)). So now you have to trust two parties. Note: For enterprise customers they provide support for a lot more IDPs but that doesn't really make sense for a personal user.
For my VPN I'd really like to keep things fully self-hosted including the servers for security. I don't want to depend on others for privacy and security reasons. Any information they don't have can't be compromised there.
Luckily there are others like Nebula and Tinc that do provide fully self-hosted options. And there's ZeroTier which provides it to some extent (though fully self-hosted is intentionally difficult). But Tailscale doesn't offer it at all.
I wouldn't mind so much if they had built it all themselves (like ZeroTier for example) but this way it feels like they're hitchhiking on WireGuard's success while not sharing its values like providing a fully self-hosted option. I'm sure it's all above board legally but it doesn't feel very nice.
The Tailscale mobile apps aren't currently compatible with Headscale unless you modify and compile them yourself. But, those clients are mostly open source,* and the open parts can be forked and republished.
That's exactly my problem as well. The other problem I have is the way proprietary manufacturers rely on the fact you can configure IPsec insecurely so that they never need to update their broken-on-arrival IPsec hardware and software to support modern, secure standards.
> The end-user does not have to worry about the complexity of the protocol. If that was an issue we would have definitely gone rid of SIP and H.323, FTP and other protocols that don’t cope well with NAT and are decades old.
Well, to be fair, we probably SHOULD get rid of SIP and H.323
Modern networking looks funny. UDP as a baseline protocol. Wireguard and HTTPS/3 are built over UDP. Custom protocols are built over HTTPS/3. I think that it's good and simple suite of protocols.
The main selling point imho is the ability to build multi-node-mesh-networks super easily with something like tailscale on top of wireguard.
I also think this is a total different use-case than the one you’d most likely find in the wild today: people looking to use a VPN for „privacy issues“
The insane number of advertisements (TV, radio, internet) for different consumer "privacy" VPNs suggests otherwise. Nobody would waste money trying to sell VPN service if people weren't buying a lot of it.
I don’t consume enough broadcast media to comment there, but I certainly haven’t seen many privacy VPN ads online. And of course it doesn’t have to be popular to support a lot of ads - high margin would do that too.
If the wifi is eduroam, as many are now on university campuses, you should take a look at the service standards [1], especially page 32. While recommendations (on page 33) are only to block a minimum number of ports, if needed, in practice, I've found that some universities block all ports except those they are required to have open per eduroam policy. This includes blocking all UDP ports except 4500, 1194, and (outgoing only) 500. The trick of using common TCP ports won't work on these networks, as they open those only for TCP per policy, and often only outbound. On those networks, I've found using port 4500 for WireGuard works.
This is a bit annoying, because the policy is clearly designed to ensure that VPNs work, it just isn't written to support WireGuard yet.
Funny, the eduroam universities I've been to never blocked any outgoing traffic based on port number alone. In fact, one of them essentially provides you with a world routable IP address, only blocking some incoming ports known for abuse such as 25 and 53. A port scan of the network is a reminder of how badly the world has been relying on NAT to provide security (which it doesn't even do in the real world) because people will just permanently disable their firewall and think nothing of it. Once you hit the wired network, all ports are free game, which is even worse! Luckily, these networks are scanned and honeypots/badly configured servers will get hit with a warning in hours to minutes.
My solution for those restrictive networks is to pick common ports as well. Outgoing ports 53 and 443 work in most networks I've tried, even for UDP. Running a WireGuard server on port 53 means you can't run DNS from that server, and running a server from 443 means no HTTP/3 or QUIC. If the goal is to run a server from behind Eduroam then I think you'll be tough out of luck.
I suspect there's a big variation, particularly in whether the university has placed the keys to the kingdom in the hands of a "partner" of, shall we say, dubious competence and understanding of academia, after getting rid of decades worth of local experience. Fortunately those with decades of experience outside Networks group can usually find an "impossible" way to work around notwork and other roadblocks, but it's so much wasted time.
Why are they doing this at all? I don't think it's in the name of "security", if you can establish any VPN connection, you can easily exfiltrate any kind of traffic without anybody noticing.
In the name of security for the millions of BYOD devices that connect to eduroam. Only 0.1% may find inbound or strange ports useful but probably a double digit percentage of BYOD devices find unfiltered networks (particularly inbound or peer to peer communication) to result in massive continuous malware outbreaks.
Usually to protect the random unprotected machines on the local network (and the rest of the world from the poorly administered machines), in my experience.
Some of it often boils down to mindset of the admin - allow everything unless you know it is a problem, or block everything unless you ‘know’ it is good.
I have some tangential experience with a big sprawling old university network. It's a hard job. On the one hand, you need to protect academic freedom. Someone really is writing a paper about sexuality and needs access to crazy port sites. There's also the 90 year old advisor that never really understood email and why it's bad to click on every link.
Reach out to a professor, and write up a paper proposal about practical deployment of wireguard. You should be able to get some access to university IT folks. Not like, help desk, but net engineers. Take notes, capture the details about why it's tricky, and how you solve it.
You're not going to get into a journal for pure research, or anything super fancy like that. But if you put in the time, you'll get wireguard working and get a little credit on campus as not being clueless.
Same. Not that it means much, but I've been seeing 51820 being used in all documentation, blog posts, etc. Probably just copypasting the original examples, e.g.
There is a whole host of things this could be, but you may want to talk to your University IT and determine if they're doing any kind of port blocking, NAT blocking, etc. on the network.
Many campus networks are fairly restricted, often for a variety of reasons. IPSec / OpenVPN may get a pass because they're known exceptions, whereas Wireguard is new enough I'd not be surprised if your campus didn't move fast enough to include it as an exception.
> This is a surprising set of claims. First of all, that is not the only information needed to configure IPsec: critically, correct use of IPsec requires you to specify exactly which cipher suites you want to allow. This is an unanswerable question for anyone who is not a cryptography expert. The defaults are virtually never secure or cross-platform.
This is so true. I once configured a Sonicwall and Cisco router and even though all encryption settings for both phase 1 and phase 2 were exactly the same, the tunnel refused to come up with negotiation errors. I had to change ciphers on both sides before it worked. Vendor incompatibility is an absolute pain with IPsec and IKE.