VPN Packets are decrypting, but not encrypting

[cbestbone]

I have a VPN issue, that I know seems straight forward. However I seem to get the packets decrypted, but they will not encrypt. I think I had this issue once before about 4 years ago, but I cannot remember what I did to resolve it. Any ideas. The sh crypto ipsec sa command output is below. I have check this out with my remote site, and verified all configs. Any suggestions will be appreciated.

local ident (addr/mask/prot/port): (172.20.0.0/255.255.0.0/0/0)

remote ident (addr/mask/prot/port): (172.30.0.0/255.255.0.0/0/0)

current_peer: xxx.xxx.xxx.xxx:500

PERMIT, flags={origin_is_acl,}

#pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0

#pkts decaps: 476, #pkts decrypt: 476, #pkts verify 476

#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.: xxx.xxx.xxx.xxx remote crypto endpt.: xxx.xxx.xxx.xxx

path mtu 1500, ipsec overhead 56, media mtu 1500

current outbound spi: 43b2ec63

inbound esp sas:

spi: 0x140a3b94(336214932)

transform: esp-3des esp-md5-hmac ,

in use settings ={Tunnel, }

slot: 0, conn id: 16, crypto map: newmap

sa timing: remaining key lifetime (k/sec): (4607939/11726)

IV size: 8 bytes

replay detection support: Y

inbound ah sas:

inbound pcp sas:

outbound esp sas:

spi: 0x43b2ec63(1135799395)

transform: esp-3des esp-md5-hmac ,

in use settings ={Tunnel, }

slot: 0, conn id: 15, crypto map: newmap

[hemendoz]

This is either a routing problem or there is another firewall in between these two devices filtering esp traffic. Can you check the routing tables on both sides to ensure VPN traffic is flowing as you expect. If that is working as is, can you verify there is no filtering device in between filtering esp traffic. Neither side has any decrypts which implies they never receive any esp traffic from their respective peer.

[cbestbone]

Yes the local side had decrypts if you look at the first show crypto ipsec sa. That was on the Local side.

[hemendoz]

Woops - my apologies. Can you place a sniffer on the local segment and check if traffic is flowing as you expect. What does the destination do when it gets the unencrypted traffic? Does it respond and forward to the local router? If so, what does the router do? Does it send it back through the interface with crypto map applied?

[cbestbone]

A little more background on the local config. This is a VPN termination point for seven addtional VPN tunnels. All seem to be functioning without incident. This is a new VPN config for a brand new site. So the suggestions to check acls for esp might not be beneficial at this time. Also, and more to the point I do not have access to the router configurations, as another entity is managing that. However that being said, I do have requesting permissions,

[cbestbone]

I have another question about encryptions and decryptions. If the packet gets encrypted on one side, and makes it to the other side, and decryps, Wouldn't the fault lie with the pix that cannot encrypt, and send back. In other words in my case does not the fault lie with the local pix?

[Fernando_Meza]

Hi .. I have been following you guys on this post and I suggest to really put a packet capture such ethereal on a system on the remote site to make sure the decrypted packets are actually hitting the destination. If they are then I suggest checking the routing on the other side to make sure packets are being sent back to the local VPN gateway. If they are then I would start checking for any ACL applied to the interface facing the hosts.

The tunnel is up and so this issue smell like routing problem to me.

[cbestbone]

Forgive me fernando, but your isntructions are not clear, vague at best.

1. put the ethereal packet sniffer on the remote peer network, or the internal 172.30 network.

2. "If they are" I am assuming you mean decrypted packets on the remote side.

3. "on the other side" I am also assuming you mean the remote side.

Fernando, I really appreciate the response, and when you answer my assumptions I will be happy to employ your suggestions. In the future when answering message posts, please be as specific as possible. This is the reason why I like my support on a vocal forum. Time does not elapse in between communicatation, making troubleshooting a lot more efficient. Thank you.

[cbestbone]

Could this access list be doing this.

access-list nonat line 1 permit ip 172.20.0.0 255.255.0.0 172.30.0.0 255.255.0.0

...

access-list nonat line 14 permit ip 172.16.0.0 255.240.0.0 172.25.0.0 255.255.0.0

The reason I say this is because the source network on the first acl is a subset of the second...even thought the networks are on opposite ends.

[nitishh]

Are you using ASA what version code are you running . I have run into the same issue with ASA and had to downgrade code to 7.0(5) and got resolved . This is a well know bug in code 7.0(4)

thanks

[cbestbone]

Nope....PIX 6.3(5)

[cbestbone]

You can close this out, but can you tell me how I stumbled upon this support section. I need to open another, but I cannot remember what I did.

[nefkensp]

Did you manage to get it working?

Sometimes I have to reapply the crypto map to the interface on the PIX to get new tunnels active (e.g. to get data for the new tunnel encrypted).

You don't need to remove the entry, you can just type (in config mode)

crypto map interface outside

Hope this helps

[cbestbone]

Yes, I got this working. It seems that there was a rogue route in the layer 3 switch that was diverting the route to a non existing interface. It was either an old route, or someone misconfigured the device. In any event, this can be closed.