[Webinar] Streamline your web hosting managementRegister Today

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 3622
  • Last Modified:

Cisco VPN Error Messages

I have a VPN that has been configured for a couple months between a clients SonicWall and my ASA 5505.   The tunnel have been active with no error messages, but I just started receiving the following error messages.   I've contacted the client and he states that nothing has changed (that he is aware of), but I believe something had to be changed to drop the tunnel.  I will pass Phase1, but crash on Phase2.   Can someone assist me with what these error messages are referencing to?   I'm not to sure about SonicWall applicances, but I need to have some idea of where to have him look.

  • 2
  • 2
2 Solutions
Nole_FanAuthor Commented:

Unknown identification type, Phase 2, Type 7
Error processing payload: Payload ID: 5
QM FSM error (P2 struct &0xce8e2ad0, mess id 0xed88bf4c)!
Removing peer from correlator table failed, no match!
Nole_FanAuthor Commented:
Also, If I clear the IPSEC o the tunnel, the VPN will come back up, but I still receive the error messages.
I've never seen this exact symptom, but I think I know your problem anyway - I've seen similar weirdness when using L2L VPN on SonicWall firewalls, I won't deploy them anymore.

The SonicWall is most likely doing it's encryption in software, which is far slower than your ASA's hardware encryption module.  SonicWall offers some hardware encryption accelerators on some models, but I bet you don't have one in use here.

I think your ASA is timing out and dropping the tunnel because it doesn't like the delays in getting data back from the remote SonicWall.   I know that sounds silly, but I really think it's it - I've seen it many times, on all the platforms (ASA, 5505, 5510, 5520, SonicWall from SOHO models to their enterprise platforms).  

That said, there are known VPN buggy issues with ASA 7.x code, if you're on one of those versions, that could be your problem.  Admittedly, these issues of which I'm aware are all related to remote access vpn, not l2l, but you never know, right?  Upgrade to 8.x and see if that helps.  

I'm assuming, of course, that you've checked other possibilities such as a configuration mismatch.  You said the tunnel will be up and working, then just lay an egg on you.  If you had something like a pre-shared key mismatch, hash, pfs, encryption, DH group mismatch, anything like that, your tunnel would never come up in the first place.  So unless someone is having some fun with you on one side or another, I doubt that's it, but it's worth checking tunnel parameters on both sides just for giggles.  

Another thing, is the remote SonicWall on a dynamic IP on the WAN side?  I ask because you're getting an unknown identification type.  If the tunnel were never coming up at all, this would indicate to me that you've got an ISAKMP problem with one side identifying itself by IP address and the other using Domain Name, for example.  But again, if this was happening, the tunnel would never come up in the first place.  You're not getting "unknown identification parameter" (i.e., the hostname is wrong), but rather "unknown identification type", which would mean that your ASA is expecting something like "ISAKMP identity address", but for some reason, on occasion, it's getting "ISAKMP identity domain".  

If the SonicWall has a dynamic IP on the WAN side, that's likely your problem.  --TX
Here is the official Cisco explanation for the syslog message you're getting:
Error Message    %PIX|ASA-3-713016: Unknown identification type, Phase 1 or 2, Type
Explanation    This message indicates that the ID received from the peer is unknown. The ID could be an unfamiliar valid ID or an invalid or corrupted ID.

Recommended Action    Check the configuration on head end and peer(s).

But again, if the tunnel is coming up and working, you've got a good ID type negotiated between the peers or it would never work.  It's possible that someone is inadvertantly changing this in one of the configs without knowing it, the SonicWall has a dynamic IP, or, and I think most likely, the SonicWall is doing encryption in software and through normal operation it's taking so long to respond to the ASA that the ASA is dropping the tunnel.  --TX

Featured Post

Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now