2

There is a layer 3 switch which is responsible for inter-vlan routing. One VLAN (10, network: 172.16.10.0/24) cannot be accessed from any other VLANs (for management purposes). In order to do that I used the following ACL

access-list 1 permit 172.16.10.0 0.0.0.255
access-list 1 deny any

interface vlan 10
ip access-group 1 out

This blocks any traffic with source IP address outside VLAN 10 from exiting out the VLAN 10 SVI interface.

I chose to block the traffic when exiting the VLAN 10 SVI interface instead of blocking the traffic when entering all the other VLAN SVI interfaces because new VLANs can be added later, which means setting the same ACL for the new VLANs as well.

The problem is that the layer 3 switch has a management interface (172.16.10.1) which any VLANs can access, because the traffic will enter through the SVI interface corresponding to the source VLAN and it will remain in the switch. It will not get a chance to be filtered by the ACL which resides at the exit of the VLAN 10 SVI.

Is there a solution for filtering traffic destined to this interface residing on the switch without putting ACLs on inbound traffic for every other VLAN SVI?

Improve this question

2 Answers 2

Reset to default
3

If you want to restrict management access to the switch, you need to apply the ACL to the VTY interfaces:

ip access-list standard MY-ACL
permit ip 172.16.10.0 0.0.0.255

line vty 0 15
access-class MY-ACL in
Improve this answer
4
  • So this can be used without the ACL that I wrote. In real life, which option would be chosen, this one or the one suggested by @Ron Maupin?
    – user42768
    May 8, 2017 at 18:42
  • If your intent was just to restrict management access to this switch, I think this is simpler. If you have other requirements (it wan't too clear from your question), we need to look at other options.
    – Ron Trunk
    May 8, 2017 at 18:57
  • Depending on the switch model and IOS version, you might consider VRF to isolate management access.
    – Ron Trunk
    May 8, 2017 at 18:58
  • It was mainly a theoretical problem. I was told I had to isolate the management VLAN from the others, without any more details. I tried the solution in the post, then I realized the problem. I don't know almost anything about VRF, I will read about it. Thank you!
    – user42768
    May 8, 2017 at 19:08
2

You must put the ACL before the target from the perspective of traffic routing. Your problem is that the ACL is after one of the targets. Also, such an outbound ACL will actually route traffic that is destined to be dropped. If you place inbound ACLs, then the traffic will be dropped before resources are used to route the traffic.

You could have a single ACL that is used by the other interfaces, but, as you pointed out, you will need to add this ACL to any future networks you may add that should not access that network.

Improve this answer
13
  • So there is no way to filter packets which are already inside the "routing engine"? The only solution is to put inbound ACLs on every other SVI?
    – user42768
    May 8, 2017 at 18:31
  • That would be the correct way to do it. ACLs are evaluated as traffic attempts to pass through the interface. Your problem is that the traffic to that interface is going to the interface, not through the interface. As I wrote, you don't need multiple ACLs for the other interfaces; you can create a single ACL for all the other interfaces.
    – Ron Maupin ♦
    May 8, 2017 at 18:35
  • Yes, that is what I was referring to. Ok, thank you!
    – user42768
    May 8, 2017 at 18:37
  • Also, you must consider the case of someone attempting to manage the switch through any of the other interfaces on the switch.
    – Ron Maupin ♦
    May 8, 2017 at 18:38
  • Are you referring to the situation when someone tries to connect to 172.16.20.1 (from inside VLAN 20), while this IP is assigned to the SVI of VLAN 20 on the switch? So, afterall, the solution proposed by @Ron Trunk should be the correct one?
    – user42768
    May 8, 2017 at 18:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.