Adtran
Help
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Show  only  | Search instead for 
Did you mean: 
telepdx
New Contributor
‎06-16-2017 02:19 PM

native android vpn client connection to 3140

I've been through the past posts regarding this but not finding anything recent. Not clear on whether anyone has been successful using the native android vpn client to connect with 31xx,

getting this error from debug.  Tried various policy config but to no avail.

2001.05.02 23:17:18 CRYPTO_IKE.NEGOTIATION 101: Failed to get policy info from IPSec

2001.05.02 23:17:18 CRYPTO_IKE.NEGOTIATION peer 70.210.136.67: IkeQMIdleProcess failed 

2001.05.02 23:17:18 CRYPTO_IKE.NEGOTIATION peer 70.210.136.67: IkeQMIdleProcess returned failure

Tags (1)
0 Kudos
Reply
2 Replies
mick
Contributor
Contributor
‎06-21-2017 06:55 AM

Re: native android vpn client connection to 3140

Hi telepdx,

I do not have an android device to try this out in a real world scenario and you have not offered much information on your android and router settings for me to compare, but I used genymotion to run Android in a VM.  I selected Nexus-9, with Android-7.1.0, API-25.  Below are my results from trying to connect to a Netvanta 3120:

PHASE 1 - IKE

I only tried this with Pre-Shared Keys, not SSL Certificates.

With pre-shared keys the Android native client only accepts key exchange DH Group 2 (1024-bit).  It will fail to establish an IKE connection if the router's corresponding 'crypto ike policy' specifies the stronger Group 5.  Regarding IKE encryption the strongest cipher offered by the router, AES-256-CBC, will work with the Android client.

Android's 'IPSec Identifier' string is what the Netvanta will receive as remote-id for the peer in Aggressive Mode.  When the 'IPSec Identifier' string is filled in on the Android device, then Android will use Aggressive Mode to initiate a connection with the router.  When left empty the Android will use Main Mode.  If no value is entered for 'IPSec Identifier' then Android is hard coded to use Main Mode to initiate a connection and this case the 'IPSec Identifier' string will be obtained from the SSL Certificate, which appears to be necessary for Main Mode on Android.  With SSL Certificates the 'IPSec Identifier' string for the Android device will be read from the subjectAltName field in the certificate, so it will be necessary to add the user-fqdn string in the certificate's email information.

Leaving the 'IPSec Identifier' field empty in Android's settings without providing an SSL Certificate on the device will not feed any suitable peer ID to the router during IKE negotiation (I tried all remote-ID types on the Netvanta) and the connection in Main Mode will fail.  From what I figured, without rooting the Android OS there is no way to change from Aggressive to Main Mode when using pre-shared key authentication.

The Android client also appears to be hard coded to only accept user-fqdn (i.e. an email address formatted string) to be entered as the type of 'IPSec Identifier'.  Using anything else will fail to complete the IKE negotiation.

The Android client requires Mode_Cfg to be set on the router, without it the IKE negotiation will fail.

I did not try without XAUTH.

With the above in mind the following settings appear to complete the IKE connection and proceed to start Phase 2 negotiation.

On the Netvanta:

!

ip crypto

!

crypto ike client configuration pool VPN_modconfig

  ip-range            172.16.1.1        172.16.1.254   

  dns-server          10.10.10.1     

!

crypto ike policy 150

  no initiate

  respond anymode

  local-id address AAA.BBB.CCC.DDD                        !! This is Netvanta's public IP address

  peer ZZZ.YYY.XXX.WWW                                        !! This is Android's public IP address, but 'any' will work too.

  client authentication server list LoginUseLocalUsers

  client configuration pool VPN_modconfig

  attribute 1

    encryption aes-256-cbc

    authentication pre-share

    group 2                                                                    !! Group 5 will not work with Android-7.1.0

!

crypto ike remote-id user-fqdn remote@remote_client.com preshared-key Very_Long_Secret_Passwd ike-policy 150 crypto map VPN 15

!

On the Android:

Name: Android-to-Netvanta

Type: IPSec Xauth PSK

Server address: AAA.BBB.CCC.DDD

IPSec identifier: remote@remote_client.com

