VPN Packets are decrypting, but not encrypting

Unanswered Question
Jul 5th, 2006

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

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 0 (0 ratings)
Richard Burts Wed, 07/05/2006 - 11:15

Eric

As I read your description of the symptoms my first suggestion is to verify (probably again) that the access list used in the crypto map is mirror image of each other on both sides.

My other suggestion is that I remember getting symptoms that look like one way traffic and found that there was some parameter mismatch - I think it was the timer parameter. I know that you have said that you checked with the other end. But it might be worth checking again - especially to be sure that the timer match.

HTH

Rick

hemendoz Wed, 07/05/2006 - 13:49

This really sounds like a routing problem. The only way you could have an ACL mismatch is if one ACL is a subset of another. If there are not identical or subsets of one another, the tunnel would not even establish. You would be getting a proxy identities mismatch. I also wouldn't expect a timer mismatch to be a possible cause.

Can you access any local hosts thru the VPN tunnel, that is directly connected hosts? If you can, but still can't access hosts further downstream, make sure routing is in place.

Hope this helps! If so, please rate.

Thanks,

hemendoz

cbestbone Thu, 07/06/2006 - 19:55

Not exactly sure what you are asking. As I stated earlier, I cannot access any hosts on the other side, that is my question. Please clarify. There are exactly two networks a remote and a local. no routing anywhere else. Please advise.

hemendoz Thu, 07/06/2006 - 20:50

Can you paste your crypto ACL? Also what happens if you originate traffic on the other side? Perhaps esp traffic is being blocked somewhere in between???

cbestbone Fri, 07/07/2006 - 04:46

Configure Local Site

isakmp key ***** address 10.0.1.1 netmask 255.255.255.255

access-list nonat permit ip 172.20.0.0 255.255.0.0 172.30.0.0 255.255.0.0

access-list 101 permit ip 172.20.0.0 255.255.0.0 172.30.0.0 255.255.0.0

crypto ipsec transform-set 3des esp-3des esp-md5-hmac

crypto map newmap 80 ipsec-isakmp

crypto map newmap 80 match address 101

crypto map newmap 80 set peer 10.0.1.1

crypto map newmap 80 set transform-set 3des

crypto map newmap interface outside

nat (inside) 0 access-list nonat

sysopt connection permit-ipsec

Configure Remote site

isakmp enable outside

isakmp policy 1 authentication pre-shared

isakmp policy 1 encryption 3des

isakmp policy 1 hash md5

isakmp policy 1 group 2

isakmp policy 1 lifetime 300

isakmp key ***** address 192.168.1.1 netmask 255.255.255.255

access-list nonat permit ip 172.30.1.0 255.255.255.0 172.20.0.0 255.255.0.0

crypto ipsec transform-set tolocal esp-3des esp-md5-hmac

crypto map newmap 80 ipsec-isakmp

crypto map newmap 80 match address nonat

crypto map newmap 80 set peer 192.168.1.1

crypto map newmap 80 set transform-set tolocal

crypto map newmap interface outside

nat (inside) 0 access-list nonat

sysopt connection permit-ipsec

It's obvious that all vital information has been altered.

Answering the second half of your question:

When they ping I get the decrypted traffic. But I cannot send it

attrgautam Fri, 07/07/2006 - 05:39

Wonder if you can do this on the local site

crypto map newmap 80 match address nonat

hemendoz Fri, 07/07/2006 - 07:03

Hello attrgautam ,

They are both the same. Why would it matter if used either nonat or 101 here?

access-list nonat permit ip 172.20.0.0 255.255.0.0 172.30.0.0 255.255.0.0

access-list 101 permit ip 172.20.0.0 255.255.0.0 172.30.0.0 255.255.0.0

Thanks

hemendoz Fri, 07/07/2006 - 05:45

Check your ACLs, one is a subset of the other

access-list nonat permit ip 172.20.0.0 255.255.0.0 172.30.0.0 255.255.0.0

access-list nonat permit ip 172.30.1.0 255.255.255.0 172.20.0.0 255.255.0.0

