2 Replies Latest reply on Jun 21, 2017 11:59 AM by mick

    native android vpn client connection to 3140

    telepdx New Member

      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

        • Re: native android vpn client connection to 3140
          mick Visitor

          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

            • Re: native android vpn client connection to 3140
              mick Visitor

              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