Username: my-XAUTH-username

Password: my-XAUTH_secret_passwd

Result:

#show crypto ike sa

Using 1 SAs out of 20

Peak concurrent SAs: 2

IKE Security Associations:

Peer IP Address: ZZZ.YYY.XXX.WWW

  Mode-config Address: 172.16.1.1

  Local IP Address: AAA.BBB.CCC.DDD

  Remote ID: remote@remote_client.com

  XAUTH Username: my-XAUTH-username

  Lifetime: 28718

  Status: UP (SA_MATURE)

  IKE Policy: 150

  NAT-traversal: V2

  Detected NAT / Behind NAT: Yes / No

  Dead Peer Detection: Yes

PHASE 2 - IPSec

This phase failed in my tests, but as I mentioned above I did not try using RSA signatures with SSL Certificates and I don't know if this will make a difference.

I tried with and without AH, with ESP ciphers aes-256-cbc, aes-128-cbc and 3des, none of which made any difference.  The error message was about selectors not found, but the IKE negotiation had completed successfully with the Mode_Cfg IP address range seemingly accepted by Android, so I am not sure what's causing this.  It may be that the Android is not respecting the Mode_Cfg settings and uses some hard coded own private IP address?

This is from the IPSec settings on the Netvanta:

!

ip crypto ipsec transform-set esp-aes-256-cbc-esp-sha-hmac esp-aes-256-cbc esp-sha-hmac

  mode tunnel

!

ip crypto map VPN 15 ipsec-ike

  description Android_test

  match address ip VPN-120-vpn-selectors

  set transform-set esp-aes-256-cbc-esp-sha-hmac

  set pfs group2

  ike-policy 150

  mobile

Log output showing Mode_Cfg exchange completing:

CRYPTO_IKE.XAUTH EDCallBackFun: Xauth succeeded

CRYPTO_IKE.XAUTH XauthProcessVpnMutexPath: After State machine Fun execution  State:  0x3  Event : 0x3 

CRYPTO_IKE.NEGOTIATION peer ZZZ.YYY.XXX.WWW: received transaction exchange message

CRYPTO_IKE.MODE_CONFIG IkeHandleTXchg Starts 

CRYPTO_IKE.MODE_CONFIG IkeHandleTransXChg:Transaction Exchange is protected

CRYPTO_IKE.MODE_CONFIG IkeHandleTransXchgVpnMutexPath: mdcf msg id 0x00000000

CRYPTO_IKE.MODE_CONFIG IkeHandleTransXchgVpnMutexPath: generate new IV

CRYPTO_IKE.MODE_CONFIG IkeHandleTransXchgVpnMutexPath: ulMessgaeId 0x00000000 pIsakmpSA 0x030bb010 uiModeCfgMesgId 0xef873d25

CRYPTO_IKE.NEGOTIATION InitialiseCipherContext :: Not DES and Not 3DES 

CRYPTO_IKE.MODE_CONFIG ModeCfgProcess Starts

CRYPTO_IKE.MODE_CONFIG ModeCfgFormAttribMask: rcvd request for attrib 0x0001, INTERNAL_IP4_ADDRESS

CRYPTO_IKE.MODE_CONFIG ModeCfgFormAttribMask: rcvd request for attrib 0x0002, INTERNAL_IP4_NETMASK

CRYPTO_IKE.MODE_CONFIG ModeCfgFormAttribMask: rcvd request for attrib 0x0003, INTERNAL_IP4_DNS

CRYPTO_IKE.MODE_CONFIG ModeCfgFormAttribMask: rcvd request for attrib 0x0004, INTERNAL_IP4_NBNS

CRYPTO_IKE.MODE_CONFIG ModeCfgFormAttribMask: rcvd request for attrib 0x7000 (Unknown)

CRYPTO_IKE.MODE_CONFIG ModeCfgFormAttribMask: rcvd request for attrib 0x7002 (Unknown)

CRYPTO_IKE.MODE_CONFIG ModeCfgFormAttribMask: rcvd request for attrib 0x7003 (Unknown)

CRYPTO_IKE.MODE_CONFIG ModeCfgFormAttribMask: rcvd request for attrib 0x7004 (Unknown)

