ACL on SVI not working?

Unanswered Question
Feb 8th, 2010

Config....

ip access-list extended Internet_Only
deny   ip any any


interface Vlan4
ip address 10.17.2.2 255.255.255.0
ip access-group Internet_Only in
ip access-group Internet_Only out
ip helper-address 10.131.1.17
no ip unreachables
standby 1 ip 10.17.2.1
standby 1 priority 101
standby 1 preempt
end



i can still ping 10.17.2.2 and telnet to it from PCs on other subnets. Intrestingly enough if i telnet or ping 10.17.2.2 from that switch it is denied. The ACL was originally much more complicated but it didnt seem to work so im doing a deny any simply to get it working. Is there something i am missing? I have done this before but it doesnt appear to be working in this scenario.



System image file is "flash:c3750-ipservices-mz.122-25.SEB2/c3750-ipservices-mz.122-25.SEB2.bin"

cisco WS-C3750-48P (PowerPC405) processor (revision J0) with 118784K/12280K bytes of memory.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Jon Marshall Mon, 02/08/2010 - 10:35

mikegrous wrote:


Config....

ip access-list extended Internet_Only
deny   ip any any


interface Vlan4
ip address 10.17.2.2 255.255.255.0
ip access-group Internet_Only in
ip access-group Internet_Only out
ip helper-address 10.131.1.17
no ip unreachables
standby 1 ip 10.17.2.1
standby 1 priority 101
standby 1 preempt
end



i can still ping 10.17.2.2 and telnet to it from PCs on other subnets. Intrestingly enough if i telnet or ping 10.17.2.2 from that switch it is denied. The ACL was originally much more complicated but it didnt seem to work so im doing a deny any simply to get it working. Is there something i am missing? I have done this before but it doesnt appear to be working in this scenario.



System image file is "flash:c3750-ipservices-mz.122-25.SEB2/c3750-ipservices-mz.122-25.SEB2.bin"

cisco WS-C3750-48P (PowerPC405) processor (revision J0) with 118784K/12280K bytes of memory.


Mike


You are pinging it from remote subnets.


So the out direction on the vlan interface affects traffic going to clients on vlan 4. But this packet is not going out from the interface so the acl is not relevant in the out direction.


The in direction is for traffic coming from clients on vlan 4. But the packets are coming from remote subnets so the acl is not relevant in the in direction.


If you want to limit ping from remote subnets to the clients on vlan 4 then the acl will work in the out direction. But if you want to limit ping to the actual vlan 4 interface then you need to apply the acl on the relevant remote subnet vlan interfaces in the inbound direction.


Jon

mikegrous Mon, 02/08/2010 - 11:11

I follow your logic however: On a differnt L3 switch i have the same thing configured and i am unable to telnet to 10.17.3.1 or 10.17.3.2..


interface Vlan400
ip address 10.17.3.2 255.255.255.0
ip access-group Internet_Only in
ip helper-address 10.2.1.50
no ip unreachables
standby 1 ip 10.17.3.1
standby 1 priority 101
standby 1 preempt
end


Extended IP access list Internet_Only
    10 permit udp any host 10.2.1.50 eq bootpc
    20 permit udp any host 10.2.1.50 eq bootps
    30 permit ip any host 208.67.222.222
    40 permit ip any host 208.67.220.220
    50 deny tcp any host 10.17.3.1 eq telnet (4 matches)
    60 permit ip any host 10.17.3.1 (21 matches)
    70 deny ip any 10.0.0.0 0.255.255.255 (6034 matches)
    80 deny ip any 155.250.11.0 0.0.0.255
    90 deny ip any 155.243.11.0 0.0.0.255
    100 deny ip any 155.242.11.0 0.0.0.255
    110 deny ip any 140.2.11.0 0.0.0.255
    120 deny ip any 155.12.0.0 0.0.255.255
    130 deny ip any 155.6.0.0 0.0.255.255
    140 deny ip any 140.1.0.0 0.0.255.255
    150 deny ip any 156.21.0.0 0.0.255.255
    160 deny ip any 192.168.0.0 0.0.255.255
    170 deny ip any 172.16.0.0 0.0.15.255
    180 permit ip any any (13242 matches)

Jon Marshall Mon, 02/08/2010 - 11:21

mikegrous wrote:


I follow your logic however: On a differnt L3 switch i have the same thing configured and i am unable to telnet to 10.17.3.1 or 10.17.3.2..


interface Vlan400
ip address 10.17.3.2 255.255.255.0
ip access-group Internet_Only in
ip helper-address 10.2.1.50
no ip unreachables
standby 1 ip 10.17.3.1
standby 1 priority 101
standby 1 preempt
end


