Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 28 replies
  • Subscribers 1 subscriber
  • Views 16711 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Cisco VPN not working with Apple iOS 6

Nemo
Hi there!

Since installing the new iOS update for the iPhone (version 6) the Cisco VPN client is not working anymore. I get the following logs in the UTM (Release 9.002-12):

2012:09:21-11:45:45 utm-1 pluto[26458]: packet from 89.204.137.123:42730: received Vendor ID payload [RFC 3947]
2012:09:21-11:45:45 utm-1 pluto[26458]: packet from 89.204.137.123:42730: ignoring Vendor ID payload [4df37928e9fc4fd1b3262170d515c662]
2012:09:21-11:45:45 utm-1 pluto[26458]: packet from 89.204.137.123:42730: ignoring Vendor ID payload [8f8d83826d246b6fc7a8a6a428c11de8]
2012:09:21-11:45:45 utm-1 pluto[26458]: packet from 89.204.137.123:42730: ignoring Vendor ID payload [439b59f8ba676c4c7737ae22eab8f582]
2012:09:21-11:45:45 utm-1 pluto[26458]: packet from 89.204.137.123:42730: ignoring Vendor ID payload [4d1e0e136deafa34c4f3ea9f02ec7285]
2012:09:21-11:45:45 utm-1 pluto[26458]: packet from 89.204.137.123:42730: ignoring Vendor ID payload [80d0bb3def54565ee84645d4c85ce3ee]
2012:09:21-11:45:45 utm-1 pluto[26458]: packet from 89.204.137.123:42730: ignoring Vendor ID payload [9909b64eed937c6573de52ace952fa6b]
2012:09:21-11:45:45 utm-1 pluto[26458]: packet from 89.204.137.123:42730: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
2012:09:21-11:45:45 utm-1 pluto[26458]: packet from 89.204.137.123:42730: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
2012:09:21-11:45:45 utm-1 pluto[26458]: packet from 89.204.137.123:42730: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
2012:09:21-11:45:45 utm-1 pluto[26458]: packet from 89.204.137.123:42730: received Vendor ID payload [XAUTH]
2012:09:21-11:45:45 utm-1 pluto[26458]: packet from 89.204.137.123:42730: ignoring Vendor ID payload [Cisco-Unity]
2012:09:21-11:45:45 utm-1 pluto[26458]: packet from 89.204.137.123:42730: ignoring Vendor ID payload [FRAGMENTATION 80000000]
2012:09:21-11:45:45 utm-1 pluto[26458]: packet from 89.204.137.123:42730: received Vendor ID payload [Dead Peer Detection]
2012:09:21-11:45:45 utm-1 pluto[26458]: "D_for Anselment to Internal (Network)"[4] 89.204.137.123:42730 #9: responding to Main Mode from unknown peer 89.204.137.123:42730
2012:09:21-11:45:46 utm-1 pluto[26458]: "D_for Anselment to Internal (Network)"[4] 89.204.137.123:42730 #9: NAT-Traversal: Result using RFC 3947: peer is NATed
2012:09:21-11:45:47 utm-1 pluto[26458]: packet from 89.204.137.123:52568: next payload type of ISAKMP Message has an unknown value: 132
2012:09:21-11:45:47 utm-1 pluto[26458]: packet from 89.204.137.123:52568: sending notification PAYLOAD_MALFORMED to 89.204.137.123:52568
2012:09:21-11:45:47 utm-1 pluto[26458]: packet from 89.204.137.123:52568: next payload type of ISAKMP Message has an unknown value: 132
2012:09:21-11:45:47 utm-1 pluto[26458]: packet from 89.204.137.123:52568: sending notification PAYLOAD_MALFORMED to 89.204.137.123:52568
2012:09:21-11:45:50 utm-1 pluto[26458]: packet from 89.204.137.123:52568: next payload type of ISAKMP Message has an unknown value: 132
2012:09:21-11:45:50 utm-1 pluto[26458]: packet from 89.204.137.123:52568: sending notification PAYLOAD_MALFORMED to 89.204.137.123:52568
2012:09:21-11:45:50 utm-1 pluto[26458]: packet from 89.204.137.123:52568: next payload type of ISAKMP Message has an unknown value: 132
2012:09:21-11:45:50 utm-1 pluto[26458]: packet from 89.204.137.123:52568: sending notification PAYLOAD_MALFORMED to 89.204.137.123:52568
2012:09:21-11:45:53 utm-1 pluto[26458]: packet from 89.204.137.123:52568: next payload type of ISAKMP Message has an unknown value: 132
2012:09:21-11:45:53 utm-1 pluto[26458]: packet from 89.204.137.123:52568: sending notification PAYLOAD_MALFORMED to 89.204.137.123:52568
2012:09:21-11:45:53 utm-1 pluto[26458]: packet from 89.204.137.123:52568: next payload type of ISAKMP Message has an unknown value: 132
2012:09:21-11:45:53 utm-1 pluto[26458]: packet from 89.204.137.123:52568: sending notification PAYLOAD_MALFORMED to 89.204.137.123:52568
2012:09:21-11:45:56 utm-1 pluto[26458]: packet from 89.204.137.123:52568: next payload type of ISAKMP Message has an unknown value: 132
2012:09:21-11:45:56 utm-1 pluto[26458]: packet from 89.204.137.123:52568: sending notification PAYLOAD_MALFORMED to 89.204.137.123:52568
2012:09:21-11:45:56 utm-1 pluto[26458]: packet from 89.204.137.123:52568: next payload type of ISAKMP Message has an unknown value: 132
2012:09:21-11:45:56 utm-1 pluto[26458]: packet from 89.204.137.123:52568: sending notification PAYLOAD_MALFORMED to 89.204.137.123:52568
2012:09:21-11:45:57 utm-1 pluto[26458]: packet from 89.204.137.123:52568: next payload type of ISAKMP Message has an unknown value: 132
2012:09:21-11:45:57 utm-1 pluto[26458]: packet from 89.204.137.123:52568: sending notification PAYLOAD_MALFORMED to 89.204.137.123:52568
2012:09:21-11:45:57 utm-1 pluto[26458]: "D_for Anselment to Internal (Network)"[4] 89.204.137.123:42730 #8: max number of retransmissions (2) reached STATE_MAIN_R2
2012:09:21-11:45:57 utm-1 pluto[26458]: packet from 89.204.137.123:52568: next payload type of ISAKMP Message has an unknown value: 132
2012:09:21-11:45:57 utm-1 pluto[26458]: packet from 89.204.137.123:52568: sending notification PAYLOAD_MALFORMED to 89.204.137.123:52568 


