Project

General

Profile

Issue #255

IKEv1 can't connect from Android's default vpn client

Added by Khaos Tian almost 7 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Normal
Category:
-
Affected version:
Resolution:
Invalid

Description

There is a problem on establishing connection between server and android device. I'm not sure if this is a bug but I tried to setup the server with racoon and it can be connected from android device.

Logs from racoon on Android

I/racoon (11464): 192.168.1.142500 used as isakmp port (fd=10)
I/racoon (11464): 192.168.1.142500 used for NAT-T
I/racoon (11464): 192.168.1.1424500 used as isakmp port (fd=11)
I/racoon (11464): 192.168.1.1424500 used for NAT-T
I/racoon (11464): initiate new phase 1 negotiation: 192.168.1.142500<=>SERVER_IP500
I/racoon (11464): begin Aggressive mode.
E/racoon (11464): ignore the packet, received unexpecting payload type 20.
E/racoon (11464): ignore the packet, received unexpecting payload type 20.
E/racoon (11464): ignore the packet, received unexpecting payload type 20.
E/racoon (11464): ignore the packet, received unexpecting payload type 20.
E/racoon (11464): ignore the packet, received unexpecting payload type 20.
E/racoon (11464): ignore the packet, received unexpecting payload type 20.
E/racoon (11464): ignore the packet, received unexpecting payload type 20.

I tried to use wireshake to capture the packet and found payload 20 is NAT-D.
And here is the log from server

