L2L VPN failed inside on ASA 5520 (8.02)

[Michael Garcia]

L2L VPN is dropping packets at Phase 5 because of a Configured rule. I have an isakmp sa but the client cannot connect to the destination here in my network. I'll post my access list config at bottom of Packet-tracer output.

vpnASA01# packet-tracer input inside icmp [10.0.0.243] 0 8 10.97.29.73 det

Phase: 1

Type: CAPTURE

Subtype:

Result: ALLOW

Config:

Additional Information:

Forward Flow based lookup yields rule:

in  id=0xc92087c8, priority=12, domain=capture, deny=false

        hits=85188209121, user_data=0xc916a478, cs_id=0x0, l3_type=0x0

        src mac=0000.0000.0000, mask=0000.0000.0000

        dst mac=0000.0000.0000, mask=0000.0000.0000

Phase: 2

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

Forward Flow based lookup yields rule:

in  id=0xc87f1f98, priority=1, domain=permit, deny=false

        hits=85193048387, user_data=0x0, cs_id=0x0, l3_type=0x8

        src mac=0000.0000.0000, mask=0000.0000.0000

        dst mac=0000.0000.0000, mask=0000.0000.0000

Phase: 3

Type: FLOW-LOOKUP

Subtype:

Result: ALLOW

Config:

Additional Information:

Found no matching flow, creating a new flow

Phase: 4

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   10.0.0.0        255.0.0.0       inside

Phase: 5

Type: ACCESS-LIST

Subtype:

Result: DROP

Config:

Implicit Rule

Additional Information:

Forward Flow based lookup yields rule:

in  id=0xc87f3670, priority=111, domain=permit, deny=true

        hits=67416, user_data=0x0, cs_id=0x0, flags=0x4000, protocol=0

        src ip=0.0.0.0, mask=0.0.0.0, port=0

        dst ip=0.0.0.0, mask=0.0.0.0, port=0

Result:

input-interface: inside

input-status: up

input-line-status: up

output-interface: inside

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule

============ACCESS-LIST + Config============

object-group network L2LVPN-blah_local
network-object 10.97.29.73 255.255.255.255
object-group network L2LVPN-blah_remote
network-object [10.0.0.240]  255.255.255.240

access-list INBOUND_OUTSIDE extended permit ip object-group L2LVPN-blah_remote object-group L2LVPN-blah_local

access-list L2LVPN-blah_obj extended permit ip object-group L2LVPN-blah_local object-group L2LVPN-blah_remote

access-list NONAT extended permit ip any [10.0.0.243]  255.255.255.240

route outside[10.0.0.240]  255.255.255.240 [10.97.29.1]  1

crypto map outside-VPN 46 match address L2LVPN-blah_obj
crypto map outside-VPN 46 set peer [10.0.0.243]
crypto map outside-VPN 46 set transform-set esp-sha-aes-256
crypto map outside-VPN interface outside

tunnel-group [10.0.0.243]  type ipsec-l2l
tunnel-group [10.0.0.243]  ipsec-attributes
pre-shared-key *

[10.0.0.1] is to protect clients global addresses. Assume these are all the same being used in place of the actual IP range. 10.0.0.240/28

===========================================

Thanks in advance.

Michael Garcia

Lucrative Systems, Inc.

[busterswt · Accepted solution]

Hi Michael,

- Is the peer IP really part of the network that makes up the encryption domain?

- Is the INBOUND_OUTSIDE ACL applied to the inside (inbound) or outside (inbound) interface? In it's current form it would need to be on the outside interface.

- You've specified the peer IP only in the NONAT ACL, so all other traffic is being NAT'd and possibly denied since it does not match the encryption domain

Someone else may have some ideas, but these are questions I have at the moment.

James

[Michael Garcia]

James,

- Is the peer IP really part of the network that makes up the encryption domain?

Yes this Peer IP is part of the encryption domain.

- Is the INBOUND_OUTSIDE ACL applied to the inside (inbound) or outside (inbound) interface? In it's current form it would need to be on the outside interface.

