[Openswan Users] Openswan pluto causes connection drop after 10s with Android IPsec/L2TP clients

[Rene Mayrhofer]

Hi Paul,

On Thursday 01 September 2011 22:46:55 Paul Wouters wrote:
> On Thu, 1 Sep 2011, René Mayrhofer wrote:
> 
> >>        leftprotoport=17/1701
> >>         rightprotoport=17/0
> >> 
> >> You should use rightprotoport=17/%any
> >> 
> >> Strongswan might have a different interpretation from Openswan on the 
> >> meaning of 17/0
> > As far as I am aware, %any translates to 0.
> 
> There is a difference.
> 
> - 0 means "everything"
> - %any meants "any 1 port"
> 
> Also, %any causes instantiation. I am not sure if 0 causes that.

Tried with %any instead of 0, with the same outcome. Connection is established, but terminated again after 10s.

I still think that these messages might be an indication of something going wrong on the openswan pluto side:

Sep  2 10:39:08 sesame-test-client pluto[4450]: "l2tpCertRoadwarriors"[2] 193.170.124.198 #1: retransmitting in response to duplicate packet; already STATE_MAIN_R3
Sep  2 10:39:19 sesame-test-client pluto[4450]: "l2tpCertRoadwarriors"[2] 193.170.124.198 #1: retransmitting in response to duplicate packet; already STATE_MAIN_R3
Sep  2 10:39:28 sesame-test-client pluto[4450]: "l2tpCertRoadwarriors"[2] 193.170.124.198 #1: discarding duplicate packet -- exhausted retransmission; already STATE_MAIN_R3

strongswan pluto does not produce these, and consequently established the IPsec connection significantly faster (ca. 2s vs. ca. 10s for openswan pluto before the L2TP connection starts).
 
> >> The ppp logs show the android phone is deciding to hang up. Can you see its 
> >> logs
> >> on why it is doing that?
> > According to the logs, yes. However, it seems unlikely that the Android 
> > client is behaving differently when connecting to openswan (as opposed to 
> > strongswan).
> 
> Well, it is not hanging up on strongswan, so it is behaving differently.
> What's cause and effect can be argued. Having logs would have been nice.
> 
> With ppp packets flowing, it seems that IPsec is working fine. So I don't
> know why it is hanging up....

Potentially because it never gets the final answer to STATE_MAIN_R3 and then times out on the connection?
 
> > Unfortunately, I have not yet found any detailed logs of the 
> > embedded racoon and therefore can't debug from the client side.
> 
> That complicates things, yes. I would still recommand trying %any

I haven't managed to start racoon in debugging mode so far, as it is started automatically be the framework when a connection is established and then terminated again. I don't seem to have control over that even in a root shell (at least, I haven't dug deep enough yet to find out how to, but that might be very complicated considering the current state of documented-ness of the Android VPN client....).

best regards,
Rene