Nov 26 02:50:02 Chaos charon: 09[NET] received packet: from CLIENT_IP500 to SERVER_IP500
Nov 26 02:50:02 Chaos charon: 09[ENC] parsed AGGRESSIVE request 0 [ SA KE No ID V V V V V V V V ]
Nov 26 02:50:02 Chaos charon: 09[ENC] received unknown vendor ID: 40:48:b7:d5:6e:bc:e8:85:25:e7:de:7f:00:d6:c2:d3:80:00:00:00
Nov 26 02:50:02 Chaos charon: 09[IKE] received NAT-T (RFC 3947) vendor ID
Nov 26 02:50:02 Chaos charon: 09[IKE] received draft-ietf-ipsec-nat-t-ike-02 vendor ID
Nov 26 02:50:02 Chaos charon: 09[IKE] received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
Nov 26 02:50:02 Chaos charon: 09[IKE] received draft-ietf-ipsec-nat-t-ike-00 vendor ID
Nov 26 02:50:02 Chaos charon: 09[IKE] received XAuth vendor ID
Nov 26 02:50:02 Chaos charon: 09[IKE] received Cisco Unity vendor ID
Nov 26 02:50:02 Chaos charon: 09[IKE] received DPD vendor ID
Nov 26 02:50:02 Chaos charon: 09[IKE] CLIENT_IP is initiating a Aggressive Mode IKE_SA
Nov 26 02:50:02 Chaos charon: 09[CFG] looking for XAuthInitPSK peer configs matching SERVER_IP...CLIENT_IP[XXX]
Nov 26 02:50:02 Chaos charon: 09[CFG] selected peer config "xxx"
Nov 26 02:50:02 Chaos charon: 09[ENC] generating AGGRESSIVE response 0 [ SA KE No ID NAT-D NAT-D HASH V V V ]
Nov 26 02:50:02 Chaos charon: 09[NET] sending packet: from SERVER_IP500 to CLIENT_IP500
Nov 26 02:50:05 Chaos charon: 11[NET] received packet: from CLIENT_IP500 to SERVER_IP500
Nov 26 02:50:05 Chaos charon: 11[IKE] received retransmit of request with ID 0, retransmitting response
Nov 26 02:50:05 Chaos charon: 11[NET] sending packet: from SERVER_IP500 to CLIENT_IP500
Nov 26 02:50:06 Chaos charon: 10[IKE] sending retransmit 1 of response message ID 0, seq 1
Nov 26 02:50:06 Chaos charon: 10[NET] sending packet: from SERVER_IP500 to CLIENT_IP500
Nov 26 02:50:08 Chaos charon: 12[NET] received packet: from CLIENT_IP500 to SERVER_IP500
Nov 26 02:50:08 Chaos charon: 12[IKE] received retransmit of request with ID 0, retransmitting response
Nov 26 02:50:08 Chaos charon: 12[NET] sending packet: from SERVER_IP500 to CLIENT_IP500
Nov 26 02:50:11 Chaos charon: 13[NET] received packet: from CLIENT_IP500 to SERVER_IP500
Nov 26 02:50:11 Chaos charon: 13[IKE] received retransmit of request with ID 0, retransmitting response
Nov 26 02:50:11 Chaos charon: 13[NET] sending packet: from SERVER_IP500 to CLIENT_IP500
Nov 26 02:50:13 Chaos charon: 14[IKE] sending retransmit 2 of response message ID 0, seq 1
Nov 26 02:50:13 Chaos charon: 14[NET] sending packet: from SERVER_IP500 to CLIENT_IP500
Nov 26 02:50:14 Chaos charon: 15[NET] received packet: from CLIENT_IP500 to SERVER_IP500
Nov 26 02:50:14 Chaos charon: 15[IKE] received retransmit of request with ID 0, retransmitting response
Nov 26 02:50:14 Chaos charon: 15[NET] sending packet: from SERVER_IP500 to CLIENT_IP500
Nov 26 02:50:17 Chaos charon: 07[NET] received packet: from CLIENT_IP500 to SERVER_IP500
Nov 26 02:50:17 Chaos charon: 07[IKE] received retransmit of request with ID 0, retransmitting response
Nov 26 02:50:17 Chaos charon: 07[NET] sending packet: from SERVER_IP500 to CLIENT_IP500
Nov 26 02:50:20 Chaos charon: 08[NET] received packet: from CLIENT_IP500 to SERVER_IP500
Nov 26 02:50:20 Chaos charon: 08[IKE] received retransmit of request with ID 0, retransmitting response
Nov 26 02:50:20 Chaos charon: 08[NET] sending packet: from SERVER_IP500 to CLIENT_IP500
Nov 26 02:50:23 Chaos charon: 09[NET] received packet: from CLIENT_IP500 to SERVER_IP500
Nov 26 02:50:23 Chaos charon: 09[IKE] received retransmit of request with ID 0, retransmitting response
Nov 26 02:50:23 Chaos charon: 09[NET] sending packet: from SERVER_IP500 to CLIENT_IP500
Nov 26 02:50:26 Chaos charon: 11[IKE] sending retransmit 3 of response message ID 0, seq 1
Nov 26 02:50:26 Chaos charon: 11[NET] sending packet: from SERVER_IP500 to CLIENT_IP500
Nov 26 02:50:26 Chaos charon: 10[NET] received packet: from CLIENT_IP500 to SERVER_IP500
Nov 26 02:50:26 Chaos charon: 10[IKE] received retransmit of request with ID 0, retransmitting response
Nov 26 02:50:26 Chaos charon: 10[NET] sending packet: from SERVER_IP500 to CLIENT_IP500
Nov 26 02:50:29 Chaos charon: 12[NET] received packet: from CLIENT_IP500 to SERVER_IP500
Nov 26 02:50:29 Chaos charon: 12[IKE] received retransmit of request with ID 0, retransmitting response
Nov 26 02:50:29 Chaos charon: 12[NET] sending packet: from SERVER_IP500 to CLIENT_IP500
Nov 26 02:50:32 Chaos charon: 13[JOB] deleting half open IKE_SA after timeout

History

#1 Updated by Tobias Brunner almost 7 years ago

  • Status changed from New to Closed
  • Assignee set to Tobias Brunner
  • Affected version deleted (5.0.1)
  • Resolution set to Invalid

This seems to be a bug in the current releases of the IKEv1 client on Android. It only happens if Aggressive Mode is used (i.e. an "IPsec identifier" is specified on the client). With Main Mode the NAT-D payloads are properly processed. Not sure what the actual problem is, perhaps racoon expects the NAT-D payloads in a different message. Anyway, sending these payloads in the second Aggressive Mode message is correct according to RFC 3947, section 3.2, and since the same payloads are properly handled when Main Mode is used I don't think it is a strongSwan bug.

Please reopen the ticket if you think otherwise.

#2 Updated by Andreas Steffen over 6 years ago

  • Tracker changed from Bug to Issue

Also available in: Atom PDF