Cisco VPN stop working after upgrading to IOS 6

Just an update to a message I wrote previously - I can confirm the following works/doesn't work:

At the company I work for we've been focusing on VPN on-demand so the operation of client-side certificate-based VPNs has been our focus. I've been able to get PSK VPNs working with either iOS version on any type of network. 3G is, in our case, a wireless connection through Verizon. Wifi-to-Internet means an 802.11g connection that has broadband down the line (DSL, etc.). Wifi-to-LAN is an 802.11g connection to a VLAN at the company I work for. The gateway for that network is a logical interface off the firewall which is the same firewall providing VPN connectivity (from a different interface). The firewalls handling our VPNs are an A/P HA pair of 1240b Fortigates.

We've had two problems, actually: one is iOS 6 not playing with certificate-based VPNs. The second was a connection drop problem that would typically happen within 2 to 16 minutes of an iPhone establishing a tunnel, regardless of iOS version tested (the problem remained the same after upgrading some phones to 6). It appears the connection drop problem is fixed now but I still can't get cert-based VPNs to work "over the Internet" (3G or wifi-to-Internet).

I tried something that I was hoping would fix both problems but only fixed the connection drop. I created a second firewall (fortigates can have virtual firewalls) with a separate outside interface, change the MTU from 1500 to 800 bytes (I picked that number out of thin air, more or less), and created another client-side certificate that's 1024 bits instead of 2048. Granted, there's a security concern by going with a cert that small but I was just looking to try things. This suggests the connection drop problem was one of packet size; could be fragmentation, truncation, packet drops, who knows.

