Best practice for controlling inter-VLAN access

[Josh Mil]

Hi, can I get some help with implementing inter-VLAN access control?

Scenario: A layer 3 switch is handling multiple VLANs, such as Staff, IT, Guest, IoT, and CCTV. I need to define access rules to control which VLAN can access which VLAN. For example, IT can access all VLANs, Corporate can access IoT and CCTV, Guest cannot access any other VLAN.

I have the following options:
(1) ACLs on source SVIs
(2) ACLs on destination SVIs
(3) VACLs on source VLANs
(4) VACLs on destination VLANs

My questions:

[1] Everyone says, ACLs should be applied as close to the traffic source as possible. That means option 1 and 3 are preferred? But what if I define ACLs on the destination? Does it really have noticeable impact on performance? Nevertheless, it feels more natural and intuitive to hire a security guard at the visitee's door to check visitors, and not at the visitors' homes. When a new VLAN is added to the network, if no denial rules are defined (or not correctly defined), at least it won't accidentally grant the new VLAN access to the existing VLANs, which feels safer.

[2] ACL vs VACL, which is more suitable in this scenario?

[3] Is it possible to define a rule that controls access between whole VLANs? For example:

! enable routing from vlan 20 to vlan 30, regardless of layer 3 address, protocol, port number
permit vlan 20 vlan 30
! disable routing from vlan 40 to vlan 10
deny vlan 40 vlan 10

So far, all the ACLs for controlling inter-VLAN access that I've seen are based on IP addresses. Even 0.0.0.0 or any are still IP addresses. I assume the switch still needs to do computing like XOR operations to determine whether a given address matches the criteria. If there is a simple 'toggle' enabling or disabling routing between two given VLANs, that would be more efficient.

[MHM Cisco World]

Inter VLAN traffic filter need ACL not VACL' VACL us mainly for intra VLAN not inter VLAN

Best config is use ACL in source (under vlan source)

MHM

[Josh Mil]

Thank you. Can I further ask the reasons? What issues can it cause if I use VACL for filtering inter VLAN traffic? And are there any scenarios where ACL on destination side is preferred?

[MHM Cisco World]

VACL use for intra and inter VLAN' wrong config can lead to loss connection between client to client in same subnet or client to GW' I prefer use ACL which is use only for inter VLAN.

Apply ACL in destiantion not recommend' 

Image this guest vlan abd corporate vlan try to access server in server vlan' 

You have DDoS attack from guest vlan

The traffic will pass until SVI of server VLAN and then drop' this effect whole server vlan

Where if I apply it at guest vlan then traffic will drop in guest vlan (near source) and other traffic not effect.

MHM

[Josh Mil]

Thank you. In the DDos example, I assume the rate limiting set on the incoming port of the guest vlan should be much lower than the switching capacity of the server vlan, so the incoming port will get blocked before the server vlan is saturated. Not sure whether this is right?

[MHM Cisco World]

Rate limit meaning CoPP?

The target of DDoS is server not vlan IP

So it better isolate guest from server and corporate vlan. 

MHM

[M02@rt37]

Hello @Josh Mil 

When you’re implementing intervlan access control on a L3 switch, the most efective and manageable option is to use routed ACLs 'RACL' applied to SVIs. These operate at L3 and allow you to define which subnets (i.e., VLAN interfaces) can communicate with each other.

Vlan ACLs, VACL, are generally not suitable for this scenario since they apply filtering inside a VLAN and are not meant for controlling trafic routed between VLANs...

Now, regarding the placement of ACL_ whether on the source or the destination SVI_ the performance difference is negligible because both directions are evaluated in hardware. Instead, the decision should be made based on operational clarity. If your team think of VLANs like secured rooms with a guard at the door, inbound ACLs on destination SVIs make sense. If you prefer to stop traffic right when it leaves its source, inbound ACLs on source SVIs would be the choice.

The important thing is to be consistent in how you implement them, so the rule placement is predictable and more intuitive.

Finaly, there isn’t a built-in command to simply deny VLAN 40 to VLAN 10 without referencing IP address. Once routing is enabled, the switch makes all forwarding decisions based on L3 networks, not vlan id. The "clean way" to implement your requirements is to create acl that reference the VLANs’ subnet addresses, and then apply those ACLs inbound on the appropriate SVIs. This achieves the same result, and since ACL lookup are done in hardware, there is no performance penalty !

[Josh Mil]

Thank you so much for your reply in detail. Now I have no more concern on using IP address for defining access rules.

With regard to choosing between ACL and VACL, if I define the rule by specifying a source IP range from VLAN 10 and a destination IP range from VLAN 20, it seems to do the job as well. I don't even need to create SVIs before creating the access rules. In the future, should any changes are made to the SVI, I won't need to re-assign the ACL. So, what are the drawbacks of using VACLs for controlling inter-VLAN access?

Since the mainstream designs apply ACLs on the source side, there must be some strong reasons. If I decide to assign ACLs on the destination SVIs, what possible downsides shall I be aware of?

[M02@rt37]

@Josh Mil 

VACL can technicaly block intervlan trafic, but they apply to all traffic within a VLAN (including intra-vlan), are less flexible, less intuitive to read anlso, and not universally supported.

RACLs on SVIs are clearer I think, safer, and purpose-built for inter-VLAN access control !

ACL on the source SVI are the mainstream choice because they contain mistakes, prevent new VLANs from accidentally accessing everything, and reduce wasted traffic.

Apply an ACLs on the destination SVI also works, but carries a higher risk of exposing a VLAN if an ACL is missed...

[Josh Mil]

Thank you. I still don't quite understand the point that applying ACL on the source SVI prevents new Vlans from accidentally accessing everything.

If we define access rules on each destination SVI, a new VLAN should be denied access to other VLANs due to the "deny any any" at the bottom of each existing ACL. In other words, a new VLAN has access to nothing by default, until we explicitly create permit entries on the destination Vlans.

In contrast, if we take the approach of defining access rules on the source side, that means there is no default protection on the destination side. When we create a new VLAN but forget to restrict its access to existing VLANs, the new VLAN will gain access to all the existing VLANs by default.

Certainly, if we create a new VLAN but forget to create an ACL to protect itself, then it's exposed to the existing VLANs, but I think the consequence of exposing a new VLAN (probably not put in use yet) should be less severe than exposing existing VLANs (already have servers or restricted resources in them).

[MHM Cisco World]

Certainly, if we create a new VLAN but forget to create an ACL to protect itself, then it's exposed to the existing VLANs, but I think the consequence of exposing a new VLAN (probably not put in use yet) should be less severe than exposing existing VLANs (already have servers or restricted resources in them). <<- if by mistake and add vlan without config ACL under it, then sure ACL in destination is solution, but each solution have pros&cons the cons of add ACL in destination is more than it pros

MHM

[Rob Ingram]

@Josh Mil what is the scale of your scenario? Managing ACLs/VACLS locally on switches is cumbersome and doesn't scale well. TrustSec is more scalable as policies are managed centrally via ISE, tags (SGTs) are assigned to the authenticated devices and policies based on SGT rather than IP to restrict the traffic (inter and intra-VLAN). These SGTs can be used throughout the network on switches, routers, firewalls and proxies - so you can get end-to-end policy enforcement.

The downside is the additional cost of ISE and implementation.

[Josh Mil]

It's a small network, but I'd like to learn more in general.