Extended IP access list Internet_Only
    10 permit udp any host 10.2.1.50 eq bootpc
    20 permit udp any host 10.2.1.50 eq bootps
    30 permit ip any host 208.67.222.222
    40 permit ip any host 208.67.220.220
    50 deny tcp any host 10.17.3.1 eq telnet (4 matches)
    60 permit ip any host 10.17.3.1 (21 matches)
    70 deny ip any 10.0.0.0 0.255.255.255 (6034 matches)
    80 deny ip any 155.250.11.0 0.0.0.255
    90 deny ip any 155.243.11.0 0.0.0.255
    100 deny ip any 155.242.11.0 0.0.0.255
    110 deny ip any 140.2.11.0 0.0.0.255
    120 deny ip any 155.12.0.0 0.0.255.255
    130 deny ip any 155.6.0.0 0.0.255.255
    140 deny ip any 140.1.0.0 0.0.255.255
    150 deny ip any 156.21.0.0 0.0.255.255
    160 deny ip any 192.168.0.0 0.0.255.255
    170 deny ip any 172.16.0.0 0.0.15.255
    180 permit ip any any (13242 matches)


Mike


Okay, it's a bit more complicated with a switch that s running HSRP with another switch. Imagine this scenario -


you are telnetting from a remote subnet. You are telnetting to the vlan 400 address on SW2. But your HSRP active gateway is SW1. So your packet comes in on SW1. Now if the address you were telnetting to was on SW1 vlan interface then what i wrote in previous post applies.


But the address is on SW2. So the packet is routed onto vlan 400 on SW1 and then sent across the L2 trunk to SW2. Now the packet is in vlan 400 so the acl in the inbound direction now applies.


So with 2 switches interconnected via a L2 trunk running HSRP/GLBP then the direction of the packet relevant to the vlan interface can be different depending on where your source host is connected and it's active HSRP gateway.


Jon

mikegrous Mon, 02/08/2010 - 13:28

perfect. I got it. I changed my HSRP active router to the one my vlan's default gateway is active for and then i could telnet 10.17.3.1.

Change it back and i was not able to. It makes sence. Thanks a bunch.

Jon Marshall Mon, 02/08/2010 - 13:35

mikegrous wrote:


perfect. I got it. I changed my HSRP active router to the one my vlan's default gateway is active for and then i could telnet 10.17.3.1.

Change it back and i was not able to. It makes sence. Thanks a bunch.


Mike


No problem, glad to have helped.


By the way is that the Middlesex hsopital that is next to the North Circular ? I only ask as i spent many hours sitting in traffic jams on the North Circular so got to know it quite well


Jon

tdistlists Wed, 12/08/2010 - 10:38

I hate to bring up an old thread, but the response on this one confused me a bit.


If the packet enters SW1 (due to it being the HSRP primary as described) on lets say vlan 100, and was destined to the SW2 IP address of vlan 400, the SW1 sould have to route this packet to vlan400. After the route took place, it should be the OUT ACL that takes effect, because basically it came into the switch in VLAN 100 (inbound ACL on vlan 100) and was routed to vlan 400 (outbound ACL on SVI vlan 400).


However, the explanation provided was inbound direction on vlan 400. If this is correct, then two inbound ACLs would take effect on this packet, IN on vlan 100 AND in on vlan 400 (if he did have an ACL on vlan 100).


Am I incorrect in thinking that it should only match one "inbound" ACL on a single L3 switch?


ACLs on SVI are straighforward for me when dealing with SVIs where pc's are located (user subnets, etc).


inbound - traffic sourced by hosts on the vlan

outbound - traffic destined to hosts on the vlan


However, when dealing with SVIs that are used for routing (/30s, etc) things get pretty sketchy for me. Traffic flowing through the vlan, never really sure what direction the ACL should be in.


What I have been assuming is this. If the traffic enters an access/trunk port on vlan 100 (for example), then no matter the dst/src IP it would be applied to IN on SVI 100. After routing takes place, if the exit interface is an access/trunk port on vlan 100, then it would be the OUT ACL.


Thanks in advance for the clarification!

Jon Marshall Wed, 12/08/2010 - 12:53

If the packet enters SW1 (due to it being the HSRP primary as described) on lets say vlan 100, and was destined to the SW2 IP address of vlan 400, the SW1 sould have to route this packet to vlan400. After the route took place, it should be the OUT ACL that takes effect, because basically it came into the switch in VLAN 100 (inbound ACL on vlan 100) and was routed to vlan 400 (outbound ACL on SVI vlan 400).


Your'e thinking of it only on the same switch but that was not what i was explaining (although what you say is correct) ie.


you have 2 switches (sw1 & sw2)  connected via a trunk link running HSRP for all vlans. There are 2 vlans involved -


