Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

VPN Packets are decrypting, but not encrypting

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

  • Other Security Subjects
27 REPLIES
Hall of Fame Super Silver

Re: VPN Packets are decrypting, but not encrypting

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

Cisco Employee

Re: VPN Packets are decrypting, but not encrypting

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

New Member

Re: VPN Packets are decrypting, but not encrypting

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.

Cisco Employee

Re: VPN Packets are decrypting, but not encrypting

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???

New Member

Re: VPN Packets are decrypting, but not encrypting

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

Silver

Re: VPN Packets are decrypting, but not encrypting

Wonder if you can do this on the local site

crypto map newmap 80 match address nonat

Cisco Employee

Re: VPN Packets are decrypting, but not encrypting

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

Cisco Employee

Re: VPN Packets are decrypting, but not encrypting

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

New Member

Re: VPN Packets are decrypting, but not encrypting

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

2040
Views
0
Helpful
27
Replies
This widget could not be displayed.