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

[Richard Burts]

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]

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]

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]

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]

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]

Wonder if you can do this on the local site

crypto map newmap 80 match address nonat

[hemendoz]

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]

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]

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

[cbestbone]

The answer is yes it was a type 172.30.0.0 255.255.0.0

[hemendoz]

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

[cbestbone]

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]

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]

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