CRYPTO_IKE.MODE_CONFIG ModeCfgFormAttribMask: rcvd request for attrib 0x7006 (Unknown)

CRYPTO_IKE.MODE_CONFIG ModeCfgFormAttribMask: rcvd request for attrib 0x0007, APPLICATION_VERSION

CRYPTO_IKE.MODE_CONFIG MdCfgAddNewSessionNode: Initialize ref count to 1, ZZZ.YYY.XXX.WWW - 172.16.1.1 

CRYPTO_IKE.NEGOTIATION Injecting mode-config host route 172.16.1.1 for ZZZ.YYY.XXX.WWW on interface ppp 1

CRYPTO_IKE.MODE_CONFIG ModeCfgConstructReply: pIsakmpSA 0x030bb010 uiModeCfgMesgId 0xef873d25

CRYPTO_IKE.MODE_CONFIG ModeCfgSetupAttribs: sending attrib 0x0001, INTERNAL_IP4_ADDRESS

CRYPTO_IKE.MODE_CONFIG ModeCfgSetupAttribs: sending address 172.16.1.1

CRYPTO_IKE.MODE_CONFIG ModeCfgSetupAttribs: sending attrib 0x0002, INTERNAL_IP4_NETMASK

CRYPTO_IKE.MODE_CONFIG ModeCfgSetupAttribs: sending netmask 255.255.255.255

CRYPTO_IKE.MODE_CONFIG ModeCfgSetupAttribs: sending attrib 0x0003, INTERNAL_IP4_DNS

CRYPTO_IKE.MODE_CONFIG ModeCfgSetupAttribs: sending primary DNS 10.10.10.1

CRYPTO_IKE.MODE_CONFIG ModeCfgSetupAttribs: sending attrib 0x0007, APPLICATION_VERSION

CRYPTO_IKE.MODE_CONFIG ModeCfgSetupAttribs: sending version eVPN V2.0 (c) Intoto Inc.

CRYPTO_IKE.NEGOTIATION InitialiseCipherContext :: Not DES and Not 3DES 

CRYPTO_IKE.MODE_CONFIG ModeCfgProcess: sending out msg sz: 124

CRYPTO_IKE.MODE_CONFIG ModeCfgProcess: Message Send sz: 124

CRYPTO_IKE.MODE_CONFIG  MODE-CONFIG TRANSACTIONS COMPLETED

CRYPTO_IKE.NEGOTIATION peer ZZZ.YYY.XXX.WWW: Received first message of quick mode

Then it tries to negotiate quick mode but eventually fails with this message:

CRYPTO_IKE.NEGOTIATION   NONCE PAYLOAD

CRYPTO_IKE.NEGOTIATION   ID PAYLOAD

CRYPTO_IKE.NEGOTIATION     IANA No. for identifn: 1 -> ID_IPV4_ADDR

CRYPTO_IKE.NEGOTIATION     Protocol Id: 0

CRYPTO_IKE.NEGOTIATION     Port: 0

CRYPTO_IKE.NEGOTIATION     Id Data: 172.16.1.1

CRYPTO_IKE.NEGOTIATION   ID PAYLOAD

CRYPTO_IKE.NEGOTIATION     IANA No. for identifn: 4 -> IPV4_ADDR_SUBNET

CRYPTO_IKE.NEGOTIATION     Protocol Id: 0

CRYPTO_IKE.NEGOTIATION     Port: 0

CRYPTO_IKE.NEGOTIATION     Id Data: 0.0.0.0, 0.0.0.0

CRYPTO_IKE.NEGOTIATION

CRYPTO_IKE.NEGOTIATION Using the IPSec Policy "VPN 15" specified by the ike remote-id

CRYPTO_IPSEC Cannot find matching SPD entries

CRYPTO_IKE.NEGOTIATION The remote ID specified IPSec Policy "VPN 15", but the selectors did not match

CRYPTO_IKE.NEGOTIATION 150: Failed to get policy info from IPSec

CRYPTO_IKE.NEGOTIATION peer ZZZ.YYY.XXX.WWW: IkeQMIdleProcess failed