Here's the kicker - we can sidestep iOS 6 VPN problems by moving the bulk of our devices over to an APN and wait (and hope) for Apple to fix the problems introduced by iOS 6. For those who don't know, the APN sounds like a sweet option (I haven't configured anything for it yet but will soon). You communicate to the carrier (Verizon, AT&T, etc.) the identifier for each iPhone you want to be on the APN and the carrier establishes a single VPN tunnel from their network to yours. All iPhone data will then travel over that single VPN connection, into the company's Internet pipes and back out (for Internet-bound traffic). It's invisible to the user and would appear to require the least amount of support. So far the cost is a one-time fee of about $500 ... and that's it. Seems too good to be true - we'll see. Granted, you have to pay for the 3G phone data but that's a cost regardless. Essentially, the APN has zero marginal cost and less support because you're only setting up a single site-to-site VPN that's always on, not some on-demand client tunnel that changes an iPhones routing on-the-fly, etc. Plus, if Apple screws up their VPN client in the future, we'll be insulated from that. Also, the built-in iPhone VPN client can't re-key their phase1 (or 2?) so there's an upper limit to how long they can stay connected whereas a site-to-site tunnel has no such limitation.

Hi,

since we have the same problem here and we already use a site-to-site tunnel to our carrier (vodafone calls it CDA), we thought about using this for our iOS devices. BUT: you have to switch of wifi on that devices, cause the carrier solutions ONLY works via 3G. This was a no-go for us....

Michael

We are not using certs for Cisco VPN in our company but after upgrade VPN seems to connect and no data recieve. Only on mobile data. with wifi works fine. still.

I note one thing - if turn ON modem mode and then turn off wifi and BT - VPN becomes to work.

It seems like 3g mode mismatch with some providers......

So problem I think is with DNS splitting. After changing address of Exchange from FQDN to ip address (intranet) it works fine in any case. I suppose as for me problem is closed and guys from A and C should find out whats up and fix in new release.

I have the same issue. I tried to google and it seems that a lot of people have the same issues with the vpn after upgrade to ios 6. In my case i'm able to establish the vpn with the Cisco Asa using the ipsec preshared key connection, but the traffic is not passing. Waiting for the apple to solve the issue.

We have done some testing on this and identified the root cause of the issue regarding certificate based VPN authentication not working correctly in IOS 6. When using certificate based authentication (rather than PSK), the VPN client in IOS 6 correctly uses IKE fragmentation to split the authentication message up into smaller chunks. The authentication message is supposed to be encrypted, split into smaller messages (which are not encrypted themselves) and then sent. Unfortunately the VPN client is setting the ISAKMP encrypted flag for these fragment messages (refer to http://www.ietf.org/rfc/rfc2408.txt page 22) when actually the messages are not encrypted. If the VPN server ignores this flag, which it can safely do by looking at the next payload type in the header and confirming it is a fragment, then the connection is established as normal.

It would seem as though this was an oversight during development and hopefully will be fixed soon.

Thanks for that. You need to formally feed that back to Apple. Anyway to get around it or improve the security if I can't use a VPN?

What VPN server software / appliance are you using that allows you to tweak whether the ISAKMP encrypted flag is ignored?

Thank you.

We have developed our own IPSEC VPN networking stack for our cloud security service (http://www.threatspike.com) so we were able to tweak the software to work around this specific bug once we identified the cause. I have submitted this as a formal bug to Apple though so hopefully they will fix it soon so you can connect as normal to your VPN gateway.

Anyone tested this with iOS 6.0.1?

It seems no to be fixed for me :-(

With the latest iOS 6.0.1 update we're finding our client-side certificate (on-demand) IPSec VPNs work now. Maybe Apple fixed the issue threatspike referred to? I see no mention of it in Apple's release notes: http://support.apple.com/kb/DL1606

threatspike, any feedback on the bug you filed?

I still get the same IKE decryption error with iOS 6.0.1 and an iPhone 4S via 3G when I try VPN with RSA certificate. None of the possible tweaks in our configuration regarding the proposal changes that -:(

My sincere apologies - ours works over local wifi now but not over 3G or wifi-to-Internet. I thought my first successful test was over 3G but the phone was probably on wifi and I missed it. : (

Hi,

problems as reported with PSK over wifi / 3g i can't reproduce.

@threatspike we were looking into the problem deeply today using tcpdump, and i don't think you are right.

The packet that is not accepted is sent from ios6 (6.0.1) using a propretary cisco IKE fragmentation.

For Strongswan 4.4.1 + 4.6.4 the following patch (done by Astaro guys) adds support for IKE fragment payloads to strongswan. That patch does not work for >= strongswan 5.x since strongswan fully removed pluto.

If applied on strongswan 4.4.1 / 4.6.4, ios 6.x devices using long certificates can connect without issues.

http://pastebin.com/mHS68juq

--- taken from the patch-description ---

The IPsec client in iOS 6 sends IKE packets split up into

IKE fragment payloads in some situations. This is done

regardless of whether UTM announces support for this

undocumented Cisco proprietary IKE extension or not.

This patch adds support for incoming IKE fragments.

----

--- Log from strongswan 5.0.1

Nov 30 00:55:21 zabbix charon: 16[NET] received packet: from 217.113.177.189[4500] to 77.232.232.141[4500]

Nov 30 00:55:21 zabbix charon: 16[ENC] decryption failed, invalid length

Nov 30 00:55:21 zabbix charon: 16[ENC] could not decrypt payloads

Nov 30 00:55:21 zabbix charon: 16[IKE] integrity check failed

---

See this screenshot, that is ios 5.1.1 connection to the server:

Ios 5.1.1 sends 2 normal fragmented udp package (1808).

Ios 6.x sends the same packages, but using cisco IKE fragmentation:

So the problem is that most non Cisco ipsec server do not understand the propretary IKE Fragementation Payload.

We are trying to integrate the patch from Astaro to Strongswan 5.0.1.

It seems that your analysis backs up what was previously discussed - specifically that the encrypted flag is incorrectly set on each of the fragment packets, hence the 0x01 value that appears in the ISAKMP header. I agree that if VPN servers don't understand the Cisco Fragmentation protocol then they will obviously fail, but even if they do then they may be thrown by the fact that the packet is advertised as having an encrypted payload when this is not the case. The Cisco Fragmentation protocol breaks up an encrypted payload into chunks and then sends each chunk wrapped in a non-encrypted ISAKMP packet.

If your device negotiates AES as the cipher for the phase 1 security association then the VPN server will attempt to decrypt 1252 bytes (taken from your first screenshot) using a cipher which works on block sizes of 128 bits (16 bytes). Since 1252 isn't divisible by 16, the decryption routine would likely throw an exception which seems to match your log extract. If the issue is simply that the Cisco fragmentation payload is not supported then this seems like a strange error message to be getting?