iPad and the Cisco VPN
Published: 06/11/2010
Reference trace file:
ipad_and_cisco_vpn.cap
The iPad is certainly a cool little toy. Not only does it support WPA Enterprise for Wi-Fi connectivity, it also has a built-in Cisco VPN client which does IPsec, L2TP, and PPTP. It unfortunately doesn't have the SSL-based AnyConnect client (which all Cisco shops seem to be moving over to these days), although iPhone OS 4 may potentially include it, but nevertheless an IPsec-capable client isn't a bad thing. But does it actually work? I've occasionally seen consumer devices feature something "enterprise-grade" because it's nifty for marketing while the implementation actually falls flat on its face when you attempt to use it.
We all know what an IPsec transaction looks like. Would it be any different on an iPad? Probably not, but wouldn't it be interesting to just see it happen? That's what we're here for today - have the device associate to an open hotspot and make the VPN connection. For this article, I configured an old Cisco 3005 concentrator with an external address of 1.2.3.4, created a simple group profile and a user account on the VPN concentrator, and statically configured an IP of 1.2.3.6 on the iPad (because the ancient Netgear access point used as the public hotspot simulation really sucks when it comes to doing simple things like handing out addresses; consumer-grade junk, I tell you...).
The first few moments with our hotspot...
The trace file has been pared down a bit from the original. I've taken the liberty of removing all 802.11 Beacons, Probe Requests, Probe Responses, and a few other control frames, as well as ARP to improve the signal-to-noise ratio for our analysis.
In the first four frames, we see your basic 802.11 association process taking place between the iPad and the access point broadcasting the SSID "232." As you can tell by the parameter information in packet 3, this is a pretty old 802.11b-only Netgear AP. I didn't feel like breaking out the spare Cisco 1230 today. I got lazy.
As I mentioned earlier, I manually pre-configured an IP to the iPad before connecting to the access point. Even after I did this, the iPad apparently likes to send out a DHCP Discover packet after associating. I guess old habits die hard.
The iPad is apparently an IPv6-capable device, as we can see from the various ICMPv6 and multicast DNS queries that get loudly sent out to the network via an IPv6 link-local address, announcing my device's hostname in the process (this is also noted in the first DHCP Discover packet as well). This, along with a few IGMP packets using our real IPv4 address, get sent over the network for the next few seconds while I fumble around the iPad to start the VPN client which I pre-configured for our Cisco gateway.
iPad does IKE
Starting at packet 90, I switch on the slider for the VPN client in the iPad GUI and we see the three-packet phase 1 / Aggressive Mode exchange with the initiator cookie value of E970B24A2B2043F3:
Show packet content
Initiator cookie: E970B24A2B2043F3
Responder cookie: 0000000000000000
Next payload: Security Association (1)
Version: 1.0
Exchange type: Aggressive (4)
Flags: 0x00
.... ...0 = Not encrypted
.... ..0. = No commit
.... .0.. = No authentication
Message ID: 0x00000000
Length: 736
Security Association payload
Next payload: Key Exchange (4)
Payload length: 292
Domain of interpretation: IPSEC (1)
Situation: IDENTITY (1)
Proposal payload # 1
Next payload: NONE (0)
Payload length: 280
Proposal number: 1
Protocol ID: ISAKMP (1)
SPI Size: 0
Proposal transforms: 8
Transform payload # 1
Next payload: Transform (3)
Payload length: 36
Transform number: 1
Transform ID: KEY_IKE (1)
Life-Type (11): Seconds (1)
Life-Duration (12): Duration-Value (3600)
Encryption-Algorithm (1): AES-CBC (7)
Key-Length (14): Key-Length (256)
Authentication-Method (3): XAUTHInitPreShared (65001)
Hash-Algorithm (2): SHA (2)
Group-Description (4): Alternate 1024-bit MODP group (2)
Transform payload # 2
Next payload: Transform (3)
Payload length: 36
Transform number: 2
Transform ID: KEY_IKE (1)
Life-Type (11): Seconds (1)
Life-Duration (12): Duration-Value (3600)
Encryption-Algorithm (1): AES-CBC (7)
Key-Length (14): Key-Length (128)
Authentication-Method (3): XAUTHInitPreShared (65001)
Hash-Algorithm (2): SHA (2)
Group-Description (4): Alternate 1024-bit MODP group (2)
Transform payload # 3
Next payload: Transform (3)
Payload length: 36
Transform number: 3
Transform ID: KEY_IKE (1)
Life-Type (11): Seconds (1)
Life-Duration (12): Duration-Value (3600)
Encryption-Algorithm (1): AES-CBC (7)
Key-Length (14): Key-Length (256)
Authentication-Method (3): XAUTHInitPreShared (65001)
Hash-Algorithm (2): MD5 (1)
Group-Description (4): Alternate 1024-bit MODP group (2)
Transform payload # 4
Next payload: Transform (3)
Payload length: 36
Transform number: 4
Transform ID: KEY_IKE (1)
Life-Type (11): Seconds (1)
Life-Duration (12): Duration-Value (3600)
Encryption-Algorithm (1): AES-CBC (7)
Key-Length (14): Key-Length (128)
Authentication-Method (3): XAUTHInitPreShared (65001)
Hash-Algorithm (2): MD5 (1)
Group-Description (4): Alternate 1024-bit MODP group (2)
Transform payload # 5
Next payload: Transform (3)
Payload length: 32
Transform number: 5
Transform ID: KEY_IKE (1)
Life-Type (11): Seconds (1)
Life-Duration (12): Duration-Value (3600)
Encryption-Algorithm (1): 3DES-CBC (5)
Authentication-Method (3): XAUTHInitPreShared (65001)
Hash-Algorithm (2): SHA (2)
Group-Description (4): Alternate 1024-bit MODP group (2)
Transform payload # 6
Next payload: Transform (3)
Payload length: 32
Transform number: 6
Transform ID: KEY_IKE (1)
Life-Type (11): Seconds (1)
Life-Duration (12): Duration-Value (3600)
Encryption-Algorithm (1): 3DES-CBC (5)
Authentication-Method (3): XAUTHInitPreShared (65001)
Hash-Algorithm (2): MD5 (1)
Group-Description (4): Alternate 1024-bit MODP group (2)
Transform payload # 7
Next payload: Transform (3)
Payload length: 32
Transform number: 7
Transform ID: KEY_IKE (1)
Life-Type (11): Seconds (1)
Life-Duration (12): Duration-Value (3600)
Encryption-Algorithm (1): DES-CBC (1)
Authentication-Method (3): XAUTHInitPreShared (65001)
Hash-Algorithm (2): SHA (2)
Group-Description (4): Alternate 1024-bit MODP group (2)
Transform payload # 8
Next payload: NONE (0)
Payload length: 32
Transform number: 8
Transform ID: KEY_IKE (1)
Life-Type (11): Seconds (1)
Life-Duration (12): Duration-Value (3600)
Encryption-Algorithm (1): DES-CBC (1)
Authentication-Method (3): XAUTHInitPreShared (65001)
Hash-Algorithm (2): MD5 (1)
Group-Description (4): Alternate 1024-bit MODP group (2)
Key Exchange payload
Next payload: Nonce (10)
Payload length: 132
Key Exchange Data (128 bytes / 1024 bits)
Nonce payload
Next payload: Identification (5)
Payload length: 20
Nonce Data
Identification payload
Next payload: Vendor ID (13)
Payload length: 12
ID type: 11
ID type: KEY_ID (11)
Protocol ID: Unused
Port: Unused
Identification Data
Vendor ID: RFC 3947 Negotiation of NAT-Traversal in the IKE
Next payload: Vendor ID (13)
Payload length: 20
Vendor ID: RFC 3947 Negotiation of NAT-Traversal in the IKE
Vendor ID: 4DF37928E9FC4FD1B3262170D515C662
Next payload: Vendor ID (13)
Payload length: 20
Vendor ID: 4DF37928E9FC4FD1B3262170D515C662
Vendor ID: 8F8D83826D246B6FC7A8A6A428C11DE8
Next payload: Vendor ID (13)
Payload length: 20
Vendor ID: 8F8D83826D246B6FC7A8A6A428C11DE8
Vendor ID: 439B59F8BA676C4C7737AE22EAB8F582
Next payload: Vendor ID (13)
Payload length: 20
Vendor ID: 439B59F8BA676C4C7737AE22EAB8F582
Vendor ID: 4D1E0E136DEAFA34C4F3EA9F02EC7285
Next payload: Vendor ID (13)
Payload length: 20
Vendor ID: 4D1E0E136DEAFA34C4F3EA9F02EC7285
Vendor ID: 80D0BB3DEF54565EE84645D4C85CE3EE
Next payload: Vendor ID (13)
Payload length: 20
Vendor ID: 80D0BB3DEF54565EE84645D4C85CE3EE
Vendor ID: 9909B64EED937C6573DE52ACE952FA6B
Next payload: Vendor ID (13)
Payload length: 20
Vendor ID: 9909B64EED937C6573DE52ACE952FA6B
Vendor ID: draft-ietf-ipsec-nat-t-ike-03
Next payload: Vendor ID (13)
Payload length: 20
Vendor ID: draft-ietf-ipsec-nat-t-ike-03
Vendor ID: draft-ietf-ipsec-nat-t-ike-02
Next payload: Vendor ID (13)
Payload length: 20
Vendor ID: draft-ietf-ipsec-nat-t-ike-02
Vendor ID: draft-ietf-ipsec-nat-t-ike-02\n
Next payload: Vendor ID (13)
Payload length: 20
Vendor ID: draft-ietf-ipsec-nat-t-ike-02\n
Vendor ID: draft-beaulieu-ike-xauth-02.txt
Next payload: Vendor ID (13)
Payload length: 12
Vendor ID: draft-beaulieu-ike-xauth-02.txt
Vendor ID: CISCO-UNITY-1.0
Next payload: Vendor ID (13)
Payload length: 20
Vendor ID: CISCO-UNITY-1.0
Vendor ID: RFC 3706 Detecting Dead IKE Peers (DPD)
Next payload: NONE (0)
Payload length: 20
Vendor ID: RFC 3706 Detecting Dead IKE Peers (DPD)
|
and responder cookie of 82C0EB9C1ACECA54. The negotiated IKE transform is 3DES / MD5.
Show packet content
Initiator cookie: E970B24A2B2043F3
Responder cookie: 82C0EB9C1ACECA54
Next payload: Security Association (1)
Version: 1.0
Exchange type: Aggressive (4)
Flags: 0x00
.... ...0 = Not encrypted
.... ..0. = No commit
.... .0.. = No authentication
Message ID: 0x00000000
Length: 444
Security Association payload
Next payload: Key Exchange (4)
Payload length: 52
Domain of interpretation: IPSEC (1)
Situation: IDENTITY (1)
Proposal payload # 1
Next payload: NONE (0)
Payload length: 40
Proposal number: 1
Protocol ID: ISAKMP (1)
SPI Size: 0
Proposal transforms: 1
Transform payload # 6
Next payload: NONE (0)
Payload length: 32
Transform number: 6
Transform ID: KEY_IKE (1)
Encryption-Algorithm (1): 3DES-CBC (5)
Hash-Algorithm (2): MD5 (1)
Group-Description (4): Alternate 1024-bit MODP group (2)
Authentication-Method (3): XAUTHInitPreShared (65001)
Life-Type (11): Seconds (1)
Life-Duration (12): Duration-Value (3600)
Key Exchange payload
Next payload: Nonce (10)
Payload length: 132
Key Exchange Data (128 bytes / 1024 bits)
Nonce payload
Next payload: Identification (5)
Payload length: 24
Nonce Data
Identification payload
Next payload: Hash (8)
Payload length: 12
ID type: 1
ID type: IPV4_ADDR (1)
Protocol ID: UDP (17)
Port: Unused
Identification data: 1.2.3.4
Hash payload
Next payload: Vendor ID (13)
Payload length: 20
Hash Data
Vendor ID: CISCO-UNITY-1.0
Next payload: Vendor ID (13)
Payload length: 20
Vendor ID: CISCO-UNITY-1.0
Vendor ID: draft-beaulieu-ike-xauth-02.txt
Next payload: Vendor ID (13)
Payload length: 12
Vendor ID: draft-beaulieu-ike-xauth-02.txt
Vendor ID: RFC 3706 Detecting Dead IKE Peers (DPD)
Next payload: Vendor ID (13)
Payload length: 20
Vendor ID: RFC 3706 Detecting Dead IKE Peers (DPD)
Vendor ID: draft-ietf-ipsec-nat-t-ike-02\n
Next payload: NAT-D (draft-ietf-ipsec-nat-t-ike-01 to 03) (130)
Payload length: 20
Vendor ID: draft-ietf-ipsec-nat-t-ike-02\n
NAT-D (draft-ietf-ipsec-nat-t-ike-01 to 03) payload
Next payload: NAT-D (draft-ietf-ipsec-nat-t-ike-01 to 03) (130)
Payload length: 20
Hash of address and port: 90A541258A81A1E5FFA0F55FCC42B636
NAT-D (draft-ietf-ipsec-nat-t-ike-01 to 03) payload
Next payload: Vendor ID (13)
Payload length: 20
Hash of address and port: C62CBE5CD0D8C1DEEED644DC94DA8B71
Vendor ID: Microsoft L2TP/IPSec VPN Client
Next payload: Vendor ID (13)
Payload length: 24
Vendor ID: Microsoft L2TP/IPSec VPN Client
Vendor ID: 77074C811ACFCA5423C9883F592404F5
Next payload: Vendor ID (13)
Payload length: 20
Vendor ID: 77074C811ACFCA5423C9883F592404F5
Vendor ID: 1F07F70EAA6514D3B0FA96542A500407
Next payload: NONE (0)
Payload length: 20
Vendor ID: 1F07F70EAA6514D3B0FA96542A500407
|
The two hosts do their Diffie-Hellman thing, and by packet 92 all we see is gibberish while they get ready to do XAUTH and proceed to Config Mode for the client's tunnel IP address, internal DNS, tunnel parameter information, inside routes, etc. We can't see it due to it being encrypted, of course, so we'll just have to use our imagination here. By the way, I'm prompted to enter my username / password on the iPad at this point.
Oddly enough, in packet 98 we see the gateway sending the iPad an "UNKNOWN-ISAKMP-VERSION" message, but to an IP address of 1.2.17.28 (although based on the information in the MAC header, it's clearly meant for the iPad's network interface). Config Mode continues on, however.
At packet 104, we finally move into phase 2 / Quick Mode. This is roughly twelve seconds after our first IKE packet, so the Config Mode process was a bit slow, probably due to the ISAKMP version message above. But phase 2 finishes quickly ...
... and then poof! we're in. Looking at the Cisco concentrator's log we see that the reported client operating system is the iPhone OS. It feels a bit strange seeing that since I'm so used to seeing a Windows value. I remained logged in for a while and then terminated the connection, followed by me switching off the virtual Wi-Fi switch. You can see the 802.11 Disassociate frame go out on packet 123.
So yes, it does work...
I have no idea how many iPad users would actually use the Cisco VPN client (aside from students at schools requiring it), but I suspect they're not that common in the grand scheme of things. I once connected to my work's VPN gateway and started some Remote Desktop sessions with a couple of Windows servers (Mocha Remote Desktop Lite 2.3 was free when I downloaded this from the App Store). Otherwise, it would seem to be kind of a novelty since most users won't have an IPsec / L2TP / PPTP gateway running at home.
But it's still cool nonetheless.
Go back to the main articles list.