CRYPTO_IKE.NEGOTIATION peer ZZZ.YYY.XXX.WWW: IkeQMIdleProcess returned failure

CRYPTO_IKE.NEGOTIATION peer ZZZ.YYY.XXX.WWW: Received first message of quick mode

CRYPTO_IKE.NEGOTIATION InitialiseCipherContext :: Not DES and Not 3DES

...

I also tried setting 'Forwarding Routes' on the Android.  The Android VPN then showed as being connected, but the Netvanta IPSec had no connections running and attempts to connect to servers on the LAN behind Netvanta failed.

#show ip crypto ipsec sa

0 current IPv4 IPsec SAs on default VRF

0 current IPv4 + IPv6 IPsec SAs on all VRFs (2 peak of 40 max)

So, it seems that there is a problem with setting up Phase 2 successfully.  Perhaps the use of SSL Certificates will make a difference, perhaps not.  I would be interested to find out any settings that could make Phase 2 work.

--

Kind regards,

Mick

0 Kudos
Accept as Solution Reply
mick
Contributor
Contributor
‎06-21-2017 01:56 PM

Re: native android vpn client connection to 3140

I had another look and did some further tests.  This entry in the logs shows that Android is setting up a full VPN tunnel.  All connections from Android will flow through the VPN, including connections to the wider Internet:

CRYPTO_IKE.NEGOTIATION   ID PAYLOAD

CRYPTO_IKE.NEGOTIATION     IANA No. for identifn: 4 -> IPV4_ADDR_SUBNET

CRYPTO_IKE.NEGOTIATION     Protocol Id: 0

CRYPTO_IKE.NEGOTIATION     Port: 0

CRYPTO_IKE.NEGOTIATION     Id Data: 0.0.0.0, 0.0.0.0  <==This will route all IP addresses via the tunnel, not just 10.10.10.0/24.

Using Android's 'Forwarding Routes' setting made no difference to the above.  A full tunnel seems to be set up in all occasions.  However, when setting up 'Forwarding Routes' for Netvanta's LAN subnet(10.10.10.0/24) , both IKE and IPSec associations are completed successfully for an instance, then Quick Mode renegotiations start afresh:

CRYPTO_IKE.NEGOTIATION        Length: 2
CRYPTO_IKE.NEGOTIATION        Value:  Unknown/Other (61443)
CRYPTO_IKE.NEGOTIATION      SA Attrib: Authentication Algorithm (5)
CRYPTO_IKE.NEGOTIATION        Length: 2
CRYPTO_IKE.NEGOTIATION        Value:  MD5 (1)

CRYPTO_IKE.NEGOTIATION   NONCE PAYLOAD

CRYPTO_IKE.NEGOTIATION   ID PAYLOAD

CRYPTO_IKE.NEGOTIATIONIANA No. for identifn: 1 -> ID_IPV4_ADDR
CRYPTO_IKE.NEGOTIATIONProtocol Id: 0
CRYPTO_IKE.NEGOTIATIONPort: 0
CRYPTO_IKE.NEGOTIATIONId Data: 172.16.1.1

CRYPTO_IKE.NEGOTIATION   ID PAYLOAD

CRYPTO_IKE.NEGOTIATIONIANA No. for identifn: 4 -> IPV4_ADDR_SUBNET
CRYPTO_IKE.NEGOTIATIONProtocol Id: 0
CRYPTO_IKE.NEGOTIATIONPort: 0
CRYPTO_IKE.NEGOTIATIONId Data: 0.0.0.0, 0.0.0.0

CRYPTO_IKE.NEGOTIATION

CRYPTO_IKE.NEGOTIATION Using the IPSec Policy "VPN 20" specified by the ike remote-id

CRYPTO_IKE.NEGOTIATION IPSec Policy "VPN 20" matched the selectors... comparing transforms

CRYPTO_IKE.NEGOTIATION   IkeSelectXform::IPSEC_KEYLENGTH::

CRYPTO_IKE.NEGOTIATION   IkeSelectXform::pAttrib->usEncryptKeyLen = 32

CRYPTO_IKE.NEGOTIATION   IkeSelectXform::Transform.aAttributes[ij].ulValLen = 256

