Confused - ACL direction

[louis0001]

I'm getting confused over ACL directions on sub interfaces.

I have the following

interface GigabitEthernet0/0.200

description CORP
encapsulation dot1Q 200
ip address 10.1.1.1 255.255.255.0

interface GigabitEthernet0/0.300

description GUEST
encapsulation dot1Q 300
ip address 172.16.1.1 255.255.255.0

ip access-list extended GUEST_INBOUND
deny ip 10.0.0.0 0.255.255.255 172.16.0.0 0.0.255.255 log
deny ip 192.168.0.0 0.0.255.255 172.16.0.0 0.0.255.255 log
permit ip any any

ip access-list extended GUEST_OUTBOUND
deny ip 172.16.0.0 0.0.255.255 10.0.0.0 0.255.255.255 log
deny ip 172.16.0.0 0.0.255.255 192.168.0.0 0.0.255.255 log
permit ip any any

If I apply GUEST_OUTBOUND to int g0/0.300   OUT, clients can still talk to the CORP and vice versa
If I apply GUEST_OUTBOUND to int g0/0.300   IN, it blocks traffic to CORP and vice versa

It's as if the list is reversed. Similarly, if I 

If I apply GUEST_INBOUND to int g0/0.300   IN, clients can still talk to the CORP and vice versa
If I apply GUEST_INBOUND to int g0/0.300   OUT, it blocks traffic to CORP and vice versa

Please could somebody explain why this is occuring?

I would have though that applying GUEST_OUTBOUND OUT on int g0/0.300 would have prevented anything on 172.16.1.0/24 talking to anything on 10.0.0.0/8

[Seb Rupik]

Hi there,

You just need to change your perspective J

Inbound is traffic arriving at the sub-interface from sources external to the switch, ie not from the backplane. Outbound traffic is leaving a sub-interface.

With regard to your ACLs the first network ID and netmask definition is the source, so for GUEST_OUTBOUND, the source is 172.160.0.0/16, so it will only be effective if applied inbound on the guest sub-interface gi0/0.300.  You would not find IP packets  sourced from 172.160.0.0/16 on any other interface.

GUEST_OUTBOUND ACL is trying to prevent traffic destined to 172.160.0.0/16 so ideally would be applied outbound on Gi0/0.300, but could be used inbound on Gi0/0.200 .

Cheers,

Seb.

[louis0001]

I'm still confused....

interface GigabitEthernet0/0.300

description GUEST
encapsulation dot1Q 300
ip address 172.16.1.1 255.255.255.0

With the above, a client (172.16.1.2) pinging the interface would be traffic that coming IN to the interface?
Another client eg 8.8.8.8 pinging 172.16.1.1 would be the same? ie traffic coming IN to the interface?
When 172.16.1.1 replies to 172.16.1.2, it is traffic going OUT of the interface?
When 172.16.1.1 replies to 8.8.8.8, it is traffic going OUT of the interface?

If the above is true, should the below work:

deny host 172.16.1.2 host 172.16.1.1  (IN)  to prevent client 172.16.1.2 pinging 172.16.1.1
deny host 8.8.8.8 host 172.16.1.1  (IN)  to prevent 8.8.8.8 pinging 172.16.1.1

deny host 172.16.1.1. host 172.16.1.2 (OUT) to prevent 172.16.1.1 ping 172.16.1.2

deny host 172.16.1.1 host 8.8.8.8 (OUT) to prevent 172.16.1.1 pinging 8.8.8.8

[Seb Rupik]

You cannot control traffic moving between sub-interfaces/ SVIs via the backplane with ACLs.

A client 172.16.1.2 would be inbound to gi0/0.300 as that is its gateway. If you look at the routing table (sh ip route) you will see that 172.16.1.0/24 is reached via gi0/0.300). Unless the subnet 172.16.1.0/24 contains your internet gateway there is a good chance that 8.8.8.8 is not reached via Gi0/0.300 so traffic from that source would never be inbound on gi0/0.300 .

Of the examples you provide, the following would work:

! 
int gi0/0.300
  ip access-group GUEST_INBOUND in
  ip access-group GUEST_OUTBOUND out
!
ip access-list ext GUEST_INBOUND
  deny host 172.16.1.2 host 172.16.1.1
!
ip access-list ext GUEST_OUTBOUND
  deny host 172.16.1.1. host 172.16.1.2
!

cheers,

Seb.

[louis0001]

Hi Seb,

please bear with me on this as I'm trying to wrap my head around this. Based on the above, would the following work:

int gi0/0.300
  ip access-group GUEST_INBOUND in   <<< this is traffic coming from 172.16.1.0/24
  ip access-group GUEST_OUTBOUND out   <<< this is traffic going to 172.16.1.0/24
!
ip access-list ext GUEST_INBOUND
  deny host 172.16.1.2 host 172.16.1.1
  deny host 172.16.1.2 host 8.8.8.8   <<< to deny traffic form 172.16.1.2 coming IN to the interface and going to 8.8.8.8
!
ip access-list ext GUEST_OUTBOUND
  deny host 172.16.1.1. host 172.16.1.2
  deny host 8.8.8.8 host 172.16.1.2   <<< to deny traffic that originates from 8.8.8.8 leaving the interface and going to 172.16.1.2

So the access list will only work with the subnets that the interface is a member of ie 172.16.1.0/24 and in the above example, I can only control traffic coming from 172.16.1.0/24 (the source coming IN) and traffic going to 172.16.1.0/24 (the destination going OUT)

[yasseryy]

You can not control the host in the same subnets

[louis0001]

Hi, maybe I should have rephrased that to "manage the traffic allowed through the sub interface" for hosts that are on the same subnet as the interface? I know I can't block traffic between hosts on the same subnet at L2

So with the above, I can only manage the traffic that hits the interface which is coming from/going to clients on that interfaces subnet.

So I can only block traffic going to 172.16.1.2 from 8.8.8.8 (OUT) and traffic coming from 172.16.1.2 destined for 8.8.8.8 (IN)

[Seb Rupik · Accepted solution]

So I can only block traffic going to 172.16.1.2 from 8.8.8.8 (OUT) and traffic coming from 172.16.1.2 destined for 8.8.8.8 (IN)

Yes, that statement holds true only when applied to Gi0/0.300 . To achieve the same security function on a different interface in the same chassis along the path of the flow would require the access-group direction to be reversed.

cheers,

Seb.

[Seb Rupik]

The ACLs and directions all look good.

"So the access list will only work with the subnets that the interface is a member of"

...this is not strictly true. An interface may be the next-hop to multiple subnets. Think of your subnet between your router and ISP. Chances are it is a very small subnet, a /30, but beyond that you have the entire internet 0.0.0.0/0 . An INBOUND ACL on your internet facing interface would possibly have a huge range of ACEs blocking all manner of subnets/ ports/ protocols that are sourced from beyond the immediately connected /30 that you share with your ISP.

cheers,

Seb.

[louis0001]

Thank you Seb for taking the time to explain. I think I've got the concept now as i played around with blocking an individual host  whilst allowing others. Cheers