Community discussions

MikroTik App
 
moveik
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 54
Joined: Tue Nov 24, 2020 1:16 am

Firewall rules for VLANs using their interface name

Sat Mar 25, 2023 3:36 pm

Based on the post of "Router-Switch-AP (all in one)":
viewtopic.php?f=13&t=143620#p706998

and following my post here:
viewtopic.php?p=989204#p989204

I had applied VLANs and firewall rules.

I want all my packets to go through the firewall rules which will accept or drop the packet based on the VLAN interface name.
I prefer to avoid using any IP addresses in the firewall rules, because it is less robust.

So, I also applied this command (required also for QoS):
# Make sure that all VLAN traffic goes through the IP firewall.
# This makes it necessary to allow traffic of a VLAN to itself via IP firewall.
/interface bridge settings
set \
    use-ip-firewall=yes             \
    use-ip-firewall-for-vlan=yes
See specs here:
https://help.mikrotik.com/docs/display/ ... geSettings


BUT, I discovered that VLAN traffic is detected by the LAN "bridge", instead of being detected by the VLAN interface name.

Meaning, I had two clients connected to the *same* VLAN.
Each client tried to ping to the other.
But their packets eventually reached to the "Drop ALL" firewall rule, while skipping the firewall rule which should accept the packet for that specific VLAN.

In the log, I noticed the following regarding the dropped packets (omitted irrelevant data for clarity):
forward: in:bridge(ether2) out:bridge(ether3), connection-state:new
"bridge" here is the LAN bridge to which both clients are connected to via Ethernet ports.
These Ethernet ports are "ether2" and "ether3".

I don't understand why the firewall thinks that the packet was sent from "bridge(ether2)" and sent to "bridge(ether3)" ?
That is technically true, though I expected the firewall to think that the packet is sent from "VLAN_Interface_Name" and sent to "VLAN_Interface_Name".

Please help me to correct my lack of understanding.
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11381
Joined: Thu Mar 03, 2016 10:23 pm

Re: Firewall rules for VLANs using their interface name

Sat Mar 25, 2023 4:39 pm

Bridge ... has ports as members. Ports are ether2 or ether3. When it comes to bridge, VLANs are simply frame headers but beyond that bridge has no notion of vlan interfaces.

Then there are interfaces. Those are entities where router actively communicates with rest of networks. Bridge happens to come with port facing ROS (CPU) and it can have IP address assigned (which then makes it interface). Or bridge port can serve as anchor of vlan ports - assigning IP address to a VLAN port again makes it interface so that ROS can interact with VLANed networks.

