Guest User!

You are not Sophos Staff.

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

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.
Parents
  • 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
Reply
  • 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
Children
No Data