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

Thu Mar 5 20:16:49 UTC 2020

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