So if local site, had packet

src = 172.20.1.1 dst = 172.30.2.1

Packet would get encrypted and remote site would decrypt, but it would not encrypt the response back.

Hope that helps! If so, please rate.

Thanks

cbestbone Fri, 07/07/2006 - 08:42

I believe that the acl is set up correctly, but I will double check. I think that third octet .1 was just a type-o. I'll get back to you

hemendoz Fri, 07/07/2006 - 12:04

Can you paste "show crypto ipsec sa" output from remote peer?

cbestbone Fri, 07/07/2006 - 12:43

interface: outside

Crypto map tag: outside_map, local addr. 10.0.1.1

local ident (addr/mask/prot/port): (172.30.1.0/255.255.255.0/0/0)

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

current_peer: 192.168.1.1:500

PERMIT, flags={origin_is_acl,}

#pkts encaps: 3125, #pkts encrypt: 3125, #pkts digest 3125

#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.: 10.0.1.1, remote crypto endpt.: 192.168.1.1

path mtu 1500, ipsec overhead 56, media mtu 1500

current outbound spi: c438e494

inbound esp sas:

spi: 0xcfcd15ae(3486324142)

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

in use settings ={Tunnel, }

slot: 0, conn id: 4, crypto map: outside_map

sa timing: remaining key lifetime (k/sec): (4608000/28298)

IV size: 8 bytes

replay detection support: Y

inbound ah sas:

inbound pcp sas:

outbound esp sas:

spi: 0xc438e494(3292062868)

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

in use settings ={Tunnel, }

slot: 0, conn id: 3, crypto map: outside_map

sa timing: remaining key lifetime (k/sec): (4607968/28289)

IV size: 8 bytes

replay detection support: Y

outbound ah sas:

outbound pcp sas:

same assumption as the local show crypto. IP have been replaced

cbestbone Fri, 07/07/2006 - 12:50

I know what you are going to say....The subnet is still there. Well the actual screen capture was taken before I moved the subnet to .0. I actually have a copy of the remote config. If you need it just email

cbestbone Fri, 07/07/2006 - 12:54

I'll just send it. It will confirm what I said.

access-list inside_outbound_nat0_acl permit ip 172.30.0.0 255.255.0.0 172.20.0.0 255.255.0.0

access-list outside_cryptomap_20 permit ip 172.30.0.0 255.255.0.0 172.20.0.0 255.255.0.0

nat (inside) 0 access-list inside_outbound_nat0_acl

sysopt connection permit-ipsec

sysopt connection permit-pptp

crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac

crypto map outside_map 20 ipsec-isakmp

crypto map outside_map 20 match address outside_cryptomap_20

crypto map outside_map 20 set peer 192.168.1.1

crypto map outside_map 20 set transform-set ESP-3DES-MD5

crypto map outside_map interface outside

isakmp enable outside

isakmp key ******** address 192.168.1.1 netmask 255.255.255.255

isakmp policy 50 authentication pre-share

isakmp policy 50 encryption 3des

isakmp policy 50 hash md5

isakmp policy 50 group 2

isakmp policy 50 lifetime 300

hemendoz Fri, 07/07/2006 - 14:04

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 Fri, 07/07/2006 - 14:08

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

hemendoz Fri, 07/07/2006 - 15:45

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 Sat, 07/08/2006 - 06:06

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 Sat, 07/08/2006 - 06:11

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 Sun, 07/09/2006 - 01:53

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 Sun, 07/09/2006 - 08:32

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 Mon, 07/10/2006 - 10:05

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 Tue, 07/11/2006 - 09:05

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 Thu, 07/27/2006 - 16:29

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 Mon, 07/31/2006 - 02:07

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 Mon, 07/31/2006 - 04:34

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.

Actions

Login or Register to take actions

This Discussion

Posted July 5, 2006 at 9:09 AM
Stats:
Replies:27 Avg. Rating:
Views:347 Votes:0
Shares:0
Tags: No tags.

Discussions Leaderboard