Issue with VLAN Configuration in a Critical Environment

Hello everyone,

I am trying to create a VLAN using a Mikrotik CCR2004 Router and a CRS326 switch, but I’m unsure about the correct approach given my specific scenario.

I have two public IP addresses: one for the LAN (WiFi, cameras, etc.) and another for the server. I want to completely separate the LAN from the server. Here is the VLAN configuration I’ve set up -( you can see the attached file for both Router and switch)-

Is this setup correct? As you can see, the server network is on VLAN 10, but the LAN network is not; it’s on a bridge. as I know This setup allows routing between the bridge and VLAN 10, correct me if I am wrong.

Could you please advise on a more professional way to isolate the two networks?
switch.rsc (4.22 KB)
mt.rsc (5.46 KB)

There’s no “professional” or “unprofessional” way here, there are just “working” and “non-working” ways :slight_smile:

If I understand your requirements correctly, you want to make sure that devices in “VLAN 99” (subnet 10.99.99.0/24) or “VLAN 1” (subnet 192.168.0.0/24) will not be able to reach the devices in “VLAN 10” (subnet 10.0.0.0/24) in any uncontrolled way and that all the traffic from those devices to internet will only use the .84 addres whereas the traffic of the server will only use the .85 one.

I do mention both VLANs and subnets as that is important. By proper configuration of VLANs (in this particular case, on the switch), you can make sure that even a malicious software on a device that belongs to VLAN 99 but can send and receive VLAN-tagged frames will be unable to talk to devices in VLAN 10 directly, bypassing the router; by proper use of firewall rules on the router you can make sure that the traffic between 10.0.0.0/24 and 10.99.99.0/24 passing through the router will be properly filtered, i.e. that you will be able to selectively permit only some types of connections.

I can see multiple issues in your configurations.

First, both 10.0.0.1/24 and 10.99.99.1/24 are attached to vlan interfaces that in turn are attached to ether9, so traffic from both these IP addresses egresses from ether9 tagged. But on the switch, vlan-filtering is set to no in the bridge configuration, which means that the settings in /interface bridge vlan as well as some parameters on the /interface bridge port rows are ignored, hence no tagging/untagging on ingress/egress takes place; the frames pass through the switch unchanged. If you set vlan-filtering to yes, the settings in /interface bridge vlan will start having effect, and you will lose access to management of the switch via 10.99.99.2 because those settings are incorrect. In order not to lose communication via 10.99.99.2, you have to move the port of the bridge named bridge from the untagged list on the row with vlan-ids=99 to the tagged one before setting vlan-filtering to yes. Other than that, there is no access port to vlan 99 neither on the switch nor on the router, whereas vlan 1 that hosts 192.168.0.0/24 on the switch and has some access ports there is not handled on ether9 of the router, so there is either another cable connecting one of the member ports of the bridge on the router with one of the ethernet ports of the switch with pvid 1 or there is no way how you the router could talk to 192.168.0.2. The former is quite an unusual setup that does not actually improve the isolation as compared to having all 3 VLANs on the same cable between the router and the switch, the latter would be strange. What is the intention? Can you provide a diagram of the actual interconnection (a photo of a handmade drawing is sufficient)?

Second, the firewall filter rules on the router do not block forwarding of any traffic, except incoming connections from the internet. The safest way to build a firewall is to make it drop everything by default and only selectively permit what you intentionally want it to permit; the reverse approach, where you permit everything except what you intentionally want to drop, leaves you at risk that you forget to drop something and leave a security loophole that way.

Third, the purpose of the masquerade action in NAT is to deal with dynamically changing WAN addresses. This means that it chooses the reply-dst-address to use automatically so the to-addresses parameter seems redundant to me. Also, you don’t restrict the effect of either rule in the srcnat chain to any out-interface or out-interface-list, so it affects also traffic from one local network to another. If this is intentional, what is the idea behind that?

Other than that, it’s not a mistake but using mac-vlan the way you do seems like an overkill to me, as you do not make use of it for any VRF handling nor you refer to the interface name in any firewall rules. VRF is an elegant way to isolate groups of networks if you need to isolate them completely; if you need some communication between them, it’s better to use other ways to control the isolation.

Hey sindy..! hope you are very well..

First, both 10.0.0.1/24 and 10.99.99.1/24 are attached to vlan interfaces that in turn are attached to ether9, so traffic from both these IP addresses egresses from ether9 tagged. But on the switch, vlan-filtering is set to no in the bridge configuration, which means that the settings in /interface bridge vlan as well as some parameters on the /interface bridge port rows are ignored, hence no tagging/untagging on ingress/egress takes place;
yes I am a ware of this issue

[]for this statement[]
The former is quite an unusual setup that does not actually improve the isolation as compared to having all 3 VLANs on the same cable between the router and the switch, the latter would be strange. What is the intention? Can you provide a diagram of the actual interconnection (a photo of a handmade drawing is sufficient)?
there is a connection between the router and switch but it is just a normal connection not trunk or any other thing, that’s why.

