[Openswan Users] Openswan pluto causes connection drop after 10s with Android IPsec/L2TP clients
rene at mayrhofer.eu.org
Fri Sep 2 05:08:03 EDT 2011
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: "l2tpCertRoadwarriors" 184.108.40.206 #1: retransmitting in response to duplicate packet; already STATE_MAIN_R3
Sep 2 10:39:19 sesame-test-client pluto: "l2tpCertRoadwarriors" 220.127.116.11 #1: retransmitting in response to duplicate packet; already STATE_MAIN_R3
Sep 2 10:39:28 sesame-test-client pluto: "l2tpCertRoadwarriors" 18.104.22.168 #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....).
More information about the Users