[Slavius]

Yet still it spreads lies. There's not only 4 pieces of information needed to establish IPsec (they even cannot count as they mention 5 pieces). In addition to named remote and local IP addresses, subnets and a pre-shared key you also need: * mode of operation (transport or tunnel) * exchange mode (base, main, aggressive or ikev2) * policy mode of operation (encrypt and/or protect - yes encryption is optional with IPsec) * Phase 1 parameters (hashing algorithm(s) + encryption algorithm(s)), key lifetime in bytes or seconds * Whether you/remote uses a PFS (if so, then also DH Group) * Phase 2 parameters (hashing algorithm(s) + encryption algorithm(s)), key lifetime in bytes or seconds * Whether or not to use NAT traversal (changes the protocols and ports needed to be opened on the firewall(s))

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

[Spivak]

I think the point is that if you “WireGuard-ify” IPSec and just fix all those parameters (e.g. take the vendor defaults) then you’re left with 5 pieces of information.

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.

[Slavius]

Are you saying that fixed parameters chosen for no apparent reason by the WireGuard developers are better than modularity and interoperability of IPsec? 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?