[Swan] IKEv2 connection from Android drops after a few minutes

Beat Zahnd beat.zahnd at gmail.com
Thu Mar 5 20:26:58 UTC 2020


Thanks for the hint. 

According to https://wiki.strongswan.org/projects/strongswan/wiki/AndroidVPNClient mobike seems to be suported. And it seems to work. When I arrive at home and the phone goes to WiFi the connection stays up.

Do not yet really understand how the client (mobile phone) shall detect that the cellular proider NAT changes the port number.

I recently switched from raccoon/xl2tpd to libreswan IKEv2. Using the Android standard VPN client this was never a problem.

> On 5 Mar 2020, at 21:16, Paul Wouters <paul at nohats.ca> wrote:
> 
> You need to enable mobike on the client? Not sure if strongswan supports that ?
> 
> The keepalivr won’t help if the phone goes to sleep 
> 
> Sent from my iPhone
> 
>> On Mar 5, 2020, at 14:58, Beat Zahnd <beat.zahnd at gmail.com> wrote:
>> 
>> Yes, just discovered this:
>> 
>> 20:43:26.048376 IP 84.75.x.x.4500 > 178.197.x.x.21977: UDP-encap: ESP(spi=0xbe045de8,seq=0x178), length 88
>> 20:43:26.080322 IP 84.75.x.x.4500 > 178.197.x.x.21977: UDP-encap: ESP(spi=0xbe045de8,seq=0x179), length 88
>> 20:43:26.164652 IP 178.197.x.x.21977 > 84.75.x.x.4500: UDP-encap: ESP(spi=0x85bb58ce,seq=0x178), length 88
>> 20:43:26.166635 IP 178.197.x.x.21977 > 84.75.x.x.4500: UDP-encap: ESP(spi=0x85bb58ce,seq=0x179), length 88
>> 20:43:26.168593 IP 178.197.x.x.21977 > 84.75.x.x.4500: UDP-encap: ESP(spi=0x85bb58ce,seq=0x17a), length 88
>> 20:43:26.214647 IP 178.197.x.x.21977 > 84.75.x.x.4500: UDP-encap: ESP(spi=0x85bb58ce,seq=0x17b), length 100
>> 20:43:26.216616 IP 178.197.x.x.21977 > 84.75.x.x.4500: UDP-encap: ESP(spi=0x85bb58ce,seq=0x17c), length 100
>> 20:43:26.218614 IP 178.197.x.x.21977 > 84.75.x.x.4500: UDP-encap: ESP(spi=0x85bb58ce,seq=0x17d), length 100
>> 20:43:26.220576 IP 178.197.x.x.21977 > 84.75.x.x.4500: UDP-encap: ESP(spi=0x85bb58ce,seq=0x17e), length 100
>> 20:43:26.222600 IP 178.197.x.x.21977 > 84.75.x.x.4500: UDP-encap: ESP(spi=0x85bb58ce,seq=0x17f), length 100
>> 20:44:45.725612 IP 178.197.x.x.21977 > 84.75.x.x.4500: UDP-encap: ESP(spi=0x85bb58ce,seq=0x180), length 88
>> 20:44:45.725670 IP 178.197.x.x.21977 > 84.75.x.x.4500: UDP-encap: ESP(spi=0x85bb58ce,seq=0x181), length 88
>> 20:44:45.725681 IP 178.197.x.x.21977 > 84.75.x.x.4500: UDP-encap: ESP(spi=0x85bb58ce,seq=0x182), length 88
>> 20:44:45.725849 IP 84.75.x.x.4500 > 178.197.x.x.21977: UDP-encap: ESP(spi=0xbe045de8,seq=0x17a), length 88
>> 20:44:45.726333 IP 178.197.x.x.21977 > 84.75.x.x.4500: UDP-encap: ESP(spi=0x85bb58ce,seq=0x183), length 88
>> 
>> 20:47:52.022713 IP 178.197.x.x.21978 > 84.75.x.x.4500: UDP-encap: ESP(spi=0x85bb58ce,seq=0x184), length 88
>> 20:47:52.022804 IP 178.197.x.x.21978 > 84.75.x.x.4500: UDP-encap: ESP(spi=0x85bb58ce,seq=0x185), length 88
>> 20:47:52.022836 IP 178.197.x.x.21978 > 84.75.x.x.4500: UDP-encap: ESP(spi=0x85bb58ce,seq=0x186), length 88
>> 20:47:52.022858 IP 178.197.x.x.21978 > 84.75.x.x.4500: UDP-encap: ESP(spi=0x85bb58ce,seq=0x187), length 88
>> 20:47:52.022879 IP 178.197.x.x.21978 > 84.75.x.x.4500: UDP-encap: ESP(spi=0x85bb58ce,seq=0x188), length 88
>> 20:47:52.022892 IP 178.197.x.x.21978 > 84.75.x.x.4500: UDP-encap: ESP(spi=0x85bb58ce,seq=0x189), length 88
>> 20:47:52.022909 IP 178.197.x.x.21978 > 84.75.x.x.4500: UDP-encap: ESP(spi=0x85bb58ce,seq=0x18a), length 88
>> 20:47:52.022922 IP 178.197.x.x.21978 > 84.75.x.x.4500: UDP-encap: ESP(spi=0x85bb58ce,seq=0x18b), length 88
>> 20:47:52.024400 IP 178.197.x.x.21978 > 84.75.x.x.4500: UDP-encap: ESP(spi=0x85bb58ce,seq=0x18c), length 88
>> 20:47:52.041538 IP 178.197.x.x.21978 > 84.75.x.x.4500: UDP-encap: ESP(spi=0x85bb58ce,seq=0x18d), length 96
>> 20:47:52.041633 IP 178.197.x.x.21978 > 84.75.x.x.4500: UDP-encap: ESP(spi=0x85bb58ce,seq=0x18e), length 88
>> 20:47:52.041674 IP 178.197.x.x.21978 > 84.75.x.x.4500: UDP-encap: ESP(spi=0x85bb58ce,seq=0x18f), length 88
>> 20:47:52.041701 IP 178.197.x.x.21978 > 84.75.x.x.4500: UDP-encap: ESP(spi=0x85bb58ce,seq=0x190), length 88
>> 20:47:52.041725 IP 178.197.x.x.21978 > 84.75.x.x.4500: UDP-encap: ESP(spi=0x85bb58ce,seq=0x191), length 88
>> 20:47:52.041745 IP 178.197.x.x.21978 > 84.75.x.x.4500: UDP-encap: ESP(spi=0x85bb58ce,seq=0x192), length 96
>> 20:47:52.041765 IP 178.197.x.x.21978 > 84.75.x.x.4500: UDP-encap: ESP(spi=0x85bb58ce,seq=0x193), length 88
>> 20:47:52.041785 IP 178.197.x.x.21978 > 84.75.x.x.4500: UDP-encap: ESP(spi=0x85bb58ce,seq=0x194), length 88
>> 20:47:52.041961 IP 84.75.x.x.4500 > 178.197.x.x.21977: UDP-encap: ESP(spi=0xbe045de8,seq=0x17b), length 96
>> 20:47:52.042104 IP 84.75.x.x.4500 > 178.197.x.x.21977: UDP-encap: ESP(spi=0xbe045de8,seq=0x17c), length 96
>> 
>> The server knows the connection at port 21977:
>> 
>> Mar  5 20:40:28 core pluto[12227]: "ikev2-cp"[2] 178.197.x.x #2: STATE_V2_IPSEC_R: IPsec SA established tunnel mode {ESP/NAT=>0xbe045de8 <0x85bb58ce xfrm=AES_GCM_16_256-NONE NATOA=none NATD=178.197.x.x:21977 DPD=active}
>> 
>> After the 3 min break the client-side NAT sends from port 21978.
>> 
>> I configured the NAT-T keepalive interval to 15. But this seems not to help. Any Ideas what is missing? Putting mobike=yes on the server does not help.
>> 
>>> On 5 Mar 2020, at 19:44, Paul Wouters <paul at nohats.ca> wrote:
>>> 
>>> On Wed, 4 Mar 2020, Beat Zahnd wrote:
>>> 
>>>> The client is the strongswan app. Initiating a connection works well and no problem is observed as long as the mobile phone is not put to sleep. After a few minutes on sleep no traffic goes trough anymore and the connection needs to be restarted first.
>>>> 
>>>> But I still see UDP-encap ESP traffic on my server network interface...
>>> 
>>> Did the NAT port change? Likely the client is not using MOBIKE to send
>>> an UPDATE_ADDRESS request to the server to share the information that
>>> the NAT router has changed its ports mapping.
>>> 
>>> Paul
> 



More information about the Swan mailing list