VPN with iPad

[ckwill90]

I apologize in advance if this is already somewhere in this forum. I couldn't find anything on it though. We have an NetVanta 3430. We have VPN setup and currently use Shrew Soft VPN client to connect from remote Windows computers. All works fine. I would really like to setup VPN on my iPad. But I can't seem to get the VPN to connect. I found a thread on an Apple forum from 2012 asking about this and they were told it's not possible. But that was 2012. It's 2014 so surely there is a way. Right? Does anyone happen to have the answer to this?

[jayh]

Have you tried on IOS 7:  Settings -> General - > VPN -> Add Configuration -> IPSec and filling in the parameters? 

[ckwill90]

I apologize for my delayed response. I was away on business. To answer your question, yes, that's exactly what I did. Problem was it wouldn't connect. I originally thought maybe I was not entering the correct information. But when I looked into it further I found a thread on the Apple site that said the iOS VPN is not compatible with NetVanta. Maybe I should have asked if anyone else is successfully doing this. If so then I know it's me.

[Anonymous · Accepted solution]

Hi ckwill90:

This is a topic of great interest to us.  The iOS IPSec implementation seems to be very narrow, as it has been from the iPhone 1, and suited for Cisco Easy VPN connections only.  If you wish to establish VPN from an iOS device through a NetVanta firewall, I think you're going to have to setup a PPTP or L2TP VPN service on an inside machine and simply forward ports as needed.  This is what we do for our customers using NetVanta firewalls.

Hopefully Apple will expand their IPSec client capabilities in the future and allow greater compatibility with "standard" IPSec servers like AOS firewalls!

Best,

CJ

[ckwill90]

Thanks, CJ! At least now I know it's not just me.

[mick]

I don't have an iPad device to try it out, but from what I understand IOS 7 uses IKEv1 and therefore it should work with Netvanta.  Some things you ought to try are:

• Set up mode-config on the Netvanta.
• Set up SSL certificates and upload the CA and client certificate to the iPad.  Use the IP address on the subjectAltName field for the server certificate and email for the client certificate (if the client is expected to have a dynamic IP address).
• Set up Extended Authentication on the Netvanta.

The IOS uses aggressive mode, so the Netvanta must be configured to respond to it.

Please let us know if you get it going.

--

Regards,

Mick

[ckwill90]

Thanks for the suggestion. I will try it out!

[Anonymous]

I get through the fifth message when debugging IKE, and the certificate is sent, then the AOS device sends a Payload Malformed (16) failure message.  This is a crypto scenario beyond my expertise.  Anyone feel like having a look?

Updated to attach configuration.

[mick]

Hi cj!,

Your connection fails at the last stage of the IKE negotiation between peers.  This is when the IKE IDs are sent and verified by each end point.  I see this in your log (lines 394 to 416):

3814.05.27 00:52:16 CRYPTO_IKE.NEGOTIATION peer 70.198.xxx.xxx: Received fifth message of main mode

3814.05.27 00:52:16 CRYPTO_IKE.NEGOTIATION Intoto_DH_mod_exp :: Entry

3814.05.27 00:52:16 CRYPTO_IKE.NEGOTIATION InitialiseCipherContext :: !DES and ! 3DES 

3814.05.27 00:52:16 CRYPTO_IKE.NEGOTIATION <POLICY: 199> PAYLOADS: ID,CERT,SIG,CERTREQ,NOTIFY

3814.05.27 00:52:16 CRYPTO_IKE.NEGOTIATION   ID PAYLOAD

3814.05.27 00:52:16 CRYPTO_IKE.NEGOTIATION     IANA No. for identifn: 9 -> ID_DER_ASN1_DN  <----this is the remote-id

3814.05.27 00:52:16 CRYPTO_IKE.NEGOTIATION     Protocol Id: 0

3814.05.27 00:52:16 CRYPTO_IKE.NEGOTIATION     Port: 0

3814.05.27 00:52:16 CRYPTO_IKE.NEGOTIATION     Id Data:

3814.05.27 00:52:16 CRYPTO_IKE.NEGOTIATION       BB 3F 4A 21 BB 1F 06 77  0?8!0...

3814.05.27 00:52:16 CRYPTO_IKE.NEGOTIATION       2B 04 0B 6C 18 44 6F 6D  U....Dom

3814.05.27 00:52:16 CRYPTO_IKE.NEGOTIATION       61 69 6E 38 42 6F 6E 74  ain Cont