access-group INBOUND_OUTSIDE in interface outside

- You've specified the peer IP only in the NONAT ACL, so all other traffic is being NAT'd and possibly denied since it does not match the encryption domain

This is an error on my part... The NONAT is for the range, not the single IP. Sorry

access-list NONAT extended permit ip any [10.0.0.240]  255.255.255.240

Great Questions, thank you for your help!

Michael

[busterswt · Accepted solution]

Hi Michael,

After looking at your packet-tracer syntax, I think you have the source and dest IP swapped:

Yours: packet-tracer input inside icmp [10.0.0.243] 0 8 10.97.29.73 det

Proper: packet-tracer input [src_int] protocol src_addr src_port dest_addr dest_port [detailed] [xml]

Try swapping your IPs and see if that makes a difference.

James

P.S. I would also look at excluding the peer IP from the encryption domain by adding a deny statement for that particular IP before the permit for the network.

IE.

access-list L2LVPN-blah_obj extended deny ip object-group L2LVPN-blah_local host [10.0.0.243]

access-list L2LVPN-blah_obj extended permit ip object-group L2LVPN-blah_local object-group L2LVPN-blah_remote

[Michael Garcia]

thanks James, I have done that and I'm still not able to ping the clients peer. I had him debug ipsec, here's the debug my client is reporting.

Dec 30 16:47:57 [IKEv1]: Group = 65.114.207.251, IP  = 65.114.207.251, construct_ipsec_delete(): No SPI to identify Phase 2  SA!
Dec 30 16:47:57 [IKEv1]: Group =  65.114.207.251, IP = 65.114.207.251, Removing peer from correlator table failed,  no match!

I looked that up on the forum and there are a couple of reasons for this... either PFS is mismatched or ACLs are.

1) PFS is disabled by Default and I confirmed that it's disabled on both of our policies.

2) Our ACLs do not match. He's using a private IP range but he's not NAT'ing them to the public range.

His ACL -

access-list Outside_cryptomap_18940 extended permit ip 63.175.126.240 255.255.255.240 host 10.97.29.73

crypto map Outside_map 18940 match address Outside_cryptomap_18940
crypto map Outside_map 18940 set peer [my peer IP]
crypto map Outside_map 18940 set transform-set ESP-AES-256-SHA

access-list AS248 extended permit ip host 10.160.91.225 host 10.97.29.73
access-list AS248 extended permit ip 10.160.91.32 255.255.255.224 host 10.97.29.73
access-list AS250 extended permit ip host Unicenter-NSM host 10.97.29.73
access-list AS251 extended permit ip host Unicenter-DSM1 host 10.97.29.73
access-list AS249 extended permit ip host Unicenter-SD host 10.97.29.73

The 10.160.91.0/24 will not be routed on my network. This is where I would modify his access-list.

object-group network L2LVPN-Olympus_local

network-object 10.97.29.73 255.255.255.255

object-group network L2LVPN-Olympus_remote

network-object 63.175.126.240 255.255.255.240

access-list INBOUND_OUTSIDE extended permit ip object-group L2LVPN-Olympus_remote object-group L2LVPN-Olympus_local

access-list L2LVPN-Olympus_obj extended deny ip object-group L2LVPN-Olympus_local host 63.175.126.243

access-list L2LVPN-Olympus_obj extended permit ip object-group L2LVPN-Olympus_local object-group L2LVPN-Olympus_remote

access-list NONAT extended permit ip any 63.175.126.240 255.255.255.240

this is still broken. We get Phase1 but no Phase2... I'm convinced that this is the problem.

any thoughts?

Michael

[Michael Garcia]

James,

The final resolution was to change encryption domain from x.x.x.240/28 to x.x.x.248/29. This took the peer address of x.x.x.243 out of the Encryption domain and the tunnel came up immediately. I'm not sure why but using the access list to remove that peer from domain didn't work. I was able to convince the client to make the change and all is well in the world again. Thanks!

Michael