MTU size for IPsec connection?

[dmgeurts]

For the time being I've fixed the user experience by setting MSS through a policy for traffic to/from IPsec. However, I'd like to ensure I get the issue fixed properly in case a client ignores MSS or uses UDP.

Note the RTT in the following two pings:

Code Select Expand

user@server:~$ ping -M do -s 1400 192.168.104.1
PING 192.168.104.1 (192.168.104.1) 1400(1428) bytes of data.
1408 bytes from 192.168.104.1: icmp_seq=2 ttl=62 time=735 ms
1408 bytes from 192.168.104.1: icmp_seq=4 ttl=62 time=733 ms
^C
--- 192.168.104.1 ping statistics ---
4 packets transmitted, 2 received, 50% packet loss, time 3077ms
rtt min/avg/max/mdev = 732.831/734.164/735.498/1.333 ms

user@server:~$ ping -M do -s 1398 192.168.104.1
PING 192.168.104.1 (192.168.104.1) 1398(1426) bytes of data.
1406 bytes from 192.168.104.1: icmp_seq=1 ttl=62 time=24.7 ms
1406 bytes from 192.168.104.1: icmp_seq=2 ttl=62 time=25.8 ms
^C
--- 192.168.104.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 24.732/25.269/25.807/0.537 ms

I'd rather the 1400-byte ping gets dropped than see this delay. The problem is that TCP windowing won't adjust down with a delay of 700 msec, but it will have a big impact on the speed of transfers. How UDP handles this will be down to the application, but it can't be helpful there either.

What could be causing this jump in latency from 25 to 735 msec?

Setting the LAN interface MTU to 1426 would certainly be one option, but one I'd like to avoid as this would affect traffic between LAN interfaces and unencrypted traffic to/from the WAN.

Sadly OPNsense doesn't expose a way to set the MTU on a simple (non-VTI) IPsec tunnel. Strongswan does have the option of `charon.plugins.kernel-netlink.mtu` but I've not found a way to test this without breaking IPsec.

[danderson]

I do this via MSS and have for years, no issues or concerns using MSS instead of setting MTU on the interface.