[]for this[]
the firewall filter rules on the router do not block forwarding of any traffic, except incoming connections from the internet. The safest way to build a firewall is to make it drop everything by default and only selectively permit what you intentionally want it to permit; the reverse approach, where you permit everything except what you intentionally want to drop, leaves you at risk that you forget to drop something and leave a security loophole that way.
actually I am using the default firewall rules of the router so incase any attack happen I will blame Mikrotik.
[]for this[]
Third, the purpose of the masquerade action in NAT is to deal with dynamically changing WAN addresses. This means that it chooses the reply-dst-address to use automatically so the to-addresses parameter seems redundant to me. Also, you don’t restrict the effect of either rule in the srcnat chain to any out-interface or out-interface-list, so it affects also traffic from one local network to another. If this is intentional, what is the idea behind that?
it just a Temporally setting I will changed after I apply the VLANs.

The Idea that I am very ware a bout it is to make sure that vlan10 is separated from bridge1 = 192.168.0.1/24 that represent the wifi network.
I applied alot of VLAN Scenario but like this case I didn’t. previously I used to create two VLAN one for wifi for example and the other for server. what is the different here is the CCR2004 has it own ports that belong to the 192.168.0.1/24 and I want to dedecated one of this port -(that doesn’t belong to this bridge1)- as a trunk with the switch. and the question is does this trunk that carry the VLAN traffic will be separated from the bridge1..?

Since we seem to misunderstand each other a lot, I’ll start from responding this last question. Using a dedicated Ethernet port, which is not part of the bridge, for vlans 10 and 99 will indeed separate these two VLANs from VLAN 1 on the bridge on the router on L2 level, but I cannot see any advantage in doing so as the three subnets that “live” in those VLANs are not isolated at L3 level.

Why do you create a difficult situation for yourself??
One bridge all vlans → step1 complete all subnets are separated at Layer2

Firewall filter forward chain
default rules except for removing the default DSTNAT and WAN rule and replacing with
allow lan interface list access to wan interface list
allow port forwarding connection-nat-state=dstnat
add action=drop chain=forward comment=“drop all else”

Traffic between vlans is now blocked between layer3

Just assign /interface bridge ports and /interface bridge vlans correctly

**but I cannot see any advantage in doing so as the three subnets that “live” in those VLANs are not isolated at L3 level.**yes exactly that what I am looking for, how can I isolate those VLANs at L3 level?
if you have any suggestion I am ready to listen, I don’t say that I want to apply my scenario just give me a recommendation, on what I can do in such situation.
as I said the idea is to separate wifi from the server giving my situation.
by the way there is no VLAN1 just bridge with its ports and VLAN10 & VLAN99 on the ether9

Hey anav ..Thank you for your reply.
step1 complete all subnets are separated at Layer2
I didn’t really catch what you meant by this phrase, Could you please clarify more?

At L3 level, there are no VLANs (in the traditional sense, leaving MAC-VLAN aside), only subnets. By default, any router routes traffic between all subnets inside which it has its own addresses. The fact that VLAN 1 on the switch is physically accessible via bridge on the router whereas VLANs 10 and 99 on the switch are physically accessible via ether9 on the router changes nothing about that.

To prevent packets from one subnet from reaching another subnet, you have to use a firewall filter like both me and @anav have suggested. The IP (and IPv6) firewall only handles traffic being routed from one subnet to another. To become visible for the IP stack, an IP packet that came in inside a VLAN-tagged frame must first get untagged, which is what /interface vlan does. So the IP firewall cannot match on VLAN IDs directly, but it can match on names on /interface vlan, which are L3 interfaces from the perspective of the IP stack.

Or, if you want an “automatic” isolation of subnets, which is not prone to mistakes in firewall configuration, you have to partition the router into multiple virtual routers using the VRF functionality. So you would place one group of LAN interfaces and ether1 into one VRF, and the other group of LAN interfaces and the mac-vlan interface attached to ether1 into another VRF. In this case, the traffic would be unable to leak between the VRFs on L3 level even without any IP firewall rules.


This may be a sufficient understanding when talking about the router itself in your particular configuration, but as soon as you include the switch into your thinking, VLAN 1 pops up in the network. If vlan-filtering is set to no on the bridge on the switch, no VLANs exist for the bridge, not even 10 and 99, as it just forwards the all the frames it receives, tagged or tagless, based on destination MAC address alone. As soon as you set vlan-filtering to yes, it starts taking the VLAN tags into account, but also to add and strip them according to the pvid settings and /interface bridge vlan settings. So tagless frames that come from the router get tagged with a VLAN tag with VID 1 as they enter the bridge, and get untagged again as they leave the bridge via its member port also named bridge towards the interface of the IP stack of the switch, which is also named bridge. See this for clarification why 3 distinct objects share the same name.

With vlan-filtering is set to no, no isolation of VLANs exists on the switch, as any device connected to the switch has access to all of them if it can tag&untag frames.


After some thinking, I stand corrected here. A professional would never use a non-standard approach where a standard one gives equal results, as it costs time both to develop the non-standard one and to understand it again whenever you return to the network for maintenance.

1 Like

Your dealing with routers in critical environments and do not know what layer2 entails…
Good luck with your bizarre alternative approach to simple one bridge multi-vlan setups.

If you want assistance, read this first…

Then perhaps the advice above for a secure clear approach will make sense.

Thank you so much My friend sindy

also thank you so much anav.