Limiting ACL to specific VLANs when using vlan aware bridge


Userlevel 1
I can't figure out how to limit an ACL rule to only apply to a specific VLAN when using a single vlan-aware bridge.

I tried the --vlan-id match, but it says unsupported. I tried using the ifname.vlan notation in the -i / -o for the rules but although it doesn't throw an error, the rule is also not applied. (it shows in an ebtables -L but traffic is not affected by it)

I've tried by using the 'classic' bridge (i.e. have one bridge per vlan) and when doing it that way, then using the subinterface seems to work.

16 replies

Userlevel 3
Hi Sylvain, thanks for asking but we don't support VLAN-based matching on a VLAN-aware bridge at this time.
Userlevel 1
Pete B wrote:

Hi Sylvain, thanks for asking but we don't support VLAN-based matching on a VLAN-aware bridge at ...

Is there any chance to have this supported (i.e. in vlan-aware mode) at some point ?

It's the only reason I'm still using traditional bridge mode and I'm falling in love with vlan aware mode 😛
Userlevel 1
Ok thanks. I can live with the traditional style since I have < 10 VLANs.

However even in that case it'd still be useful to consider for future extensions to be able to match on the current vlan because having to list explicitely all subinterfaces quickly leads to a _lot_ of rules.
Userlevel 3
I hear that, Sylvain. I'll pass along your feedback.
Sylvain, ACLs can be applied to a traditional bridge, rather than specifying each sub-interface as the ingress interface.

The following is a policer rule, but permit/deny statements to the best of my understanding should function as well.

root@leaf2:/home/cumulus# cat /etc/cumulus/acl/policy.d/customer1.rules  INGRESS_INTF = br-100
INGRESS_CHAIN = FORWARD
[ebtables]
-A $INGRESS_CHAIN --in-interface $INGRESS_INTF -j police --set-mode KB --set-rate 100 --set-burst 100
Userlevel 1
It was my impression that the bridge interface itself was representing the bridge port going up to the host / OS layer, which doesn't make all that much sense in the FORWARD chain.

And checking on a pure linux box, a FORWARD rule with a -i on the bridge interface just seem to never match.

Now of course that's a pure linux box, not involving switchd ...
Sylvain, your last comment is apt.

Under the covers, each traditional bridge in the underlying switching hardware is actually an internal VLAN.

Take the following configuration as an example:
auto bridge100
iface bridge100
bridge-ports swp1.100 swp2.100
auto bridge200  iface bridge200    bridge-ports swp1.200 swp2.200

On ingress to the switch, the VLAN translation blocks in the switching hardware are used to map the (port,vlan) pair in the bridge-ports list to one internal VLAN.
  • IN swp1.100 to INTERNAL_VLAN 1
  • IN swp1.200 to INTERNAL_VLAN 2
On egress from the switch, those same translation blocks are used to convert the internal VLAN to the correct "external" VLAN on the port to be transmitted on the wire.
  • INTERNAL_VLAN 1 to swp2.100 OUT
  • INTERNAL_VLAN 2 to swp2.200 OUT
By applying the ACL on the traditional bridge as the ingress interface, one effectively creates a VACL.

Hope this helps.
Userlevel 1
Hi Scott,

It's been a while but I finally got a real switch to "play" with and came back to this to test it.

I've put two samples rules like this :

[iptables]
-A FORWARD -i br-test -d 172.30.128.2 -j ACCEPT
-A FORWARD -i br-test -p icmp -j DROP

And if I try to ping 172.30.128.2, packets don't go though ...
If I look at the stats, I see that _both_ rules are matched which is obviously unexpected, since after the ACCEPT, processing should be done.

If I replace the "-i br-test" with "-i swp+", then things works as expected (but of course the ACL is global and no longer limited to one VLAN).

Cheers,

Sylvain
Userlevel 1
Any comment on that weird behavior described in my last post that suspiciously looks like a bug ?
Userlevel 4
Sylvain,

Can you walk me through the steps you used to apply the iptables rule? I assume you:

  • created a file like 10.rules under /etc/cumulus/acl/policy.d/
  • used your syntax from above
  • applied the config to hardware with cl-acltool -i
Also why do you 'have' to have the VLAN-aware config applied to a physical VLAN. Why not just use source and destination subnets?
Userlevel 1
Yes, I followed those step exactly.

Why do I "have" to have this ...

Well right now I'm mostly in an exploratory phase where I try to understand what's possible, how things work, etc ... so I can come up with implementable solutions when faced when a problem.