3814.05.27 00:52:16 CRYPTO_IKE.NEGOTIATION       72 6F 6C 38 56 61 6C 69  rol Vali

3814.05.27 00:52:16 CRYPTO_IKE.NEGOTIATION       64 61 74 65 64 4A 1A BB  date49.0

3814.05.27 00:52:16 CRYPTO_IKE.NEGOTIATION       18 06 77 2B 04 77 0C 11  ...!....

3814.05.27 00:52:16 CRYPTO_IKE.NEGOTIATION       2A 2E 74 65 61 6D 61 6C  *.mycomp  <--This is the ID sent

3814.05.27 00:52:16 CRYPTO_IKE.NEGOTIATION       6C 73 74 61 72 2E 9A 6F  any.com

3814.05.27 00:52:16 CRYPTO_IKE.NEGOTIATION   CERT PAYLOAD

3814.05.27 00:52:16 CRYPTO_IKE.NEGOTIATION     Certificate Type: X.509 - Signature (4)

3814.05.27 00:52:16 CRYPTO_IKE.NEGOTIATION     Length: 9D43

3814.05.27 00:52:16 CRYPTO_IKE.NEGOTIATION     Certificate In HEX Follows:

3814.05.27 00:52:16 CRYPTO_IKE.NEGOTIATION       BB 82 05 59 BB 82 04 41  0..Y0g+C

                                                 <certificate follows...>

You have defined your ike remote-id as fqdn "*.mycompany.com" in your configuration.  Can you try something like:

crypto ike remote-id asn1-dn "C=US, ST=blah-blah, O=some_org, CN=ipsec-client.mycompany.com" ike-policy 199 crypto map VPN 199 xauth nat-t v2 force

Of course replace the content of asn1-dn between the "double quotes" in the line above, with the full DN field of your client certificate.  If you use the subjectAltName field take note that you may need to change local-id and remote-id to correspond to the type of ID shown in the subjectAltName, e.g. "local-id address 123.456.78.9".  Play around with this until Phase 1 succeeds.  Once each peer's ID is exchanged and verified as matching the specified configuration at both ends, you should see the Phase 2 negotiation taking place (Quick Mode).

Hope this helps.

--

Regards,

Mick

[mick]

Hi again cj!,

I forgot to mention that I have not been successful setting fqdn and having it recognised as a local-id by the client, but this could well be client specific and how they parse the x509 certificate fields.  I have had succcess using "local-id address 123.456.78.9" and also using the full Subject field of the router's certificate:

local-id asn1-dn "CN=myrouter; OU=VPN Gateway; O=mycompany; C=US; ST=SomeState"

In case the iPad client is temperamental you may want to stick with the full asn1-dn as IDs for both end points.

Hope this helps.

--

Regards,

Mick

[mick]

I managed to get my hands on a MacBook Pro, running OSX El Capitan.  I tried connecting to a 3120 VPN, on main mode, no xauth, with SSL certificate authentication.  To set all this up I had to copy /var/run/<IP address>.conf to /etc/racoon/ in the Apple Mac and modify its parameters accordingly.  Then I changed the include directive in the default /etc/racoon/racoon.conf to read the new config file.  However, the connection failed in a similar fashion like the iPad mentioned above in this thread.

I looked at the logs and ran tcpdump on the Apple Mac to check the packets exchanged between the peers.  I found out the connection would fail on the exchange of message 5 between the two peers when using SSL certificates. The exchange of certificates would not complete according to the Netvanta logs, although the Apple Mac logs showed it reaching exchange of message 6.  I experimented with different MTU values and also set esp_frag in the racoon configuration file.  This had a direct effect on how much of the certificate(s) would be transmitted on messages 5 and 6 before the connection failed.  Message 6 would not complete no matter what MTU and esp-frag values I used.  So it seems to me the problem is caused by the way OSX fails to deal with packet fragmentation with ESP and NAT-T.  The Apple Mac logs complained that the kernel is not configured to deal with esp_frag, although racoon was reading and modifying the packet sizes.  Linux doesn't have these problems when using racoon as a VPN client.  I don't have the time to start patching the OSX kernel just for this use case, so we'll have to wait and see what Apple may come up with in the future.

When I get a moment I'll try to set up a connection with PSK just for grins, to see how this may complete.

--

Regards,

Mick

[mick]

I spent some more time on this problem.  Unlike authentication with SSL certificates, the PSK definitely succeeds in completing the Phase 1 negotiation.  However, another problem appears to stop the connection moving on to Phase 2.  The NAT-T implemented by Apple is of a previous draft to what all current ipsec-tools implementations are using:

