Wireless Access

I've noticed a pattern with at least 4 different iOS (iPhone & iPad) devices where after updating to iOS 6, VPN to our 620 controller no longer connections. We were successfully using IPSEC VPN from these iOS devices to a 620 running 6.1.3. After the udpdate these same devices get an "unexpected error". I can confirm that the configuration on the controller didn't change at all. I have tested the exact same VPN configuration from other iOS devices that have not been updated & they connect just fine. Anyone else run into this?

Here is the debug output from the controller. Based on what I'm seeing in the debugs, the pool assigns an IP and an SA is created. By the way, the debug is me testing from an iPhone just using 3G service.

=======================================================================

Oct 12 13:26:48 :103063:  <DBUG> |ike|  174.225.5.57:4500-> new length of attribute is 21
Oct 12 13:26:48 :103063:  <DBUG> |ike|  174.225.5.57:4500-> got username=<username>
Oct 12 13:26:48 :103063:  <DBUG> |ike|  174.225.5.57:4500-> got password=******
Oct 12 13:26:48 :103063:  <DBUG> |ike|  174.225.5.57:4500-> got user=<username>, pass=******
Oct 12 13:26:48 :103060:  <DBUG> |ike|  174.225.5.57:4500-> ipc.c:ipc_auth_xauth:3056 ipc_auth_xauth user=<username>, pass=******
Oct 12 13:26:48 :103063:  <DBUG> |ike|  174.225.5.57:4500-> ipc_auth_xauth exch:101dd9e4 exip:0 extype:6 cookie:3404411434
Oct 12 13:26:48 :103063:  <DBUG> |ike|   ipc_auth_recv_packet cookie:3404411434 innerip 0
Oct 12 13:26:48 :103063:  <DBUG> |ike|   *** ipc_auth_recv_packet user=<username>, pass=******, result=0   exch:101dd9e4, exch-innerip:0 l2tp_pool:NYC-Private
Oct 12 13:26:48 :103063:  <DBUG> |ike|   ipc_auth_recv_packet pool NYC-Private
Oct 12 13:26:48 :199800:  <DBUG> |l2tp|  shared_cli.c, shared_cli_get_addr:1279:  Caller:ike Allocated IP address 192.168.21.58 pool:NYC-Private
Oct 12 13:26:48 :103063:  <DBUG> |ike|   ipc_auth_recv_packet Inner-ip 192.168.21.58 from L2TP pool NYC-Private, DNS1:44691c10, DNS2:4020202, WINS1:0, WINS2:0
Oct 12 13:26:48 :103063:  <DBUG> |ike|   ipc_auth_recv_packet innerip:192.168.21.58 user-pool:NYC-Private
Oct 12 13:26:48 :103063:  <DBUG> |ike|   ipc_auth_recv_packet sa src=0x4859837a, dst=0xaee10539
Oct 12 13:26:48 :103063:  <DBUG> |ike|   ipc_auth_recv_packet calling client_auth_ip_up for InnerIP c0a8153a
Oct 12 13:26:48 :103047:  <INFO> |ike|  IKE XAuth succeeded for 192.168.21.58 (External 174.225.5.57) for vpn-nycprivate-role
Oct 12 13:26:48 :103063:  <DBUG> |ike|   xauth_responder_send_statusset peer:174.225.5.57
Oct 12 13:26:49 :103063:  <DBUG> |ike|  174.225.5.57:4500-> xauth_responder_recv_statusack peer:174.225.5.57
Oct 12 13:26:49 :103063:  <DBUG> |ike|  174.225.5.57:4500-> exchange_update_iv: udpating exch 0x101dd9e4 from 0x9764f9f5 to 0xb86844ee
Oct 12 13:26:49 :103063:  <DBUG> |ike|  174.225.5.57:4500-> xauth_responder_recv_ipreq peer:174.225.5.57
Oct 12 13:26:49 :103063:  <DBUG> |ike|  174.225.5.57:4500-> length of attribute is 102
Oct 12 13:26:49 :103063:  <DBUG> |ike|  174.225.5.57:4500-> xauth_responder_send_iprep peer:174.225.5.57 innerip:192.168.21.58
Oct 12 13:26:50 :103060:  <DBUG> |ike|  174.225.5.57:4500-> sa.c:ike_sa_setup_ph2complete_timer:2860 SA 0x101e868c ph2-completion timeout in 30 seconds
Oct 12 13:26:50 :103063:  <DBUG> |ike|  174.225.5.57:4500-> ike_phase_2_validate_prop_for_client dyn-map default-dynamicmap
Oct 12 13:26:50 :103063:  <DBUG> |ike|  174.225.5.57:4500-> ike_phase_2_validate_prop_for_client map default-dynamicmap  v:1
Oct 12 13:26:50 :103060:  <DBUG> |ike|  174.225.5.57:4500-> ike_quick_mode.c:responder_recv_HASH_SA_NONCE:2589 message negotiation succeeded
Oct 12 13:26:50 :103063:  <DBUG> |ike|  174.225.5.57:4500-> post_quick_mode keymat:0 len:52
Oct 12 13:26:50 :103063:  <DBUG> |ike|  174.225.5.57:4500-> post_quick_mode keymat:1 len:52
Oct 12 13:26:50 :103022:  <INFO> |ike|  IKE Quick Mode succeeded for peer 174.225.5.57
Oct 12 13:26:50 :103033:  <INFO> |ike|  IKE Quick Mode succeeded internal 192.168.21.58, external 174.225.5.57
Oct 12 13:26:50 :103060:  <DBUG> |ike|  174.225.5.57:4500-> ike_quick_mode.c:ike_quick_mode_send_notify:3499 ike_quick_mode_send_notify: Added ike quick mode notify payload.
Oct 12 13:26:50 :103063:  <DBUG> |ike|  174.225.5.57:4500-> ipsec_finalize_exchange: src_net 0.0.0.0 src_mask 0.0.0.0 dst_net 192.168.21.58 dst_mask 255.255.255.255 tproto 0 sport 0 dport 0
Oct 12 13:26:50 :103063:  <DBUG> |ike|  174.225.5.57:4500-> ipsec_exchange_finalize : Phase 2 SA: checking VPN limits
Oct 12 13:26:50 :103063:  <DBUG> |ike|  174.225.5.57:4500-> ipsec_finalize_exchange: increment limit 2
Oct 12 13:26:50 :103063:  <DBUG> |ike|  174.225.5.57:4500-> pf_key_v2_enable_sa rekeying 0 saxauthip 0 isainnerip 0
Oct 12 13:26:50 :103063:  <DBUG> |ike|  174.225.5.57:4500-> pf_key_v2_enable_sa saxauthip 192.168.21.58
Oct 12 13:26:50 :103063:  <DBUG> |ike|  174.225.5.57:4500-> pf_key_v2_enable_sa isainnerip 192.168.21.58
Oct 12 13:26:50 :103063:  <DBUG> |ike|  174.225.5.57:4500-> ipsec_sa 0x101d6934, proto 0x101e9294
Oct 12 13:26:50 :103063:  <DBUG> |ike|  174.225.5.57:4500-> ipc_setup_ipsec_dp_sa add=1, out=1, sa=0x101e8c44, proto=0x101e9294
Oct 12 13:26:50 :103063:  <DBUG> |ike|  174.225.5.57:4500-> ipc_setup_ipsec_dp_sa sa src=0x4859837a, dst=0xaee10539
Oct 12 13:26:50 :103060:  <DBUG> |ike|  174.225.5.57:4500-> ipc.c:ipc_print_dp_packet:2610 DP: :TUNNEL::SA_ADD::L2TP: OFF::outgoing::ESP::AES256::Auth = SHA1:, SPI 90564FA, esrc 4859837A, edst_ip AEE10539, dst_ip C0A8153A, natt 1, natt_dport 43839, l2tp_tunid 0, l2tp_sessid 0, l2tp_hello 0
Oct 12 13:26:50 :103060:  <DBUG> |ike|  174.225.5.57:4500-> ipc.c:ipc_modify_sb_data:2016 IPSEC  dst_ip=192.168.21.58, dst_mask 0.0.0.0 inner_ip 192.168.21.58 client:yestrusted:no, Master-Local:no
Oct 12 13:26:50 :103063:  <DBUG> |ike|  174.225.5.57:4500->  Setup the outgoing IPSEC SA --- DONE  !!
Oct 12 13:26:50 :103063:  <DBUG> |ike|  174.225.5.57:4500-> ipc_setup_ipsec_dp_sa add=1, out=0, sa=0x101e8c44, proto=0x101e9294
Oct 12 13:26:50 :103063:  <DBUG> |ike|  174.225.5.57:4500-> ipc_setup_ipsec_dp_sa sa src=0x4859837a, dst=0xaee10539
Oct 12 13:26:50 :103060:  <DBUG> |ike|  174.225.5.57:4500-> ipc.c:ipc_print_dp_packet:2610 DP: :TUNNEL::SA_ADD::L2TP: OFF::incoming::ESP::AES256::Auth = SHA1:, SPI 3239FB00, esrc AEE10539, edst_ip 4859837A, dst_ip C0A8153A, natt 1, natt_dport 43839, l2tp_tunid 0, l2tp_sessid 0, l2tp_hello
Oct 12 13:26:50 :103063:  <DBUG> |ike|  174.225.5.57:4500->  Setup the incoming IPSEC SA --- DONE  !!
Oct 12 13:26:50 :103063:  <DBUG> |ike|  174.225.5.57:4500-> ->Delete DOI_MIN Exchange ic be5f90ff551ee7c1 rc 84ffad691266ed3a
Oct 12 13:26:50 :103060:  <DBUG> |ike|  174.225.5.57:4500-> message.c:message_validate_hash:881 DELETE notification received with proper hash
Oct 12 13:26:50 :103060:  <DBUG> |ike|  174.225.5.57:4500-> ipsec.c:ipsec_delete_spi_list:1689 DELETE made us delete Phase-1 SA 0x101e868c (8 references) for proto 1 Initiator cookie:be5f90ff551ee7c1 Responder cookie:84ffad691266ed3a Peer:174.225.5.57
Oct 12 13:26:50 :103063:  <DBUG> |ike|  174.225.5.57:4500-> ->Delete INFO Exchange ic be5f90ff551ee7c1 rc 84ffad691266ed3a

UPDATE: It looks like there are a ton of threads in the Apple communities about this very same thing. It appears to be only impacting IPSEC VPN.

Bump...anyone else run into this?

Edit:  Please see the attached release notes on Arubaos 6.1.3.5.  

72258 An issue has been fixed where Apple devices running iOS 6 were not able to establish VPN tunnel using their built-in VPN client. This issue was seen in 3200 controller running ArubaOS 6.1.3.3.

Attachment(s)

ArubaOS6.1.3.5 Release Notes.pdf   677 KB 1 version

Thanks! Thats good to know. Was this a bug within iOS 6 that Aruba was able to navigate around?

I'm sorry.  All that I know is that it was a change in Apple's behavior that had to be accounted for.