[strongSwan] Cannot connect to IPsec gateway in a roadwarrior scenario because of large packet lengths
noel.kuntze+strongswan-users-ml at thermi.consulting
Wed Sep 27 02:17:33 CEST 2017
UDP packets can not be fragmented on the transport layer. UDP packets represent a complete datagram, not a byte stream like TCP. Fragmentation needs to be implemented on the application layer, which is what charon supports with IKEv1 and IKEv2 fragmentation, configurable with fragmentation=yes, which enables support for it. It is used, if the remote peer indicates support for it as well.
Yes, the problem is caused by your new ISP (or some other hop to the other peer) dropping IP fragments.
On 23.09.2017 18:46, Anvar Kuchkartaev wrote:
> You can use fragmentation=yes option in your server side configuration file and authentication request/responce will be fragmented before forming ip packets.
> Anvar Kuchkartaev
> anvar at anvartay.com
> *From: *Олег Пруц
> *Sent: *sábado, 23 de septiembre de 2017 05:09 p.m.
> *To: *users at lists.strongswan.org
> *Subject: *[strongSwan] Cannot connect to IPsec gateway in a roadwarrior scenario because of large packet lengths
> Hello strongSwan team,
> Thank you for your great job. You are enabling user privacy and internet freedom for people really concerned with this. As for me, this is my use case: I purchased AWS instance with Ubuntu 16.04.2 and installed strongSwan on it, so I was successfully connecting from my home computer to it and was able to bypass restrictions.
> However, as I have to use another network now, the connection is not establishing anymore. I did IP packet captures both on the server and on my machine and found out that the server fragments packets and sends packets with size larger than my MTU during key exchange. I set server MTU to be 1000, but fragmentation is still there, and fragmented packets do not pass to my machine. It seems to be an issue with my new ISP which does not handle fragmented packets.
> I can supply the captures if necessary.
> Oleg Prutz
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the Users