But to be fair, this doesn't work perfectly (especially if you have certain firewall rules that block UDP packets if they're not part of the what the firewall thinks is the same "connection", if both peers change their IP at the same time, or if the peer whose IP changed was rebooted or reconfigured before the other peer received a packet from its new IP addreds) but it really does work surprisingly well. For those (important) corner-cases, I would imagine that higher-level tooling such as NetworkManager would do the DNS checks you're talking about.
The non-roaming end (end with a known endpoint) will update the IP of the roaming end every time a handshake occurs. The issue the OP is getting at though is when both ends are roaming. In this case the, er, "more roaming" peer needs some way to find the other peer. There are a lot of technically interesting ways that we could solve this problem, but in practice it's pretty much always solved by dynamically updating a DNS record. I would say Wireguard handles this scenario about as well as anything else (maybe a little worse, see sibling comment).
Another approach would be using a "meet-me" relay with a fixed IP, such as TURN. This also has the advantage of handling NAT on both sides (which would be a common issue with a roaming-to-roaming situation). I can't think of any reason it's impossible to run Wireguard through TURN but I can't find any examples of anyone doing so, likely in part because the TURN client is usually embedded in the application and is a bit complicated. Still, might be a hobby project to implement it for Wireguard.
That said, I do believe both IPv6 and OpenVPN will have this exact same problem - IP change will not be reflected until something forces setup to repeat. The difference would be that these, at least I do believe, will re-resolve on retries. Wireguard doesn't really have a sense of "retrying the connection" which makes it sort of philosophically difficult for it to do so.
Once I move into the network that has the respective VPN endpoint, the subnets that are routable via wg become routable via ethernet/wifi which have higher priority, so the traffic will go directly.
If you don't know some of these parameters chances are you won't be able to establish the tunnel no matter how hard you try.
Plus you need to know all the vendor quirks as establishing IPsec from Cisco to Fortigate or Sophos is not straightforward.
Then you may end up playing with NAT-exclusions, SNAT/DNAT if both sides of the tunnel have the same or overlapping IP ranges.
Setting up IPsec is definitely not an exchange of 4 parameters...
If the value of WG is just that it forces all these parameters to be static then the best thing we could do is come up with the “WireGuard” IPSec profile call it a day.
It's a very weird assertion that the Wireguard devs just threw the software together at random, choosing parameters for "no apparent reason".
> What if in a few months ChaCha20 gets proven insecure due to collisions found or easy factorisation? What can WireGuard offer to mitigate that? Shouldn't then also browsers implement only TLS1.3 and ed25519 ciphers because they are currently the most secure?
TLS is famously susceptible to downgrade attacks. (https://blog.ivanristic.com/2013/09/is-beast-still-a-threat.... etc.)
Ultimately, it's a value judgement. You can either have resistance to downgrade attacks (which have themselves proven to be quite problematic), or you have interoperability across multiple versions and configurations of endpoints. Increase the configurability of the protocol, and you massively increase the complexity. Increased complexity means increased testing burden and ultimately increased risk.
If Wireguard needs to be fixed in a backwards-incompatible way, then we'll find ourselves with a new version of Wireguard that doesn't work with the old version.
Right, and maybe this is actually in improvement in security overall but it just externalizes the downgrade attack since once there are multiple versions of WG floating around with different vendors/clients only supporting a specific version you end up similarly vulnerable since you need to run multiple WG endpoints of different versions.
And since it’s a kernel module you’ve made the hassle of doing so very annoying compared to one line in a config file.
IPSec feels messy and complex specifically because the world is messy and complex. WG is fantastic and I love it dearly for “the 90% case” where I have total control over all peers.
The article is from 8 years ago so I would suggest that the fame has mostly faded. TLS downgrade attacks are not a thing in practice. A system with non-upgradable and broken crypto is much worse than something that requires a MITM attack to get at the broken crypto. I am not sure why there are opinions to the contrary. In either case you still have to fix things. The non-upgradable case will just be much much harder.
The section discussing dynamic IP addresses seems to be based on a misunderstanding of Wireguard. The IP addresses that must be statically established in Wireguard are the addresses used inside of the tunnel, and are independent of the public (internet) IPs of the machines involved. The wg-dynamic daemon mentioned is a system for dynamically allocating IP addresses in the tunnel, and has so far not been completed, at least in part because it's not very obvious why you would want to do this (although in general the development of an in-band configuration standard for Wireguard has useful implications).
Wireguard allows you to identify the endpoint using a DNS name, which means you can handle a 'server' with a dynamic IP address by dynamically updating the DNS record - a common approach that is no doubt exactly what ipfire supports doing for ipsec.
In the end, though, the article just suffers from being an apples-to-oranges comparison. Wireguard is a VPN tunnel protocol implementation, ipfire is some sort of GUI frontend for managing a bunch of network tools. Of course ipfire has quite a few more features than wireguard.