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
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…)
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
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.
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.
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.
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
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.