VLAN ACLs are (AFAIK) a pretty common feature.

One thing I would for instance use them for, is to actually _enforce_ which subnet is used on which vlan to make sure someone isn't trying to sneak stuff by. Then I can even set alerts on the "drop" counter that if any packet ever violates this rule, something really bad is happening and needs my immediate attention.

Something else, is that I tend to use switches as virtual patch panels to make point to point connection as well (just use a dedicated vlan to make the connection). And so for those, I wouldn't want any of my other ACL to apply without having to go through the full list every time to make sure one doesn't conflict.

If the swpX.Y syntax works, I could also use that, it's just more cumbersome to have to repeat the same rule (well at least there is templating !) and it might also use more ASIC RAM space which is inconvenient. But that still doesn't change the fact that is cl-acltool is not throwing an error saying something is not supported, then it should actually do it 🙂

Userlevel 4

VLAN ACLs are (AFAIK) a pretty common feature.

Yeah so we support L2 and L3 iptables rules (ebtables == L2). We just don't have a knob yet for VLAN-aware bridge (to specify a VLAN within VLAN-aware and not a subnet). Since you own hardware I would open a ticket with this so we can document the ask (or talk to your SE, or both). What I meant by "VLAN-aware config applied to a physical VLAN" above was that we can't enforce a subnet on a VLAN-aware VLAN, but we can enforce that a subnet can only talk to a VLAN, whether or not there is an SVI on that VLAN.

e.g.
[iptables]
-A FORWARD -s 172.30.128.0/24 -d 172.30.128.0/24 -j ACCEPT
-A FORWARD -j DROP

This only allows the VLAN associated with that subnet to talk to that subnet, we can check the config like this->
root@vleaf02:~# iptables -L FORWARD -v --line-numbers
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 0 0 DROP all -- swp+ any 240.0.0.0/5 anywhere
2 0 0 DROP all -- swp+ any loopback/8 anywhere
3 0 0 DROP all -- swp+ any base-address.mcast.net/8 anywhere
4 0 0 DROP all -- swp+ any 255.255.255.255 anywhere
5 0 0 ACCEPT all -- any any 172.30.128.0/24 172.30.128.0/24
6 0 0 DROP all -- any any anywhere anywhere

I used the --list-numbers so I can see the order. I think its usually obvious they are in order but just in case someone else is reading this thread.

But that still doesn't change the fact that is cl-acltool is not throwing an error saying something is not supported, then it should actually do it :)

I know this is super simple network but where does 172.30.128.2 exist? Can you draw a tiny diagram of what IPs are on switch (SVI) and what is the host and what you are pinging from?

Userlevel 1
First, despite the title of the thread, I'm now using the "traditional" model and not VLAN-aware !
Since "Pete-B" noted than vlan matching wasn't supported in vlan-aware mode.

For the test above (with br-test), I just had a single traditional bridge "br-test" and I had swp1,swp2,swp3 in that bridge (not even using VLAN tagging or trunking) and I was trying to add an ACL that would only influence traffic bridged through br-test and not any of the other ports / bridge configured on the switch.

swp1 was connected to a machine with 172.30.128.1
swp2 was connected to a machine with 172.30.128.2
swp3 was connected to a machine with 172.30.128.3

(note it might not have been 1/2/3, maybe it was 1/48/50, can't remember the exact port number but same topology)

And then from 172.30.128.1, I was trying to ping 2 & 3 and see if things were behaving as I expected.

I can re-set that up tomorrow when I'm the office and post the exact /etc/network/interfaces and acl rule file.

Userlevel 4
When you set it up, provide /etc/network/interfaces for the switch and provide the output of iptables -L FORWARD -v --line-numbers

Also provide the output of 'ip route show'. The box needs some sort of L3 address even if its not on the same VLAN for it to be able to 'do' anything with L3 rules.
Userlevel 1
OMG ... I'm an idiot ...

In the test above, the same packet wasn't hitting both rules ... the icmp-echo request was hitting the ACCEPT and the matching reply was hitting the DROP.

Not sure how I missed that the first time around, sorry for the noise guys !
I do my best to make sure I check everything I can think of before asking, but obviously sometimes I fail at that ...

I'm kind of intrigued by your last comment about L3 address though. Currently the only L3 interface I have is the management one on eth0, is that enough ?

Userlevel 4
yes eth0 is enough, put the eth0 into management vrf though, reboot and then see how the behavior changes.

Reply