ASA ACL issue

Joel Fox · ‎04-24-2014

Good morning - I have a strange issue, and I know it's something simple. I have an ASA running 8.6(1)2 that has a vpn tunnel established to our MPLS provider. I have 3 inside interfaces configured:

Inside - 10.1.1.0/24, Inside-2 - 10.1.2.0/24, and Inside-3 - 10.1.3.0/24. Each interface is plugged into a Cisco 2960 switch port. The Inside subnet talks to our remote networks as intended, ACL's, NAT - everything is configured properly and talks across the MPLS network happily.

Inside-2 and Inside-3 subnets do not talk, so I performed a packet-trace from the CLI from both the Inside and Inside-2 subnets to stare and compare; below are the results:

Working subnet

MyFirewall(config)# packet-tracer input inside icmp 10.1.1.1 1 1 172.16.1.1

Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 0.0.0.0 0.0.0.0 outside

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group inside_access_in in interface inside
access-list inside_access_in extended permit ip any any
Additional Information:

Phase: 3
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 4
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside,outside) source static Inside-Network Inside-Network destination static DM_INLINE_NETWORK_1 DM_INLINE_NETWORK_1 no-proxy-arp route-lookup
Additional Information:
Static translate 10.1.1.1/0 to 110.1.1.1/0

Phase: 6
Type: VPN
Subtype: encrypt
Result: ALLOW
Config:
Additional Information:

Phase: 7
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 13213742, packet dispatched to next module

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow

Non-working subnet

MyFirewall(config)# packet-tracer input inside-2 icmp 10.1.2.1 1 1 172.16.1.1

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 0.0.0.0 0.0.0.0 outside

Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group inside-2_access_in in interface inside-2
access-list inside-2_access_in extended permit ip any any
Additional Information:

Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside-2,outside) source static Inside-Network2 Inside-Network2 destination static DM_INLINE_NETWORK_4 DM_INLINE_NETWORK_4
Additional Information:
Static translate 10.1.2.1/0 to 10.1.2.1/0

Phase: 7
Type: VPN
Subtype: encrypt
Result: DROP
Config:
Additional Information:

Result:
input-interface: inside-2
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

------------------------------------------------------------------------------------------------------------------------------

Here are the acl's:

access-list inside_access_in extended permit ip any any
access-list inside_access_in extended deny ip any any
access-list global_access extended permit object-group DM_INLINE_SERVICE_4 any any
access-list outside_cryptomap_1 extended permit ip object-group DM_INLINE_NETWORK_3 object-group DM_INLINE_NETWORK_2
access-list outside_access_in extended deny tcp any any range 1024 65535
access-list inside-2_access_in extended permit ip any any
access-list inside-2_access_in extended permit icmp any any
access-list inside-2_access_in extended deny ip any any inactive
access-list outside_cryptomap_2 extended permit ip 10.1.2.0 255.255.255.0 object-group DM_INLINE_NETWORK_6
access-list inside-3_access_in extended permit ip any any

-------------------------------------------------------------------------------------------

Am I missing something here? I'm certain there is a better way to configure this, but I can't take the network down to reconfigure anything....

Thanks in advance!

Marvin Rhoads · ‎04-24-2014

Only one cryptomap can be active on a given site-site VPN. You appear to have outside_cryptomap_1 active and working.

Inside 2 would appear to use outside_cryptomap_2. Is it going to a different peer?

Joel Fox · ‎04-24-2014

It is not, I forgot to remove that. However, after removing outside-cryptomap_2, I still get the same result with an acl causing the traffic to drop.

Marvin Rhoads · ‎04-24-2014

OK, so we need to know the definitions of the DM_INLINE_NETWORK_3 and DM_INLINE_NETWORK_2 objects you created with ASDM to verify that they have the necessary source and destination networks in them. If they are OK, we should next check the IPSec SAs in the active VPN (show cry ipsec sa) and look for the local and remote network pairs along with encaps and decaps of interesting traffic.

I also notice that for the working network you are translating from 10.1.1.x to 110.1.1.x. Is this not necessary for your non-working connection from 10.1.2.x?

Joel Fox · ‎04-24-2014

Ah, the translation was just a typo on my part, I was just using a generic subnet in this example to protect the innocent :).

DM_INLINE_NETWORK_3 is an object group that represents the three local subnets protected via our vpn tunnel. DM_INLINE_NETWORK_2 an object group consisting of the trusted subnets on the MPLS cloud.

Marvin Rhoads · ‎04-24-2014

OK - so check the IPSec SAs in the active VPN (show cry ipsec sa) and look for the local and remote network pairs along with encaps and decaps of interesting traffic.

Joel Fox · ‎04-25-2014

When I show the ipsec sa, it verifies that I am using access-list outside_cryptomap_1. This contains an object-group with 3 subnets; 10.1.1.0,10.1.2.0, and 10.1.3.0. The interesting traffic also contains 3 subnets. However, below is what is listed:

access-list outside_cryptomap_1 extended permit ip 10.1.1.0 255.255.255.0 192.168.0.0 255.240.0.0
local ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.0.0/255.240.0.0/0/0)

What I find interesting is it lists this 3 times, once for each subnet listed as interesting traffic. According to this access-list, should I not see the the same thing for the other 2 local subnets? (10.1.2.0, 10.1.3.0)

Marvin Rhoads · ‎04-25-2014

I'd ask your provider to have a close look at their end's cryptomap. If they don't have the second and third subnet included that could result in the observed behavior.

Joel Fox · ‎04-25-2014

They match; when I do a capture I can see incoming pings from my laptop ip, but no return ip. When I try to send a ping from the router sourcing that interface (10.1.2.254) it times out. I know traffic is getting there, but it isn't leaving for some reason. On the router, they have a default route of 10.1.1.254, which is the inside interface of the firewall. This has always been the same default route on the router, and at one time, with the configuration as it is now, I could ping that router interface 10.1.2.254 from my laptop. Nothing has changed, at least on my end, so I'm really confused. I would think that if it was something from the provider that I wouldn't see my ping request from a capture.

I can't really blow the config away and reconfigure it since the network is in production unfortunately.