I think only a new update will resolve this.


This thread was automatically locked due to age.
  • 0 in reply to BAlfson

    • Name             : Local X509
    • Key Size         : 1024
    • VPN-ID-Type      : Distinguished Name
    • Country          : DE
    • State            : mb
    • City             : mb
    • Organization     : mb
    • Org.-Unit        : mb
    • Common Name      : mb
    • E-Mail           : mb@mb.de



    I just got a call from a customer, he has a brand new ipad, since the update to ios6 the vpn is broken.
    This did not work for my customer like BAlfson suggested, the empty fields like in the thread above did work tough without problems according to the other side of the phone. Thanks!
  • 0 in reply to all4it
    Hi Folks!

    The hint with the as-short-as-possible certificates allowed my devices to connect with the Astaro (8.305) again - but I can't reach my exchange or any of my local IPs/Sites/Servers.

    The Logs and VPN-Status shows no traces of the connection, so I have no idea where to investigate further... .

    Any suggestions

    Thanks in advance!

    Thomas 1000
  • 0 in reply to BAlfson
    Hi Bob,

    We have Astaro SW v8.301 

    is there a workaround for this version, when we try and change the specific certificate or create a new one it applies the certificate key globally, so if we try change the certificate for one we have to change it for all certificates and we have many other VPN certs (site - site, SSL etc...)

    is there any way we can just apply this change to the Cisco one specifically?

    Thanks
  • 0
    Hey Richo & Thomas - welcome to the User BB!

    [[:(]] This is one of the reasons I'm waiting another month to move up to an iPhone 5. [[:(]]

    Thomas, what do you see on the iPhone that tells you you are connected?  What do you see on 'Remote Access Status' in WebAdmin?  I don't understand how the IPsec log can be empty.

    Richo, thank Apple for this.  I'm sure they or Astaro/Sophos will have a workaround soon.  If you want to make the change now, send the new public key to install in each of your remote sites first.  Then you should be able to change over invisibly.  Anyone using a "regular" IPsec Remote Access client (like the Astaro AIC) will need to download anew, too, just like the Cisco clients.

    Cheers - Bob
  • 0
    The patch for this was merged into 9.004 recently. For V8 I targeted it for 8.307. I suppose it's important enough to get into this release.

    A little background for those of you interested in what was causing this:
    The IPsec client in iOS 6 sends IKE packets split up into IKE fragment payloads in some situations. This is a bit hacky workaround to get around some broken NAT gateways that don't handle IP fragments properly. iOS 6 sends the IKE fragment payloads regardless of whether its IKE peer announced support for this unpublished IKE extension or not. A clear case of iOS being a bit of a bully here. =)
  • 0 in reply to d12fk
    The patch for this was merged into 9.004 recently. For V8 I targeted it for 8.307. I suppose it's important enough to get into this release.

    A little background for those of you interested in what was causing this:
    The IPsec client in iOS 6 sends IKE packets split up into IKE fragment payloads in some situations. This is a bit hacky workaround to get around some broken NAT gateways that don't handle IP fragments properly. iOS 6 sends the IKE fragment payloads regardless of whether its IKE peer announced support for this unpublished IKE extension or not. A clear case of iOS being a bit of a bully here. =)


    Good to hear, what do you think, when can we expect 9.004? I won't twist your arm if its not the exact date!
  • 0
    9.004 has just been soft-released and it fixes the issue. iOS VPN is working again.
  • 0
    Hi,
    on two different UTMs with 9.004, I get this error:

    ERROR: asynchronous network error report on eth1 for message to 89.x.x.x port 49270, complainant 89.x.x.x: Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)] 


    On the IOS6 device: 
    server certificate could not be verified


    Before this update, with IOS5 it was working fine :-(
    Now I get the same error... maybe I forgot something?


    Nice greetings
  • 0 in reply to GuyFawkes
    Strange, I didn't have to do anything. It's working again on all our iOS6 devices.

    Franc.