But when one enables IP firewall for VLAN traffic, this is sort of extension of firewall functionality (because normally firewall only filters traffic passing via router's interfaces) ... and thus firewall sees traffic coming in via bridge ports. Indeed logs could include VLAN IDs, but that still wouldn't make them interfaces ... even less can those be associated with VLAN interfaces, not every VLAN passing bridge needs a vlan port/interface.

More on different bridge personalities in ROS: viewtopic.php?t=173692
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Firewall rules for VLANs using their interface name

Sat Mar 25, 2023 4:49 pm

Hi MKX

I think you have a typo........
But when one enables IP firewall for VLAN traffic, this is sort of extension of firewall functionality (because normally firewall .................

Did you actually mean
But when one enables Bridge IP firewall for VLAN traffic, this is sort of extension of firewall functionality (because normally firewall

My rule of thumb is no need for any Bridge shenanigans or extra settings UNLESS you really need them.
The tricky part for me is I dont know when one needs to get fancy and invoke bridge filtering.
A set of example use cases would be worthwhile.
In the meantime the regular firewall suffices for 95% of configs.

(and u have mail)
 
moveik
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 54
Joined: Tue Nov 24, 2020 1:16 am

Re: Firewall rules for VLANs using their interface name

Sat Mar 25, 2023 5:26 pm

Bridge ... has ports as members. Ports are ether2 or ether3. When it comes to bridge, VLANs are simply frame headers but beyond that bridge has no notion of vlan interfaces.

Then there are interfaces. Those are entities where router actively communicates with rest of networks. Bridge happens to come with port facing ROS (CPU) and it can have IP address assigned (which then makes it interface). Or bridge port can serve as anchor of vlan ports - assigning IP address to a VLAN port again makes it interface so that ROS can interact with VLANed networks.

But when one enables IP firewall for VLAN traffic, this is sort of extension of firewall functionality (because normally firewall only filters traffic passing via router's interfaces) ... and thus firewall sees traffic coming in via bridge ports. Indeed logs could include VLAN IDs, but that still wouldn't make them interfaces ... even less can those be associated with VLAN interfaces, not every VLAN passing bridge needs a vlan port/interface.

More on different bridge personalities in ROS: viewtopic.php?t=173692
I understand your post.
Also I had been given that link/tutorial and read it before.
Still I can't deduce from this a viable solution.

How would I apply a firewall rule for each VLAN?
To allow/block traffic between a VLAN to itself.

Funny thing is that the logs show that the another firewall rule successfully drops packets which go from one VLAN interface to some other VLAN interface.
For example, the log shows something like this:
forw: in:VLAN_A(ether2) out:VLAN_B, connection-state:new
So, the firewall is able to recognize the VLAN interface name and perform the filtering based on the VLAN interface - but only when source and destination interfaces are distinct.

But, when source and destination interfaces are identical, then firewall doesn't recognize the VLAN interface name.

I had remove the IP address from the bridge, so it isn't an interface and it should no longer be recognized in the firewall, though still the log shows the same text for a packet that is dropped while trying to be sent from a VLAN to itself:
forward: in:bridge(ether2) out:bridge(ether3), connection-state:new
So I am still missing on how to filter properly for packets which try to be sent from a VLAN to itself.

My rule of thumb is no need for any Bridge shenanigans or extra settings UNLESS you really need them.
The tricky part for me is I dont know when one needs to get fancy and invoke bridge filtering.
A set of example use cases would be worthwhile.
In the meantime the regular firewall suffices for 95% of configs.
I believe so too, though now is the time for me to learn and experiment.
I prefer to build a so-called "fancy" setup which will later allow me to easily (and quickly) perform critical changes, rather to have a "simple" setup that will make me lose time when I barely have it.

Also, now I learn a lot which is important for me (the learning process itself).
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 3169
Joined: Sun May 01, 2016 7:12 pm
Location: California

Re: Firewall rules for VLANs using their interface name

Sat Mar 25, 2023 5:39 pm

The tricky part for me is I dont know when one needs to get fancy and invoke bridge filtering.
A set of example use cases would be worthwhile.
That's very true.

I don't have any examples. But at a 10K foot level, this MAY be better approach than sending bridge traffic through the IPv4 firewall, as all the packet stuff be available directly in the bridge firewall & that has to be faster than the roundtrip through firewall. But depends on needs I guess...

Food for thought only.
 
User avatar
Hominidae
Member
Member
Posts: 309
Joined: Thu Oct 19, 2017 12:50 am

Re: Firewall rules for VLANs using their interface name

Sat Mar 25, 2023 6:14 pm

How would I apply a firewall rule for each VLAN?
To allow/block traffic between a VLAN to itself.
...just a hunch, but enabling an "allow" (like all clients in the same VLAN can ping each other) would be against other port isolation rules you have set?, see: https://help.mikrotik.com/docs/display/ ... tisolation

Otherwise, I am lost as well...interesting topic, though.
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 3169
Joined: Sun May 01, 2016 7:12 pm
Location: California

Re: Firewall rules for VLANs using their interface name

Sat Mar 25, 2023 6:47 pm

The tricky part for me is I dont know when one needs to get fancy and invoke bridge filtering.
I don't have any examples.
Actually, quickset takes this approach for the guest wi-fi. What they do is:
/interface bridge filter
add action=drop chain=forward in-interface=wifi3
add action=drop chain=forward out-interface=wifi3
which what enforces "Client Separation" on the Wi-Fi (so client can only go to the internet).

I only bring this up since bridge filter matchers are "richer", and can directly match on L2/MAC/vlan-id or IPv6 things if needed.

But there is a cleanliness in everything using "use-ip-firewall[for-vlan]=yes"...
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Firewall rules for VLANs using their interface name

Sat Mar 25, 2023 6:49 pm

How would I apply a firewall rule for each VLAN?
To allow/block traffic between a VLAN to itself.
This makes little sense to me? Do you have a use case?
Why would you want to filter some vlan users from other vlan users in the same vlan.
The whole purpose of VLANS is to segregate a group of users/devices from other users/devices, at layer 2 by putting them in their own bubble.
A vlan also makes a great entity to apply regular firewall rules to. In addition you fire as many of these vlans as you want down a single port!!

The only time I have seen such a requirement or something close is when one has a subnet of wired users and wifi users,
and the person doesnt want the wifi users to be able to access the wired users and then access list is required i beleive.

Typically if you want to control a subset of users within a subnet, one does have the option of ROUTING them accordingly, nothing to do with firewall rules.
One mangles their traffic and routes them as desired BUT THIS IS LAYER 3!!
No way to touch their layer 2 connectivity.
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 3169
Joined: Sun May 01, 2016 7:12 pm
Location: California

Re: Firewall rules for VLANs using their interface name

Sat Mar 25, 2023 6:59 pm

Why would you want to filter some vlan users from other vlan users in the same vlan.
Guest Wi-Fi be the classic case. You don't want these guest user to see other random people's iPhones etc popping up in AirDrop etc etc., but you only have one SSID for all guests.

Depends on how much you trust your devices I guess. L2 filtering at bridge captures all traffic. For these untrusted light bulbs case, maybe they just need to talk to the cloud & you know they don't need access to anything locally, so you can enforce. Without putting each light bulb on a different VLAN.

And there are tons some things that don't use IPv4...
 
holvoetn
Forum Guru
Forum Guru
Posts: 5317
Joined: Tue Apr 13, 2021 2:14 am
Location: Belgium

Re: Firewall rules for VLANs using their interface name

Sat Mar 25, 2023 7:20 pm

Guest wifi and IoT devices are examples indeed, no need for them to be aware of other devices.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Firewall rules for VLANs using their interface name

Sat Mar 25, 2023 7:28 pm

Yes and thats why they are on their own VLAN on any sane configuration. :-)

So I guess this means that this addresses the USE CASE OF.........
MT device coupled with stewpid AP? as anyone with a smart AP would never combine guests wiith iot with family on the same SSID and same VLAN.
 
holvoetn
Forum Guru
Forum Guru
Posts: 5317
Joined: Tue Apr 13, 2021 2:14 am
Location: Belgium

Re: Firewall rules for VLANs using their interface name

Sat Mar 25, 2023 7:33 pm

Separate ssid
Separate vlan
No interconnection

Smart ap
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 3169
Joined: Sun May 01, 2016 7:12 pm
Location: California

Re: Firewall rules for VLANs using their interface name

Sat Mar 25, 2023 7:49 pm

Yes and thats why they are on their own VLAN on any sane configuration. :-)
You can bridge filtering on a VLAN too & only as a thought not recommendation per se. I wasn't saying go to one subnet here.

More saying you have two potential IoT VLAN cases:
- devices can communicate with each other on their VLAN, but no other VLANs/"interface lists".
- devices that can only go to the internet and not even see other devices in their own VLAN

It seems the OP has some variant on the later that's he's trying to filter via the /ip/firewall using use-ip-firewall=yes in the bridge, but that conversion is "lossy". How best to resolve that, I dunno.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Firewall rules for VLANs using their interface name

Sat Mar 25, 2023 9:02 pm

Vlans are cheap put the IOT device that is the problem in its own vlan.
Maybe one you experts can figure out a vxlan solution LOL.
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 3169
Joined: Sun May 01, 2016 7:12 pm
Location: California

Re: Firewall rules for VLANs using their interface name

Sat Mar 25, 2023 10:33 pm

Vlans are cheap put the IOT device that is the problem in its own vlan.
That works equally well here too.

Just here we're talking about "all-in-one" @pcunite template. The bridge filter is a possibility since everything does hit the bridge firewall itself in this case & the packets have all attributes available for filtering – which is what the OP ran into. And, I believe use-ip-firewall=yes can effect some of the hw offloading/fastrack/etc things.

Two routers, other switches, anything multiple...bridge filtering is not as potentially useful, since there are multiple bridges involved.


Maybe one you experts can figure out a vxlan solution LOL.
I'm not an expert here. But VXLAN be useful when you actually have multiple routers and ethernet between them. I suppose you could replace all VLANs with VXLANs in the @pcunite examples, but I'm not sure why you'd want to do that.
 
moveik
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 54
Joined: Tue Nov 24, 2020 1:16 am

Re: Firewall rules for VLANs using their interface name

Mon Apr 03, 2023 11:16 pm

Hello friends

Thank you all for your replies.
I've contacted support team and they notified me as follows:
When traffic is forwarded on the same VLAN, it gets forwarded by the bridge, not the routable VLAN interface. Thus your accept IP firewall rule will not match, even with enabled use-ip-firewall under the bridge settings.
and:
matching the VLAN interface is not possible when a packet is L2 forwarded at the bridge level, but you could use in/out bridge ports or source/destination IPs (when use-ip-firewall is enabled).
Only when a packet is routed between VLANs, you can use VLAN interface matching (this does not even require to enable use-ip-firewall).
Thus, the only option is to use bridge filtering for this scenario.
 
moveik
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 54
Joined: Tue Nov 24, 2020 1:16 am

Re: Firewall rules for VLANs using their interface name

Thu Apr 13, 2023 12:04 am

Apparently that wasn't so trivial.
But I finally understand it.
I have read the manual "Packet Flow in RouterOS" (Link) multiple time, every time understood a bit more.

My understanding is as follows:

The Bridge Filter doesn't know the VLAN interface name because that it is an early stage in the packet flow, it is before the Decapsulation phase.
When a packet reaches the "ROUTING DECISION" block, then necessarily it means that Decapsulation has executed, thus the VLAN interface name is available.

After the "Bridging Decision" block, a forwarded packet will go through the Forward chain (due to use-ip-firewall=yes), though this time without the extra information (like VLAN interface) which is available after a "ROUTING DECISION" block.

My solution:

I added an interface list of the "bridge-LAN" bridge ports which are relevant only to the LAN, i.e.:
ether1
ether2
ether3
ether4
Every virtual Wifi interface
The interface list is called "bridge_LAN_ports".

I excluded "ether5" because it is a WAN port.

I added a firewall rule which accepts a packet that complies with the criteria:
in-bridge-port-list=bridge_LAN_ports
out-bridge-port-list=bridge_LAN_ports
The firewall rule is added near the end of the IP Firewall forward chain, right before the rule which drops "ALL ELSE".

Until now, clients are still allowed to communicate in the same VLAN.
So we need to do the "vlan-client-isolation" feature.
I achieved this using Bridge Filter rules, as follows (an example):
/interface bridge filter

# The following VLANs don't have client isolation.
# (Meaning, clients of these VLAN may communicate with each other.)

add \
    chain=forward                \
    action=accept                \
    mac-protocol=vlan            \
    vlan-id=### Insert here the VLAN ID for the LAN VLAN
    comment="VLAN_LAN->self: Accept" \
    log=yes log-prefix="bridge-forward-accept-VLAN_LAN-to-self:"

# ...

# The following VLANs have client isolation.
# (Meaning, clients of these VLAN cannot communicate with each other.)

add \
    chain=forward                \
    action=drop                  \
    mac-protocol=vlan            \
    vlan-id=### Insert here the VLAN ID for the Guest VLAN
    comment="VLAN_GUEST->self: Drop" \
    log=yes log-prefix="bridge-forward-drop-VLAN_GUEST-to-self:"

# ...

The reasoning behind this:

When a packet goes through the "BRIDGING" flow with use-ip-firewall=yes, then "necessarily" the packet will be executed against the IP Firewall forward chain (if "BRIDGING DECISION" decides it needs to be forwarded and the Bridge Filter doesn't block it).
So in that case, the packet must be blocked only in the Bridge Filter (for it to be convenient). The packet cannot be conveniently blocked in IP Firewall because its VLAN interface isn't recognized.
Also, the fact that a packet reached the "BRIDGE FORWARD" block means that it necessarily needs to be forwarded "internally" in the bridge to some other port (it may be the same VLAN or some other VLAN).
So, the IP firewall rule which we added now performs the Accepting (of a packet) based on the bridge's port, which in our case is equivalent to "VLAN-to-self", because this is the only thing that is recognized during bridging.
BUT, when a packet is forwarded to another network, then it will go to "BRIDGE INPUT" and from there to "Decpasulation" which will reveal its VLAN interface name and then to IP Firewall.
Assuming that all packets in the network are VLANed properly, then these packets necessarily will have VLAN Interface name.
So, we could easily filter them using a VLAN interface name - I already had a IP firewall rule which drops packets from *any* VLAN interface to *any* VLAN interface - this provides the protection that a packet won't travel between distinct VLANs (unless specifically allowed).

Bottom line - IP firewall rules are something like this:
# ... <some stuff here>
{Drop a packet that match:
    In interface list = VLAN_Interfaces
    Out interface list = VLAN_Interfaces
}
{Accept a packet that match:
    in-bridge-port-list=bridge_LAN_ports
    out-bridge-port-list=bridge_LAN_ports
}
{Drop ALL ELSE}

And Bridge Filter is something like this:
{Accept a packet with VLAN-ID = <some_VLAN_ID_without_Client_Isolation>}
{Drop a packet with VLAN-ID = <some_VLAN_ID_with_Client_Isolation>}

Please let me know if you notice issues with this.

Who is online

Users browsing this forum: guilly and 26 guests