MM_WAIT_MSG2

[gmail2]

I have a site to site VPN between a PIX at HQ (515E) and 3 branch offices (506E). All 3 have been working fine for over 2 years now, until today when one of the VPN's went down.For the life of me, I can't get it back up. Nothing has changed on the any of the PIX's.

If I put both the remote and HQ pix in debug mode and send some traffic from HQ to the remote site, no debug messages come up on the remote PIX - so does this mean that phase 1 is failing?

If I run sh crypto isakmp sa on the HQ pix, it says state MM_WAIT_MSG2 ... but I can't find out what that means. I presume MM means Main Mode and MSG possibly refers to the pre-shared key ????? But I've already put in new shared keys on both ends (I even used a simple one with only lower case letters and a number, no symbols, just to make sure) but it hasn't helped.

Also, the sh crypto isakmp sa says type user instead of L2L for that peer which I find quiet strange as the config doesn't say this.

If somebody really wants to see the configs I'll post them (bit tired now as it's been a long day and I don't fancy trawling through 2 sets of configs picking out all the public IP's etc), but if somebody can point me towards what MM_WAIT_MSG2 might mean I think this would help. Also, the remote PIX is in a US Sanctioned Country (where encryption is "not allowed") ... but like I said, has been working fine until this morning

Any help would be really greatly appreciated

Irish Poetry - Karen O'Connor
Irish Poetry and Short Stories - Doghouse Books
Garten und Landschaftsbau

 

[NetworkGhost]

The status messages are kind of a pain to interpret but Ill take a stab. There are 6 Main Mode messages. Each message has a specific purpose. The status state of MM_WAIT_MSG2 could mean:

1. you are using Main Mode

2. You are waiting

3. You are waiting on Message 2 of Main mode

Message 1 is used to send your phase 1 proposals. Message 2 is sent by the remote end accepting the SA.

So the question is "Why is my PIX waiting on MSG 2?"

This could be for several reasons.
1. Maybe your packet is being dropped somewhere

2. Maybe there is a problem in the path causing the drop (High BW Utilization, bad circuit etc...)

3. The remote device believes it does not have to renogotiate or the SA is stuck for some reason

What you could try is configuring dead peer detection. This would allow the PIX to detect if the peer is gone, tear down the tunnel and allow for the new SA to be established when the peer is available.

The command below should help:

isakmp keepalive xxx

Place this on both devices then clear the isakmp SAs on both ends. Reoport back on the status.

http://www.wr-mem.com

 

[gmail2]

Thanks for your reply NetworkGhost. Actually, after several hours of staring at configs, debugs, websites and what nots, I decided that MM_WAIT_MSG2 meant the exact same as what you though

However, it seems that there's a firewall at the remote end which is blocking some udp ports required for isakmp, so that's the problem. Thanks for your reply none the less though. You provided some useful info there

Irish Poetry - Karen O'Connor
Irish Poetry and Short Stories - Doghouse Books
Garten und Landschaftsbau