Using a Linux L2TP/IPsec VPN server with Mac OS X and iPhone

As a result it won't go further than this:

2016.07.10 18:06:46 CRYPTO_IKE.NEGOTIATION peer AA.BBB.CCC.DD: Received fifth message of main mode

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION InitialiseCipherContext :: !DES and ! 3DES  

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION <POLICY: 100> PAYLOADS: ID,HASH,NOTIFY

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION   ID PAYLOAD

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION     IANA No. for identifn: 1 -> ID_IPV4_ADDR

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION     Protocol Id: 17

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION     Port: 500 <== Shouldn't this be 4500?

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION     Id Data: AA.BBB.CCC.DD

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION   HASH PAYLOAD

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION   NOTIFY PAYLOAD

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION     DOI: 1

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION     Protocol Id: 1

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION     Size of SPI: 16

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION     Type of notify message: 24578

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION     Notify Type: Status: Initial Contact (24578)

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION     Length of Notification Data: 0

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION IkeInNotifyProcess: NOTIFY TYPE: INITIAL CONTACT (24578)

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION <POLICY: 100> PAYLOADS: ID,HASH

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION   ID PAYLOAD

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION     IANA No. for identifn: 1 -> ID_IPV4_ADDR

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION     Protocol Id: 0

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION     Port: 0

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION     Id Data: EEE.FFF.GG.HHH

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION   HASH PAYLOAD

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION InitialiseCipherContext :: Not DES and Not 3DES  

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION peer AA.BBB.CCC.DD: Main mode completed <== I don't get this far with SSL certs.

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION SENDING NOTIFY MSG:

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION INITIAL CONTACT

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION <POLICY: 100> PAYLOADS: HASH,NOTIFY

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION   HASH PAYLOAD

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION   NOTIFY PAYLOAD

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION     DOI: 1

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION     Protocol Id: 1

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION     Size of SPI: 16

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION     Type of notify message: 24578

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION     Notify Type: Status: Initial Contact (24578)

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION     Length of Notification Data: 0

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION InitialiseCipherContext :: Not DES and Not 3DES  

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION 100: Sent informational exchange message

2016.07.10 18:06:48 CRYPTO_IKE.NEGOTIATION

2016.07.10 18:06:55 CRYPTO_IKE.NEGOTIATION IkeRetryTimeOut :: Retrying 1st phase..

2016.07.10 18:07:00 CRYPTO_IKE.NEGOTIATION IkeRetryTimeOut :: Retrying 1st phase..

2016.07.10 18:07:05 CRYPTO_IKE.NEGOTIATION IkeRetryTimeOut :: Retrying 1st phase..

2016.07.10 18:07:14 CRYPTO_IKE.NEGOTIATION peer 86.189.253.74: Received informational exchange message

2016.07.10 18:07:14 CRYPTO_IKE.NEGOTIATION InitialiseCipherContext :: Not DES and Not 3DES  

2016.07.10 18:07:14 CRYPTO_IKE.NEGOTIATION <POLICY: 100> PAYLOADS: HASH,DEL

2016.07.10 18:07:14 CRYPTO_IKE.NEGOTIATION   HASH PAYLOAD

2016.07.10 18:07:14 CRYPTO_IKE.NEGOTIATION   DELETE PAYLOAD

2016.07.10 18:07:14 CRYPTO_IKE.NEGOTIATION     DOI: 1

2016.07.10 18:07:14 CRYPTO_IKE.NEGOTIATION     Protocol Id: 1

2016.07.10 18:07:14 CRYPTO_IKE.NEGOTIATION     Size of the SPI field: 16

2016.07.10 18:07:14 CRYPTO_IKE.NEGOTIATION     Number of SPIs being deleted: 1

2016.07.10 18:07:14 CRYPTO_IKE.NEGOTIATION

2016.07.10 18:07:14 CRYPTO_IKE.NEGOTIATION IkeDeleteIsakmpSA :: Deleting any DPDRdebusts queued in isakmpsa

I set up 'nat_traversal force;' on the Apple Mac, but the connection does not proceed.  As all my use cases require the MacBook to be behind a router I am running out of ideas.  Either Apple will have to update their racoon fork and ideally use ipsec-tools that every other distribution uses, or Adtran should upgrade their VPN to use IKEv2, which most OEMs and PCs have now moved to.

--

Regards,

Mick