Solved: ACL Question

MW20082008 · ‎03-22-2008

Boy, I never thought I would be asking a question again about the behavior of an ACL, but here goes...

Here is the scenario:

There is a L3 core switch with a management vlan interface configured on it. The address of the management subnet is 10.120.255.0/24. The interface address is 10.120.255.5.

There are 2 Internet routers that also have interfaces configured on this mgmt vlan. Their addresses are 10.120.255.163 and 10.120.255.164.

With no ACL applied anywhere, I can ping the routers from the same core switch. makes sense, they are all on the same vlan.

Anyway, I wanted to configure an ACL on the mgmt interfaces on the routers to prevent anyone from telneting to it, except for the network administrators on 3 subnets (10.100.4 -.5 -.6.0/24)

So, I configured the following:

ip access-list DENY_UNAUTH_USERS

permit 10.100.4.0 0.0.0.255

permit 10.100.5.0 0.0.0.255

permit 10.100.6.0 0.0.0.255

deny any log

I applied it to the internet routers' mgmt interfaces:

interface gi0/2

10.120.255.163

ip access-group DENY_UNAUTH_USERS in

and the same on the other router...

interface gi0/2

10.120.255.164

ip access-group DENY_UNAUTH_USERS in

Now, from the core switch, which has a directly connected route to the mgmt vlan, I can PING .163, but not.164.

Here are my questions:

1. Regardless of the ACL, if I ping a device on the same vlan (the source interface would also be on that vlan), as occurs when I ping those internet routers from the core switch, the ACL is immaterial, right? It shouldnt come into play. I say that because the source address is 10.120.255.5 and the destination is 10.120.255.163 -- not 10.100.4,5 or 6 -- yet the ping goes through.

2. If that is the case, though, then why could I not ping the .164 router?

You should know that between the core switch and the routers, there are 2 FWs, one behind each router.

I cant help but think that the FW behind the .164 internet router is doing some sort of NATing on my source address, and so the router interface sees the traffic as coming from another subnet and then blocks the icmp traffic....(?)

By teh way, the routing is all good because without the ACLs, everything works.

Any ideas?

Thanks

MW

Jon Marshall · ‎03-22-2008

Hi MW

The more relevant question is why you can ping .163 and not why you can't ping .164.

If you apply the access-list inbound then it will deny 10.120.255.5 because that is not in your permit list. Just because it is on the same vlan does not mean that the acl does not apply, the packet still has to enter via the gi0/2 interface on each router.

So the firewalls must be in transparent mode ?.

Jon

View solution in original post

Jon Marshall · ‎03-22-2008

Well need to try a few things

1) Try to ping .163 and .164 from one of the allowed subnets.

2) Try to ping .163 and .164 from a subnet that is not allowed, but NOT from your core switch.

If you get the expected results ie.

1 - both should work

2 - neither should work

then it suggests that the issue is that when you ping .163 the source IP address is from your allowed list of subnets. Are you doing an extended ping from the core switch ie. where you can specify the source IP address as well.

Jon

View solution in original post

Jon Marshall · ‎03-22-2008

Hi MW

The more relevant question is why you can ping .163 and not why you can't ping .164.

If you apply the access-list inbound then it will deny 10.120.255.5 because that is not in your permit list. Just because it is on the same vlan does not mean that the acl does not apply, the packet still has to enter via the gi0/2 interface on each router.

So the firewalls must be in transparent mode ?.

Jon

MW20082008 · ‎03-22-2008

i dont know anything about the FW set up. i dont even have access ot them.

So why then can I ping the .163 address?

Jon Marshall · ‎03-22-2008

Well need to try a few things

1) Try to ping .163 and .164 from one of the allowed subnets.

2) Try to ping .163 and .164 from a subnet that is not allowed, but NOT from your core switch.

If you get the expected results ie.

1 - both should work

2 - neither should work

then it suggests that the issue is that when you ping .163 the source IP address is from your allowed list of subnets. Are you doing an extended ping from the core switch ie. where you can specify the source IP address as well.

Jon

MW20082008 · ‎03-22-2008

OK, Im accessing the network through a VPN connection, so I cant simulate being on the 10.100.4 or .5 networks. Those are corporate LANs.

And the .6 is a VPN subnet, BUT, after accessing the network through PPTP, the user is once again tunneled through a site to site VPN, so the source address changes.

What I can say is that I run my regular ping tests from the core switch, which is separate from the corporate network. IOW, it is impossible to be sourcing the traffic from any of those allowed subnets if I ping from the core because the core does not have any interfaces on those subnets.

This sucks...

