cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

Community Helping Community

109
Views
0
Helpful
4
Replies

ASA5505 VPN - ISAKMP Active, SH IPSEC SA Blank Output

I have two ASA's that are attempting to communicate via IPSEC VPN... They both list MM_ACTIVE under SH ISAKMP SA, but when i try SH IPSEC SA, there is no output. Anyone able to help me figure out why this would be? I've done the usual double checking access lists for interesting traffic, and verified the Peer IP Addresses are correct (isakmp has established obviously).

Thanks.... :)

1 ACCEPTED SOLUTION

Accepted Solutions
Hall of Fame Master

If ISAKMP is establishing

If ISAKMP is establishing then obviously it is not a connectivity issue but would seem to be some type of mismatch between the two ASA with their IPsec parameters.

The IKEv1 DEBUG output is not helpful at this point and could be turned off. If there were more of the IPSEC debug it might point us to the mismatch. And it may be that debug from one peer might have information that debug from the other peer does not have. So seeing debug output from both peers might be helpful.

Posting the appropriate parts of both configs would allow us to help you find the mismatch. As a start I would suggest checking to be sure that both peers have the same setting for PFS. I find this to be a pretty common issue when IPsec negotiation is failing.

HTH

Rick

View solution in original post

4 REPLIES 4

To clarify this appears to be

To clarify this appears to be a Phase 2 failure ... for 2 ASA's in a L2L tunnel.

Did some googling, appears to

Did some googling, appears to be stuck on QM2, i get spammed on both devices with: 

[IKEv1]: Group = 10.0.0.2, IP = 10.0.0.2,  
IKE: requesting SPI!
IPSEC: New embryonic SA created @ 0x53FC3698,
SCB: 0x53FC2998,
Direction: inbound
SPI : 0x1698CAC7
Session ID: 0x00004000
VPIF num : 0x00000003
Tunnel type: l2l
Protocol : esp
Lifetime : 240 seconds
[IKEv1 DEBUG]: Group = 10.0.0.2, IP = 10.0.0.2,
IKE got SPI from key engine: SPI = 0x1698cac7
[IKEv1 DEBUG]: Group = 10.0.0.2, IP = 10.0.0.2,
oakley constructing quick mode
[IKEv1 DEBUG]: Group = 10.0.0.2, IP = 10.0.0.2,
constructing blank hash payload
[IKEv1 DEBUG]: Group = 10.0.0.2, IP = 10.0.0.2,
constructing IPSec SA payload
[IKEv1 DEBUG]: Group = 10.0.0.2, IP = 10.0.0.2,
constructing IPSec nonce payload
[IKEv1 DEBUG]: Group = 10.0.0.2, IP = 10.0.0.2,
constructing proxy ID
[IKEv1 DEBUG]: Group = 10.0.0.2, IP = 10.0.0.2,
Transmitting Proxy Id:
Remote subnet: 192.168.2.0 Mask 255.255.255.0
Protocol 1 Port 0
Local subnet: 192.168.1.0 mask 255.255.255.0
Protocol 1 Port 0
[IKEv1 DEBUG]: Group = 10.0.0.2, IP = 10.0.0.2,
constructing qm hash payload
[IKEv1 DECODE]: Group = 10.0.0.2, IP = 10.0.0.2,
IKE Responder sending 2nd QM pkt: msg id = 52481cf5


and



IPSEC(crypto_map_check)-3: Checking crypto map outside_map 1: matched.
IPSEC(crypto_map_check)-3: Looking for crypto map matching 5-tuple: Prot=17, Src=192.168.12.243:50195, Dest=192.168.9.50:50195
IPSEC(crypto_map_check)-3: Checking crypto map outside_map 1: matched.
IPSEC(crypto_map_check)-3: Looking for crypto map matching 5-tuple: Prot=17, Src=192.168.12.243:50195, Dest=192.168.9.50:50195


Participant

Hello.

Hello.

Please put here an output of "sh vpn-sessiondb detail" and "sh run | i crypto" (of course you could should hide all sensetive information).

Best Regards.

Hall of Fame Master

If ISAKMP is establishing

If ISAKMP is establishing then obviously it is not a connectivity issue but would seem to be some type of mismatch between the two ASA with their IPsec parameters.

The IKEv1 DEBUG output is not helpful at this point and could be turned off. If there were more of the IPSEC debug it might point us to the mismatch. And it may be that debug from one peer might have information that debug from the other peer does not have. So seeing debug output from both peers might be helpful.

Posting the appropriate parts of both configs would allow us to help you find the mismatch. As a start I would suggest checking to be sure that both peers have the same setting for PFS. I find this to be a pretty common issue when IPsec negotiation is failing.

HTH

Rick

View solution in original post

CreatePlease to create content
Content for Community-Ad