ASA to ASA tunnel - encrypting but not decrypting...

olivermerritt · ‎07-29-2007

Hi everybody,

I really hope somebody has seen this issue before and can help me!

I am trying to setup a simple L2L tunnel between two ASA5520s. I already have a tunnel from each ASA to a 837 which works perfectly. However the ASA-ASA tunnel only appears to be encrypting one end only, and decrypting on the other end only. To try and illustrate the error, the sh crypto ipsec sa looks like this for ASA1 & ASA2:

ASA1:

Crypto map tag: outside_map, seq num: 30, local addr: x.x.x.x

access-list VPN_to_ROM_test permit ip 10.216.8.0 255.255.255.0 10.216.67.0 255.255.255.0

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

remote ident (addr/mask/prot/port): (10.216.67.0/255.255.255.0/0/0)

current_peer: x.x.x.x

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

#pkts decaps: 286, #pkts decrypt: 286, #pkts verify: 286

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0

#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0

#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0

#send errors: 0, #recv errors: 0

local crypto endpt.: x.x.x.x, remote crypto endpt.: x.x.x.x

path mtu 1500, ipsec overhead 58, media mtu 1500

current outbound spi: C9D2614E

ASA2:

Crypto map tag: outside_map, seq num: 30, local addr: x.x.x.x

access-list VPN_to_SH_test permit ip 10.216.67.0 255.255.255.0 10.216.8.0 255.255.255.0

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

remote ident (addr/mask/prot/port): (10.216.8.0/255.255.255.0/0/0)

current_peer: x.x.x.x

#pkts encaps: 309, #pkts encrypt: 309, #pkts digest: 309

#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 309, #pkts comp failed: 0, #pkts decomp failed: 0

#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0

#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0

#send errors: 0, #recv errors: 0

local crypto endpt.: x.x.x.x, remote crypto endpt.: x.x.x.x

path mtu 1500, ipsec overhead 58, media mtu 1500

current outbound spi: 78EF16F5

On my 837 tunnel, it is encrypting / decrypting in pretty much equal amounts.

What am I doing wrong? Can somebody suggest where I should be looking as I'm certain that my match / nonat lists are correct.

Thanks!

Oli

saiiven07 · ‎07-29-2007

I think you should post the configs. Without them it's hard to suggest any solution.

purohit_810 · ‎07-30-2007

Hi,

You gave little bit less output.

I need such as below output:

inbound esp sas:

spi: 0x6D29993F (1831442751)

transform: esp-3des esp-sha-hmac

in use settings ={RA, Tunnel, }

slot: 0, conn_id: 7, crypto-map: cisco

sa timing: remaining key lifetime (sec): 28413

IV size: 8 bytes

replay detection support: Y

outbound esp sas:

spi: 0x2C4400C7 (742654151)

transform: esp-3des esp-sha-hmac

in use settings ={RA, Tunnel, }

slot: 0, conn_id: 7, crypto-map: cisco

sa timing: remaining key lifetime (sec): 28411

IV size: 8 bytes

replay detection support: Y

""""" replay detection support """" is it Y or N

" Check On your ASA -1 encapsulation:

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

Above output not showing encapulation than how can it will be encrypt?

Third: Romove once Access-list " access-list VPN_to_SH_test permit ip 10.216.67.0 255.255.255.0 10.216.8.0 255.255.255.0 "

and check out.

Regards,

Dharmesh Purohit

jwalker · ‎07-30-2007

Can you post a sanitized config?

Thanks.

Jay

olivermerritt · ‎07-30-2007

Thanks for your initial replies everybody - I'll try to get a copy of the config posted up. That said, I have been doing some further troubleshooting and i think I can see where the error is occuring.

At site A the remote network that we are trying to get to is 10.216.67.0/24. On the ASA there is also a route as follows:

route dmz 10.0.0.0 255.0.0.0 10.216.2.1 1

Whilst doing an ICMP trace it became clear that return traffic destined for the remote network via the tunnel, is actually going via the above route, which is why I'm seeing uni-directional encryption / decryption.

The question is, why isn't the traffic obeying the VPN match ACL ahead of the static route and what I can do about it?

Thanks!

jwalker · ‎07-30-2007

Did you use a NAT 0?

olivermerritt · ‎07-30-2007

Yes, I have a NAT0 ACL in place and the correct subnets are specified. My last post may have made it sound like the issue is resolved - but just to clarify, it isn't.

Does anybody know whether the tunnel match ACL should be read in front of any static routes?

jwalker · ‎07-30-2007

A NAT 0 should take precedence over all other types of translations.

jwalker · ‎07-30-2007

So on each ASA/PIX you have the following commands?

access-list vpn1 extended permit ip 10.1.1.0 255.255.255.0 10.2.2.0 255.255.255.0

nat (inside) 0 access-list vpn1

crypto map outside_map 10 match address vpn1

Jay