Limit path MTU of IPsec between hosts

[Noel Kuntze]

Hello list,

I'm running into some problems with IPsec, because of a low path MTU.
What happens is, that the ESP packets get fragmented by some router on the network path between the hosts.
That stops some websites from loading.
Is there a way to limit the mss that is encapsulated into the ESP packets
and/or cause fragmentation on either of the endpoints?

Regards,
Noel Kuntze

- --
GPG Key id: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658

[Tobias Brunner]

Hi Noel,

Post by Noel Kuntze
Is there a way to limit the mss that is encapsulated into the ESP packets
and/or cause fragmentation on either of the endpoints?

You can do so via iptables [1] or the patches at [2].

Regards,
Tobias

[1] http://lartc.org/howto/lartc.cookbook.mtu-mss.html
[2] https://wiki.strongswan.org/issues/632#note-14

[Noel Kuntze]

Hello Tobias,

I tried the iptables commands on the VPN endpoint, which SNATs the connections to the internet, but that didn't work.
What worked was doing it on the VPN initiator in my LAN, which connects to the internet over the other endpoint. No idea why only that works.
Thanks!

Regards,
Noel Kuntze

GPG Key id: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658

Post by Tobias Brunner
Hi Noel,

Post by Noel Kuntze
Is there a way to limit the mss that is encapsulated into the ESP packets
and/or cause fragmentation on either of the endpoints?

You can do so via iptables [1] or the patches at [2].
Regards,
Tobias
[1] http://lartc.org/howto/lartc.cookbook.mtu-mss.html
[2] https://wiki.strongswan.org/issues/632#note-14

[Johannes Hubertz]

Hello Noel, Tobias and Listreaders.

I'm oing on the strongswan gateway (4.5.2) based on Debian following
setting:

iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1280

Changing PCs behind the gateway is not neccessary. But it might be agood
idea to have the iptables on both ends of the IPsec-tunnel.

That solves? perhaps more than I need, but it works well.

Kind regards, happy working
Johannes

Post by Noel Kuntze
Hello Tobias,
I tried the iptables commands on the VPN endpoint, which SNATs the connections to the internet, but that didn't work.
What worked was doing it on the VPN initiator in my LAN, which connects to the internet over the other endpoint. No idea why only that works.
Thanks!
Regards,
Noel Kuntze
GPG Key id: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658

Post by Tobias Brunner
Hi Noel,

Post by Noel Kuntze
Is there a way to limit the mss that is encapsulated into the ESP packets
and/or cause fragmentation on either of the endpoints?

You can do so via iptables [1] or the patches at [2].
Regards,
Tobias
[1] http://lartc.org/howto/lartc.cookbook.mtu-mss.html
[2] https://wiki.strongswan.org/issues/632#note-14

_______________________________________________
Users mailing list
https://lists.strongswan.org/mailman/listinfo/users

[Noel Kuntze]

Hello Johannes,m Tobias and Listreaders,

I still have problems with hosts on the network that send packets with length > pmtu/mss and df bit set.
That generates an ICMP HOST UNREACHABLE (FRAGMENTATION NEEDED) error message that is sent by the ds-lite gateway to the VPN endpoint in the LAN.
Is there a way to relay that icmp error message to the original sender or force fragmentation on the VPN endpoint?

Regards,
Noel Kuntze

GPG Key id: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658

Post by Johannes Hubertz
Hello Noel, Tobias and Listreaders.
I'm oing on the strongswan gateway (4.5.2) based on Debian following
iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1280
Changing PCs behind the gateway is not neccessary. But it might be agood
idea to have the iptables on both ends of the IPsec-tunnel.
That solves? perhaps more than I need, but it works well.
Kind regards, happy working
Johannes

Post by Noel Kuntze
Hello Tobias,
I tried the iptables commands on the VPN endpoint, which SNATs the connections to the internet, but that didn't work.
What worked was doing it on the VPN initiator in my LAN, which connects to the internet over the other endpoint. No idea why only that works.
Thanks!
Regards,
Noel Kuntze
GPG Key id: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658

Post by Tobias Brunner
Hi Noel,

Post by Noel Kuntze
Is there a way to limit the mss that is encapsulated into the ESP packets
and/or cause fragmentation on either of the endpoints?

You can do so via iptables [1] or the patches at [2].
Regards,
Tobias
[1] http://lartc.org/howto/lartc.cookbook.mtu-mss.html
[2] https://wiki.strongswan.org/issues/632#note-14

_______________________________________________
Users mailing list
https://lists.strongswan.org/mailman/listinfo/users

[Johannes Hubertz]

Hello Noel and Listreaders,

if your gateway is sending esp packets which need to be fragmented, the
only way to change this is by setting smaller mtu-sizes on the outgoing
interfaces of those hosts, which are sending these ESP-packets. The
behavior of ESP is totally independend from tcp-mss, sorry for my
misreading of your first mail.

Pehaps you like to find out a maximum usable mtu-size by sending pings
with icnreasing paket-sizes (-s xyz) while watching with tcpdump, whats
coming back. Of course, icmp echo-request and echo-reply must not be
filtered on your gateways in INPUT and OUTPUT chains. And you need to
run tcpdump on the gateway(s) or on a router in between them.

Happy working,
Have fun!

Johannes

[Noel Kuntze]

Hello Johannes and list readers,

Getting the mtu isn't a real fix, because the kernel copies the df bit from the encapsulated packet onto the ESP packet. I saw that using tcpdump and wireshark on the local VPN endpoint.
Maybe setting a low path mtu for the route over the gateway fixes that (mtu lock 1400), so the local VPN endpoint sends ICMP error messages to the actual sender to tell it to fragment the packet.

Regards,
Noel Kuntze

GPG Key id: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658

Post by Johannes Hubertz
Hello Noel and Listreaders,
if your gateway is sending esp packets which need to be fragmented, the
only way to change this is by setting smaller mtu-sizes on the outgoing
interfaces of those hosts, which are sending these ESP-packets. The
behavior of ESP is totally independend from tcp-mss, sorry for my
misreading of your first mail.
Pehaps you like to find out a maximum usable mtu-size by sending pings
with icnreasing paket-sizes (-s xyz) while watching with tcpdump, whats
coming back. Of course, icmp echo-request and echo-reply must not be
filtered on your gateways in INPUT and OUTPUT chains. And you need to
run tcpdump on the gateway(s) or on a router in between them.
Happy working,
Have fun!
Johannes

[Noel Kuntze]

Oh and what I forgot was, that the kernel doesn't fragment the ESP packet and just sends it, ignoring the discovered path mtu.

GPG Key id: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658

Post by Johannes Hubertz
Hello Noel and Listreaders,
if your gateway is sending esp packets which need to be fragmented, the
only way to change this is by setting smaller mtu-sizes on the outgoing
interfaces of those hosts, which are sending these ESP-packets. The
behavior of ESP is totally independend from tcp-mss, sorry for my
misreading of your first mail.
Pehaps you like to find out a maximum usable mtu-size by sending pings
with icnreasing paket-sizes (-s xyz) while watching with tcpdump, whats
coming back. Of course, icmp echo-request and echo-reply must not be
filtered on your gateways in INPUT and OUTPUT chains. And you need to
run tcpdump on the gateway(s) or on a router in between them.
Happy working,
Have fun!
Johannes