CRYPTO_IKE.NEGOTIATION   Proposed Authentication Algorithim = Unknown/Other does not match SHA1

CRYPTO_IKE.NEGOTIATION IkeSelectXform : Moved to Next Transform.... 

CRYPTO_IKE.NEGOTIATION   IkeSelectXform::IPSEC_KEYLENGTH::

CRYPTO_IKE.NEGOTIATION   IkeSelectXform::pAttrib->usEncryptKeyLen = 32

CRYPTO_IKE.NEGOTIATION   IkeSelectXform::Transform.aAttributes[ij].ulValLen = 256

CRYPTO_IKE.NEGOTIATION <POLICY: 200> PAYLOADS: HASH,SA,PROP,TRANS,NOTIFY,NONCE,ID,ID

CRYPTO_IKE.NEGOTIATION   HASH PAYLOAD

CRYPTO_IKE.NEGOTIATION   SA PAYLOAD

CRYPTO_IKE.NEGOTIATIONDOI: 1
CRYPTO_IKE.NEGOTIATIONSituation: 1
CRYPTO_IKE.NEGOTIATIONPROPOSAL PAYLOAD
CRYPTO_IKE.NEGOTIATION  Proposal No.: 1
CRYPTO_IKE.NEGOTIATION  IANA No. for protocol: IPSec ESP (3)
CRYPTO_IKE.NEGOTIATION  Size of the variable SPI field: 4
CRYPTO_IKE.NEGOTIATION  Number of transforms offered: 1
CRYPTO_IKE.NEGOTIATION  SPI for the proposal: 4228292162

CRYPTO_IKE.NEGOTIATION peer ZZZ.YYY.XXX.WWW: Received third message of quick mode

CRYPTO_IKE.NEGOTIATION InitialiseCipherContext :: Not DES and Not 3DES 

CRYPTO_IKE.NEGOTIATION <POLICY: 200> PAYLOADS: HASH

CRYPTO_IKE.NEGOTIATION   HASH PAYLOAD

CRYPTO_IKE.NEGOTIATION

CRYPTO_IKE.NEGOTIATION SENDING NOTIFY MSG:

CRYPTO_IKE.NEGOTIATION CONNECTED

CRYPTO_IKE.NEGOTIATION <POLICY: 200> PAYLOADS: HASH,NOTIFY

CRYPTO_IKE.NEGOTIATION   HASH PAYLOAD

CRYPTO_IKE.NEGOTIATION   NOTIFY PAYLOAD

CRYPTO_IKE.NEGOTIATIONDOI: 1
CRYPTO_IKE.NEGOTIATIONProtocol Id: 3
CRYPTO_IKE.NEGOTIATIONSize of SPI: 4
CRYPTO_IKE.NEGOTIATIONType of notify message: 16384
CRYPTO_IKE.NEGOTIATIONSPI: 207330403
CRYPTO_IKE.NEGOTIATIONNotify Type: Status: Connected (16384)
CRYPTO_IKE.NEGOTIATIONLength of Notification Data: 0

CRYPTO_IKE.NEGOTIATION InitialiseCipherContext :: Not DES and Not 3DES 

CRYPTO_IKE.NEGOTIATION IkeEndNegotiationVpnMutexPath..MySPI: 4228292162

CRYPTO_IKE.NEGOTIATION IkeEndNegotiationVpnMutexPath..PeerSPI: 207330403

CRYPTO_IKE.NEGOTIATION  ulEncapsMode : 61443

CRYPTO_IKE id=vpn time="2017-06-21 17:46:57" fw=3120 pri=6 proto=esp dst=AAA.BBB.CCC.DDD vpn=IN8-3 type=1 msg="Inbound SA Created - SPI 0xfc069e42" agent=IPsec

CRYPTO_IKE id=vpn time="2017-06-21 17:46:57" fw=3120 pri=6 proto=esp dst=ZZZ.YYY.XXX.WWW vpn=8-3 type=1 msg="Outbound SA Created - SPI 0xc5b9c63, Remote ID remote@remote_client.com" agent=IPsec

