VPN -PIX 6.3 shows a QM_IDLE status when I do a show crypto isakmp sa

[blade10]

Hello-

For the longest time, my site to site VPN between a pix 6.3 515E and an ASA5510 has been working like a charm.

Yesterday evening, I recieve calls from users at the remote site where the ASA resides and they are telling me they cannpt access certain servers at my site where the pix 6.3

I've checked both configs on both devices, all seem fine as far as crypto, isakmp and the shared key for the peer information but when I do a SHOW CRYPTO ISAKMP SA on my PIX 515, I get receive this:


dst src state pending


12.34.96.18 209.227.21.2 QM_IDLE 0

created
1

Obviously, the idle state is suggesting my site to site vpn has halted? Anyone know how I can fix this? what would generally cause this. I have change nothing on my PIX and the same goes for the primary engineer at the other site where the ASA is...

any ideas would be greatly appreciated.

Thanks

blade

 

[NetworkGhost]

The idle state means that the SA is established and isnt doing anything until the SA needs to be rebuilt.

This is a good thing.

http://www.wr-mem.com

 

[blade10]

Networkghost-

Could I rebuild the SA using the debug commands?

how can I essentially fix this since even though the tunnel SA is established for some reason I can't ping or or rdp to any servers at the other side like I used to for many years.
This just stopped working for some reason. supposedly no acl's were created from either router impeding this vpn site to site tunnel.

thanks again
blade

 

[NetworkGhost]

Get the following info from both sides

show crypto ipsec sa

ping a server that should be accessible through the VPN and get the SAs again

show cry ipsec sa

When you do your ping, send 500 requests so we can expect to see the decrypt and encrypt counters increment. This will tell us if traffic is hitting the tunnel and actually getting through the VPN. Post the results and then we can figure out what to do next.

http://www.wr-mem.com

 

[blade10]

Hi NG!

It looks like the traffic does encap in the tunnel, a peek at my doctored sho cry ipsec sa:

It shows the encap and encrypted, but it doesn't decap and decrypt which what I believe you were aiming for here.. It gives 1 send error also.

local ident (addr/mask/prot/port): (10.1.x.0/255.255.252.0/0/0)
remote ident (addr/mask/prot/port): (192.168.200.175/255.255.255.255/0/0)
current_peer: 12.x.x.x:500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 1041, #pkts encrypt: 1041, #pkts digest 1041
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0
#send errors 1, #recv errors 0

local crypto endpt.: 209.227.x.x, remote crypto endpt.: 12.x.x.x
path mtu 1500, ipsec overhead 56, media mtu 1500
current outbound spi: 8a60ee0e

inbound esp sas:
spi: 0x474acdf0(1196084720)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 26, crypto map: outside_map_2
sa timing: remaining key lifetime (k/sec): (4608000/24415)
IV size: 8 bytes
replay detection support: Y


inbound ah sas:


inbound pcp sas:


outbound esp sas:
spi: 0x8a60ee0e(2321608206)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 25, crypto map: outside_map_2
sa timing: remaining key lifetime (k/sec): (4607996/24388)
IV size: 8 bytes
replay detection support: Y


outbound ah sas:


outbound pcp sas:



local ident (addr/mask/prot/port): (10.1.20.0/255.255.252.0/0/0)
remote ident (addr/mask/prot/port): (192.168.200.176/255.255.255.255/0/0)
current_peer: 12.x.x.x:0
PERMIT, flags={origin_is_acl,}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0

local crypto endpt.: 209.227.x.x, remote crypto endpt.: 12.x.x.x
path mtu 1500, ipsec overhead 0, media mtu 1500
current outbound spi: 0

inbound esp sas:


inbound ah sas:


inbound pcp sas:


outbound esp sas:


outbound ah sas:


outbound pcp sas:



I wonder if there is just some funky access-list created on "their" side on the internet router...

hey, maybe you can verify but I have received the customers Internet router code (perimeter router and the ASA sits behind this of course) and noticed this specific access-list that seemed odd:

what is the logic behind this acl, can you decipher and let me know if this is what is stopping the traffic from getting thru the tunnel:


access-list 101 deny ip 192.168.0.0 0.0.255.255 any

but, there is a an access-list permit ip any any at the end of the 101 acl trail.

could this be the reason? doesn't the acl mean "allow no one access to this ip range?"

thanks again

blade

 

[NetworkGhost]

This ACL:

access-list 101 deny ip 192.168.0.0 0.0.255.255 any

means allow no one from the 192.168.0.0 network to flow. If the router is the internet router than this ACL should not be the problem.

Just out of curiosity is there anyway that the router in front of the remote end is blocking ip protocol 50 or is natting for the ASA?

http://www.wr-mem.com

 

[blade10]

Hi networkghost..

I found this on the ASA (this is the otherside of the VPN tunnel).. access-group outside_acl in interface outside

route outside 0.0.0.0 0.0.0.0 12.34.x.x 1

The last octet is not the external IP of the primary ASA but is the IP of the secondary which is in standby.. Doesn't this static router mean "send all traffic thru and out using the default IP of 12.34.x.x

This might be it since the VPN tunnel is in idle state.. the tunnels SA looks good

any ideas?

blade