[strongSwan] Cannot connect to IPsec gateway in a roadwarrior scenario because of large packet lengths
Олег Пруц
olegp04728 at gmail.com
Thu Oct 5 15:12:44 CEST 2017
Thanks to your advice I resolved the problem and managed to connect using
IKE fragmentation. I had to install the latest (5.6.0) version of
strongSwan and set `fragmentation=yes` on both client and server because
fragmentation does not work for IKEv2 before 5.2.1 (the most recent version
for Ubuntu 14.04 is 5.1.2). That also means I had to set up an ipsec.conf
profile instead of using Network Manager.
Thanks,
Oleg Prutz
2017-09-28 13:55 GMT+03:00 Anvar Kuchkartaev <anvar at anvartay.com>:
> I had problem with some clients connecting from restricted networks the
> service providers where filtering out the last 1 or 2 fragments of
> authentication response and connections were being failed. Try to create
> non network manager connection profile to strongswan's ipsec.conf on client
> and bring up connection from root terminal via:
>
> strongswan up [connection name]
>
> At the same time monitor server logs to see which step failing every time.
> The other possible problem is AWS instances uses jumbo packets by default
> (MTU is 9000) and this might cause packet fragmentation on AWS side. You
> can decrease MTU of amazon instance to standard 1500 by command:
>
> Ifconfig eth0 mtu 1500
>
> Anvar Kuchkartaev
> anvar at anvartay.com
> *From: *Олег Пруц
> *Sent: *jueves, 28 de septiembre de 2017 09:09 a.m.
> *To: *Noel Kuntze
> *Cc: *Anvar Kuchkartaev; Users at lists.strongswan.org
> *Subject: *Re: [strongSwan] Cannot connect to IPsec gateway in a
> roadwarrior scenario because of large packet lengths
>
> Ok, I just created a new ec2 instance, generated a new server certificate
> and set up strongswan so let's say the authentication problem is solved.
> There is still original problem: I cannot establish connection due to
> fragmentation filtering and when I add 'fragmentation=yes' in conn %default
> section, strongswan does not seem to notice it, which can be seen from the
> logs after I run 'sudo ipsec restart':
>
> Sep 28 06:43:53 ******** charon: 11[CFG] received stroke: add connection
> 'IPSec-IKEv2'
> Sep 28 06:43:53 ******** charon: 11[CFG] conn IPSec-IKEv2
> Sep 28 06:43:53 ******** charon: 11[CFG] left=%any
> Sep 28 06:43:53 ******** charon: 11[CFG] leftsubnet=0.0.0.0/0
> Sep 28 06:43:53 ******** charon: 11[CFG] leftcert=server2Cert.pem
> Sep 28 06:43:53 ******** charon: 11[CFG] right=%any
> Sep 28 06:43:53 ******** charon: 11[CFG] rightsourceip=172.16.16.0/24
> Sep 28 06:43:53 ******** charon: 11[CFG] rightdns=31.3.135.232,87.98.17
> 5.85
> Sep 28 06:43:53 ******** charon: 11[CFG] ike=aes128-sha256-ecp256,aes25
> 6-sha384-ecp384,aes128-sha256-modp2048,aes128-sha1-modp2048,
> aes256-sha384-modp4096,aes25$
> -sha256-modp4096,aes256-sha1-modp4096,aes128-sha256-modp1536
> ,aes128-sha1-modp1536,aes256-sha384-modp2048,aes256-sha256-
> modp2048,aes256-sha1-modp2048,aes128-sha256-modp$
> 024,aes128-sha1-modp1024,aes256-sha384-modp1536,aes256-sha25
> 6-modp1536,aes256-sha1-modp1536,aes256-sha384-modp1024,
> aes256-sha256-modp1024,aes256-sha1-modp1024!
> Sep 28 06:43:53 ******** charon: 11[CFG] esp=aes128gcm16-ecp256,aes256g
> cm16-ecp384,aes128-sha256-ecp256,aes256-sha384-ecp384,
> aes128-sha256-modp2048,aes128-sha1$
> modp2048,aes256-sha384-modp4096,aes256-sha256-modp4096,
> aes256-sha1-modp4096,aes128-sha256-modp1536,aes128-sha1-
> modp1536,aes256-sha384-modp2048,aes256-sha256-modp2048,a$
> s256-sha1-modp2048,aes128-sha256-modp1024,aes128-sha1-modp10
> 24,aes256-sha384-modp1536,aes256-sha256-modp1536,aes256-
> sha1-modp1536,aes256-sha384-modp1024,aes256-sha256-$
> odp1024,aes256-sha1-modp1024,aes128gcm16,aes256gcm16,aes128-
> sha256,aes128-sha1,aes256-sha384,aes256-sha256,aes256-sha1!
> Sep 28 06:43:53 ******** charon: 11[CFG] dpddelay=300
> Sep 28 06:43:53 ******** charon: 11[CFG] dpdtimeout=150
> Sep 28 06:43:53 ******** charon: 11[CFG] dpdaction=1
> Sep 28 06:43:53 ******** charon: 11[CFG] mediation=no
> Sep 28 06:43:53 ******** charon: 11[CFG] keyexchange=ikev2
> Sep 28 06:43:53 ******** charon: 11[CFG] adding virtual IP address pool
> 172.16.16.0/24
> Sep 28 06:43:53 ******** charon: 11[CFG] loaded certificate "******"
> from 'server2Cert.pem'
> Sep 28 06:43:53 ******** charon: 11[CFG] id '%any' not confirmed by
> certificate, defaulting to '******'
> Sep 28 06:43:53 ******** charon: 11[CFG] added configuration 'IPSec-IKEv2'
> Sep 28 06:43:53 ******** charon: 13[CFG] received stroke: add connection
> 'IPSec-IKEv2-EAP'
> Sep 28 06:43:53 ******** charon: 13[CFG] conn IPSec-IKEv2-EAP
> Sep 28 06:43:53 ******** charon: 13[CFG] left=%any
> Sep 28 06:43:53 ******** charon: 13[CFG] leftsubnet=0.0.0.0/0
> Sep 28 06:43:53 ******** charon: 13[CFG] leftcert=server2Cert.pem
> Sep 28 06:43:53 ******** charon: 13[CFG] right=%any
> Sep 28 06:43:53 ******** charon: 13[CFG] rightsourceip=172.16.16.0/24
> Sep 28 06:43:53 ******** charon: 13[CFG] rightdns=31.3.135.232,87.98.17
> 5.85
> Sep 28 06:43:53 ******** charon: 13[CFG] rightauth=eap-mschapv2
> Sep 28 06:43:53 ******** charon: 13[CFG] eap_identity=%any
> Sep 28 06:43:53 ******** charon: 13[CFG] ike=aes128-sha256-ecp256,aes25
> 6-sha384-ecp384,aes128-sha256-modp2048,aes128-sha1-modp2048,
> aes256-sha384-modp4096,aes256
> -sha256-modp4096,aes256-sha1-modp4096,aes128-sha256-modp1536
> ,aes128-sha1-modp1536,aes256-sha384-modp2048,aes256-sha256-
> modp2048,aes256-sha1-modp2048,aes128-sha256-modp1
> 024,aes128-sha1-modp1024,aes256-sha384-modp1536,aes256-sha25
> 6-modp1536,aes256-sha1-modp1536,aes256-sha384-modp1024,
> aes256-sha256-modp1024,aes256-sha1-modp1024!
> Sep 28 06:43:53 ******** charon: 13[CFG] esp=aes128gcm16-ecp256,aes256g
> cm16-ecp384,aes128-sha256-ecp256,aes256-sha384-ecp384,
> aes128-sha256-modp2048,aes128-sha1-
> modp2048,aes256-sha384-modp4096,aes256-sha256-modp4096,
> aes256-sha1-modp4096,aes128-sha256-modp1536,aes128-sha1-
> modp1536,aes256-sha384-modp2048,aes256-sha256-modp2048,ae
> s256-sha1-modp2048,aes128-sha256-modp1024,aes128-sha1-modp10
> 24,aes256-sha384-modp1536,aes256-sha256-modp1536,aes256-
> sha1-modp1536,aes256-sha384-modp1024,aes256-sha256-m
> odp1024,aes256-sha1-modp1024,aes128gcm16,aes256gcm16,aes128-
> sha256,aes128-sha1,aes256-sha384,aes256-sha256,aes256-sha1!
> Sep 28 06:43:53 ******** charon: 13[CFG] dpddelay=300
> Sep 28 06:43:53 ******** charon: 13[CFG] dpdtimeout=150
> Sep 28 06:43:53 ******** charon: 13[CFG] dpdaction=1
> Sep 28 06:43:53 ******** charon: 13[CFG] mediation=no
> Sep 28 06:43:53 ******** charon: 13[CFG] keyexchange=ikev2
> Sep 28 06:43:53 ******** charon: 13[CFG] reusing virtual IP address pool
> 172.16.16.0/24
> Sep 28 06:43:53 ******** charon: 13[CFG] loaded certificate "******"
> from 'server2Cert.pem'
> Sep 28 06:43:53 ******** charon: 13[CFG] id '%any' not confirmed by
> certificate, defaulting to '******'
> Sep 28 06:43:53 ******** charon: 13[CFG] added configuration
> 'IPSec-IKEv2-EAP'
> Sep 28 06:43:53 ******** charon: 14[CFG] received stroke: add connection
> 'CiscoIPSec'
> Sep 28 06:43:53 ******** charon: 14[CFG] conn CiscoIPSec
> Sep 28 06:43:53 ******** charon: 14[CFG] left=%any
> Sep 28 06:43:53 ******** charon: 14[CFG] leftsubnet=0.0.0.0/0
> Sep 28 06:43:53 ******** charon: 14[CFG] leftcert=server2Cert.pem
> Sep 28 06:43:53 ******** charon: 14[CFG] right=%any
> Sep 28 06:43:53 ******** charon: 14[CFG] rightsourceip=172.16.16.0/24
> Sep 28 06:43:53 ******** charon: 14[CFG] rightdns=31.3.135.232,87.98.17
> 5.85
> Sep 28 06:43:53 ******** charon: 14[CFG] rightauth=pubkey
> Sep 28 06:43:53 ******** charon: 14[CFG] rightauth2=xauth
> Sep 28 06:43:53 ******** charon: 14[CFG] ike=aes128-sha256-ecp256,aes25
> 6-sha384-ecp384,aes128-sha256-modp2048,aes128-sha1-modp2048,
> aes256-sha384-modp4096,aes256
> -sha256-modp4096,aes256-sha1-modp4096,aes128-sha256-modp1536
> ,aes128-sha1-modp1536,aes256-sha384-modp2048,aes256-sha256-
> modp2048,aes256-sha1-modp2048,aes128-sha256-modp1
> 024,aes128-sha1-modp1024,aes256-sha384-modp1536,aes256-sha25
> 6-modp1536,aes256-sha1-modp1536,aes256-sha384-modp1024,
> aes256-sha256-modp1024,aes256-sha1-modp1024!
> Sep 28 06:43:53 ******** charon: 14[CFG] esp=aes128gcm16-ecp256,aes256g
> cm16-ecp384,aes128-sha256-ecp256,aes256-sha384-ecp384,
> aes128-sha256-modp2048,aes128-sha1-
> modp2048,aes256-sha384-modp4096,aes256-sha256-modp4096,
> aes256-sha1-modp4096,aes128-sha256-modp1536,aes128-sha1-
> modp1536,aes256-sha384-modp2048,aes256-sha256-modp2048,ae
> s256-sha1-modp2048,aes128-sha256-modp1024,aes128-sha1-modp10
> 24,aes256-sha384-modp1536,aes256-sha256-modp1536,aes256-
> sha1-modp1536,aes256-sha384-modp1024,aes256-sha256-m
> odp1024,aes256-sha1-modp1024,aes128gcm16,aes256gcm16,aes128-
> sha256,aes128-sha1,aes256-sha384,aes256-sha256,aes256-sha1!
> Sep 28 06:43:53 ******** charon: 14[CFG] dpddelay=300
> Sep 28 06:43:53 ******** charon: 14[CFG] dpdtimeout=150
> Sep 28 06:43:53 ******** charon: 14[CFG] dpdaction=1
> Sep 28 06:43:53 ******** charon: 14[CFG] mediation=no
> Sep 28 06:43:53 ******** charon: 14[CFG] keyexchange=ikev1
> Sep 28 06:43:53 ******** charon: 14[CFG] reusing virtual IP address pool
> 172.16.16.0/24
> Sep 28 06:43:53 ******** charon: 14[CFG] loaded certificate "******"
> from 'server2Cert.pem'
> Sep 28 06:43:53 ******** charon: 14[CFG] id '%any' not confirmed by
> certificate, defaulting to '******'
> Sep 28 06:43:53 ******** charon: 14[CFG] added configuration 'CiscoIPSec'
>
> In case it matters, I used this guide for setup:
> https://www.zeitgeist.se/2013/11/22/strongswan-howto-create-your-own-vpn/
>
> My strongSwan version:
> Linux strongSwan U5.3.5/K4.4.0-1022-aws
>
> 2017-09-27 3:17 GMT+03:00 Noel Kuntze <noel.kuntze+strongswan-users-
> ml at thermi.consulting>:
>
>> Hi,
>>
>> 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.
>>
>> Kind regards
>>
>> Noel
>>
>> 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.
>> >
>> > Regards,
>> > Oleg Prutz
>> >
>> >
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20171005/498fa135/attachment-0001.html>
More information about the Users
mailing list