CRYPTO_IKE.MODE_CONFIG MdCfgReference: Inc. ref count to 2, ZZZ.YYY.XXX.WWW - 172.16.1.1 

CRYPTO_IKE.MODE_CONFIG MdCfgReference: Inc. ref count to 3, ZZZ.YYY.XXX.WWW - 172.16.1.1 

CRYPTO_IKE.NEGOTIATION peer ZZZ.YYY.XXX.WWW: Quick mode completed

CRYPTO_IKE.NEGOTIATION peer ZZZ.YYY.XXX.WWW: Received first message of quick mode  <==Then starts renegotiating Phase2 all over again.

CRYPTO_IKE.NEGOTIATION 200: Commit bit set

CRYPTO_IKE.NEGOTIATION peer ZZZ.YYY.XXX.WWW: IkeQMIdleProcess failed

CRYPTO_IKE.NEGOTIATION SENDING NOTIFY MSG:

CRYPTO_IKE.NEGOTIATION INVALID_FLAGS

CRYPTO_IKE.NEGOTIATION <POLICY: 200> PAYLOADS: HASH,NOTIFY

CRYPTO_IKE.NEGOTIATION   HASH PAYLOAD

CRYPTO_IKE.NEGOTIATION   NOTIFY PAYLOAD

CRYPTO_IKE.NEGOTIATIONDOI: 0
CRYPTO_IKE.NEGOTIATIONProtocol Id: 1
CRYPTO_IKE.NEGOTIATIONSize of SPI: 16
CRYPTO_IKE.NEGOTIATIONType of notify message: 8
CRYPTO_IKE.NEGOTIATIONNotify Type: Invalid Flags (8)
CRYPTO_IKE.NEGOTIATIONLength of Notification Data: 0

CRYPTO_IKE.NEGOTIATION InitialiseCipherContext :: Not DES and Not 3DES 

CRYPTO_IKE.NEGOTIATION 200: Sent informational exchange message

CRYPTO_IKE.NEGOTIATION

CRYPTO_IKE.NEGOTIATION peer ZZZ.YYY.XXX.WWW: Received first message of quick mode

CRYPTO_IKE.NEGOTIATION 200: Commit bit set

CRYPTO_IKE.NEGOTIATION peer ZZZ.YYY.XXX.WWW: IkeQMIdleProcess failed

CRYPTO_IKE.NEGOTIATION SENDING NOTIFY MSG:

CRYPTO_IKE.NEGOTIATION INVALID_FLAGS

CRYPTO_IKE.NEGOTIATION <POLICY: 200> PAYLOADS: HASH,NOTIFY

CRYPTO_IKE.NEGOTIATION   HASH PAYLOAD

CRYPTO_IKE.NEGOTIATION   NOTIFY PAYLOAD

CRYPTO_IKE.NEGOTIATIONDOI: 0
CRYPTO_IKE.NEGOTIATIONProtocol Id: 1
CRYPTO_IKE.NEGOTIATIONSize of SPI: 16
CRYPTO_IKE.NEGOTIATIONType of notify message: 8
CRYPTO_IKE.NEGOTIATIONNotify Type: Invalid Flags (8)
CRYPTO_IKE.NEGOTIATIONLength of Notification Data: 0

CRYPTO_IKE.NEGOTIATION InitialiseCipherContext :: Not DES and Not 3DES 

CRYPTO_IKE.NEGOTIATION 200: Sent informational exchange message

CRYPTO_IKE.NEGOTIATION

CRYPTO_IKE.NEGOTIATION Got Keep Alive Message !

CRYPTO_IKE.NEGOTIATION peer ZZZ.YYY.XXX.WWW: Received first message of quick mode

....

I also set up ACL selectors and policies to forward connections from the VPN tunnel via Netvanta's firewall to the Internet, but I still couldn't get the Android device to connect either to the Netvanta admin interface, or to the Internet.  This may be related to me running Android in a VM, essentially a double NAT situation.

Telepdx you could try my suggested settings above and see if you can get the Android VPN to perform split and full tunnel successfully as a stand alone device, as opposed to how I have been running it in a VM.

--

Kind regards,

Mick

0 Kudos
Accept as Solution Reply