Site to Site VPN keeps dropping, QM FSM Error, etc

Question : Site to Site VPN keeps dropping, QM FSM Error, etc

Hi all

This is a bit mind boggling. Short summary of the WAN. We have two sites that are inter-connected via IPSec VPN tunnel. At HQ is an ASA5520 and at the remote site is a PIX506e. This Pix is plugged into a Cisco 851 Router which in turn is plugged into the ISP.

Last week we replaced an old Linksys router with the aforementioned Cisco 851 (no fancy config, just plain routing). Ever since the swap I see the following errors in the HQ ASA’s log all the time:

3  Aug 04 2008 09:51:29 713902 Group = 89.x.y.z, IP = 89.x.y.z, Removing peer from correlator table failed, no match!
3  Aug 04 2008 09:51:29 713902 Group = 89.x.y.z, IP = 89.x.y.z, Removing peer from correlator table failed, no match!
3  Aug 04 2008 09:51:29 713902 Group = 89.x.y.z, IP = 89.x.y.z, QM FSM error (P2 struct &0x4ed8c40, mess id 0xb8812293)!
3  Aug 04 2008 09:51:29 713227 IP = 89.x.y.z, Rejecting new IPSec SA negotiation for peer z.y.x.89. A negotiation was already in progress for local Proxy 172.30.50.0/255.255.254.0, remote Proxy 10.11.12.0/255.255.255.0
3  Aug 04 2008 09:51:29 713902 Group = 89.x.y.z, IP = 89.x.y.z, QM FSM error (P2 struct &0x4f5c2f0, mess id 0x7926298)!
3  Aug 04 2008 09:51:29 713902 Group = 89.x.y.z, IP = 89.x.y.z, Removing peer from correlator table failed, no match!
3  Aug 04 2008 09:51:29 713902 Group = 89.x.y.z, IP = 89.x.y.z, QM FSM error (P2 struct &0x4f0bff8, mess id 0xbf087005)!

The strangest thing is that the tunnel is up enough for the likes of exchange traffic to go though it, but you do consistently get messages in outlook saying it’s lost connectivity to the exchange server.

Has anybody seen this before and how do I debug/fix it? This is fairly urgent as we have developers working remotely who can’t really afford having their connection drop all the time.

Thanks in advance for any input.


 

Solution : Site to Site VPN keeps dropping, QM FSM Error, etc
One of the things that may cause this type behavior is duplex mismatch.
I don’t see any types of error packets that I would expect to see if that was the problem, so I think we can rule that out.

I would still take the router out of the pie. It is simply providing no value.
You can simply assign the outside interface of the PIX the same IP/subnet as the WAN interface of the router, change the default route, and still keep all of your existing statics and rules in place on the PIX.

What version OS on the PIX?
What version OS on the ASA5520?
Absolutely no changes were made to either one, only changes are in the router?