I own a company that works in public safety and need VPN access to many of my clients. When I updated to 6.0 it totally broke my IPSEC VPN and now I need to go back to my Panasonic Toughbook until they get this fixed!
I'm pretty new to Apple so this iPad with Verizon 4G is my first Apple product and I've only owned it for about 3 months and just started trusting it to carry with me on my jobs.
I was absolutely amazed when I called Apple Care and found out they don't allow a previous signed ios version and there is no way to revert back to the previous ios!
I'm a Microsoft, Cisco, Intel, etc., etc. partner and this is unheard of in my industry. They always provide a path back because they know it's virtually imposible to find every bug in a general release.
In my role working with Police, Fire, and other first responders in some of our largest cities I can tell you now that if they do not change this policy of not allowing you to fall back to the previous ios I will strongly lobby my customers to never buy Apple iPads and share my frustrating story.
Are you listening Tim Cook.
Just an update to a message I wrote previously - I can confirm the following works/doesn't work:
iOS version w/ client-side cert 3G wifi-to-internet wifi-to-LAN iOS 5.x yes yes yes iOS 6 no no yes iOS version w/ PSK 3G wifi-to-internet wifi-to-LAN iOS 5.x yes yes yes iOS 6 yes yes yes
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.
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......
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.
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.
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?
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.
--- 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 22.214.171.124 to 126.96.36.199
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.