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.
1 Like
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.
1 Like
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 
1 Like
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.
Have you tried this again with core144? We have seen some attacks at a german cable provider that route dhcp answers from the internet to the customers which bring the dhcp client in trouble. The client was updated in core144.
Holy Cow! Such a… not pleasant scenario. Ok, the device should not be vulnerable, but the provider should not route packages like that on it’s network.
We tried to contact them, but did not get a response.
Sheet, happens. I also hope that their tech department can receive the hint/info and implement a solution for that.
The only portion of Tailscale’s blog article you need to read is the bold part…
“However, there are various scripts and higher-level tools (including ours) that make this work fine.”
There is his reason and ulterior motif, for writing such a motivational advertisement of brain-farts and bum-fluff.
Kindly note that Avery Pennarun repeatedly in his blog mentions that Wireguard does not support Dynamic to Dynamic IP connections. Not unless you haul out a blowtorch, angel-grinder, and sledgehammer. Sorry he said, scripts… which is more or less the same thing for a home user that has no clue, or just enough knowledge to make matters worse.
Avery admits the main “connection” needs to have a static IP. This means the home user, or SMEs, are not really Wireguard’s target market, and his aim to gradually replace “bottleneck” connections, brings us back to the original question from Michael’s article.
Why would a corporate or even VPN service supplier move away from the demons they know to a new devil-spawn that, by Avery’s own admittance, has not even remotely the same current capabilities?
Food for thought, or something else to consider is that for the past 3-4 years David Miller (the code maintainer, and maybe even Jason Donenfeld the founder of wireguard) have been hounding Linus Torvalds to include the Wireguard module into the Linux kernel. The community and Linus have been against it. Why would Linus cave to the demand if the product is not actually ready? In the world of 1984, that is the right question to ask.
2 Likes
Very well said and absolutely accurate. 
Hi,
we are using ipfire for years without huge problems. But now I have to build a wireguard connection coexisting with running IPSEC und OVPN networks. Because a remote station only supports wireguard. Not my decision …
I found that there was a old build of modules here: https://people.ipfire.org/~ummeegge/wireguard/
I guess that the modules are somewhat out of date. Are there any new modules for ipfire 2.2.5 core 146?
I would like to do some tests if possible.
If I cant get ipfire running with wireguard there are only 2 options:
- Add new redundant hardware to support wireguard at 2 locations -> expensive
- switch from ipfire to opensense -> many hours of learning to handle
Henning
Hi,
have deleted this package since it is an very old one which was for heavily asking people at that time. If you are interested in it, you can write me an PM for this.
Best,
Erik
1 Like
Up. After more than 3 years later.
Mind has changed?
Wireguard is being looked at for IPFire-3.x but not for IPFire-2.x
1 Like