Totally agree with you Eric. I personally have spent way too much “quality time” with Cisco devices over almost three decades trying to get IPSec to work reliably. IPSec will always be the choice of last resort for us.
OpenVPN ALWAYS works, especially when trying to connect to road warriors in East Asia to other continents, particularly North America. Don’t ask how I know this.
Fred
I dont think so. We had three times in history where OpenVPN has messed backward compatibility of the configuration/clients so all roadwarrior clients need new config/certs. This is a absolute nogo!
Here it is:
It is a bit long, and I still have more points that I did not fit in, but the most important ones are in here.
In short: WireGuard just won’t be an option for what you want to achieve.
You cover a fair number points in the blog and I agree with most of them. Yes the protocol is not yet ready for prime time for the reasons you outline but it doesn’t mean it wouldn’t be useful for us to experiment with. Personally, I would love to be able to drop IPSec. As I said in another message, I’ve lost tens of hours trying to make it work reliably with Cisco firewall (ASA 5508 I believe). It runs fine for a couple of hours then loses its key mind and reconstructs the entire tunnel breaking any persistent connection like SSH. Cisco can’t find it. I can’t find it.
Even between two identical IPFire configurations, (which is set up to match the Cisco configuration) won’t work. Single choice encryption, hash functions etc. Doesn’t work and no idea why. Back when I was working on IPCop, IPSec was cantankerous and I see that it still fails today.
I’ve had to bodge together an openVPN net to net connection using one of the servers as an OpenVPN client. It’s reliable, performance is not as good as IPSec but at least I don’t have my client yelling at me multiple times a day. On the other hand, OpenVPN is not ideal either. I have failed to connect IPFire OpenVPN to Mikrotik.
Hey, if not wire guard how about tinc? https://www.tinc-vpn.org/
Thanks for your feedback on the post…
You can definitely play around with it. Just do not expect something that you can use to replace your IPsec net-to-net or roadwarrior tunnels with.
tinc is just another multi-point TLS VPN. Use OpenVPN if you want to use TLS.
I would urge you to investigate the IPsec issues and find out what is going wrong. I honestly do not have any problems with tunnels cutting out and breaking TCP connections with IPFire.
Investigate the IP sec issues? You mean like this Ipsec to cisco asa 5506 failing (corrected)
I’ll try again on the IPFire to IPFire config. I’ll make a new post with config files etc.
Well, it is difficult to work this one out from a one-line bug report. The context on this post helps.
And in reply to this all, the Tailscale (Wireguard) folks reply…:
LOL 2-factor authentication… With a “secure” protocol with static keys…
$3 million seed round. I wish I was that much into money like he is.
Let’s be serious: He is forgetting that this is a blog post. It is not a scientific article of course. There are no extensive benchmarks to prove every single point in the article. It is already way too long for a casual read.
But a whole article just bashing my points and just saying I am wrong is a bit poor. He does not have any benchmarks or other proofs either to disproof my points. Instead he is “worried” and “surprised” about my “claims”.
He even went very far into the past (to 2003) to find a paper that shows how bad IPsec is. The problem only is that the IPsec folks have listened to that and improved.
I am flattered that my article was read. I do not write these things for publicity. Just for my own entertainment. But it would have been nice to have a debate and not just a PR stunt.
It disappoints me thought, that he is trying to deliberately misunderstand me to make his own points. And I am sure he knows better.
In the end, I think my point stands that in the real world, WireGuard has no place - yet. Maybe it will never find it with people like him backing it.
Kernel and other newer applications. An unreachable desire for some. I keep imagining CentOS, FreeBSD and other projects that focus on what really works, on stability.
Another possibly useful write-up for the Ubuntu users among us:
In particular, my attention was drawn to the little section in it entitled:
Benefits of WireGuard vs. Other VPNs
For someone like myself who depends upon remote access to help a totally non-technical friend who lives too far away for in-person help, I could easily set this or Tailscale up on any of his in-house network’s Ubuntu PCs and gain access WITHOUT having to wrangle with OpenVPN problems that are now in my way.
I saw both articles is being driven by ego, a whole Lotta handwaving and a lot of misunderstanding (deliberate and otherwise) on both sides. It’s also important to recognize that technical decisions are made on the basis of emotion, ego, ignorance, and imposter syndrome.
Let me illustrate why I say technical decisions are made based on ego and emotion through my tale of why I forking hate IPSec to the ends of the earth and if I could burn away anything or any knowledge related to IPSec, it would be a good way to spend my life.
Back when I was working with IPCop, we recognized that IPSec was a cluster fark. I tried really really hard to make incredibly simple user interface that solved the net to net problem. I almost succeeded but to be fair, it still took at least an hour of digging around to make it work.
Fast forward to today. In the past year alone IPSec has cost me close to $8000 in lost billable time. Every implementation I encounter is different and incompatible. Every vendor swears they are fully inherent to the standard. This means either they are completely full of crap or the standard is so bad it makes a dogs breakfast look appealing.
My latest loss was trying to connect to IPFire systems to each other by IPSec and also to a Cisco AS5508.
Problem 1) you can’t run IPSec over a red interface using DHCP. This only happens when IPSec is active, every time Comcast does a DHCP lease renewal, the red interface is shut down and restarted which temporarily breaks the VPN. If you have any persistent connection such as SSH, it fails.
I need to try and see if IP fire does the same interface breaking trick with open VPN. I’m more than willing to dig into the problem myself but there’s some demon triggering the interface shut down that I haven’t been able to figure out yet.
Problem 2) IPFire to IPFire. Should be simple but no. It runs for a while and then stops. Nothing’s changed. It just stops working. I kicked both ends, sometimes it restarts, sometimes it doesn’t. Thankfully open VPN is a couple orders of magnitude more reliable so I was able to ditch IPSec that circumstance.
Problem 3) one of the times I briefly got IPFire IPSec talking to the Cisco box, it would run fine for about three hours and then the key negotiation sequence would fail, the connection will break and then it would restart. For a month or two no one could track it down but although we knew was that SSH connections to the data center were breaking This one did serious damage to my client’s business, caused me serious reputation damage and I had to compensate them by giving them between $5000 to $6000 of free consulting.
You know what the reliable solution was? Running open VPN client net to net from one of the servers in the data center back to the office plus a little bit of router magic in the rack. It’s a bit of a kludge, I’m a little embarrassed to have them would say it but it took me an hour to get it to run and it just forking works.
Wireguard has its own challenges. It’s a different concept of a VPN than traditional ones. I am going to experiment with it and see if it’s more like open VPN or more like IPSec.
In conclusion, this is the year I tell IPSec to go fark itself for no other reason that it has driven me insane, cost me lots of money, and has been a complete and total forking pain in the ass. I hate it beyond all rational reason and this is why I say technical decisions are made on emotion and ego dressed up in the language of capx and opx.
Interesting way to think.
Developers and hardware providers deliver some crappy and “non standard” IPsec implementation, but the screwable thing is the protocol, not the developers.
Very interesting…
These are my experiences of successful IPSec connections
Zyxel -> Zyxel
Zyxel -> NetGear
Zyxel -> NethServer
NethServer -> Endian
Zyxel -> IpFire
NetGear -> IPFire
TP-Link -> Zyxel
The most unpleasant was the one related to NetGear, most of this due to the crappyness of the home router (DES as most safe protocol, 'nuff said). But i succeeded, even if it was not rock-stable as connection (dynamic ip addresses on both side of the tunnel, not the finest setup)
By my perspective, give me manuals and time, and i will connect any device with enough similar setup (if one side supports only DES and the other side supports only AES no way to let it work…)
Interesting view.
But I do not share the rest of your post. The VPN of course loses connectivity if RED goes down. I have no idea how wireguard will work around that.
The rest are simple configuration issues. IPsec works when it is configured correctly.
I am not sure if such hardware should be considered to be a part of a network. They might route packets but they simply don’t have the power to encrypt and decrypt fast enough.
That won’t change with wireguard either. DES is probably still faster than ChaCha20.
That’s just it. The red interface should not go down! There was no reason for the red interface to go down!
How do I find out why IPFire took down the red interface when IPSec was active and it got a DHCP lease renewal? If IPSec was disabled, the red interface stayed up.
They may be simple configuration issues but they are obscure problems. Is not enough information for a reasonably competent network person to be able to diagnose what is the problem and find a solution. How I know this? I had to Cisco trained engineers give up making IPSec work after hours research and trials.
IPSec is a brittle, easily broken system that has left me a bitter and broken person. You are right that when configured correctly, it does work. But when it doesn’t work, there’s nothing to lead you to a correct configuration. (Wait a minute, maybe it was my ex that left me bitter. But IPSec definitely broke me 
You either lost link or the DHCP lease expired.
If the lease is renewed we are not doing anything.
Are you using IKEv2 or 1?
IKEv2.
Once I learned what to look for, it was quite clear that the link loss was triggered when IPSec was up and a DHCP lease renewal happened. If IPSec was off, I could watch lease renewal after lease renewal without a problem.
OT for OT, DGN 2200v4 is currently my ADSL router. I’m looking for a VDSL-enabled with AC Wireless replacement, but it won’t go away into 30 minutes.