vlan 100 - vlan where the client you want to telnet from is

vlan 400 - vlan where you are telnetting to. Specifically you are trying to telnet to the L3 vlan interface for vlan 400 on sw2


the active HSRP gateway for vlan 100 is sw1.


So when you telnet from a pc in vlan 100 to sw2 vlan 400 interface -


1) you first go to vlan 100 SVI on sw1. If you applied an acl inbound on this SVI this would be checked


2) the packet is then routed onto vlan 400 on sw1. You are right in that if you wanted to then filter the traffic you could use an outbound acl on vlan 400 on sw1.


3) what i was explaining to Mike was why an inbound acl on vlan 400 was still blocking traffic. And this is because once traffic has been routed onto vlan 400 on sw1 that traffic is now coming from vlan 400 to sw2. So an acl applied inbound on the vlan 400 SVI will indeed be checked when that packet arrives.


This was the key bit i was explaining ie. if you have 2 switches running HSRP the direction of the traffic in relation to the vlan interface depends on which switch routed it onto that vlan. But as i say you are not wrong in what you say above.


However, the explanation provided was inbound direction on vlan 400. If this is correct, then two inbound ACLs would take effect on this packet, IN on vlan 100 AND in on vlan 400 (if he did have an ACL on vlan 100).


Yes in this particular instance it would. But it's important to note we are talking about a very specific instance. So using the example above if the client on vlan 100 telnetted to another device in vlan 400 (not the SVI for vlan 400 on sw2) then the acl applied inbound on the sw2 vlan 400 SVI would not apply because once sw1 has routed the traffic onto vlan 400 on sw1 even if the end device was connected to sw2 it would be switched straight to that device ie. not to the SVI for vlan 400 on sw2.


So we are talking only about if you wanted to telnet to the actual SVI itself rather than devices within vlan 400. I think that is where the confusion has come from.


Am I incorrect in thinking that it should only match one "inbound" ACL on a single L3 switch?


No your'e not. Generally speaking you are right and this is by far the commonest case, it just we are not dealing with the common case - see above.


However, when dealing with SVIs that are used for routing (/30s, etc) things get pretty sketchy for me. Traffic flowing through the vlan, never really sure what direction the ACL should be in.


If you are using /30 vlan for routing then you could apply the acl in all 4 ways to be honest -


1)  inbound on sw1 SVI to control which traffic is accepted from sw2

2)  outbound on sw1 SVI to control which traffic is forwarded  to sw2

3)  inbound on sw2 SVI to control which traffic is accepted from sw1

4)  outbound on sw2 SVI to control which traffic is forwarded to sw1


in practice it wouldn't make a lot of sense to use all 4, where 1 on either end would suffice or even just 1 on one end. Because there are no clients in this vlan traffic would only ever be destined for either SVI. I say destined in the sense that the destination IP would be not be either SVI but if the traffic is routed onto the link at one end the only place to send the traffic so that it can be forwarded is the other end of the link ie. the other SVI, there is nothing inbetween such as clients etc.


What I have been assuming is this. If the traffic enters an access/trunk port on vlan 100 (for example), then no matter the dst/src IP it would be applied to IN on SVI 100. After routing takes place, if the exit interface is an access/trunk port on vlan 100, then it would be the OUT ACL.


Not sure i totally follow. Is this meant to relate the /30 bit because if it does i'm not sure how trunk links come into it ?


Jon

tdistlists Wed, 12/08/2010 - 13:28

Jon, thank you very much for helping clear this up for me. I greatly appreciate it.


I failed to realize that the ACL taking action was the one on SW2. That makes perfect sense now. I thought you were referring to the ACL on SW1, which threw me for a tailspin -- thinking the interface the packet came in on SW1 (vlan 100, or any other L3 interface) and vlan 400 could have both triggered an "inbound" ACL on the same switch. Instead, it was "inbound" on vlan 100 on SW1 and "inbound" on vlan 400 on SW2.


Having the two "inbounds" both on SW1 is what threw me off. As a rule of thumb I tend to think "in" is pre-routed and the "out" is post-routed.


As for my feable attempt at some logic, what I meant was if I get lost for directionality, I tend to follow the MAC address to a L2 port, and if the source MAC arrived on an access port in vlan 100 (or a trunk port allowing vlan 100), then its traffic no matter the src/dst IP address, would be applied "inbound" on vlan 100 SVI. Alternatively, if traffic arrived on a different interface/vlan, and after routing took place it needed to get to the next hop via vlan 100 (ie destination MAC was to leave a switchport on vlan 100), then the "outbound" ACL would apply.




Thanks again!

mikegrous Wed, 12/08/2010 - 17:41

Didnt see this message before. And it is Middlesex Hospital in CT.

Actions

This Discussion