[strongSwan] Android Client - issue on long running connection

[Tobias Brunner]

Hi André,

> 09-19 09:11:30.800 I/charon  (12923): 16[NET] received packet: from X.Y.Z.65[4500] to 10.27.3.195[49398] (1836 bytes)
> 09-19 09:11:30.800 I/charon  (12923): 16[ENC] parsed IKE_AUTH response 1 [ IDr CERT AUTH CP(ADDR ADDR6 DNS) SA TSi TSr N(MOBIKE_SUP) N(ADD_6_ADDR) ]
> 09-19 09:11:30.805 I/charon  (12923): 16[IKE] received end entity cert "C=DE, O=test.loc, CN=vpn.test.loc"
> 09-19 09:11:30.805 I/charon  (12923): 16[CFG]   using certificate "C=DE, O=test.loc, CN=vpn.test.loc"
> 09-19 09:11:30.805 I/charon  (12923): 16[CFG]   using trusted ca certificate "C=DE, O=test.loc, CN=test.loc"
> 09-19 09:11:30.805 I/charon  (12923): 16[CFG]   reached self-signed root ca with a path length of 0
> 09-19 09:11:30.805 I/charon  (12923): 16[IKE] authentication of 'vpn.test.loc' with RSA signature successful
> 09-19 09:11:30.805 I/charon  (12923): 16[IKE] IKE_SA android[5] established between 192.168.203.96[C=DE, O=test.loc, CN=avalentin-nexus]...X.Y.Z.65[vpn.test.loc]
> 09-19 09:11:30.805 I/charon  (12923): 16[IKE] scheduling rekeying in 35411s
> 09-19 09:11:30.805 I/charon  (12923): 16[IKE] maximum IKE_SA lifetime 36011s
> 09-19 09:11:30.805 I/charon  (12923): 16[IKE] looking up interface for virtual IP 10.150.240.194 failed
> 09-19 09:11:30.805 I/charon  (12923): 16[IKE] looking up interface for virtual IP 2abc:123:123:8002:1::12 failed
> 09-19 09:11:30.805 I/charon  (12923): 16[IKE] CHILD_SA android{3} established with SPIs 6413df23_i cda5eef7_o and TS 10.150.240.194/32 2abc:123:123:8002:1::12/128 === 10.150.240.0/23 2abc:123:123::/48 
> 09-19 09:11:30.810 I/charon  (12923): 16[DMN] setting up TUN device for CHILD_SA android{3}
> 09-19 09:11:30.810 I/charon  (12923): 16[DMN] setting up TUN device failed, no virtual IP found
> 09-19 09:11:30.810 I/charon  (12923): 16[DMN] failed to setup TUN device

While the app is able to send and receive IKE messages it does not seem
to be able to find the network interface that has its local address
installed, which is the reason for the following two messages (and the
reason why setting up the TUN device eventually fails):

> 09-19 09:11:30.805 I/charon  (12923): 16[IKE] looking up interface for virtual IP 10.150.240.194 failed
> 09-19 09:11:30.805 I/charon  (12923): 16[IKE] looking up interface for virtual IP 2abc:123:123:8002:1::12 failed

This problem occurs when the device switches network interfaces or IP
addresses right before (or while) establishing an SA.

> 09-19 09:11:29.845 I/charon  (12923): 14[NET] sending packet: from 192.168.203.96[49398] to X.Y.Z.65[4500] (648 bytes)
> 09-19 09:11:30.030 I/charon  (12923): 15[NET] received packet: from X.Y.Z.65[4500] to 10.27.3.195[49398] (465 bytes)

Here we see that the app believes its local address is 192.168.203.96
when sending the IKE_SA_INIT request, but the response is then actually
received on 10.27.3.195.  This address is not automatically updated,
partly because MOBIKE is enabled, but since [1] the local address is
actually only rarely updated automatically.

The result can be seen in the IKE_AUTH request that is still sent from
192.168.203.96 (the packet is not actually sent with that address in the
header, as we don't set source addresses on Android, but it shows what
the app thinks its local address is):

> 09-19 09:11:30.400 I/charon  (12923): 15[NET] sending packet: from 192.168.203.96[49398] to X.Y.Z.65[4500] (1900 bytes)

So when it comes to looking up an interface to install the virtual IP on
(something not really used on Android, oh well), it uses not the
actually active address but that old one instead, which, of course,
fails as that address is gone by now.

I pushed a fix that tries to counter this by finding a new source
address when reestablishing an IKE_SA (previously the old addresses were
reused - which is now just the fallback).  It might not fix the problem
in all cases but should offer better recovery after failed retransmits.

By the way, the following error is unrelated to the connectivity issue
and is caused by the GUI calling commit() on a FragmentTransaction when
the Fragment is not actually shown.  A fixed version will be released
next week.

> 09-19 09:11:30.830 W/System.err(12923): java.lang.IllegalStateException: Can not perform this action after onSaveInstanceState

Regards,
Tobias

[1] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=21dd4c4be