Sounds like IP fragmentation. This is pretty normal with any VPN or tunnelling protocol unless the MTU is set correctly.

[1] https://en.wikipedia.org/wiki/IP_fragmentation

It's worse with VPNs like Wireguard because Wireguard only supports tunneling (e.g. IP in IP), which when you add the authentication header means a minimum of 3x the overhead of a regular connection, whereas IPSec encapsulation without tunneling only requires 2x the overhead (just the additional authentication header). Worse, Wireguard also requires UDP encapsulation (i.e. IP inside UDP+IP), which means 4x the overhead.

To be fair, IPSec tunneling is quite common (unsure if its the predominant mode) because tunneling makes routing easier. And for road warrior setups where the peer is often behind a NAT gateway, IPSec VPNs will also tend to use UDP. In such cases there's no advantage to IPSec.

IPSec is just usually an abysmal inane thing to set up, with defaults from the 90s and an extra bonus of error messages and documentation that just make you cuss. I don't recommend anyone IPSec, whatever it offers, after you spend all the time making sure your configuration is good, is really not worth it if you can do Wireguard or even OpenVPN. Ugh, I'm annoyed just thinking about it again.

The best part is when you find out your phone supports set of parameters A, your tablet set of parameters B and your MacBook set of parameters C.... and there's no intersection between sets.

Complexity is the n.1 enemy of security and IPsec is horribly complex.

Wireguard is very lean and simple.

ipsec is complex because it can be used in a LOT of situations.

can wireguard do tunnel state detection? Can i do a hub and spoke topology with wireguard? or auto-vpn?

ipsec is complex because it is mainly designed as a tunnel protocol with encryption. (site-to-site), compared to the "road warrior" setup wireguard seems more useful for.

Things you can't do with wireguard (unless you use workarounds like iptables, etc):

* bind a tunnel to a certain interface/ip

* use same port for different tunnels (with same ip or separate iface/ip)

* specify a fixed peer ip/port (or network, interface to use)

* use tunnel in tunnel (with kernel implementation, unless you get creative)

Yes to all the questions.

mind you ipsec in AH mode does NOT encrypt packets. ESP (and thus tunneling) is required for packet level encryption.

your encapsulation argument still holds true however.

Make sure you don’t block ICMP, which is used by Path MTU Discovery [0].

Blocking ICMP may result in black holed connections. I experienced this just like you with websites not working, and with ssh freezing when doing an ll in a directory with a large number of files, or even when starting mc. In my case, an upstream server was blocking ICMP for no good reason (there’s never a good reason to do it permanently, really).

[0]: https://en.m.wikipedia.org/wiki/Path_MTU_Discovery

Ehm, make sure you don't block parts of ICMP important in given network circumstances.

Many types of ICMP messages can be very nasty. ICMP and ICMPv6 RFCs actually describe which messages are importatnt and should not be blocked in any networks, which are dangerous and should be restricted, and varieties between.