Jon Marshall · ‎03-22-2008

Okay, try

1) an extended ping from the core switch making sure the source IP address is 10.120.255.5 to both .163 and .164

2) Do a traceroute to both .163 & .164 to see which path the packets are taking.

Jon

MW20082008 · ‎03-22-2008

EXTENDED PINGS:

CoreSW11#ping

Protocol [ip]:

Target IP address: 10.120.255.163

Repeat count [5]:

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]: y

Source address or interface: gigabitethernet 1/37

% Invalid source

Source address or interface: 10.120.255.5

Type of service [0]:

Set DF bit in IP header? [no]:

Validate reply data? [no]:

Data pattern [0xABCD]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.120.255.163, timeout is 2 seconds:

Packet sent with a source address of 10.120.255.5

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms

CoreSW11#

CoreSW11#ping

Protocol [ip]:

Target IP address: 10.120.255.164

Repeat count [5]:

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]: y

Source address or interface: 10.120.255.5

Type of service [0]:

Set DF bit in IP header? [no]:

Validate reply data? [no]:

Data pattern [0xABCD]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.120.255.164, timeout is 2 seconds:

Packet sent with a source address of 10.120.255.5

U.U.U

Success rate is 0 percent (0/5)

CoreSW11#

TRACE ROUTES:

CoreSW11#trace 10.120.255.163

Type escape sequence to abort.

Tracing the route to 10.120.255.163

1 10.120.255.163 0 msec * 0 msec

CoreSW11#

CoreSW11#trace 10.120.255.164

Type escape sequence to abort.

Tracing the route to 10.120.255.164

1 10.120.255.164 !A * !A

CoreSW11#

Note the !A results when I trace .164. Its telling me the ACL is blocking it. Its reachable, just blocked. So, that IS Normal for .164.

The problem with .163 remains: why is traffic from a blocked subnet, according to the ACL, being allowed through.

So, maybe my first suspicion -- that traffic is being routed through the FW and being NATed IS the case, but for the .163, not .164 - and instea dof being NAted to a disallowed subnet, I am being NAt'ed to an allowed subnet.

Thats the only thing I can think of. These are supposed to be directly connected hosts. The routing should be fine. According to the traces, it is. However, oftentimes FWs do NOT show themselves as a hop, so with the .163 trace, it MAY be going through a FW. No?

The funny part about it is that these 2 routers have direct connections to the mgmt switch, which is directly connected to the core switch. IOW, if you do a sh cdp nei on the core and 2 Intrenet routers, you will see the mgmt switch.

Confusing...

Jon Marshall · ‎03-22-2008

If the firewalls are between your core switch and the 2 routers then they must be in transparent mode ie. L2 bridging mode. The reason for this is that if the firewall was in routed mode and sat between your core switch and the 2 routers then the core switch and 2 routers would have to be in different subnets.

The management switch, this is just a Layer 2 switch yes ?

Jon

So if you are sure firewalls are in the way then they must be in transparent ie. traffic will not be routed through the firewall.

MW20082008 · ‎03-22-2008

Mr. Jon:

Let me post the configs of everyone involved, ok?

Attached.

Jon Marshall · ‎03-22-2008

Hi

On fesw11 under int gi0/2

ip access-group DENY_UNAUTH_USER in

whereas your access-list is actually called

Standard IP access list DENY_UNAUTH_USERS

10 permit 10.100.4.0, wildcard bits 0.0.0.255

20 permit 10.100.5.0, wildcard bits 0.0.0.255

30 permit 10.100.6.0, wildcard bits 0.0.0.255

40 deny any log

ie. should be DENY_AUTH_USERS but under the interface you have DENY_AUTH_USER

Is this just a typo ?

Jon

MW20082008 · ‎03-22-2008

Here is the topology

Attached

MW20082008 · ‎03-22-2008

OH MY GOD!!!

I am SOOO STUPID!!! HOLY ^%$#!!

A lousy TYPO!!!

I am so sorry, dude. If you were here I would let you punch me in the face -- and then ask for more. :-(

What a fool. All this work because of a typo!

Wow!!

Anyway, have you seen my drawing.

I want to add the list to vlan 60 -- just not sure if it should be applied out or in..?

Can you look at the drawing and tell me?

Im so sorry man...

MW

Jon Marshall · ‎03-22-2008

MW

No apology necessary, sometimes it takes someone else to spot a typo, i know it's happened to me many times.

Vlan 60, is that the connection from your routers to the ASA firewalls. If so then would the traffic be coming in through the ASA firewalls. If so apply it inbound on the vlan 60 interface.

Jon