Using RouterOS to VLAN your network

pcunite · Sat Jan 05, 2019 1:02 am

Title:
Using RouterOS to VLAN your network

Welcome:
This article is for system integrators, network administrators, and product enthusiasts looking for the definitive guide on how to design and setup VLAN networks using MikroTik. Follow along the light reading material and diagrams that make learning about VLAN an enjoyable topic. See the theory and then deep dive into the actual commands to implement it all. We'll discuss Access, Trunk and Hybrid ports, switching and routing, and guest access into our networks.

Why VLAN?
If you have a need to partition and isolate networks and devices from each other using the same physical hardware, you maybe a good candidate for VLAN. If you have IoT devices, IP cameras, guests who need to use your WiFi, and a need to QoS who gets what, VLAN can make your network simpler to reason about. In micro-sized networks, it is possible to use other methods besides VLAN, but VLAN is never a wrong choice. This should give you the confidence to learn the VLAN concept knowing it will scale as your network and the number of devices grow.

VLAN Types:
Sometimes you see other terms alongside VLAN, such as Port Based VLAN, MAC Based VLAN, Native VLAN, and Voice VLAN. Some of these are really just names for what all is really the same thing. Maybe they use a different approach (automated vs manual) to get there, but ultimately, network devices are segmented. This document will focus on a manual Tag Based VLAN approach. Dynamic VLAN assignment using Radius examples can come if we have knowledgeable feedback in those areas.

VLAN Examples:
I focus on the most commonly requested scenarios: switch with separate router, WiFi router combo, guest WiFi, and public VLAN and printers. Basically hardware and scenarios that mirror MikroTik’s product lineup. From these examples you’ll be able to create any custom configuration on your own. Security topics are covered later under a separate section.

VLAN Terminology Overview:
Before discussing the various examples, we need to establish some common terminology and concepts about VLAN. In Tag Based VLAN, you'll be working with Access and Trunk ports, configuring IP Addressing & Routing, and setting up IP Services on VLAN interfaces. These elements combine to create a managed VLAN network. This virtual network can be as big or as little as you like. You'll be thinking about what to allow and what to block. Read each of these VLAN concepts below before using our configuration examples to understand how we use them on the command line.

Access Ports:
These ports define the entry into your VLAN. They represent groups of devices that need access to each other but not other networks. You will group them by ID. In this documentation we use colors like Blue, Green, and Red to help us to visualize the ID numbers. Access ports are configured in a way that means ingress (incoming) packets must not have tags and thus will get a tag applied. The egress (outgoing) packets (that are replying back to whatever was plugged in) get tags removed.

Trunk Ports:
These ports are what carry everything you care about between VLANs. If Access ports represent groups of things, think of Trunk ports as what enables these groups to get to places they need to go, like other areas of the switch or network. Trunk ports are configured such that ingress packets must have tags and egress packets will have tags.

Hybrid Ports:
These ports are for special situations and requirements. They share qualities and behaviors of Access and Trunk ports. Basically, they function as an Access port for ingress traffic without tags. When incoming traffic is tagged, and the tag is on the allowed list, it will then function as a Trunk port.

When designing your VLAN, you'll have reached your first step when you can logically think about Access port grouping and Trunk port interconnections. How many VLANs and devices will you need to work with? Who gets access to what? Don't rush this step. Take time to diagram your VLAN.

Native, Base, & MGMT (management) VLAN:
As you create your VLANs and pick VLAN IDs for each one, understand that the base network that you used to initiate your first connection to a router or switch is often termed the Native VLAN. In our examples, we do not use this default network. Instead we implement a Base VLAN (our name for the management VLAN) with an ID of 99. Over this network will be device to device traffic (routing, etc.). We also default Winbox availability here as well.

A word of caution if you are thinking of using VLAN 1 in your network design. Most vendors use VLAN 1 as the native VLAN for their hardware. MikroTik uses VLAN 0. If you try to create a VLAN 1 scenario with MikroTik, and expecting tagged frames, it will be incompatible with other vendors who default VLAN 1 as untagged. Therefore, unless you are prepared to change the default behavior in MikroTik and/or other vendors, it is simpler to use VLAN 2 and higher.

IP Addressing & Routing:
Since every VLAN you create should have a different IP Addressing scheme, you'll use something different for each VLAN. If you set the Base VLAN to 192.168.0.x, your Blue VLAN might be 10.0.10.x, Green is 10.0.20.x, and Red set to 10.0.30.x. Just make sure that all VLANs are unique.

With an IP addressing scheme in mind, you'll set your core equipment with manual assignments. So, a router might be set to 192.168.0.1, a core switch 192.168.0.2, a WiFi AP 192.168.0.3, and so on. The router can now become the default gateway routing your VLAN, switches, and connected devices. Using IP Services, you will make information available in an automated way.

IP Services:
The most well known is probably DHCP. Generally, every VLAN has its own DHCP server ensuring devices know about gateways and DNS servers they should use. When everything in the VLAN has an IP address, they'll talk to each other over the ethernet protocol making broadcasts and generating other network traffic between each other.

When you have more than one VLAN, you have a truly segmented set of networks. If you plug a PC into a Blue VLAN, it can see and communicate only with other devices on Blue but not anything on Green or Red. If a printer is plugged into Green VLAN, only devices on the Green network could access it. You can share resources across VLANs while still not allowing interVLAN access. Just one of the benefits you'll be reading about in this document.

Disclaimer:
What follows is my best understanding of how to implement the stated goals in RouterOS v6.43.12 based on the documentation available. Feedback from MikroTik as well as fellow forum members is required to make this an accurate document. Please suggest changes that should be made. Let's make this issue a commonly understood one. Thank you.

pcunite · Sat Jan 05, 2019 1:02 am

Switch with a separate router (RoaS)

Overview:
This is the most recommended configuration for a business and forms the basis for all other examples. Everything lives on a switch until it needs to access the Internet or another specific VLAN or network resource. When that happens, a router (RoaS) will facilitate those requests. Otherwise, only devices on the same VLAN can communicate with each other.

Switch Configuration at a glance:

Access Ports:
Here we segment the network across three different VLANs. Blue is VLAN 10, Green is VLAN 20, and Red is VLAN 30. All of these will be configured as Access ports. These are ports in which end users may have physical access.

Trunk Ports:
In this switch example, we show purple fiber sfp inputs as being Trunk ports. Use ethernet interfaces if you prefer. We also show two ports to illustrate a switch linking itself to a router on sfp1 and another switch on sfp2. Use the number and combination you need. In the real world, most enterprises will have traffic coming into a switch, interacting with devices there, and then replying back out the same port or going out another port to hit additional networks. Imagine a Blue network spread across three physical switches and you get the idea.

Hybrid Ports:
These types of ports are shown in a separate configuration file linked below because their behavior and descriptions have not been illustrated in the diagrams. Here we change Blue VLAN ports Hybrid by setting a Green egress behavior on them. When traffic does not have a tag, it will be placed on the Blue VLAN. If arriving packets do have tags, and the VLAN ID is Green, those packets are allowed to ingress, placed on the Green VLAN, and the correct egress behavior is honored for both types of packets. If any other VLAD ID tries to ingress, it will be dropped.

IP Addressing & Routing:
While it is possible with RouterOS to do everything on the switch, that is not something you would truly do in practice unless you never want anything to leave the switch (full hardware isolation). Our example will show the router handling the creation and management of IP Services instead of the switch. First, we need to setup the switch's IP address.

Switch IP Address:
Before the router can serve IP Services on the different VLANs, the switch and router should be on their own VLAN, which we call the Base VLAN. Others might term it the Management VLAN. The router's IP address will be 192.168.0.1, so we’ll make our switch 192.168.0.2. Set the switch's default route (gateway) to be the router, and anything else you might want, like NTP, DNS, etc.

Router Configuration at a glance:

IP Services:
With the switch complete, time to setup the router to provide IP Services. On the router we create three different IP Service interfaces: Blue, Green, and Red. Each one of these correspond to the VLANs it will be serving. For each one of these service groups, we turn on at least one item, a DHCP server. You can add or point to more as necessary.

Now, when we connect the Purple Trunk port on the router to the Purple Trunk port on the switch, anything following Ethernet protocol begins to function.

How it all works:
A PC plugged into the Blue VLAN starts broadcasting for a DHCP address. The switch keeps this from all other VLANs. The incoming packets from this PC get tagged with a Blue ID, and since the Purple Trunk port can pass Blue, it sends the packet out that port which goes to the router. The router's Purple Trunk port sees a Blue DHCP request and allows a Blue DHCP server, running on a configured Blue VLAN interface, to respond to the request, sending the packet back out its Trunk port.

Meanwhile, a PC plugged into the Red VLAN tries to ping a Blue VLAN device. The ping reply goes out the switch's Purple Trunk port to the router's Purple Trunk port. The router would have sent the reply on to the Blue VLAN device except that a firewall rule drops interVLAN access.

Switch Config File:

switch.rsc

Switch with Hybrid Ports:

switch_hybrid.rsc

Router Config File:

router.rsc

pcunite · Sat Jan 05, 2019 1:03 am

Router-Switch-AP (all in one)

Overview:
This is a configuration for a home or even a micro business. Everything lives on a single hardware unit with PCs, laptops, NAS servers, printers, and phones all on the Blue VLAN. The Blue network is considered the home LAN making use of local ethernet ports and a home SSID. When friends come over, you give them a Guest SSID to keep them off your network.

Unit Configuration at a glance:

Access Ports:
Since most ports are on the Blue VLAN, you trust your PC, laptop, NAS, and printer to live there together. All your IoT devices are probably on a separate simple switch connected to Green via the one local ethernet port or WiFi. You can create as many VLANs on WiFi as you need, although three is probably a good limit to minimize WiFi inefficiency.

Trunk Ports:
There are no Purple Trunk ports. The Green VLAN is our other network. Whatever is plugged into the Green ethernet port may or may not be VLAN aware. However, it does not really matter. Once it hits our router/switch, its Green to us. Create more VLAN interfaces if you need more organization.

IP Addressing & Routing:
There is only one hardware device, of which we create one bridge to manage all LAN side devices. We set this IP address to 192.168.0.1. Everything gets routed out the Yellow WAN interface for Internet access.

IP Services:
The Blue interface supplies the home network with the services it needs. A Green VLAN interface supplies the Guest network with Green IP Services.

How it all works:
Firewall rules keep everyone separate.

Config File:

RouterSwitchAP.rsc

pcunite · Sat Jan 05, 2019 1:04 am

Access Point

Overview:
In the business environment and increasingly in homes, multiple wifi Access Points are used to provide coverage over wide areas and between building floors. Today, these devices are the network. So, learning how to control them and limit the physical areas they cover is of upmost importance. In this document, we only focus on implementing VLAN techniques across them.

Unit Configuration at a glance:

Access Ports:
Do these have Access ports? Yes, the invisible kind! Think of each SSID as playing the same role as an ethernet port would. In our example we show three: Blue, Green, and Red. Blue is for clients that will be accessing the corporate (or home) network, Green could be for guests, and Red would be for things you really want to limit, maybe not even allow them Internet access.

Trunk Ports:
There should always be at least one Purple Trunk per AP connecting back to another Purple Trunk on a switch or router. Our AP will have very minimal configuration, instead the connected clients will be managed by upstream hardware. To us, these hockey pucks are radios and that's about all.

IP Addressing & Routing:
There is only one bridge managing all the configured VLANs. We set the Base VLAN's IP address to 192.168.0.3 and the default gateway to our router. If you have very many APs you'll want to use an Access Point Manager. For now, we hard code in the SSID names and passwords. VLAN ids are assigned to each WiFi interface.

IP Services:
IP Services are managed by our example router. The Purple Trunk port places us on the same network as other devices entering the router. VLAN interfaces running there respond to the ethernet protocol.

How it all works:
Firewall rules keep everyone separate.

AP Config File:

AccessPoint.rsc

pcunite · Sat Jan 05, 2019 1:07 am

Public VLAN, Printer & Server

Overview:
After configuring VLAN for your network, traffic is neatly categorized and segmented. However, you may develop a need for a LAN side resource to be accessible by some or all VLANs. This could be a group of printers or servers. You can make this as granular as you would like it to be. Here we illustrate the idea of simply using the Red VLAN for this purpose and then using interVLAN routing to allow access to this Public VLAN of shared resources.

We will use the router and switch from our first example. Only very small changes to the Firewall section allow for what we need.

Router Configuration at a glance:

How it all works:
Firewall rules allow visibility for entire VLANs or resources within a VLAN. Customize to suit your needs.

Firewall Customizations:

FirewallCustom.rsc

pcunite · Sat Jan 05, 2019 1:08 am

Security

Overview
To properly configure VLAN networks, or any form of a network, we must think about packet identity, direction, flow, permissions, and utilization. Deep diving into these concepts may make you feel like you're learning more than you ever thought you needed to. Depending on the amount of value your network has to you, you only need to learn up to that level.

Security Utopia
There is no such thing as perfect security. The best security uses reporting and notifications alongside virtual and physical barriers. A steel door and a glass window each have something in common. Both can be broken into! However, if you have certain features in place, you can rewind to see what happened before and after an intrusion, maybe even respond in real time if you have the infrastructure.

This document, while highlighting a security utopia, does not actually implement it all for you. Instead we offer concepts you will need to research and think about. It is up to you to implement them in your environment. Understand that switching, routing, and security is not about controlling people. Rather, its about protecting and ensuring uptime across the section of digital highway you maintain. Make it a good experience and usable by everyone you're responsible for. Be a good steward. That is the goal of this document and the purpose behind why we maintain networks.

VLAN Concerns
Access ports do not have physical security because end users need to manually plug things into them. Thus they should always be untrusted. They will also be the source of packets coming from an intruder in your network who may have found a way to have the same credentials as a staff member. As a network manager, it is probably not your concern to stop credential theft. Instead, be aware and plan for when a staff id does go rogue. There are also several other Layer 2 related security behaviors you need to know about because they will be coming in through these ports. On Access ports, always drop ingress packets that do have tags.

Trunk ports require physical security. Do not place switch hardware, or network Trunk drops anywhere near the public. Do not run switch-to-switch network cabling in easy to get to areas. Otherwise, the cable can be cut and spliced into and if the packet streams are not encrypted, then its game over. You could detect the downtime but then must be capable of locating the tap. Do not utilize automated Trunk port configuration, without also notifying yourself when such events occur. On Trunk ports, always drop ingress packets that do not have tags.

Hybrid ports are merely Access ports with all the same security challenges. They are a consideration for scenarios where you have limited network drops and still want assumed control over traffic type and behavior. They are most commonly used when a PC is connected to a mini-switch located in a VoIP phone. The phone is then connected to an Access port with Hybrid behavior. The phone marks its packets with a specific VLAN ID while the PC sends untagged packets. A Hybrid port therefore passes packets without a tag and also packets with this known VLAN ID. Always drop all other tags. The allowed VLAN ID tag should not have security permissions or too much priority over the untagged traffic occurring in the area.

Document
Take time to understand and document the types of VLAN interfaces you are managing. You should always have at least one VLAN per department, or per building, or even per floor, even if you don't plan to segment the traffic. This is a personal decision you will make to be as granular as you need to be. Just don't lump everything together. Otherwise, you won't be able to QoS, secure, document, and prepare for needed downtime and upgrades.

More VLANs, along with good descriptions, can make everything easier to reason about. You probably allow every VLAN to access the Internet. That's fine. But what about when Building 2, floor 3 has a virus outbreak sending all your data encrypted over port 80 to who knows where? You get the call, "shutdown access to that floor!". How will you do that? If you've read this document, it will be easy. You could even hand them a report of the total packet count reassuring them that the breach was only 1TB in size and from which department.

Routing Concerns
Firewalling will happen at the Router, so you'll be thinking about three main areas: WAN, LAN, and VLAN and their interactions. Treat LAN as a concept different from VLAN because VLAN can be something coming in from the WAN side of things (VPN, etc). From these three areas you can have at least eight major packet flow combinations. This will only balloon as you get more granular about things.

Keeping the WAN out is a fairly well understood concept. Making sure that the LAN has limited access to different resources, however, can be a daunting task.

pcunite · Sat Jan 05, 2019 1:10 am

Reserved

mkx · Sat Jan 05, 2019 2:26 pm

Nice start.

You might want to mention in "Native VLAN" that it's not required to have one. My personal view (but that's subjective and not everybody agrees) is that it's actually bad thing to have it when diving into sea of VLAN, it messes the otherwise clean configuration flow (i.e. you have all the L3 configuration neatly packed on corresponding vlan interfaces but not for the "native" VLAN). The same goes to pvid set on bridge (which makes some people believe that that VLAN passes untagged over bridge; my view is that it's not, rather that setting pvid on bridge "interface" is synonimous to setting pvid on e.g. ether interface so that "outside" part of bridge interface is untaged while "inside" part is tagged which makes it similar to creating vlan interface on bridge and using that one instead). Understanding that bridge is actually two personnalities (a sort of switch and interface) helps to picture things in a cleaner way.

In short: even though some things can be done in ROS, try to omit them from examples (do mention them in text if needed but note that same things can be done in other, cleaner, way) and keep tutorial compact and simple.

Another remark: when talking about router and it's WAN address ... it sounds as if WAN address is something holy and should be kept away from other physical infrastructure at all cost. Actually that's not the case, it can easily be configured as yet another VLAN. Even more, there are use cases (such as IPTV service delivered via separate VLAN) which requires this approach. Even if it's not the case, sometimes it's still benefitial to treat WAN as yet another VLAN to carry it from physical point of presence (could be LTE modem on rooftop) to router itself (might be in basement) without need for separate physical connections.

pcunite · Sat Jan 05, 2019 3:52 pm

Nice start ... keep tutorial compact and simple ...

Excellent points in your post, I will really enjoy your feedback. Allow me to finish up what I've got, and then we can edit that down. Will take me a few weeks. I'm hoping that we crowdsource this and it makes it into the Wiki. There are a stream of VLAN and configuration questions here and it all boils down to this: the documentation needs to be better. My goal is to walk through concepts, so that people have a mental model, and then show the commands so that pvid (whatever that is!) can actually mean something.

I admit that I will miss the mark too. I like your idea about all VLAN all the way, it's cleaner. I think people are nervous to commit to it. I won't get there on my first try. I'm trying to think about people new to networking, but maybe MikroTik's clientele are an advanced group anyway?

There is real trepidation to go VLAN. Hopefully, if I make it seem simple enough, it won't be so off putting. VLAN is the only way with IoT coming in like a freight train.

sindy · Sun Jan 06, 2019 12:50 pm

Sugar first: conceptually, I like the approach you use in this topic much more than the one used in your QoS one. This one concentrates on how things work rather than on a complete configuration for a single particular target scenario. The QoS one provides a ready-made working solution, however so complex that people just copy-paste it and then wonder why it doesn't work in their scenario for which it is not appropriate. Worse than that, it lacks the basics which seem obvious but the questions on the forum show that they are not to everyone.

The product manuals (not only the Mikrotik ones) rarely explain the very basics, they concentrate on the particular implementation of these basics in the product and how to use it. This approach makes a lot of sense for seasoned professionals who don't need to read the same stuff over and over, but they are only a part of the audience - for many people Mikrotik is their first network infrastructure device ever. And for those people, a link to a tutorial on "underlying basics" would be a great help while the professionals would just not click on it and continue reading the main topic.

So again, what I appreciate most on this topic is the explanation of the basics. Once one understands them, the Mikrotik's official manual is enough to set up what you need, but without the understanding, it is like a cooking recipe telling you how much of white powders A, B, and C to use without telling you which one provides which taste. If you follow the recipe exactly, the result is the same as the author's one, but if you want it to be more sweet, you can't find out in the recipe which of the powders to add more of. And whilst try-and-error approach is easy with cooking because all you need to verify the result is your taste, with VLANs you need to use sniffing and Wireshark and, first of all, you need to know what you are looking for and understand what you see in the capture.

Now some criticism: I'm confused by your mentioning of "port-based VLAN" and "trunk port" in the same sentence. What I've understood till now was that the term "port-based VLAN" means no more and no less than that all ports of the same device are split into several groups and traffic forwarding is permitted only between ports in the same group, and that this is achieved using some other means than tagging frames with VLAN ID, which implies that trunk ports cannot exist in such scheme because no tags are available on the frames themselves to distinguish those belonging to different VLANs from each other. Internally, some switch chips do use tags also to implement port-based VLANs, but these tags carry the ID of the ingress port, not an ID of the VLAN. And the ingress port ID is only meaningful inside the switch itself, so there is no point in handing it over to another switch as it would be meaningless there (unless you'd add the ID of the source switch as well but it would be an implementation and management nightmare).

So with port-based VLAN, all ports can be just access ports, each to its own VLAN, and that is it. Once you start using some kind of tags carrying a VLAN ID consciously, in my understanding it is not a port-based approach any more, although from the outside perspective the behaviour of the device may be the same if you use only access ports along with VLAN ID tagging.

pcunite · Mon Jan 07, 2019 12:05 am

... Now some criticism: I'm confused by your mentioning of "port-based VLAN" and "trunk port" in the same sentence ...

So with port-based VLAN, all ports can be just access ports, each to its own VLAN, and that is it. Once you start using some kind of tags carrying a VLAN ID consciously, in my understanding it is not a port-based approach any more.

You are correct. I have changed it to be Tag Based VLAN (802.1Q) which is the technically correct term for what is being discussed.

Chupaka · Tue Jan 08, 2019 10:22 am

Allow me to finish up what I've got, and then we can edit that down. Will take me a few weeks.

So, it's too early to make this topic sticky?

Impressive start, btw

Dude2048 · Wed Feb 06, 2019 6:32 pm

Great work. Normis, make this topic sticky..

anav · Thu Feb 07, 2019 5:51 pm

Hi pcunite. two questions.
First example, first diagram configs

(1) why are you separating out the different vlans, when there is no value added (or so it seems to me).
For example, add bridge=B1 tagged=sfp1,sfp2 vlan-ids=10,20,30 should suffice!
Similarly, add bridge=B1 tagged=ether2,ether3,ether4,ether5,ether6,ether7,sfp1 vlan-ids=10,20,30
Since there are no differences between the exact number and identification (exact replica) of tagged ports, I fail to see the need to separate the vlans out.

(2) why have you shown the PVID=1 settings. Are they not by default assumed to be PVID1 without any entry??

mozerd · Fri Feb 08, 2019 6:41 pm

@pcunite
very NICE [excellent] work

Not sure if the following is a typo or otherwise

the rsc file called switch one comment line has:

Because weird, we "also" add the Bridge

So do you mean wired or actually weird

pcunite · Fri Feb 08, 2019 7:00 pm

So do you mean wired or actually weird

Thank you, no I actually mean weird (using because noun phrasing) because I find it confusing to have bridge access set this way at this point in the syntax. The stated reasons, explain why, but I feel that port vs bridge (the bridge is a virtual switch or container for your ports) should be separate concepts. When setting up individual ports, why have this ungainly bridge thingy thrown in? Nevertheless, without understand this, unexpected behavior is the result. So, we have to document it.

I also feel like that when vlan-filtering=yes is set, it should enforce common understanding of what Access and Trunk ports do (drop any and all packets that don't comply, why in the world would you not?). I can understand the wiki's author's frustration as they try to explain securing the VLAN. I think MikroTik can get it correct and I think we should encourage them to do so. For those that need unsecured VLANs, by all means, have an option for that. The rest of us want Access & Trunk port to behave securely and not require other options. Secure should be the default.

I think my config file comments should probably be rewritten to be more clear:
Because weird, we "also" add the Bridge itself as a tagged member! This is required to control which packets get access to the Bridge itself.

mkx · Fri Feb 08, 2019 8:05 pm

OT: funny but in preceeding post by @pcunite I can only see first paragraph of his post (ending with "So we have to document it."). If I start writing a reply (quoting his post or not,) I can see two more paragraphs.

[edit] After I posted this rant, I can see the whole previous post. This is a sinister business, Watson...

I fully agree that having bridge implicitly act as a port is weird indeed. And causes lots of mis-understandings. Including the dilemma about including bridge a tagged member of itself? Probably most of misunderstandings would be gone if there was a special pseudo-interface (even implicitly created for every bridge) that would actually act as interface. In addition to that, stand-alone versions of the very same type of interface would come handy as loop-back device ... now one has to abuse a bridge for this functionality.

I'll take this opportunity to open a discussion about how to deal with wifi "access ports" to vlans.
There are two ways:

I guess the old (legacy) way is to configure
Code: Select all
```
/interface wireless set [ find name=wlan1 ] vlan-mode=use-tag vlan-id=BLUE
```
and configure wlan1 interface as tagged member port of bridge
probably the new way where we don't fuss about VLAN in /interface wireless, only deal with it in /interface bridge subtree where wlan1 interface is configured as access port to a VLAN

So what is the better (more understandable/readable) way to configure it? My guess is that way 2. is better as it keeps VLAN config in single config subtree ... but what do other forum members think about this?

pcunite · Fri Feb 08, 2019 8:34 pm

I'll take this opportunity to open a discussion about how to deal with wifi "access ports" to vlans. There are two ways:

vlan-mode=use-tag vlan-id=BLUE

interface bridge subtree where wlan1 interface is an access port to a VLAN

So what is the better (more understandable/readable) way to configure it? My guess is that way 2 is better as it keeps VLAN config in single config subtree ... but what do other forum members think about this?

I'll have a stronger opinion on this when I go to implement it. Off the top, vlan-mode=use-tag is like free candy, which can only mean its bad for you. Not sure yet. Whatever the case, don't let me be weak!

pcunite · Fri Feb 08, 2019 8:36 pm

Hi pcunite. Two questions:

@anav,
I have updated the configuration files. Please reexamine, and then ask your question again. Then, I'll give you a formal response. Yesterday evening, I had the opportunity to actually implement the config files on real hardware and made some adjustments.

Question 1:
Responding to what you have written, for now I will say that, one reason why I break out commands is to show, conceptually speaking, what is happening. When designing VLANs, the administrator has to think about how Access ports will interact with Trunk Ports, and how all that will eventually work over L3. Naturally, when someone is familiar with the MikroTik command line, they can combine several settings into one liners. But that is confusing when trying to learn it for the first time.

Question 2:
I think MikroTik's current API is not expressive enough for what is happening. There are times when you must specify PVID, so I feel, personal opinion, that as I'm trying to illustrate the VLAN concept, that the reader understands better by doing it this way. With PVID=1, it is explicitly being shown that a Trunk port is being created.

mkx · Fri Feb 08, 2019 9:15 pm

Off the top, vlan-mode=use-tag is like free candy, which can only mean its bad for you. Not sure yet. Whatever the case, don't let me be weak!

I don't see vlan-mode=use-tag as candy, it used to be the only way back in ROS<=6.40 ... as was the switch-chip VLAN stuff.

But you're right ... you've been bad to @anav so no vlan-mode=use-tag for you tonight

mkx · Fri Feb 08, 2019 9:21 pm

Question 1:
Responding to what you have written, for now I will say that, one reason why I break out commands is to show, conceptually speaking, what is happening. When designing VLANs, the administrator has to think about how Access ports will interact with Trunk Ports, and how all that will eventually work over L3. Naturally, when someone is familiar with the MikroTik command line, they can combine several settings into one liners. But that is confusing when trying to learn it for the first time.

I'm with you on this one. Let's leave taking shortcuts to experienced and adventureous users and keep newbies straight on the right path ...

anav · Fri Feb 08, 2019 10:10 pm

Hi pcunite. Two questions:

@anav,
I have updated the configuration files. Please reexamine, and then ask your question again. Then, I'll give you a formal response. Yesterday evening, I had the opportunity to actually implement the config files on real hardware and made some adjustments.

Question 1:
Responding to what you have written, for now I will say that, one reason why I break out commands is to show, conceptually speaking, what is happening. When designing VLANs, the administrator has to think about how Access ports will interact with Trunk Ports, and how all that will eventually work over L3. Naturally, when someone is familiar with the MikroTik command line, they can combine several settings into one liners. But that is confusing when trying to learn it for the first time.

Question 2:
I think MikroTik's current API is not expressive enough for what is happening. There are times when you must specify PVID, so I feel, personal opinion, that as I'm trying to illustrate the VLAN concept, that the reader understands better by doing it this way. With PVID=1, it is explicitly being shown that a Trunk port is being created.

Thanks for the response, and I fully 1000% support this educational reference.
(1) For the first type of item.......... Add text............

# Blue VLAN
set bridge=BR1 tagged=BR1,sfp1,sfp2 [find vlan-ids=10]
# Green VLAN
set bridge=BR1 tagged=BR1,sfp1,sfp2 [find vlan-ids=20]
# Red VLAN
set bridge=BR1 tagged=BR1,sfp1,sfp2 [find vlan-ids=30]

The above rules for both Access and Trunk ports illustrates the important concept of ensuring /interface bridge vlans are correctly separated by vlanIDs.
Due to the fact that in the case above (the trunk one) there is identical (no difference) tagging and untagging of bridge/ports, the rules can be combined.
/ip interface bridge vlan
bridge=BR1 tagged=BR1,sfp1,sfp2 vlan-ids=10,20,30

(2) Point taken, and concur that after thinking about it, the default PVID shows up so its not as if the person will have to actually assign it.
However I would still add a note somewhere that states.
The PVID entry of one (1) is the default entry and normally does not need entry or modification unless one is assigning an access port.
(which will tie together both the trunk and previous access port assignments examples.

(3) (a) New points, Why do we not want pvid=xx ingressfiltering=yes
From discussions with MKX, there is nothing wrong security wise with assigning ingressfiltering=yes for access ports?
However, if using it we should state exactly what function ingress filtering has when used......... What does invoking it provide in functional terms.

(b) Why do we not want pvid=xx admit frame types=
From discussions with MKX, there is nothing wrong security wise with assigning frame types for access ports?
However, if using it we should state exactly what function frame types afffects when used......... What does invoking it provide in functional terms.

(4) New Point: Firewall rules........ I understand there is a million ways to put in rules so can we use and clearly state the premise of.......
Only allow permitted traffic
Drop all ese
OR
Permit ALL
Drop unwanted traffic.

I prefer the former and I think that is where you are headed since you do have drop all else rules.
By the way order is important needs more emphasis. Order is critical!
Finally, I like your use of VLAN list member!

As for rules
# input
add chain=input action=accept in-interface-list=LAN comment="Allow Native LAN" DISAGREE
add chain=input action=accept in-interface-list=LAN source-address=IP (specific, range, subnet ) comment="Allow admin access to router"
There is no reason on gods green earth to let everyone on the LAN or (VLAN for that matter) have access to the router.
Remember the premise at the top.............

# Optional: Allow LANS and/or VLANs to access router services like DNS. Naturally, you could make it more or less granular depending upon ones needs.
add chain=input action=accept in-interface-list=VLAN/LAN dst-port=xx protocol=xx comment="Allow VLAN/LAN to Particular Service"

# forward
add chain=forward action=accept connection-state=established,related comment="Allow Estab & Related"
add chain=forward action=accept connection-state=new in-interface-list=LAN comment="Allow Native LAN"
I have no idea what your are doing with this rule and thus am very confused. In fact I cannot say I have seen new in very many configs at all.........

# Optional: Disallow only the Red VLAN from Internet access:
# add chain=forward action=drop in-interface=RED_VLAN out-interface-list=WAN comment="Drop Red from Internet"
NO NO NO NO...............remember the premise. ITS NOT ALLOWED BY DEFAULT..........\
WE ONLY NEED TO WORRY ABOUT WHAT WE WISH TO ALLOW

# Optional: Allow all VLANs to access each other and the Internet: I would remove the internet part and not combine too many factors, and better matches your comment line anyway.
#add chain=forward action=accept connection-state=new in-interface-list=VLAN comment="VLAN inter-VLAN routing"
out-interface-list=VLAN
YES YES YES, much better but from where to where.... missing the other half, so thats what I added in blue

BUT WHY are you using NEW???? arggg your killing me with this new stuff.

# Allow VLAN access to Internet only, not each other: Remove text, we are making rules that only are concerned with what we want to allow!!!
add chain=forward action=accept connection-state=new in-interface-list=VLAN out-interface-list=WAN comment="VLAN Internet Access only"
YES CORRECT, now you have both in and out, identified so its clear to the reader!!
BUT guess what LOL the F U G G I N G new cropped in again............... I think you get paid for injecting new into all rules.

mkx · Fri Feb 08, 2019 10:37 pm

Just my 5 cents about firewall rules: regardless one's personal preferences, the default firewall is "drop not wanted, implicitly allow everything else". Personally I don't think this approach is wrong and while teaching less knowledgeable users about VLAN config I don't think we should mess with default firewall philosophy.

anav · Fri Feb 08, 2019 11:53 pm

Just my 5 cents about firewall rules: regardless one's personal preferences, the default firewall is "drop not wanted, implicitly allow everything else". Personally I don't think this approach is wrong and while teaching less knowledgeable users about VLAN config I don't think we should mess with default firewall philosophy.

Well since I am only bringing 2 cents to the table, so perhaps you have a quark of a point

If you will go back and review the rules he stated, as I already noted, the author has chosen a DROP ALL ELSE philosophy, and I am just ensuring that its consistently applied.
Its not a mix and match game, its one or the other, with few exceptions thrown in.
What disappoints me is you didn't take the opportunity to educate me on why YES in his rules is viable and proper. It pains me to say, I wish sob would join this thread which involves him first impugning my capabilities and then answering my questions in his usual roundabout riddles....

pcunite · Sat Feb 09, 2019 12:29 am

(2) Add text explaining how oneliners can be used. example:
/ip interface bridge vlan bridge=BR1 tagged=BR1,sfp1,sfp2 vlan-ids=10,20,30
(3) (a) Why not show ingressfiltering=yes?
(3) (b) Why not show pvid=xx admit frame types=?

A goal I have is to be verbose about VLAN concepts and brief about other concerns. I have earmarked a Security section for example to explain that necessary topic. If I try to illustrate to many things at once, all the complexity makes is hard to follow. MikroTik syntax efficiencies won't make it into the main document, but it could very well be addressed separately. Points 3ab are security related.

As for Firewall rules
1) Only allow permitted traffic then Drop all else
2) There is no reason to let everyone on the LAN (or VLAN for that matter) have access to the router.
3) Why use connection-state=new?

#1
Firewall rules are very important to the VLAN concept, so I use some verbosity here. I'm a strong believer in drop by default, then add in rules to do otherwise. I think it reads easier too. On this, we agree.

#2
With regards to allowing access to the router, I'm torn about it, and I may have gotten this wrong. I think most people want access to the DNS instance running on it, so I allow it, but with a note that you can make it granular. Perhaps I should show that explicitly. I think that security is a massive topic on its own, so I'm trying to push it off into the Security section.

#3
I'm a fan of using interfaces whenever possible as opposed to source address and the like. Also, I like to reduce the total number of rules. So, from those two opinions, a new rule is merely the setup for the ultra simplistic Allow Estab & Related forward rule (which references nothing else), from then on. Its just easier to reason about. Visualize packet flow, and you'll see how to catch and release them. Forget everything you've learned about MikroTik firewalling, and it will all make sense. : - )

anav · Sat Feb 09, 2019 1:07 am

A. Concur with your desire to provide a basic config, but understanding is important too.
By stating the fact that the bridge vlan line should be considered on a per VLAN basis is important, and something I didnt get until Mkx jotne et al, drilled it into my head 200 times.
So its important. But its not a blindly applied rule, if there is no difference in tagged and untagged elements (identical) then vlanIDs can be combined and rules simplified.

B. As long as your going to point the reasons for and functionality of ingress filtering, and admit frames, in the security section, it can be left out here.
BUT did you explain what pVID actually does........ not sure but its important do state what effect it has on the packets.

C. So your a fan of reducing rules, just like I attempted to do in A. LOL, put that aside, I think clarity of purpose, consistency and readablity (anybody looking at your firewall rules should see the logic clearly) may call for more not less rules at times.
As I stated I dont have NEW in any of my rules, I dont see any in the default config, so where are you pulling this rectal pluck from????

Nobody needs access to the router except the admin, there is no discussion on this point.
The PCs of people may need DNS access, if they require internet access for example but it should be transparent.
Thus as per my example the router owner can decide which interfaces should have access to DNS..........

pcunite · Sat Feb 09, 2019 1:28 am

I don't have NEW in any of my rules, I don't see any in the default config, so where are you pulling this rectal pluck from?

When a packet enters a chain, I want to know what interface it came in on. Next, I want to know where it is going. Using connection-state=new allows you to make a decision right then to mark this packet as allowed, if it agrees with those two metrics. When you do, from then on you only need a single established,related rule for all future packets, coming in on all the random interfaces you might ever create in the future. This top rule need be the only rule that catches just about everything happening in the forward chain.

Interfaces are one way to group packets into virtual buckets (think business units like Research, Marketing, or protocols like VoIP, QUIC, etc.) from which you can do separate actions on. We want Security, Access, and Performance. That's three things. But you can't have three things! In life, you may only have two. So interfaces are a way to make those three goals reach a happy balance.

VLAN is for segmenting things, but not completely. In some networks, VLAN Blue gets permission to access some of VLAN Green. VLAN Red only gets access to the Internet. Thus, you'll need to accept~drop based on those new attempted packets. Once you do, you can then toss all future packets into the established,related catch all. They've been given permission to flow, simply allow that to happen.

anav · Sat Feb 09, 2019 2:18 am

You obviously understand what you are doing and I dont. Thus I have no idea what new is for as I have never seen it or put it in any of my rules.
To me new is fundamentally dangerous as if it may allow external to internal connections I dont sanction or authorize. Also something I have to learn on my own.
I am just saying that its going to confuse many people like me........... Especially because its not used whatsoever in default rules!!!

Okay I remember some nob saying this: " new connection is checked by filter rules is simple. If it's really new, it won't match the usual rule to accept established, so it will continue further, until it finds a rule that accepts it (or drops/rejects it). Then it stops. If none of the rules will match, it will be accepted at then end (default action) unless you have a drop all rule.

For example a new lan to wan request, is not established or connected but it will match the outgoing allow lan to wan rule and get passed and I imagine the return traffic is either classified as established or related. Thus it confirms my suspicion that using NEW breaks the premise of a firewall outlook that implicity denies all traffic and one has to clearly state what is accepted/authorized.
New is WAY to vague and general and thus get rid of it, if traffic doesnt match a rule I have (for a specific purpose), then off with its head!!

mkx · Sat Feb 09, 2019 11:39 am

You obviously understand what you are doing and I dont. Thus I have no idea what new is for as I have never seen it or put it in any of my rules.

Consider this rule:

add chain=input in-interface-list=LAN protocol=udp port=53

It's to allow LAN users use DNS caching server on RB btw.

It allows any packet, coming from LAN, and targeting RB's DNS service. It matches all packets regardless connection state (either new or established, related not so much, we'd need another rule for reverse direction). So the state "new" is implicit here. If the connection requires a few rounds of packets (i.e. send-reply-send-reply...), then this rule will get triggered multiple times.

If you add another rule like this

add chain=input in-interface-list=LAN connection-state=established,related
add chain=input in-interface-list=LAN protocol=udp port=53

then the first rule would actually trigger on all but the initial packet of the same DNS connection. Which means that it would be just fine if we added connection-state=new to the second rule ... from functionality point of view it wouldn't change a bit, but it'd show the real reason for having this rule.

mozerd · Sat Feb 09, 2019 2:17 pm

, if traffic doesnt match a rule I have (for a specific purpose), then off with its head!!

Yes I AGREE

I for one do not fully comprehend under what circumstances I would want to use connection-state=new ::: I have never had a situation where I've needed to use that directive
... do I need more excitement in my tech life?

@WirelessRudy in the following link asks some good questions that helped me to get some ideas and
@fewi provided a lucid explanation that made sense.to me:

For UDP, only the first packet between a connection with two unique IP/port tupels are new, all return packets and subsequent packets are established. For TCP the first three packets are new (three way handshake: SYN, SYN/ACK, ACK), everything thereafter is established.

Packets can only belong to one connection, and each connection can only have on mark. Every packet can also have an independent packet mark, and an independent routing mark. So you can mark connections for policy routing purposes (routing marks derived from the connection mark), and use the packet mark independently for QoS purposes (but not use the connection mark for QoS decisions), or vice versa.

pcunite · Sat Feb 09, 2019 4:31 pm

... it would be just fine if we added connection-state=new to the second rule ... from a functionality point of view it wouldn't change a bit, but it'd show the real reason for having this rule.

mkx has explained concisely how connection-state=new is really the highlight for the existence of another rule, which is processed first, and how these two relate to each other. I feel there is a benefit to using new, but I don't want to go into all that now.

anav · Sat Feb 09, 2019 4:33 pm

Thanks mkx, for stating it a level I can understand, and to Mozerd for delving deeper into the onion that is beyond me, only that perhaps I grasped, one doesnt need to worry about marking packets unless you want to go beyond marking connections and routes and if so probably for QoS purposes LOL.

anav · Sat Feb 09, 2019 5:05 pm

Based on the discussion...............
I still have to disagree with this combination...........
add chain=forward action=accept connection-state=established,related comment="Allow Estab & Related"
add chain=forward action=accept connection-state=new in-interface-list=LAN comment="Allow Native LAN"

From the simpletons standpoint =(me), the above first rule states for any connections that are already established,related that the router is tracking, keep forwarding these packets as they have previously matched one of my "real" rules and are legit. My understanding is these packets do not need to be matched over and over again to my firewall list............

This is takes us to the second rule and which begs the the natural question: So what happens with new packets???
Answer: Well new packets will now meet with their adversary ME, the MARVEL ADMIN, who is going to apply a series of tests to such arrogant packets!!
If you can conquer one of my tasks then yee shall pass.

Therefore why in the heck would I then state, hey ALL NEW PACKETS your allowed to go forward if coming from the LAN.
Not being extremely knowledgeable, it would seem to me in MT vernacular that if a packet matches this rule, they are passed onwards and DO NOT HAVE TO be viewed against all subsequent rules.
For me that is NOT what I want the router to do?? I want all packets coming from wherever to be matched against the rules I have created, especially the first packets-connection (new one).

What am I missing in my logic??

The only thing I can surmize is that my understanding of the filter rules is flawed, meaning in that
a. First rule is allowing ALL direction of packets if already being tracked BUT subsequent rules will still be applied because matching a connection-state does not qualify as matching rule for exit from the filter rules path??.
b. Second rule is only allowing LAN originated new packets BUT subsequent rules will still be applied because matching a connection-state does not qualify as matching a rule for exit from the
filter rules path???.

I hope someone out there can understand my misunderstanding..............

ilkogd · Sat Feb 09, 2019 5:33 pm

@anav First I think that the rule order should be opposite. NEW packets is the easiest way (for me) to tell the router which host can communicate with other and with Internet. For example you can tell that VLAN23 hosts can create NEW connections only when destination is VLAN56 and this hosts will have access ONLY to VLAN56. After your NEW connections rules you put general rule that allow established and related connections in forward chain - if first packed is allowed by the firewall every second, third and so on packed should be OK. At the end must be general drop rule, this is very important!

mkx · Sat Feb 09, 2019 5:56 pm

@anav, can we keep this thread talking about VLANs and (if needed) start a new thread (or three) to bitch about other things?

@ikogd: the rule order matters is important as packets get tested against rules in the order as they are defined and first rule that matches will end matching ... either accepting packet or dropping it. So rule order matters for two things:

more specific rules have to come earlier not to mis-trigger on the more general rule
performance ... the less rules packet has to test against, the less load on firewall/router

These two points are slightly contradictory ... but the general rule which accepts packets of established and related connections does not interfer with checking packets that belong to new connections (connection can not be established and new at the same time!). On the other hand vast majority of passing packets usually belong to established connections and we want to stop processing those packets as soon as possible, hence this rule at the very top of rule list.

sindy · Sat Feb 09, 2019 6:24 pm

@anav, can we keep this thread talking about VLANs and (if needed) start a new thread (or three) to bitch about other things?

I've made a dedicated topic for that, please continue there.

anav · Sat Feb 09, 2019 11:04 pm

I am a bit confused as to why you are setting up PVID on access point WLANs/vWLANs??
I have two Cap ACs and they dont seem to require this setup?
Perhaps I have been doing it wrong all this time LOL???
I thought the vlan tagging of the WLAN or vWLAN is done in the wireless settings??

/interface wireless
set [ find default-name=wlan1 ] antenna-gain=2 band=2ghz-g/n basic-rates-b="" \
country=canada disabled=no distance=indoors frequency-mode=\
regulatory-domain installation=indoor mac-address= mode=\
ap-bridge name=DevicesHallway rate-set=configured scan-list=2412,2437,2462 \
security-profile=devices_only ssid=RD2 supported-rates-b="" vlan-id=45 \
vlan-mode=use-tag wireless-protocol=802.11 wmm-support=enabled wps-mode=\
disabled
set [ find default-name=wlan2 ] antenna-gain=2 band=5ghz-a/n/ac channel-width=\
20/40mhz-Ce country=canada disabled=no frequency-mode=regulatory-domain \
mode=ap-bridge name=Hallway5G rate-set=configured scan-list=\
5175-5185,5195-5205,5215-5225 security-profile=Hallway_wifi ssid=\
Hallway_CellPhones wireless-protocol=802.11 wmm-support=enabled wps-mode=\
disabled
add disabled=no mac-address= master-interface=Hallway5G name=\
VisitorWIFI security-profile=HouseGuestsSecurity ssid=Guest_Wifi vlan-id=\
200 vlan-mode=use-tag wmm-support=enabled wps-mode=disabled

and my bridge ports look so.............

/interface bridge port
add bridge=bridgeHallway comment=defconf interface=ether1
add bridge=bridgeHallway comment=defconf interface=DevicesHallway (wlan1 - uses vlan45)
add bridge=bridgeHallway comment=defconf interface=Hallway5G (wlan2 - no vlan assigned uses default vlan1)
add bridge=bridgeHallway interface=VisitorWIFI trusted=yes (vWLAN - uses vlan200)

/interface bridge vlan
add bridge=bridgeHallway tagged=ether1,DevicesHallway vlan-ids=45
add bridge=bridgeHallway tagged=ether1,VisitorWIFI vlan-ids=200

mkx · Sat Feb 09, 2019 11:23 pm

@anav, did you manage to miss the second part of post #17 above? And @pcunite's reply to it ... seems like he made his mind

anav · Sun Feb 10, 2019 4:46 am

@anav, did you manage to miss the second part of post #17 above? And @pcunite's reply to it ... seems like he made his mind

I clearly did LOL, and I know what I did. I mixed that up, I read it as his way was the old way and the way I do it as the new way.
Kewl, now I get to change my config once again LOL. I do like the consistent approach he is using better!!
I was just wondering why it was different from what I was doing based on great advice from folks like yourself.

Okay so I took my perfectly working config and implemented the NEW scheme as you can see below.
(I am having issues with the checkbox for vlan filtering on the bridge)

and I no longer have access on my access wlans,
the default wlan on vlan45 and the vWLAN on vlan200. Nice signal no internet ............
UPDATE
I cycled the vlan filtering off and then back on. and everything works now!
UPDATE2: I spoke too soon, when I cycled my vlan filtering the AP burped and it worked because it went back to the old setup, that works LOL
So trying again

OKAY this is nuts, I cannot uncheck my vlan filtering or else the AP kicks out. WTF over???

# model = RouterBOARD cAP Gi-5acD2nD
/interface ethernet
set [ find default-name=ether1 ] speed=100Mbps
/interface bridge
add admin-mac= auto-mac=no comment=defconf name=bridgeHallway \
    vlan-filtering=yes
/interface vlan
add interface=bridgeHallway name=Guests_WIFI-v200 vlan-id=200
add interface=bridgeHallway name=Wifi_SDevices_cap2 vlan-id=45
/interface list
add name=WAN
add name=LAN
/interface wireless
set [ find default-name=wlan1 ] antenna-gain=2 band=2ghz-g/n basic-rates-b="" \
    country=canada disabled=no distance=indoors frequency-mode=\
    regulatory-domain installation=indoor mac-address= mode=\
    ap-bridge name=DevicesHallway rate-set=configured scan-list=2412,2437,2462 \
    security-profile=devices_only ssid=RD2 supported-rates-b="" \
    wireless-protocol=802.11 wmm-support=enabled wps-mode=disabled
set [ find default-name=wlan2 ] antenna-gain=2 band=5ghz-a/n/ac channel-width=\
    20/40mhz-Ce country=canada disabled=no frequency-mode=regulatory-domain \
    mode=ap-bridge name=Hallway5G rate-set=configured scan-list=\
    5175-5185,5195-5205,5215-5225 security-profile=Hallway_wifi ssid=\
    Hallway_CellPhones wireless-protocol=802.11 wmm-support=enabled wps-mode=\
    disabled
add disabled=no mac-address=master-interface=Hallway5G name=\
    VisitorWIFI security-profile=HouseGuestsSecurity ssid=Guest_Wifi \
     wmm-support=enabled wps-mode=disabled
/interface bridge port
add bridge=bridgeHallway comment=defconf interface=ether1
add bridge=bridgeHallway comment=defconf interface=DevicesHallway pvid=45
add bridge=bridgeHallway comment=defconf interface=Hallway5G
add bridge=bridgeHallway interface=VisitorWIFI pvid=200 trusted=yes
/interface bridge vlan
add bridge=bridgeHallway untagged=DevicesHallway vlan-ids=45
add bridge=bridgeHallway untagged=VisitorWIFI vlan-ids=200
add bridge=bridgeHallway untagged=Hallway5G vlan-ids=1
/interface list member
add interface=ether1 list=WAN
add interface=Wifi_SDevices_cap2 list=LAN
add interface=Guests_WIFI-v200 list=LAN
add interface=bridgeHallway list=LAN

pcunite · Sun Feb 10, 2019 6:24 am

All example topics have now been posted. I recommend you use test hardware to try things out before implementing them in your main network. I've been using the hEX PoE lite and hAP ac lite units because they can be found cheaply and I can power them off each other easily.

The two reserved posts I have are for adding necessary editions to make the VLAN concept complete. There are details here and there that the configurations need in the real world, security being one of them. If you find any bugs, do tell.

Dear reader:
I am not here to help you with your configuration. There are others better suited for that. I have contributed by producing this documentation. I will naturally stick around to help make this document easy to read, implementable, performant, secure, and accurate.

Testing:
I would really appreciate anyone that could help out with testing. For Security we have things like: MAC Flooding, DHCP Starvation, DHCP Rogue, VLAN Hoping, ARP Poisoning, and MAC/IP Spoofing. In the Performant area we need to test wire speed switching, how much bandwidth can the router-on-a-stick process, and so on.

Thank you to everyone who helps out in the forums.

mkx · Sun Feb 10, 2019 11:09 am

@anav: it would seem you wanted ether1 to be trunk port? And yet there's no sign of it in /interface bridge vlan?

anav · Sun Feb 10, 2019 4:21 pm

@mkx, Much thanks, with sleep and after this mornings exercise, I got it to accept the config .........
Also it working with new config..............

I have two questions........
(1) I seem to recall that we don't need to tag bridges for MT access points so I was confused when I saw pcunites config including tagging the bridge.
Please confirm!

(20 For ether1 itself, the trunk port............. which is more correct? (both seem to work)
add bridge=bridgeHallway tagged=ether1 vlan-ids=1 OR
add bridge=bridgeHallway untagged=ether1 vlan-ids=1

/interface bridge
add admin-mac=auto-mac=no comment=defconf name=bridgeHallway vlan-filtering=yes
/interface vlan
add interface=bridgeHallway name=Guests_WIFI-v200 vlan-id=200
add interface=bridgeHallway name=Wifi_SDevices_cap2 vlan-id=45
/interface wireless
set [ find default-name=wlan1 ] antenna-gain=2 band=2ghz-g/n basic-rates-b="" country=canada disabled=no distance=indoors frequency-mode=regulatory-domain installation=indoor mac-address=mode=\
    ap-bridge name=DevicesHallway rate-set=configured scan-list=2412,2437,2462 security-profile=devices_only ssid=RD2 supported-rates-b="" wireless-protocol=802.11 wmm-support=enabled wps-mode=disabled
set [ find default-name=wlan2 ] antenna-gain=2 band=5ghz-a/n/ac channel-width=20/40mhz-Ce country=canada disabled=no frequency-mode=regulatory-domain mode=ap-bridge name=Hallway5G rate-set=configured scan-list=\
    5175-5185,5195-5205,5215-5225 security-profile=Hallway_wifi ssid=Hallway_CellPhones wireless-protocol=802.11 wmm-support=enabled wps-mode=disabled
add disabled=no mac-address= master-interface=Hallway5G name=VisitorWIFI security-profile=HouseGuestsSecurity ssid=Guest_Wifi wds-cost-range=0 wds-default-cost=0 wmm-support=enabled wps-mode=disabled
/interface bridge port
add bridge=bridgeHallway comment=defconf interface=ether1
add bridge=bridgeHallway comment=defconf interface=DevicesHallway pvid=45
add bridge=bridgeHallway comment=defconf interface=Hallway5G
add bridge=bridgeHallway interface=VisitorWIFI pvid=200 trusted=yes

/interface bridge vlan
add bridge=bridgeHallway tagged=ether1 untagged=DevicesHallway vlan-ids=45
add bridge=bridgeHallway tagged=ether1 untagged=VisitorWIFI vlan-ids=200
add bridge=bridgeHallway tagged=ether1 vlan-ids=1

sindy · Sun Feb 10, 2019 5:09 pm

The port tagging mode in /interface bridge vlan and in /interface bridge port must match each other for the same VLAN ID, otherwise surprises happen.

First, let's suppose that the own pvid of bridgeHallway differs from 1. In that case, with
/interface bridge port
...
add bridge=bridgeHallway interface=ether1 pvid=1
...
/interface bridge vlan
...
add bridge=bridgeHallway untagged=...,ether1,... vlan-ids=1

ether1 will tag received (ingress) tagless frames with VLAN 1 and it will untag VLAN 1's frames when sending them to the wire (egress), which is "access" behaviour for VLAN ID 1;

with
/interface bridge port
...
add bridge=bridgeHallway interface=ether1 pvid=anything-else-than-1
...
/interface bridge vlan
...
add bridge=bridgeHallway tagged=...,ether1,... vlan-ids=1

tagless frames received at ether1 will get tagged with some other VLAN ID than 1, so those tagged with VLAN ID 1 will get in unchanged, and frames tagged with VLAN ID 1 will not get untagged on egress, which is "trunk" behaviour for VLAN 1.

The remaining two combinations can give uexpected results. When testing, always check both directions.

Now when the own pvid of bridgeHallway is 1, the behaviour on the wire is the same as above, but on the bridge itself, VLAN 1's frames live tagless. So when ether1 is set to trunk mode for VLAN 1 and bridge's own pvid is 1, ether1 untags frames tagged with VLAN1 on ingress and tags tagless frames coming from the bridge on egress; when ether1 is set to access mode for VLAN 1 and bridge's own pvid is 1, tagless frames pass unchanged via ether1 in both directions.

As you have no other port than ether1, not even bridgeHallway, in the vlan-ids=1 row of /interface bridge vlan in your export, and no wireless interface uses VLAN tagging, how do you even test the behaviour?

anav · Sun Feb 10, 2019 5:27 pm

Wow you really pooched that explanation by introducing a whole new topic and conversation, aka your almost as good a Sob at riddles.

No where did I ask about the PVID of bridges, and no where is it discussed in pcunites configuration, so you have added to my confusion not reduced it.

Perhaps I should have stuck to one question.

What I did learn.
RULE: Bridge port configuration must match Bridge vlan configuration for the same VLAN ID -- we can put that one in the bank.

With that in mind, then
My question about these..........
add bridge=bridgeHallway tagged=ether1 vlan-ids=1 OR
add bridge=bridgeHallway untagged=ether1 vlan-ids=1

Can be answered by looking at the bridge port configuration........
add bridge=bridgeHallway comment=defconf interface=ether1 (pvid=1)

And thus the correct answer is.......
add bridge=bridgeHallway untagged=ether1 vlan-ids=1

It also is consistent with the advice that every interface has to have at least one untagged vlan (but only one untagged interface per vlan is permitted).

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

As for the second question as to why bridges for access point dont seem to need to be tagged compared to routers, that one is still a mystery to me.

PS. Dont feel bad about your failure to communicate,,,, I am sure you will improve over time.................. Life would be too easy if you were explaining something to yourself.

mkx · Sun Feb 10, 2019 9:22 pm

@sindy: the way you describe what happens when bridge has pvid set (that ether ports untag packets) is an over complication. If one accepts that bridge has two personnalities (one being sort-of-switch, second one being interface), then one doesn't have do perform mental somersaults about other member ports performing out-of-line operations ... it's the bridge port that tags them on ingress (coming from L3 stage of router) ... exactly the same way as untagged ether interfaces do. And bridge sort-of-switch untags frames on egress (entering L3 stage of router) exactly the same way as bridge does it for untagged ether ports.
Then it becomes clear that packets always live tagged on bridge (sort-of-switch) except for "native" VLAN.

@anav: bridges become tagged members of a VLAN when device needs some L3 (mostly, could be L2 as well) interaction with said VLAN. AP doesn't, its job is to forward packets between L2 interfaces. Router does, it needs to shuffle packets on L3 through CPU.
So yes, adding BR1 as tagged member of VLAN_RED, VLAN_GREEN and VLAN_BLUE is un-necessary and probably @pcunite should fix it in the config example.

I really hate when tagged and untagged get mixed on the same ports ... much easier (conceptually) is to run full tagged with (plenty of) access ports ...

sindy · Sun Feb 10, 2019 10:08 pm

the way you describe what happens when bridge has pvid set (that ether ports untag packets) is an over complication.

It may look like an over-complication but the sad truth is that inside it works exactly like that (tagless packets on the bridge). So your simplification that the bridge's pvid is only meaningful for the bridge's role as its own port is useful in most situations, but sometimes people get surprised when they try to attach an /interface vlan with vlan-id=1 to a bridge with a (default) pvid=1 and get surprised that it doesn't work, or when you need to combine switch chip settings with bridge settings.

@anav: bridges become tagged members of a VLAN when device needs some L3 (mostly, could be L2 as well) interaction with said VLAN. AP doesn't, its job is to forward packets between L2 interfaces. Router does, it needs to shuffle packets on L3 through CPU.

I'd say bridges (in their "port of itself" personality, as in "Salzburg ist die Landeshauptstadt des Landes Salzburg") don't become tagged members of a VLAN but have to be made tagged members of a VLAN if you want to make that VLAN accessible for the L3 on the Mikrotik itself. And an AP (wireless interface) with vlan-mode=use-tag does become a member interface of a VLAN, except that you don't need to configure that manually, it is added dynamically (see /interface bridge vlan print).

I really hate when tagged and untagged get mixed on the same ports ... much easier (conceptually) is to run full tagged with (plenty of) access ports ...

Yes, I also wonder where @anav has seen the advice that at least one VLAN on each port should be tagless - I only use "hybrid" ports or "native VLAN on a trunk" where the connected equipment requires that and it is too complex to change it, typically for administrative reasons.

pcunite · Sun Feb 10, 2019 10:19 pm

Bridges need to be tagged members of a VLAN when device needs some L3 (mostly, could be L2 as well) interaction with said VLAN. Access Point doesn't, its job is to forward packets between L2 interfaces. Router does, it needs to shuffle packets on L3 through CPU. So yes, adding BR1 as tagged member of VLAN_RED, VLAN_GREEN and VLAN_BLUE is unnecessary (in the AP example) and probably @pcunite should fix it in the config example.

Good understanding. Makes it clearer to me now. I'm not ready to agree with needing to do this, yet. Tested and confirmed so I've updated the example.

mkx · Sun Feb 10, 2019 10:26 pm

the way you describe what happens when bridge has pvid set (that ether ports untag packets) is an over complication.
It may look like an over-complication but the sad truth is that inside it works exactly like that (tagless packets on the bridge). So your simplification that the bridge's pvid is only meaningful for the bridge's role as its own port is useful in most situations, but sometimes people get surprised when they try to attach an /interface vlan with vlan-id=1 to a bridge with a (default) pvid=1 and get surprised that it doesn't work, or when you need to combine switch chip settings with bridge settings.

This is a complication because Mikrotik uses VLAN ID 1 as synonym for untagged while other vendors might actually support it as tagged. So not only I hate using mixed tagged/untagged, I also avoid use of VLAN ID 1 at all cost.

But if we push vlan-id=1 out of picture (because it very obviously stinks), does my simplification still smell rotten?

sindy · Sun Feb 10, 2019 11:55 pm

Mikrotik uses VLAN ID 1 as synonym for untagged

This is, fortunately or unfortunately, not true. I used to think the same until I've found out that it is not VLAN ID 1 which is always handled untagged but it's actually "the VLAN ID which is configured as bridge's own pvid parameter" which is treated as untagged on the bridge. If you change bridge's own pvid to something else than 1, VID 1 starts behaving normally.

But if we push vlan-id=1 out of picture (because it very obviously stinks), does my simplification still smell rotten?

The biggest problem with VID 1 is that it is a default value, and as such it is often not explicitly shown on command line interfaces, in configuration items like switchport access vlan or switchport trunk native vlan on Cisco, and in /interface bridge port pvid and /interface vlan pvid in RouterOS.

To add another "riddle" as @anav calls it, a synonym for no effective VLAN ID (which is not the same as untagged) is VLAN ID 0. If the 802.1Q tag has all the 12 VLAN ID bits set to 0, it means that the remaining four bits carry the CoS mark but otherwise the frame should be treated as untagged {so if you receive such frame from a wire on an access port, the VLAN ID bits in the tag get rewritten to the VID to which that access port belongs). RouterOS, here clearly unfortunately, doesn't allow to set pvid=0 on a bridge, so one of the 4094 available VIDs always has to live tagless on the bridge. I don't know a scenario where all of them would be assigned, but you have to choose an unused one to play that role, and it is not 1 in all environments and there is no safe choice as in future someone may need to start using for some real purpose the one you've chosen.

So you would have to define a set of musts and must nots which would allow you to "push vlan-id=1 out of picture", as it always is present in the configration unless you explicitly assign that clumsy role to another VID. But if you have in mind that you'll never set the pvid of a bridge to anything else than 1, then you can say that whenever you don't state a pvid in /interface bridge port, it means that the traffic from this port will reach the bridge in its port personality untagged (because the default value of pvid of /interface bridge port is also 1). But even in such case you'll see the "bridge as a port" as a dynamic member port of VLAN 1 on the "bridge as a bridge" if you print the current state:

[me@MyTik] > interface bridge export verbose
...
/interface bridge
add admin-mac=XX:XX:XX:XX:XX:XX ageing-time=5m arp=enabled arp-timeout=auto auto-mac=no comment=\
    "interconnection with OTC network" dhcp-snooping=no disabled=no ether-type=0x8100 fast-forward=yes frame-types=admit-all \
    igmp-snooping=no ingress-filtering=no mtu=auto name=bridge-otc protocol-mode=none \
    pvid=1 vlan-filtering=yes

[me@MyTik] > interface bridge vlan export
...
/interface bridge vlan
add bridge=bridge-otc tagged=ether1,bridge-otc vlan-ids=2,5,6

[me@MyTik] > interface bridge vlan print
Flags: X - disabled, D - dynamic
 #   BRIDGE                           VLAN-IDS  CURRENT-TAGGED                           CURRENT-UNTAGGED
 0   bridge-otc                       2         bridge-otc
                                      5         ether1
                                      6
 1 D bridge-otc                       1                                                  bridge-otc
                                                                                         ether1

So I strongly prefer to understand properly how VID 1 is handled, in Mikrotik/RouterOS as well as in other devices, to pretending it does not exist. And I admit that on other devices some specific treatment of VID 1 may be hardcoded, but I don't know any such device. Mostly it all boils down to default values not being explicitly shown and VID 1 being a default value.

anav · Mon Feb 11, 2019 4:58 am

I think i stirred the pot.

Speaking practically I have integrated an SwOS switch, a netgear GS110 switch and a Dlink DGS1100 with my MT router and two CapACs, they all treat vlan1 as default and sorta like an untagged packet (or in other words the default lan=vlan1). What is important maybe is not to use the term untagged for anything that concerns vlan1. Untagging should be left for the act of untagging vlanids from packets where an assigned vlanID is being stripped. So what do we call untagging of VLAN1 Perhaps we should call it swagging, or fragging....................

While you guys quibble on what is actually going on in the bridge, lets provide pcunites with a clear path for describing setups and architectures that captures the salient points you both are making and will thusly allow someone to follow the bouncing ball and be able to handle the simple to complex vlan setups. By the way mkx thanks much for elucidating the need for tagging bridge on router but not on CapACs!! (L3 vice L2 interaction responsibilities).

As for my example, if I am treating vlan1 like any other vlan and I use vlan1 for my 5ghz wifi, (and not assume anything just because its default) then

/interface bridge port
add bridge=bridgeHallway comment=defconf interface=ether1 (pvid=1)
add bridge=bridgeHallway comment=defconf interface=DevicesHallway pvid=45

/ip bridge vlan
bridge=homebridge untagged=ether1 vlanid=1 is correct as it is consistent with the other interfaces

But what does that mean.......... Will the CapAC remove vlanID1 from packets going to the WLAN?? and the packets will have vlanid0 and if so how will that affect devices connecting??
As you can surmize I am still not sure how to handle the bridge vlan for my capAC for ether1

I was sorely tempted to put

/ip bridge vlan
bridge=homebridge tagged=homebridge untagged=ether1 vlanid=1 LOL

mkx · Mon Feb 11, 2019 8:38 am

Mikrotik uses VLAN ID 1 as synonym for untagged
This is, fortunately or unfortunately, not true. I used to think the same until I've found out that it is not VLAN ID 1 which is always handled untagged but it's actually "the VLAN ID which is configured as bridge's own pvid parameter" which is treated as untagged on the bridge. If you change bridge's own pvid to something else than 1, VID 1 starts behaving normally.

Perhaps things slightly changed with event of bridge vlan-filtering ... in previous times, when bridge was sort of a dumb switch, bridge interface happily utilized packets belonging to VLAN ID 1 just the same as explicitly untagged while one had to use VLAN interface for the rest of VLANs. This might explain why pvid=1 is default setting ... to keep (broken) bridge port behaviour the same as it was before 6.42.
I guess this is the origin of @sindy's explanation about what happens on the bridge.

But then again, setting bridge's pvid to some other value and setting member interfaces' pvid to the same value re-instate the same behaviour ... seemingly untagged packets on bridge, but my own simplification covers that variant just the same.

Anyhow, I'll stop bitching about this ... it is one view vs. another one and unless some MT developer explains the way it's really implemented in ROS it's all just guessing.

/interface bridge port
add bridge=bridgeHallway comment=defconf interface=ether1 (pvid=1)
add bridge=bridgeHallway comment=defconf interface=DevicesHallway pvid=45

/ip bridge vlan
bridge=homebridge untagged=ether1 vlanid=1 is correct as it is consistent with the other interfaces

But what does that mean.......... Will the CapAC remove vlanID1 from packets going to the WLAN?? and the packets will have vlanid0 and if so how will that affect devices connecting??
As you can surmize I am still not sure how to handle the bridge vlan for my capAC for ether1

There's a distinction between untagged frame and frame tagged with VLAN ID=1. The former has ethertype value 0x0800 (or, if it's not about IPv4 packet, appropriate ethertype value), the later has (outer) ether type 0x8100 with additional header (3 bits PCP - priority code point; 1 bit DEI - drop eligible indicator and 12 bits VID with value of 1 in this particular case) followed by usual ethertype 0x0800 (or, if it's not IPv4 packet, appropriate ethertype value).
So in the latter case, receiver would have to know how to deal with 802.1q frames (or blindly strip them which would become a problem in the other direction if switch/router actually expected 802.1q frames with VID set to 1) while in the former case it really is about truly untagged, plain ethernet.

In the quoted case cAPs really should strip VLAN headers even with VID=1 not to confuse wireless clients.

anav · Mon Feb 11, 2019 2:33 pm

Okay so then would this make sense for my capACs.....
/ip bridge vlan
bridge=bridge tagged=eth1 untagged=guest-wifi vlanid=200
bridge=bridge tagged=eth1 untagged=smart-devices vlanid=45
bridge=bridge tagged=eth1 untagged=homeuser-wifi vlanid=1

and because the previous post stated that vlan1 is untagged by default on the bridge we dont need the following as well
bridge=bridge untagged=eth1 vlanid=1 ???

In other words I dont know what to do with trunk port eth1 and vlan1 ????

mkx · Mon Feb 11, 2019 3:34 pm

The discussion with @sindy was, AFAIK, debate only about how bridge (port and something-like-a-switch) behaves. Now you have your dilemma about ether1 ...

With the first block of settings you're saying that ether1 should be tagged member of VID=1, thus frames, traveling on the wire, should have VLAN tags with VID=1.
With the second block, you're changing that to the state where frames, traveling on the wire, should be untagged when frame belongs to VID=1 inside cAP.

Regardless of VLAN ID (VID=1 should be considered just the same as other VIDs when on ethernet wire) settings should be consistent on both sides of wire. So setting on cAP should mirror those on router/switch/... (I don't know which device is on the other end of that UTP cable).
If you want to be consistent about VIDs on all of your LAN infrastructure devices, you should stick to all tagged trunks ... because it's just too easy to set port pvid on one end to something and on other end to something else. If frames traveled between those two ports tagged, you'd spot such error quite easily (VLAN wouldn't work).

As to how's VID=1 dealt with by default on bridge ... I'm all frustrated and I'll repeat once more (and then shut up forever): don't ever use VID=1 in any setup and always have frames tagged in LAN infrastructure ... untagged should only live on access points (wires outside active LAN infrastructure perimeter and wireless SSIDs). I'm sticking to these rules and I don't have any problems whatsoever (neither conceptual nor real).

mozerd · Mon Feb 11, 2019 3:56 pm

don't ever use VID=1 in any setup and always have frames tagged in LAN infrastructure ... untagged should only live on access points (wires outside active LAN infrastructure perimeter and wireless SSIDs). I'm sticking to these rules and I don't have any problems whatsoever (neither conceptual nor real)..

100% agree.

anav · Mon Feb 11, 2019 7:07 pm

Okay so I will create a VLAN for my homelan which DOES NOT sit on vlan1 so to speak and thus will not be in this quandry LOL.
Thanks! Consistent also with pcunite using vlan10 for his MAIN LAN.

Okay, now Im stuck. I want to use vlan11 instead of 1, but the problem I am having is that
pcunite has bridge set to pvid=1

I want my bridge lan to be vlan 11

In other words his example now brings me to MKXs point is that default is far too confusing and we should avoid using vlan1 for everything.....
SO asking pcunite to use vlan=10 for his bridge so that it matches up with the NORMAL MAIN LAN of his examples!!!!!

joystick · Mon Feb 18, 2019 8:56 pm

Hi guys,

Even I got help fron this forum (anav), I'm still stuck.
I tried to follow "all in one" post but I need to have also a trunk port (ether5).
How can I do it (I need ID=1 and 10).?

It is to complicated for me this router

( i have hap ac2)

anav · Tue Feb 19, 2019 4:08 am

Go back to your original thread please for more assistance.

anav · Sat Feb 23, 2019 4:32 am

Okay I made the big switch tonight using vlan11 vice vlan1 for my homelan.
Problem: No longer have access to my capacs

Both of them are providing connectivity to the internet so there is at least that.

One note: both of them shows in neighbours in winbox but comes up with IP address 0.0.0.0 vice its actual IP.
On the config one spot I was not sure of is bridge ports for ether2,3 I have ingress filtering on??

Router steps Quick and Easy:
changed ip address and dhcp server interface to vlan11 from bridge (decoupled bridge from lan)
added vlan11 to my interface bridge vlan (tagged for bridge and both eth2, eth3 (if you recall eth2 goes to DLINK MS 24 port, and eth3 goes to 260GS in garage)
Thats it!

Cap ACs (both)
(1) added vlan11 tagged on eth1, untagged on 5AC homeuser wifi WLAN interface.
(remember we do not tag the bridge on the capac for some reason LOL)
(2) added bridge port entry.

/ip bridge interface vlan For one cap ac the other is the same except using 40 and 200 (vice 30 and 100)
add bridge=capbridge tagged=eth1, untagged=WLAN(5ghz) vlan-id=11
add bridge=capbridge tagged=eth1 untagged=WLAN2ghz vlad-id=30
add bridge=capbridge tagged=eth1 untagged=vWLAN5 vlan-id=100

/ip bridge ports
add bridge=capbridge interface=eth1
add bridge=capbridge interface=WLAN5 admit frames untagged only pvid=11
add bridge=capbridge interface=WLAN2 admit frames untagged only pvid=30
add bridge=capbridge interface=vWLAN5 admit frames untagged only pvid=100

DLINK switch:
Added vlan 11 to all trunk ports (leading to capac2, netgear switch, 260GS switch in basement (which feeds capac-1),
changed all none trunk ports to access ports pvid=11
(so my pc is on vlan11 and cannot reach the capacs but I can reach all switches................weird!!!)

260GS Basement
added vlan11 to port1 (From Dlink trunk port) and port 3 (going to capac) a trunk port.

Router:

/interface ethernet
set [ find default-name=ether5 ] comment=Port5 name=Bell_eth5 speed=100Mbps
set [ find default-name=ether1 ] comment=Port1 name=Eastlink_eth1 speed=\
    100Mbps
set [ find default-name=ether2 ] comment=LAN1-Home speed=100Mbps
set [ find default-name=ether3 ] comment=LAN1-Home speed=100Mbps
set [ find default-name=ether4 ] comment=LAN2-DMZ
/interface bridge
add admin-mac=CC:2D:E0:F4:3F:AE auto-mac=no comment=defconf name=HomeBridge \
    vlan-filtering=yes
/interface vlan
add interface=HomeBridge name=GuestWifi_T&B_V100 vlan-id=100
add interface=HomeBridge name=Guests_WIFI-v200 vlan-id=200
add interface=HomeBridge name=MediaStreaming_V40 vlan-id=40
add interface=HomeBridge name=NAS_V33 vlan-id=33
add interface=HomeBridge name=SOLAR-36 vlan-id=36
add interface=HomeBridge name=TheoVLAN vlan-id=666
add interface=HomeBridge name=VOIP_77 vlan-id=77
add interface=HomeBridge name=VideoCamVLAN vlan-id=99
add interface=HomeBridge name=Wifi-SDevices_cap1 vlan-id=30
add interface=HomeBridge name=Wifi_SDevices_cap2 vlan-id=45
add interface=HomeBridge name=vlan11-home vlan-id=11
add interface=Bell_eth5 name=vlanbell vlan-id=35
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
add name=VLANSwInt
add name=VLANSwoInt
/ip pool
add name=dhcp-HomeLAN ranges=192.168.0.33-192.168.0.150
/ip dhcp-server
add address-pool=dhcp-HomeLAN disabled=no interface=vlan11-home lease-time=1d \
    name=HoMeLAN
/interface bridge port
add bridge=HomeBridge comment=defconf [color=#4000FF]ingress-filtering=yes[/color] interface=ether2
add bridge=HomeBridge comment=defconf [color=#4000FF]ingress-filtering=yes[/color] interface=ether3
/ip neighbor discovery-settings
set discover-interface-list=VLANSwInt
/ip settings
set allow-fast-path=no icmp-rate-limit=100 rp-filter=loose
/interface bridge vlan
add bridge=HomeBridge tagged=HomeBridge,ether2 vlan-ids=\
    30,36,40,45,100,200,666
add bridge=HomeBridge tagged=HomeBridge,ether3 vlan-ids=99,77,33
add bridge=HomeBridge tagged=HomeBridge,ether2,ether3 vlan-ids=11
/interface list member
add comment=defconf interface=HomeBridge list=LAN
add interface=vlan11-home list=LAN
add interface=vlan11-home list=VLANSwInt
/ip address
add address=192.168.0.1/24 interface=vlan11-home network=192.168.0.0
/ip dhcp-server network
add address=192.168.0.0/24 dns-server=192.168.0.1 gateway=192.168.0.1
/ip dns
set allow-remote-requests=yes servers=\
    8.8.8.8,8.8.4.4,208.67.220.220,208.67.222.222
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set ssh address=192.168.0.0/24,192.168.2.100/32 port=xx
set api disabled=yes
set winbox address=192.168.0.0/24,192.168.2.100/32 port=xx
set api-ssl disabled=yes
ip smb
set allow-guests=no
/ip ssh
set strong-crypto=yes
/ip traffic-flow
set interfaces=VOIP_77
/system clock
set time-zone-name=America/Moncton
/system identity
set name="MikroTik RM"
/system ntp client
set enabled=yes server-dns-names=time.nrc.ca,nrc.chu.ca
/system resource irq rps
set ether2 disabled=no
set ether3 disabled=no
set ether4 disabled=no
/tool bandwidth-server
set enabled=no
/tool mac-server
set allowed-interface-list=none
/tool mac-server mac-winbox
set allowed-interface-list=LAN

..
FW Rules separated out

/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related" \
    connection-state=established,related
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
    invalid
add action=accept chain=input comment="Allow ADMIN to Router" \
    in-interface-list=VLANSwInt src-address-list=adminaccess
add action=accept chain=input comment="Allow LAN DNS queries-UDP" \
    connection-state="" dst-port=53 in-interface-list=LAN protocol=udp
add action=accept chain=input comment="Allow LAN DNS queries - TCP" dst-port=\
    53 in-interface-list=LAN protocol=tcp
add action=drop chain=input comment="DROP ALL ELSE" log-prefix=\
    "INPUT DROP ALL"
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
    connection-state=established,related

add action=drop chain=forward comment=" - Drop external DNS - UDP" \
    dst-port=53 in-interface-list=WAN protocol=udp
add action=drop chain=forward comment=" - Drop external DNS - TCP" \
    dst-port=53 in-interface-list=WAN protocol=tcp
add action=drop chain=forward comment=\
    " - Drop invalid/malformed packets" connection-state=invalid \
    log-prefix=INVALID
add action=accept chain=forward comment=\
    "defconf: accept established,related, " connection-state=\
    established,related
add action=accept chain=forward comment="ENABLE HomeLAN  to WAN" \
    in-interface=HomeBridge log-prefix="ALLOWED LAN 2 WAN TRAFFIC" \
    out-interface-list=WAN src-address=192.168.0.0/24
add action=accept chain=forward comment="allow VLANS  to WAN " \
    in-interface-list=VLANSwInt out-interface-list=WAN
add action=accept chain=forward comment="Admin_To_VLANS  \
    dst-address-list=VLANS-theo in-interface=vlan11-home log=yes log-prefix=\
    "Admin to VLANS" src-address=192.168.0.39
add action=drop chain=forward comment=\
    "Alex - DROP ALL other  FORWARD traffic" log-prefix="FORWARD DROP ALL"

..
So why cannot with my pc being on vlan11 use winbox to see capacs.
I see the router fine!

mkx · Sat Feb 23, 2019 8:14 pm

capbridge (the port) should be tagged member of self (the something-like-a-switch) for vlan-id=11 and cap's IP setup should go on vlan11 interface.

It missed my mind why "we don't tag bridges on capacs" ... probably it doesn't make any sense to me, that's why ...

pcunite · Sat Feb 23, 2019 8:51 pm

I made the big switch tonight using vlan11 vs. vlan1 for my homelan. However, I can no longer access my capacs to manage them. Remember we do not tag the bridge on the capac for some reason LOL. So why can I not, with my pc being on vlan11, use winbox to see capacs? I see the router just fine!

It is tricky to get a visual understanding of it all. Allow me to explain.

The VLAN examples show an underlying VLAN which I have termed the BASE_VLAN. Depending on what you intend to do with it, you could just as well think of it as being the Management VLAN (MGMT_VLAN). A careful look at the Access Point example apears to show that, we do not tag the Bridge on Trunk ports (because IP Services are not needed). However, I do in fact tag the Bridge! It is shown later under the VLAN Security section. Now, why would I do that?

In my opinion, every device that participates in a VLAN network, should be accessible by a Management VLAN, so that you can continue to access them remotely (in the sense of not standing in front of the them, aka remote over Trunk). In the case of a Switch, sure, you can simply plug your laptop into a free port. But as you've discovered with Access Points, they have no free ports! Thus, Access Point bridges, do in fact benefit from being tagged.

Tell me again why we tag Bridges?
For IP Services. In the Access Point example, the BASE_VLAN has an IP address assigned to it. That is an L3 feature, so we are in fact using L3 over an AP's Trunk port. IP Services (L3) requires tagged bridges.

Blame mkx for your troubles. He insisted I keep it clean and simple. : - )

anav · Sat Feb 23, 2019 9:15 pm

Okay guys I have a perfect test for this.
I have a spare cable to my computer room and attached this to port 21 on the dlink and configured it as a hybrid pvid1 and tagged11.
Fired up my computer, NO internet access but I did get access on winbox to my capac2 also attached to a trunk port on this switch.
The capac1 not on a switch as goes from diff router port to 260GS switch so not visible.

I am now going to add tagging bridge as well to see if this makes the diff!!

Failed. I added the bridge on capac2 to my vlan11 line
add bridge=bridge tagged=bridge,eth1 untagged=WLAN5gig pvid=11

On hybrid port my computer can still see and modify via winbox
No internet

On access port my computer cannot access winbox (ip address 0.0.0.0 does show for it though but no access via proper IP adddress or mac address)
Good internet.
++++++++++++++++
@mkx the capac2 IP address is on vlan11 (I changed my homelan interface from bridge to vlan11)
@mkx are you saying that
bridgeport interface=eth1 should have a pvid setting of 11 (THAT IS WRONG............ its a trunk port)
The bridgeport interface=WLAN5g has pvid=11 (that is correct)

@mkx or are you saying when creating the bridge
add bridge=bridge ingress filtering=yes PVID=11???

Capac2config

/interface ethernet
set [ find default-name=ether1 ] speed=100Mbps
set [ find default-name=ether2 ] disabled=yes speed=100Mbps
/interface bridge
add admin-mac=xx auto-mac=no comment=defconf name=\
    bridgeHallway vlan-filtering=yes
/interface vlan
add interface=bridgeHallway name=Guests_WIFI-v200 vlan-id=200
add interface=bridgeHallway name=Wifi_SDevices_cap2 vlan-id=45
add interface=bridgeHallway name=homevlan vlan-id=11
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
add authentication-types=wpa2-psk disable-pmkid=yes eap-methods="" mode=\
    dynamic-keys name=Hallway_wifi supplicant-identity=""
add authentication-types=wpa2-psk disable-pmkid=yes eap-methods="" mode=\
    dynamic-keys name=devices_only supplicant-identity=""
add authentication-types=wpa2-psk disable-pmkid=yes eap-methods="" mode=\
    dynamic-keys name=HouseGuestsSecurity supplicant-identity=""
/interface wireless
set [ find default-name=wlan1 ] antenna-gain=2 band=2ghz-g/n basic-rates-b="" \
    country=canada disabled=no distance=indoors frequency-mode=\
    regulatory-domain installation=indoor mac-address=CC:2D:E1:AF:73:91 mode=\
    ap-bridge name=DevicesHallway rate-set=configured scan-list=\
    2412,2437,2462 security-profile=devices_only ssid=RD2 supported-rates-b=\
    "" wireless-protocol=802.11 wmm-support=enabled wps-mode=disabled
set [ find default-name=wlan2 ] antenna-gain=2 band=5ghz-a/n/ac \
    channel-width=20/40mhz-Ce country=canada disabled=no frequency-mode=\
    regulatory-domain mode=ap-bridge name=Hallway5G rate-set=configured \
    scan-list=5175-5185,5195-5205,5215-5225 security-profile=Hallway_wifi \
    ssid=Hallway_CellPhones wireless-protocol=802.11 wmm-support=enabled \
    wps-mode=disabled
add disabled=no mac-address=CE:2D:E2:AF:73:92 master-interface=Hallway5G \
    name=VisitorWIFI security-profile=HouseGuestsSecurity ssid=Guest_Wifi \
    wds-cost-range=0 wds-default-cost=0 wmm-support=enabled wps-mode=disabled
/interface bridge port
add bridge=bridgeHallway comment=defconf interface=ether1
add bridge=bridgeHallway comment=defconf frame-types=\
    admit-only-untagged-and-priority-tagged interface=DevicesHallway pvid=45
add bridge=bridgeHallway comment=defconf frame-types=\
    admit-only-untagged-and-priority-tagged interface=Hallway5G pvid=11
add bridge=bridgeHallway frame-types=admit-only-untagged-and-priority-tagged \
    interface=VisitorWIFI pvid=200 trusted=yes
/interface bridge vlan
add bridge=bridgeHallway tagged=ether1 untagged=DevicesHallway vlan-ids=45
add bridge=bridgeHallway tagged=ether1 untagged=VisitorWIFI vlan-ids=200
add bridge=bridgeHallway tagged=bridgeHallway,ether1 untagged=Hallway5G vlan-ids=11
/ip address
add address=192.168.0.112/24 disabled=yes interface=ether2 network=\
    192.168.0.0
/ip route
add disabled=yes distance=1 gateway=192.168.0.1
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set ssh address=192.168.0.0/24 port=xx
set api disabled=yes
set winbox address=192.168.0.0/24 port=xx
set api-ssl disabled=yes

..
I note in your config you dont have the WLANS tagged with eth1?? But I do?
The only time you have eth1 tagged is for the line wanting base vlan etc.................

anav · Wed Mar 06, 2019 4:18 pm

Looking at the example of all in one..........

(1) what the heck is base vlan???????????????
/interface list member
add interface=ether1 list=WAN
add interface=BASE_VLAN list=VLAN
add interface=BLUE_VLAN list=VLAN
add interface=GREEN_VLAN list=VLAN

I also see base vlan in the first router example???
Ahh Okay its the homelan so to speak and using vlan99 here

BUT - I am not sure why assigning ether7 to be an access port has anything to do with admin access - very confused.
On top of that you have left the bridge assigned pvid=1 ????
If 99 is your base vlan, why is it not.

# create one bridge, set VLAN mode off while we configure
/interface bridge add name=BR1 protocol-mode=none vlan-filtering=no pvid=99 ?????????????????????

pcunite · Thu Mar 07, 2019 6:15 pm

1) What the heck is BASE_VLAN?
2) Why assign ether7 to be an access port?

The BASE_VLAN is a special network for accessing the MikroTik hardware. A network consists of routers, switches, and APs, so if every device has a BASE_VLAN interface, you can Winbox them from this special MGMT network. The firewall allows all input from this interface.

The above works great. However, I show optionally, what to do if you need physical access to a device if the router (RoaS) would be down. A special MGMT port will allow you to configure the device (but you could just use the console port). It shows how the BASE_VLAN can allow control to a device in front of you with your laptop plugged in directly. Recall that all other ports are blocking access to the device itself. You don't need it, it is just there for illustration.

anav · Thu Mar 07, 2019 6:42 pm

Well I beg to differ. I now understand why you made ether7 an access port but the rest of the discussion has not been resolved.
Many are having problems trying to implement your examples and many issues stem from the lack of clarity on pvid=1 vis pvid=99.
In other words what is being assigned to the bridge.................. and what affect it has on reaching devices such as router switches APs etc if selected either way??

pcunite · Thu Mar 07, 2019 7:08 pm

The rest of the discussion has not been resolved. Many are having problems trying to implement your examples and many issues stem from the lack of clarity on pvid=1 vs pvid=99. In other words, what is being assigned to the bridge, and what affect it has on reaching devices such as router, switches, APs, etc.

The bridge itself (aka BR1 there is only ever one bridge in my examples), should not have a pvid set, but instead should be left to the default of 1. I don't illustrate nor support the concept of a Native VLAN in these examples.

Quick Overview:
Bridge ~ pvid = 1
Access Port ~ pvid = 2 to 4095, pick your fav
Trunk Port ~ pvid = 1

All Access ports need ingress-filtering=yes, frame-types=admit-only-untagged-and-priority-tagged set and all Trunk ports need ingress-filtering=yes frame-types=admit-only-vlan-tagged set on them. At this point, you are locked out of the device! Thus, the concept of a BASE or MGMT VLAN is necessary.

anav · Thu Mar 07, 2019 9:45 pm

Concur and I am using vlan10 as base vlan.
The bridge is by itself, no vlan assigned and no subnet assigned.
However when I do that I lose connectivity to my capACs and router, they no longer showup in winbox.
I have to go back to lan on bridge and lan traffic on pvid=1 to see my devices.

Should I be associateding the bridge on capacs to pvid=10 ,,,,,,,,,, I think not.
So how do I ensure all devices are still reachable.

To reiterate my homelan is put on vlan10 in the above scenario, the capacs have a vlan10 address (are on my homelan subnet).
Yet I lose connectivity and funny things happen. Have not been able to nail it down yet.

pcunite · Thu Mar 07, 2019 11:21 pm

I lose connectivity to my cAP ACs and router, they no longer show up in Winbox. How do I ensure all devices are still reachable?

Winbox accessibility and visibility are two different features that are possible with MikroTik products. When using VLANs, the Neighbor Discovery protocol will not show devices as visible unless you are on the same VLAN L2 broadcast domain. However, you can always access your devices, using L3 features, if you have configured the firewall to allow for this.

Okay, so let's go over L3 accessibility. This is a Security concept. I've not yet finished writing that section (if I ever do). It is very personable and endlessly customizable. This is what makes it confusing to design because there are so many ways to do it.

MGMT (BASE_VLAN)
Configure the firewall and allow Winbox (8291) access from one or more networks. You could also allow based on port, IP, interface, etc. The point is that you must allow 8291 access from somewhere. You have to pick something and you have to do it before you're locked out.

# "list" feature for easy rule matchmaking.
/interface list add name=WAN
/interface list add name=VLAN
/interface list add name=BASE

/interface list member
add interface=ether1     list=WAN
add interface=BASE_VLAN  list=VLAN
add interface=BLUE_VLAN  list=VLAN
add interface=GREEN_VLAN list=VLAN
add interface=RED_VLAN   list=VLAN
add interface=BASE_VLAN  list=BASE

# Set the VLAN that can "see" L2 broadcast for Neighbor Discovery protocol
/ip neighbor discovery-settings set discover-interface-list=BASE

# Setup a firewall to allow connecting to Winbox (via L3 IP Address)
/ip firewall filter
add chain=input action=accept connection-state=established,related comment="Allow Estab & Related"

# Allow VLANs to use DNS services running on the Router
add chain=input action=accept dst-port=53 in-interface-list=VLAN protocol=udp comment="Allow VLAN DNS"

# Allow VLANs to access everything on the Router. NOT recommended
add chain=input action=accept disabled=yes in-interface-list=VLAN comment="Allow VLAN Everything" disabled=yes

# Allow BASE (MGMT) VLAN access to everything. Recommended
add chain=input action=accept in-interface=BASE_VLAN comment="Allow Base_Vlan to MikroTik"

# Allow Winbox access from a list of IP addresses. Change this to be different interfaces, whatever you want
add chain=input action=accept dst-port=8291,22 protocol=tcp src-address-list=RemoteAccess comment="Remote Winbox"

# Standard VLAN rules
add chain=input action=drop comment=Drop
add chain=forward action=accept connection-state=established,related comment="Allow Estab & Related"
add chain=forward action=accept connection-state=new in-interface-list=VLAN out-interface-list=WAN comment="VLAN Internet Access only"
add chain=forward action=drop comment=Drop

Okay, so the above allows access to the router itself (RoaS), that's nice. But what about all the other devices on the BASE_VLAN? There are two ways to get access to them. The easiest way is to simply become a member of the BASE_VLAN. You'll need an access port or SSID, but once you're on that network, you are in the MGMT layer. This is why I show a BASE_VLAN (id 99) option. But this is not always practical. What if you need to be on the RED_VLAN and need to connect via Winbox to an AP to change something?

Well, just like before, it all comes down to firewall rules. This time, we configure them in the forward chain. You could do something like this:

/ip firewall filter

# Forward rules that allow for port forwarding
add chain=forward action=accept connection-state=established,related comment="Allow Estab & Related"
add chain=forward action=accept connection-state=new in-interface-list=VLAN out-interface-list=WAN comment="VLAN Internet Access only"
add chain=forward action=accept connection-nat-state=dstnat in-interface=ether1 comment="Allow port forwards"
add chain=forward action=drop comment=Drop

/ip firewall nat
add chain=srcnat action=masquerade out-interface-list=WAN

# Winbox to AP1 & AP2
add chain=dstnat action=dst-nat dst-port=8301 to-ports=8291 in-interface=ether1 protocol=tcp to-addresses=10.0.0.2 src-address-list=RemoteAccess
add chain=dstnat action=dst-nat dst-port=8302 to-ports=8291 in-interface=ether1 protocol=tcp to-addresses=10.0.0.3 src-address-list=RemoteAccess

anav · Sat Mar 09, 2019 8:22 pm

Thanks PCUNITE, concur matter of ip services winbox and also MAC SERVER under tools (ensuring management vlan is the interface so designated).
Understand about L3 if require access from a different LAN or VLAN will depend upon firewall rules and ensuring the PC (the non vlan IP) has permissions to access winbox.

For me the granular change required is to ensure the managment vlan AND BRIDGE itself are tagged on the Trunk port (for my capac).

anav · Wed Apr 10, 2019 3:30 am

The evolution of the examples is going great. Very useable and straightforward.
I also note that MT is working hard to try and keep their wiki on the topic in better shape too.
One thing they do discuss that you dont mention is hybrid ports.
Where PVID is set but also other vlans are tagged on the same port. I believe they say that is not a safe way to operate security wise in conclusion but it wasnt clear.

pcunite · Wed Apr 10, 2019 5:37 am

One thing MikroTik discusses that you don't mention is hybrid ports ... I believe they say this is not a safe way to operate security wise in conclusion but it wasn't clear.

If you trust your equipment, yourself, and your end users, you can use hybrid ports. You're giving a device the ability to send packets with or without a tag. This can be valid for when you want to connect a PC to a VoIP phone.

VoIP phones are really two port switches. One port for themselves, and the other for another device. This is done so that only one port on your switch gets utilized (because running two network drops to each desk is not as cost effective). Traffic from this mini VoIP switch can be tagged (itself) or tag less (the PC).

Unfortunately, this means that an intruder might have the opportunity to access your VoIP VLAN. Imagine someone unplugging both the VoIP phone and the PC. Then plugging in a rogue switch into your hybrid port. They get to choose the VoIP VLAN. Their rogue laptop, connected to this rogue switch, starts hacking away at your PBX server. In any event, they have the security and QoS behavior of the VoIP VLAN. That can be good or bad for their intentions.

anav · Wed Apr 10, 2019 2:43 pm

I was more thinking of the home scenario where I had my Managed Switch(dlink) which was feeding an unmanaged switch in the basement to which a CAPAC was attached.
The capac needed vlans but the unmanaged switch wasn't cutting the mustard. They hybrid feed from the dlink actually worked and fine for home but not for a business environment.
Since I changed my homelan to a vlan, the option was removed and replaced with a more secure method that you describe in your article. At least I know the option of hybrid is there if ever required.

mkx · Wed Apr 10, 2019 4:53 pm

To add my 5 cents: I don't think using hybrid ports is any less (or more) secure than using trunk (or untagged access) ports. Actually using VLANs doesn't change anything with regard to security ... if a plaintiff has physical access to LAN infrastructure, then he's in admin's nightmare already.

anttech · Thu Apr 11, 2019 5:17 pm

Hi all

i have using the info on this page to setup vlans.

The vlans seem to work but i want to route traffic between them

Here is my config file, i need to get this working asap.

I have a Hex router and have etup port 4 as one vland and port 5 as another and want to be able to ping traffic on either vlan from the other
Here is the config

/interface bridge
add admin-mac=B8:69:F4:BF:6A:40 auto-mac=no comment=defconf name=bridge vlan-filtering=yes
/interface vlan
add interface=bridge name=Control vlan-id=20
add interface=bridge name=Lighting vlan-id=10
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
add name=VLAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip pool
add name=control-dhcp ranges=10.0.100.230-10.0.100.249
add name=Lighting-dhcp ranges=10.101.10.230-10.101.10.249
/ip dhcp-server
add address-pool=control-dhcp disabled=no interface=Control name=control
add address-pool=Lighting-dhcp disabled=no interface=Lighting name=lighting_dhcp
/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf frame-types=admit-only-untagged-and-priority-tagged interface=ether4 pvid=20
add bridge=bridge comment=defconf frame-types=admit-only-untagged-and-priority-tagged interface=ether5 pvid=10
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface bridge vlan
add bridge=bridge comment=lighting tagged=bridge untagged=ether5 vlan-ids=10
add bridge=bridge comment=control tagged=bridge untagged=ether4 vlan-ids=20
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
add interface=Lighting list=VLAN
add interface=Control list=VLAN
/ip address
add address=10.0.100.254/24 comment=defconf interface=Control network=10.0.100.0
add address=10.101.10.254/24 interface=Lighting network=10.101.10.0
/ip dhcp-client
add comment=defconf dhcp-options=hostname,clientid disabled=no interface=ether1
/ip dhcp-server network
add address=10.0.100.0/24 comment=defconf gateway=10.0.100.254
add address=10.101.10.0/24 gateway=10.101.10.254
/ip dns
set allow-remote-requests=yes
/ip dns static
add address=192.168.88.1 name=router.lan
/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=accept chain=input comment="Allow VLAN" in-interface-list=VLAN
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=accept chain=input comment="Allow Estab & Related" connection-state=established,related
add action=accept chain=input comment="Allow VLAN" in-interface-list=VLAN
add action=drop chain=input comment=Drop
add action=accept chain=forward comment="Allow Estab & Related" connection-state=established,related
add action=accept chain=forward comment="VLAN inter-VLAN routing" connection-state=new in-interface-list=VLAN
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
add action=drop chain=forward comment=Drop
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN

sindy · Thu Apr 11, 2019 6:07 pm

I cannot spot anything wrong in your configuration, so if you cannot ping between devices in different VLANs, I'd blame the firewalls on those devices themselves. Use /ip dhcp-server lease print to check that the devices in both VLANs got their IP addresses and accepted them, and then use /tool sniffer to see whether ping requests from a device in one VLAN are being sent out the etherX serving as access one to the other VLAN (which will confirm that Mikrotik routes them properly).

mixig · Fri Jun 07, 2019 7:05 pm

This is great but I have one question regarding this topic (exapmle is from wiki):
Add the bridge ports and specify PVID for each access port:

/interface bridge port
add bridge=bridge1 interface=ether1
add bridge=bridge1 interface=ether2 pvid=20
add bridge=bridge1 interface=ether3 pvid=30
Icon-note.png
Note: PVID has no effect until VLAN filtering is enabled.

Add appropriate entries in the bridge VLAN table:

/interface bridge vlan
add bridge=bridge1 tagged=ether1 untagged=ether2 vlan-ids=20
add bridge=bridge1 tagged=ether1 untagged=ether3 vlan-ids=30

Why do we need configure in /interface bridge vlan untagged=ether2 vlan-ids 20 when in step before we setup PVID20 (same form eth3, where PVID 30 iconfigured.
It is also working fine without specifying that particular port to be untagged (PVID will automatically add that port to current untagged...

anav · Fri Jun 07, 2019 9:06 pm

@antech, this thread is to discuss the examples provided by the author. If you are having VLAN issues please start another thread. When you do I will point out the obvious error I spotted.

@mixig, please read through the reference from beginning to end, the answer you seek is answered within, hint - when you understand the purpose of both functions and how they pertain to the ingress and egress of vlan packets.

Sat Jun 29, 2019 2:32 pm

Great job and very informative. Thank you for this.
I am looking for a vlan configuration for my CCR-1036
VLAN 10.20.30 for example
I want two trunks, one of which goes to a CRS 328 with VLAN
10.20.30 and this via SFP + 1 the second SFP port would be used as a trunk to the CRS-326 and this with VLAN 20 and 30 as
I would also like to set Ethernet ports 23 and 24 as a trunk for connecting a Unifi controller and Unifi access point

Can you work this out if you want?
regards
Plisken

sindy · Sat Jun 29, 2019 3:11 pm

Can you work this out if you want?

I don't think this is the correct topic for this. By means of software bridges, this can be done using the information provided by @pcunite, who has stated the purpose of this topic to be a substitute for a missing layer of the documentation, not a place where people could ask for individual help. So if individual help is what you need, open a new topic for that, please.

If you had in mind extending this topic with howtos for use of hardware VLAN filtering on different switch chip types and the particular configuration you've suggested was just an example, I don't know how to do that any simpler/more comprehensible than the official wiki on the switch chip features.

HiltonT · Fri Jul 19, 2019 1:31 am

"The router's Purple Trunk port sees a Blue DHCP request and spins up a Blue DHCP server running on a configured Blue VLAN interface."

That's not actually how it works. The DHCP Server needs to be set up and running - it isn't "spun up" by the router receiving a DHCP Request from a device.

Now, I know that you know that, but the wording as originally presented is incorrect and may be confusing for some.

benjaminhso · Fri Jul 19, 2019 4:52 pm

Thank you very much PCunite for your tutroial. It helped a lot.

May be sombody has any Idea.

I configurtated the CRS328 like the Switch CRS. VLAN speration is working.

But I don´t want to user an external Router (Its an testing setup), so I tried to confugrate the CRS328 also for routing between the VLAN. Like its descripted in the router.src with:

# Blue VLAN interface creation, IP assignment, and DHCP service
/interface vlan add interface=BR1 name=BLUE_VLAN vlan-id=10
/ip address add interface=BLUE_VLAN address=10.0.10.1/24
/ip pool add name=BLUE_POOL ranges=10.0.10.2-10.0.10.254
/ip dhcp-server add address-pool=BLUE_POOL interface=BLUE_VLAN name=BLUE_DHCP disabled=no
/ip dhcp-server network add address=10.0.10.0/24 dns-server=192.168.0.1 gateway=10.0.10.1

But now wehen I try to ping the Blue-VLAN Interface with any client in the VLAN there is no respond. Also DHCP is not working. Also tried the VLAN Interface as untagged and tagged IF in the VLAN.

Can me anbody explain where my thinking fault is?

Thanks Benjamin

sindy · Sat Jul 20, 2019 9:08 am

Can me anbody explain where my thinking fault is?

Create a new dedicated topic an post the complete config there. The few lines you've posted look fine as such so there is likely a firewall issue.

marinaman · Thu Aug 01, 2019 7:32 pm

Hi pcunite, This is great thread/work! I need help are you for hire?

If so - how can I contact you?

Thanks

anav · Thu Aug 01, 2019 7:50 pm

https://mikrotik.com/consultants

ZiadZone · Tue Aug 27, 2019 11:39 am

Nice .. Clean .. Deep topic covering most of the new way of bridge vlan concept ..

For my past and legacy configuration of vlans setup I do want to move up my router configuration to the new approach +6.41
but sadly i couldn't find a topic covering what i am looking for .. If you find one you are welcome to point me there

So here is my past configuration:
1- Create vlan1, vlan2, vlan3 ... assign them to ether5 port on my CCR router --> /interface vlan create vlan1, vlan2 ...
2- Create bridge1
3- Create bridge1 ports for all vlans and do l2 isolation with (horizon: 1) for all the ports. /interface bridge ports ...
4- Create IP Address (/24) and assign it to the bridge interface then create DHCP server, Hotspot, do Nat based on the bridge interface too

That's it..
I just want to mention is why doing this setup because running my public wifi with Ubiquiti NSM2 access points and each AP is assigned one vlan id created in (step 1), so with value (horizon: 1) mentioned in (step 3) I'm isolating each AP connected hosts from the other APs devices, and this is my primary target (APs Isolation from each other)

I read along this wiki post
https://wiki.mikrotik.com/wiki/Manual:L ... _interface

and i believe my configuration is among the wrong way of working with vlans but the solutions not applicable to my current configuratoin ..
so you are welcome guiding me to the right way doing it

anav · Wed Aug 28, 2019 6:50 pm

start a new thread if you wish help on your configuration.

ZiadZone · Thu Aug 29, 2019 11:59 am

Done anav ..

viewtopic.php?f=7&t=151631&sid=abafa8b2 ... c9634d55bb

Thanks in advance for help everyone

aa10 · Sat Aug 31, 2019 2:45 am

Thank you for making this post.

I have a question regarding the Router-Switch-AP (all in one) -- Config File: RouterSwitchAP.rsc.

Shouldn't the following be added to drop all untagged packets that are destined to the CPU port?

/interface bridge
set BR1 frame-types=admit-only-vlan-tagged ingress-filtering=yes

https://wiki.mikrotik.com/wiki/Manual:Bridge_VLAN_Table

It is possible to drop all untagged packets that are destined to the CPU port:

/interface bridge
set bridge1 frame-types=admit-only-vlan-tagged ingress-filtering=yes

This does not only drop untagged packets, but this disables the feature that dynamically adds untagged ports to the bridge VLAN table. If you print out the current bridge VLAN table you would notice that bridge1 is not dynamically added as an untagged port:

[admin@MikroTik] > /interface bridge vlan print

...

Note: When frame-type=admit-only-vlan-tagged is used on a port, then the port is not dynamically added as untagged port for the PVID.

foraster · Sat Oct 12, 2019 1:09 am

Hi, thanks for the tutorial.
I've been trying the all in one (switch+router+ap) template but can't make it assign any IP with the DHCP servers associated with the vlans.
Will it work out of the box in a HAP AC2?

anav · Sat Oct 12, 2019 5:30 am

@foraster, it should work, please start a new thread and include your config.
/export hide-sensitive file=yourconfig

StubArea51 · Sun Oct 13, 2019 3:40 pm

If you're coming from Cisco, this may also be helpful for bridge VLAN configuration in MIkroTik.

https://www.stubarea51.net/2019/02/06/c ... and-vlans/

foraster · Sun Oct 13, 2019 11:50 pm

If you're coming from Cisco, this may also be helpful for bridge VLAN configuration in MIkroTik.

https://www.stubarea51.net/2019/02/06/c ... and-vlans/

Thanks for the reference, it will be very helpful!

andye2004 · Tue Nov 12, 2019 3:09 pm

The router.rsc file in post 2 of this thread looks like it has an error, it has the following:

# egress behavior
/interface bridge plan

Should this not be?

# egress behavior
/interface bridge vlan

Note: vlan instead of plan.

helipos · Sun Jan 05, 2020 11:51 am

/ip address add interface=ether1 address=a.a.a.a/aa network=a.a.a.0
If you really care, its in the RouterswitchAP file.

Other than that AWESOME guide, thank you so much for helping so many confused/bewildered people with this.
When you are finished I hope it gets Wiki'd and Mikrotik let you choose some goodies as recompense. Between youself mkx and sindy you have earned it.

comet48 · Wed Jan 08, 2020 7:57 pm

Fantastic explanation. One can only wish MT documentation was more like this. And, it's in real English!

wirelessadweb · Fri Jan 24, 2020 2:26 pm

First off thank you for this posting pcunite I have adapted the RouterSwitchAP config to a RB4011 and it is easy to follow.

I am trying to route one of the VLANs over a L2TP connection, I can get the connection L2TP connection up and route all traffic down it. But was hoping for advice on the best practice to route one of the VLANs only while maintaining a connection to the Internet with the other 2 VLANs.

Thanks in advance

mur · Mon Feb 17, 2020 1:10 pm

As for the topic "Switch with a separate router (RoaS)", what is the difference between the Switch Config File and the Router Config File?
Thank you very much.

pcunite · Mon Feb 17, 2020 10:28 pm

in the topic Switch with a separate router (RoaS), what is the difference between the Switch Config file and the Router Config file?

The two files are the configurations for the two hardware devices that will be in use. One a switch, the other a router.

mur · Mon Feb 17, 2020 11:37 pm

in the topic Switch with a separate router (RoaS), what is the difference between the Switch Config file and the Router Config file?

The two files are the configurations for the two hardware devices that will be in use. One a switch, the other a router.

Just to make sure I got it right.
Which is the correct file for this device:

https://mikrotik.com/product/hap_ac2

Thank you

anav · Tue Feb 18, 2020 12:36 am

The fun thing about MT devices is there is no one answer EVER! LOL.

IF its acting as a router and access point, look for this file........... "Router-Switch-AP (all in one)"
IF its acting solely as an access point, look for this file ............. "Access Point"
IF its acting solely as a switch, look for this file............. "Switch with a separate router (RoaS): and use the switch config.

mur · Tue Feb 18, 2020 10:09 am

The fun thing about MT devices is there is no one answer EVER! LOL.

IF its acting as a router and access point, look for this file........... "Router-Switch-AP (all in one)"
IF its acting solely as an access point, look for this file ............. "Access Point"
IF its acting solely as a switch, look for this file............. "Switch with a separate router (RoaS): and use the switch config.

Got it, thanks!

iisti · Wed Mar 04, 2020 8:55 pm

My 2 cents: this is not actually about Mikrotik software/hardware, but I've read multiple topics in this forum where people are wondering why Ping is not working between different VLANs. Sometimes the issue is fixed with firewall srcnat rules.

Usually the source of confusion is Windows firewall's default rule which doesn't allow ping between different subnets. If you enable the default File and Printer Sharing (Echo Request - ICMPv4-In) echo/icmp/ping firewall rules in Windows 10 firewall, only Local subnet is allowed as Remote Address in Private/Public profiles.

One needs to add networks/subnets by right mouse clicking the firewall rule -> Properties -> Scope, add network like 192.168.0.0/16 or select Any.

brg3466 · Mon Mar 09, 2020 6:28 am

@pcunite, this is very helpful and informative tutorial I've ever seen in this forum regarding the new Vlan setup. (bridge vlan table).
I have a couple of questions after reading thru your material.
1. If there are several APs connected to the switch, and using CAPsMAN to manage the APs (with local forwarding mode) , as illustrated in the below wiki link: https://wiki.mikrotik.com/wiki/Manual:C ... with_VLANs, say, APs are connected to the ETH2 and ETH3 port of swtich, then the ETH2 and ETH3 are considered as the trunk port ?
2. The setup in the wiki is different from the AccessPoint.rsc, esp. no set up at all on bridge vlan table. Can you explain a bit on it ?
3. Also, I noticed that your configuration has bridge vlan table set on both router and swtich, while the wiki only have bridge vlan table on switch. Why is that ?

4. I tried your RoaS file: router.rsc on 951G-2Hn (as the router). But with the router.rsc, after the set up without any firewall, I cannot get internet from ETH2-ETH5. See below configuration details. Can you look into it ?

Thank you !

# mar/08/2020 20:37:59 by RouterOS 6.46.4

# model = 951G-2HnD

/interface bridge
add name=bridge1
/interface ethernet
set [ find default-name=ether1 ] name=ether1-WAN
/interface vlan
add interface=bridge1 name=vlan10 vlan-id=10
add interface=bridge1 name=vlan20 vlan-id=20
add interface=bridge1 name=vlan99 vlan-id=99

/ip pool
add name=dhcp_pool0 ranges=10.0.10.2-10.0.10.254
add name=dhcp_pool1 ranges=10.0.20.2-10.0.20.254
add name=dhcp_pool2 ranges=192.168.0.10-192.168.0.254

/ip dhcp-server
add address-pool=dhcp_pool0 disabled=no interface=vlan10 name=dhcp10
add address-pool=dhcp_pool1 disabled=no interface=vlan20 name=dhcp20
add address-pool=dhcp_pool2 disabled=no interface=vlan99 name=dhcp99

/interface bridge port
add bridge=bridge1 interface=ether4
add bridge=bridge1 interface=ether2
add bridge=bridge1 interface=ether3
add bridge=bridge1 interface=ether5

/interface bridge vlan
add bridge=bridge1 tagged=bridge1,ether2,ether3,ether4,ether5 vlan-ids=10
add bridge=bridge1 tagged=bridge1,ether2,ether3,ether4,ether5 vlan-ids=20
add bridge=bridge1 tagged=bridge1,ether2,ether3,ether4,ether5 vlan-ids=99

/ip address
add address=192.168.0.1/24 interface=vlan99 network=192.168.0.0
add address=10.0.10.1/24 interface=vlan10 network=10.0.10.0
add address=10.0.20.1/24 interface=vlan20 network=10.0.20.0

/ip dhcp-client
add disabled=no interface=ether1-WAN

/ip dhcp-server network
add address=10.0.10.0/24 dns-server=192.168.0.1 gateway=10.0.10.1
add address=10.0.20.0/24 dns-server=192.168.0.1 gateway=10.0.20.1
add address=192.168.0.0/24 dns-server=192.168.0.1 gateway=192.168.0.1

/ip dns
set allow-remote-requests=yes servers=8.8.8.8

/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1-WAN

anav · Mon Mar 09, 2020 2:35 pm

1. It depends, assuming we are avoiding hybrid ports, then if there is only one vlan going to the AP then it could be an access port (optional). However as soon as you have two or more vlans it becomes a trunk port.
2. pcunite has great examples and this includes basically bridge to bridge (trunk port to trunk port) connectivity between devices with the vlans coming out of the bridges connected to the various ports or wlans. So suggesting follow his examples. They work!
3. Same for the switch.
Note: In both two and three the bridge vlan setups serve two functions
a. provide the functionality desired on that device (be it router, switch or AP)
b. route traffic or bridge traffic (if no routing on the next device) to the next device handoff to the next bridge.
4. IF YOU HAVE A CONFIGURATION ISSUE start a new thread, in your case probably due to your firewall setup, but like I said start a new thread for config issues.

brg3466 · Mon Mar 09, 2020 7:14 pm

@anav.
#1,2,3. Thank you for the explanation !
#4. it is just a copy of configuration of the router.rsc from pcunite. I just changed the name of blue_VLan and green_Vlan to Vlan 10 and Vlan20, all the set up are Exactly same as router.rsc. Also, I didn't put any firewall. BUT I cannot get internet from Ether2 to Ether5. That is why I asked here. I just want to try it according this tutorial see if it works.

Thank you !

mkx · Mon Mar 09, 2020 8:47 pm

BUT I cannot get internet from Ether2 to Ether5. That is why I asked here. I just want to try it according this tutorial see if it works.

I'm sure you're aware that when configured according to settings posted, none of interfaces allow untagged (access) connectivity. So to test things, you can't simply plug in a normal PC and expect "something to happen". You either need to configure interface as access (untagged) port for selected VLAN or configure PC to properly deal with tagged ethernet frames.

anav · Mon Mar 09, 2020 9:04 pm

BUT I cannot get internet from Ether2 to Ether5. That is why I asked here. I just want to try it according this tutorial see if it works.
I'm sure you're aware that when configured according to settings posted, none of interfaces allow untagged (access) connectivity. So to test things, you can't simply plug in a normal PC and expect "something to happen". You either need to configure interface as access (untagged) port for selected VLAN or configure PC to properly deal with tagged ethernet frames.

Too funny I assumed due to his config that all the ports were considered trunk ports and going to managed switches or business class APs etc.........
Especially if the OP had read the thread.............

mkx · Tue Mar 10, 2020 9:48 am

Too funny I assumed ...

Me too. But sometimes it's necessary to state the obvious specially to less knowledgeable who tend to overlook things ... But after all, my post was a long shot and might be completely off the target. Let's wait for feedback from @brg3466 ...

iisti · Wed Mar 11, 2020 6:06 pm

I fine grained the firewall rules a bit. I hope these can help somebody and better security of your network. I am by no means a Mikrotik or firewall expert. Any improvements are welcome.
There is more information about securing your router in the wiki page https://wiki.mikrotik.com/wiki/Manual:S ... our_Router

I focused on the setup below, version of RouterOS 6.46.3:

Switch with a separate router (RoaS)
viewtopic.php?f=13&t=143620#p706997



# Please note that these rules are using "all-vlan" interface and
# it is assumed that gateway/uplink interface is not using VLAN.
# If gateway/uplink interface uses VLAN, use interface lists instead of
# all-vlan.
# all-vlan example was found from the topic below:
# https://forum.mikrotik.com
# Search for: "Comfortable way to block inter-vlan traffic"
#   Attention, when pasting to serial connection, the whole URL
#   seems to have some strange effects because of the question mark in
#   the URL, even when it's commented out, so the whole URL is not
#   written above.

/ip firewall filter

######## ROUTER FIREWALL RULES ########

# Allow traffic back as long as the traffic has started from "inside"
# your network.
add action=accept chain=input comment="Allow Established & Related" \
    connection-state=established,related
    
# If you're using IPsec, allow untracked.
# This rule is especially important if one is using "Drop all"
# as the last rule.
# More information in forum.mikrotik.com topic:
# "New" default firewall config in ROS - why ipsec is default allowed
add action=accept chain=input \
    comment="Allow untracked" connection-state=untracked disabled=yes
    
# Allow DNS requests from VLANs (udp/tcp)
add action=accept chain=input comment=\
    "Allow DNS requests from LAN / VLANs UDP" dst-port=53 in-interface=\
    all-vlan protocol=udp
add action=accept chain=input comment=\
    "Allow DNS requrests from LAN / VLANs TCP" dst-port=53 in-interface=\
    all-vlan protocol=tcp
    
# Allow pinging the router from the VLANs
# This is mainly a troubleshooting option to check:
# "Why my internet is not working? Well, I can ping the gateway."
add action=accept chain=input comment=\
    "Allow pinging the router  from LAN / VLANs" in-interface=all-vlan \
    protocol=icmp
    
# Allow full access to your router from the Base / Management VLAN
add action=accept chain=input comment="Allow Base Full Access" in-interface=\
    BASE_VLAN

# Allow PING from internet. Might be nice or not.
# It's disabled by default in this conf.
add action=accept chain=input comment="Allow PING from internet" disabled=yes \
    protocol=icmp

# It's important to drop everything else incoming traffic to router,
# so any malicious intends are blocked.
add action=drop chain=input comment="Drop everything else in input"



######## CLIENT/INTERNAL NETWORK FIREWALL RULES ########

# Allow traffic back as long as the traffic has started from "inside"
# client/internal network. 
add action=accept chain=forward comment="Allow Established & Related" \
    connection-state=established,related

# If you're using IPsec, allow untracked.
# This rule is especially important if one is using "Drop all"
# as the last rule.
# More information in forum.mikrotik.com topic:
# "New" default firewall config in ROS - why ipsec is default allowed
add action=accept chain=forward \
    comment="Allow untracked" connection-state=untracked disabled=yes
    
# Allow Base / Management VLAN to connect any other VLAN
add action=accept chain=forward comment=\
    "Allow BASE / mgmt to connect all VLANs" in-interface=BASE_VLAN \
    out-interface=all-vlan

# This rule is associated with the rule below about stopping inter-VLAN
# communication (or drop all). If VLAN communication between certain VLANs
# is required, one can add something like the examples below.
# Notice that one can also only allow one direction of communication.
# In this example communication is allowed in both directions between
# BLUE and GREEN VLANs.
# Notice that the rules are disabled by default.
add action=accept chain=forward \
    comment="Allow communication from BLUE to GREEN VLAN" disabled=yes \
    in-interface=BLUE_VLAN out-interface=GREEN_VLAN
add action=accept chain=forward \
    comment="Allow communication from GREEN to BLUE VLAN" disabled=yes \
    in-interface=GREEN_VLAN out-interface=BLUE_VLAN

# Stop VLANs from communicating each other. By default VLANs are able
# to communicate each other, which doesn't make sense security-wise
# in many scenarios.
# Notice that this doesn't stop VLANs from pinging different
# router/bridge IPs. This doesn't also stop clients inside a certain
# VLAN from communicating each other.
# Notice that this rule is pointless if "Drop all" rule is being used.
add action=drop chain=forward comment="Drop all inter-VLAN traffic" \
    in-interface=all-vlan out-interface=all-vlan

# Drop invalid packets in forward chain is required if one is using NAT.
# Otherwise it's possible that packets leave router with wrong LAN IP address.
# Notice that this rule is pointless if "Drop all" rule is being used.
add action=drop chain=forward comment="Drop invalid in forward chain" \
    connection-state=invalid

# This is a bit of preference of firewall rule creator if "drop all" or
# the "drop invalid" should be used.
# If this rule is used, then the above "drop invalid" and
# "drop inter-vlan communication" are pointless.
# Notice that in this example this is disabled.
add action=drop chain=forward comment="Drop all" disabled=yes

EDIT 1: Optimized order of rules
EDIT 2: Added RouterOS version, untracked and drop all rules. Improved some notes of rules.

anav · Wed Mar 11, 2020 6:26 pm

Firewall rules seem screwy.

(1) This first rule should be moved in order to after the established related rule.
# Allow Base / Management VLAN to connect any other VLAN
add action=accept chain=forward comment=\
"Allow BASE / mgmt to connect all VLANs" in-interface=BASE_VLAN \
out-interface=all-vlan

(2) For VLANS, did you create interface lists?
That is one approach, the other is to create firewall address lists of the subnets in either case i would expect the rule to look more like
add action=accept chain=forward comment=\
"Allow BASE / mgmt to connect all VLANs" in-interface=BASE_VLAN \ {single vlan}
out-interface-list=all-vlan OR dst-address-list=AMV (AMV=All my vlan. A FW address list consisting of all the subnets of the vlans). {multiple vlans}

(3) Same issue with your input rule for DNS on port 53. You should identify your vlans by creating an interface list or by creating a firewall address list and using the appropriate config items
in-interface-list or out-interface-list / source-address-list or destination-address list

(4) Dont' recall seeing this one before, perhaps getting old. Just dont know why you have this one - purpose??
# Allow pinging the router from the VLANs
add action=accept chain=input comment=\
"Allow pinging the router from LAN / VLANs" in-interface=all-vlan \
protocol=icmp

(5) You have a redundant (not needed firewall rule) Get rid of this rule because your last rule does the same thing plus more...............
add action=drop chain=forward comment="Drop all inter-VLAN traffic" \
in-interface=all-vlan out-interface=all-vlan

Note: Not sure what you understand but by having subnets on different vlans they are blocked at Layer 2 (cannot see each other). We use Firewall rules to block any crosstalk at L3 because otherwise the router knows where they are and will try to connect them up upon a request. The last rule DROP ALL ELSE is matched by the router and thus all vlan crosstalk attempts are stopped cold at L3.

iisti · Wed Mar 11, 2020 11:05 pm

Reference to viewtopic.php?f=13&t=143620#p779492

1. Yep, this is clear mistake. Just made sure in when I was testing that I'm not screwing up. Swapped the rules in original post viewtopic.php?f=13&t=143620#p779484

2. The firewall rules should work with the original Router configuration of post viewtopic.php?f=13&t=143620#p706997
Yes, there are lists, but I don't see point to use self-managed list when an integrated "all-vlan" interface can be used. This way every VLAN is for sure included in the firewall rule.
Please give an example why interface list "All my vlan" is better than integrated all-vlan.

If there's only one management VLAN, I don't see much benefit using a list for BASE/Management VLAN, but of course it's possible to use it. Though I'm not quite sure in which scenario one needs multiple management VLANs, complexity doesn't mean more security. And well those who need multiple management VLANs are probably not reading this thread in Beginner Basics.

3. same as 2.

4. One steps in my list to troubleshoot "why network isn't working" is to ping gateway. In the rule set everything else than DNS and PING are disabled from client LANs.

5. Well, I can test this again tomorrow, but I'm quite sure I can ping/RDP/etc from VLAN to another without this rule, I think Mikrotik RouterOS's default behavior is to allow inter-VLAN communication.
I'm not sure which "DROP ALL ELSE" rule is being talked about. This rule is input chain, not in forward chain.

add action=drop chain=input comment="Drop everything else in input"

anav · Thu Mar 12, 2020 5:24 am

Yes, you need a drop rule at the end of the forward chain and this covers off more than just vlan to vlan traffic but ANY traffic you do not specifically permit.
Due to the mess of order in your presented rule set I mistook the invalid packets to be that rule.

WIthout a real config how does your all-vlan look like, where did you make it.
My comments stand until you can demonstrate otherwise. Stating interface and not interface list its really unclear what you have done.
The only way to make an all anything in interfaces is to define the interfaces indentified as a new list and then use interface-list parameter.
So lets say I have vlana, vlanb and vlanc
I make up an interface list
vlana=groupvlan
vlanb=groupvlan
vlanc=groupvlan

Now I want to make a rule that allows the admin on vland to access them all I would state it as
add action=accept chain=forward in-inteface=vland source-address=myPCsIPaddress out-interface-list=groupvlan

or lets say the vlans need access to a printer on vland
add action=accept chain=forward in-interface-list=groupvlan destination-address=PrinterIP address

iisti · Thu Mar 12, 2020 11:12 am

I'm using RouterOS 6.46.3 (added this info to the original post also).

I'm sorry if I wasn't clear enough. The RouterOS configuration I'm using is same as in the post viewtopic.php?f=13&t=143620#p706997 like I stated in my original post viewtopic.php?f=13&t=143620#p779484 I've changed some interface names and IP ranges, but essentially it's the same configuration.

"all-vlan" is a built-in interface in RouterOS. I didn't create it.
If one goes to RouterOS command line and writes command below and hits "tab" to see available interfaces, one should see something like the output below.
/ip firewall filter add in-interface=

Output should be like this:

BASE_VLAN    GREEN_VLAN     ether4-trunk         
BLUE_VLAN    all-vlan       ether5-trunk 
BR1          ether1-gw      ! 
all-ethernet ether2
all-ppp      ether3

One can also check the existence of "all-vlan" interface by logging into RouterOS with WinBox or HTTPS, and then going IP -> Firewall -> Filter Rules -> Add rule, check from In. Interface drop down menu the existence of "all-vlan".

I'll ask again, please clarify why it's better to use self managed "my all VLANs" list than use built-in feature of RouterOS?

Mikrotik's own wiki page of securing router doesn't include "drop everything else" rule in forward chain. I think there would be a need for another topic for discussion if "drop everything else" vs "drop invalid" is better in forward chain. Another reason why I didn't include "drop everything else" in forward chain was that I wasn't sure is "untracked" needed or not. But as stated in the explanation below with untracked forward chain addition, "drop everything else" could be added to the rule set.

https://wiki.mikrotik.com/wiki/Manual:S ... our_Router

Based on the post below (by Mikrotik support) if one is using IPsec and "drop everything else" rule, one should add "untracked" to be accepted in input and forward chain.

"New" default firewall config in ROS - why ipsec is default allowed?
viewtopic.php?t=128135#p630599

Why at least dropping invalid packets is required:

Drop invalid rule is necessary if you use NAT on your router. It is possible that for different reasons packet can leave router with wrong (LAN) IP address. This firewall rule will drop such packets.

From Mikrotik support post:

Is missing connection-state=invalid hugely bad?
viewtopic.php?t=125109#p616221

anav · Thu Mar 12, 2020 2:11 pm

Start your own thread. This is about vlans and its veered off into firewall rules.

mkx · Thu Mar 12, 2020 2:19 pm

Mikrotik's own wiki page of securing router doesn't include "drop everything else" rule in forward chain. I think there would be a need for another topic for discussion if "drop everything else" vs "drop invalid" is better in forward chain.

When it comes to firewall, there is no correct answer to your question.

Actually there are two philosophies floating around:

drop whatever should not pass. This philosophy seems intrinsic to linux/ROS as implicit default is to allow traffic unless explicitly denied
allow only what should pass and (explicitly) drop all other

Whichever philosophy selected one has to be careful to implement it right (and air-tight).

Many users around like philosophy #2 for one reason: it's easier to spot something that should pass (but it's not) than to spot each and every connection that should not pass.

And no, Mikrotik's documents should not be taken as any kind of ultimate guide to secure networking, MT's defaults (including firewall) have changed in the past and will likely change again in the future. And some MT documents are hopelessly obsolete (they do try to maintain documentation current one must say). So argument that "MT doesn't do it this or that way" is as relevant as any other random advice you might get on this forum (while both are more trustworthy than most of what can be found on e.g. youtube).

iisti · Thu Mar 12, 2020 3:09 pm

@anav I thought there was a section of security intended in this thread also. At least I'm using VLANs mostly because of security reasons.

@mkx fair points and certainly true that Mikrotik's documentation is quite lacking in some areas. As an example I didn't really find anything about "all-vlan" interface in the docs, which seems to be quite handy feature. I'm just trying to give some reference for other readers to make up their own opinion.

Though now the topic goes completely off-topic. I'll stop posting.

anav · Thu Mar 12, 2020 6:20 pm

Where is the ALL VLAN option. I cannot find it on my router?? The one where I can use it rules with "Interface" only (and not interface-list)/
Can you post your config??

mkx · Thu Mar 12, 2020 7:30 pm

Where is the ALL VLAN option. I cannot find it on my router?? The one where I can use it rules with "Interface" only (and not interface-list)/

That's the one.

anav · Thu Mar 12, 2020 7:55 pm

Where is the ALL VLAN option. I cannot find it on my router?? The one where I can use it rules with "Interface" only (and not interface-list)/
That's the one.

Hehe I must be blind I will look when I get home, I could have sworn there was only WAN and LAN and everything else one had to create.

sindy · Thu Mar 12, 2020 8:53 pm

Hehe I must be blind I will look when I get home, I could have sworn there was only WAN and LAN and everything else one had to create.

To me it seems as some relict of the past before the user-managed interface lists have been introduced - pre-defined items all-vlan, all-ppp, all-wireless, all-ethernet really exist. But although functionally these items are lists, their names have to be used as values of in-interface and out-interface, not of in-interface-list and out-interface-list.

spi43458 · Sun Mar 15, 2020 8:40 pm

Thanks for the excellent post! I am new to MT and struggle a lot with the configuration of VLANs.

Trying that on a hAP ac² I stumbled across https://wiki.mikrotik.com/wiki/Manual:B ... witch_chip - it says that to keep hardware offloading on specific switch chips you need a different configuration approach. As for example the Atheros8327 on a hAP ac² can't do VLAN filtering in hardware, https://wiki.mikrotik.com/wiki/Manual:B ... witch_chip suggests in section "Other devices with built-in switch chip" a different setup.

Do I get that right that the herein provided configuration examples work on Atheros8327-based devices (like the hAP ac²) but for the cost of losing bridging (speed) in hardware (due to the lack of VLAN filtering in hardware with some devices the devices' CPUs need to kick in)?

Cheers
spi

spi43458 · Wed Mar 18, 2020 2:49 pm

Do I get that right that the herein provided configuration examples work on Atheros8327-based devices (like the hAP ac²) but for the cost of losing bridging (speed) in hardware (due to the lack of VLAN filtering in hardware with some devices the devices' CPUs need to kick in)?

Checked that out myself - VLAN filtering comes on an hAP ac² with the cost of increased CPU load (and other devices probably too as only the CRS3xx series supports VLAN filtering in hardware). The other configuration approach is a bit tricky but doesn't increase CPU load. Here's a link to my thread for solving this issue successfully: viewtopic.php?f=2&t=158824&p=780499#p780499

brg3466 · Mon Mar 23, 2020 2:43 am

Hi everyone,
I tried to configure my network according to this guideline in the past few days. Everything goes well except for the AccessPoint. I have 7 cAP ac hooked up to the CRS328P and I want to use CAPsMAN on the router to manage all the CAPs. Since the WiFi set up are all configured on the CAPsMAN on the router. I wonder if I need to put the below on the cAP ac. (the wiki guideline seems there is no need to do anything on the AccessPoint itself regarding blue, green, red vlan. https://wiki.mikrotik.com/wiki/Manual:C ... with_VLANs).

Thank you in advance !

##################################
# egress behavior
/interface bridge vlan

# Blue, Green, Red VLAN
add bridge=BR1 untagged=wlan1 vlan-ids=10
add bridge=BR1 untagged=wlan2 vlan-ids=20
add bridge=BR1 untagged=wlan3 vlan-ids=30

# egress behavior
/interface bridge vlan
# Purple Trunk. L2 switching only, Bridge not needed as tagged member (except BASE_VLAN)
set bridge=BR1 tagged=ether1 [find vlan-ids=10]
set bridge=BR1 tagged=ether1 [find vlan-ids=20]
set bridge=BR1 tagged=ether1 [find vlan-ids=30]
add bridge=BR1 tagged=BR1,ether1 vlan-ids=99
####################################################################

mkx · Mon Mar 23, 2020 6:33 pm

My limited experience goes tgat you have to configure cAPs as far as needed for discovery-interface to have connectivity with capsman. So you need a vlan interface created and L2 config (bridge: ports and vlans) done so that you can configure /interface wireless cap with working discovery-interface ...

brg3466 · Mon Mar 23, 2020 8:38 pm

@mkx , thank you for the input. Yes, I set up the cAP ac so it can find the CAPsMAN, such as discovery interface etc. But I didn't set up anything regarding blue, red, green vlan. I added the Vlan99 so I can reach the device. Other than that, all configuration regarding vlan was set up in the CAPsMAN on the router according to the wiki. See below my configuration on the cAP ac and the CAPsMAN. I didn't get it work. Anything I miss ?

@cAP ac
# model = RouterBOARD wAP G-5HacT2HnD
/interface bridge
add name=bridge1
/interface wireless
# managed by CAPsMAN
# channel: 2442/20-Ce/gn(28dBm), SSID: Work, local forwarding
set [ find default-name=wlan1 ] disabled=no ssid=MikroTik
# managed by CAPsMAN
# channel: 5180/20-Ceee/ac(28dBm), SSID: Guest, local forwarding

/interface vlan
add interface=bridge1 name=vlan99 vlan-id=99
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/interface bridge port
add bridge=bridge1 interface=ether1
/interface bridge vlan
add bridge=bridge1 tagged=bridge1,ether1 vlan-ids=99
/interface wireless cap
#
set bridge=bridge1 discovery-interfaces=bridge1 enabled=yes interfaces=\
wlan1,wlan2 static-virtual=yes
/ip dhcp-client
add disabled=no interface=vlan99

/system identity
set name=Test

@ CAPsMAN on the router
[admin@MikroTik] > caps-man configuration print
0 name="2.4G" mode=ap ssid="Work" datapath.local-forwarding=yes datapath.vlan-mode=use-tag datapath.vlan-id=10

1 name="5G" mode=ap ssid="Guest" datapath.local-forwarding=yes datapath.vlan-mode=use-tag datapath.vlan-id=20

anav · Mon Mar 23, 2020 9:35 pm

So in capsman one doesnt add the wlans as a bridgeport??

brg3466 · Mon Mar 23, 2020 9:53 pm

@anav, according to the wiki: "After CAPs are successfully connected to the CAPsMAN Router, the wlan1 (SSID WiFi_WORK) and a newly created virtual wlan5 (SSID WiFi_GUEST) interfaces get dynamically added as bridge ports." I checked the cAP ac, yes, it is added as shown below. And wlan1 and wlan2 do get the vlan ID of 10 and 20 respectively.

[admin@Test] > interface bridge port pr
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload
# INTERFACE BRIDGE HW PVID PRIORITY PATH-COST INTERNAL-PATH-COST HORIZON
0 ether1 bridge1 yes 1 0x80 10 10 none
1 D wlan2 bridge1 20 0x80 10 10 none
2 D wlan1 bridge1 10 0x80 10 10 none
[admin@Test] >

mkx · Mon Mar 23, 2020 10:29 pm

Yup, capsman does add wlan interfaces as bridge ports with pvid set (if use-vlan=yes on wlan config). But doesn't take care about trunk ports etc. So you have to configure bridge with vlan-filtering and add all wlan VLANs as tagged to trunk (uplink) port. No need to configure bridge interface as member of those VLANs, bridge will just switch packets, won't interact with them.

I believe that with datapath.local-forwarding=no none of the above is necessary, I believe in this case all wlan traffic is forwarded to capsman through a tunnel which uses discovery-interface. I've never tested such setting, I don't see it useful in a typical network where L2 is well under control. Plus typically it severely affects wifi performance.

sindy · Mon Mar 23, 2020 10:32 pm

The same what @mkx just wrote but with more details:

cAPsMAN takes care of adding the wireless intefaces to the bridge as /interface bridge port items dynamically, regardless whether datapath.local-forwarding is set to yes or no; with yes, it is the bridge indicated in /interface wireless cap in the cAP's configuration, whereas with no, it is the bridge on the cAPsMAN machine indicated in the datapath.bridge item:

[me@mycAPsMAN] > caps-man export
...
/caps-man datapath
add local-forwarding=yes name=bridge-test-444 vlan-id=444 vlan-mode=use-tag
add local-forwarding=yes name=bridge-test-777 vlan-id=777 vlan-mode=use-tag
...
/caps-man configuration
add country="some country" datapath=bridge-test-444 distance=indoors installation=indoor name=my444 security=for444 ssid=ssid444
add country="some country" datapath=bridge-test-777 distance=indoors installation=indoor name=my777 security=for777 ssid=ssid777
...
/caps-man interface
add configuration=my444 l2mtu=1600 mac-address=66:D1:54:93:A8:5E master-interface=5.master.garage name=5.444.garage radio-mac=00:00:00:00:00:00
add configuration=my777 l2mtu=1600 mac-address=66:D1:54:93:A8:5D master-interface=5.master.garage name=5.777.garage radio-mac=00:00:00:00:00:00

[me@myCAP] > interface bridge port print where bridge=mytestbridge
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload
# INTERFACE BRIDGE HW PVID PRIORITY PATH-COST INTERNAL-PATH-COST HORIZON
0 D wlan630 mytestbridge 444 0x80 10 10 none
1 D wlan631 mytestbridge 777 0x80 10 10 none

It does so regardless whether vlan-filtering on that bridge is set to yes or no. If you set vlan-filtering=yes on the bridge, cAPsMAN will create also the items in /interface bridge vlan:

[me@myCAP] > interface bridge vlan print where bridge=mytestbridge
Flags: X - disabled, D - dynamic
# BRIDGE VLAN-IDS CURRENT-TAGGED CURRENT-UNTAGGED
0 D mytestbridge 1 mytestbridge
1 D mytestbridge 777 wlan639
2 D mytestbridge 444 wlan640

However, you have to manually configure items in /interface bridge port and /interface bridge vlan for the ethernet ports so that those VLANs could be connected to other devices via those ethernet port(s):
/interface bridge port
add bridge=mytestbridge interface=ether1(,ether2) (this one is likely there anyway as it is necessary regardless how many VLANs are permitted on ether1)
/interface bridge vlan
add bridge=mytestbridge vlan-ids=444,777 tagged=ether1(,ether2) (plus a separate line for an eventual VLAN-ID you want to have untagged on ether1)

But if the cAPsMAN device is the only one to have an uplink connection to the rest of the network, and if the wireless clients associated to different cAPs do not need to talk to each other directly, there is no real point in using local-forwarding=yes - you may as well let the wireless frames be transported to and from the cAPsMAN machine encapsulated into UDP, and do all the tagging and untagging on the cAPsMAN machine. In such case, you don't need to bring the VLANs to the cAPs at all.

Chupaka · Tue Mar 24, 2020 2:36 pm

Should we move the topic to viewforum.php?f=23 ?

anav · Tue Mar 24, 2020 2:44 pm

100%!! In a recent survey, 19 Pangolins recommended moving the thread to Useful user articles.

brg3466 · Tue Mar 24, 2020 8:51 pm

@Sindy, @mkx, thank you for your valuable input. I tried different ways to configure the AP. But still cannot get the WiFi working. Everything else works well.
Therefore, I want to post the configuration for the trial set up. Have been struggling for a week but no success.

Router: RB951G ( ether1 as WAN, and ether2 as trunk to Switch)
Switch: RB951-2n ( ether1 as trunk to Router, and ether2 to cAP)
AP: wAP (local forwarding mode and controlled by CAPsMAN on Router with 2 SSIDs)

Configuration: according to pcunite's guideline and wiki: CAPsMAN with Vlan

Issues: Ports of ether 3-5 on router, ether 3-5 on switch works perfect. WiFi doesn't work, either cannot connect to the SSID or extremely slow.

wAP.rsc

Switch_951n.rsc

Router_951G.rsc

3/26: I tried in the past few days and herebelow are my observations on the WiFi :
1. CAPsMAN with local forwarding mode: Cannot use Vlan filtering on CAP, turn on vlan filtering feature will lose internet connection
2. CAPsMAN with manager forwarding mode: very unstable with vlan filtering on, sometimes you can connect to the SSID, sometimes, iPhone is unable to connect to the SSID.
3. Most weird thing I noticed, if SSID1 is assigned with vlan10 and SSID2 with vlan20, the SSID1 is always faster and more stable than SSID2. Seems there is a priority. I know there must be something wrong in my configuration but I cannot figure out.

hahnhell · Thu Mar 26, 2020 1:32 am

Good day everyone,

I'm new to Mikrotik and very new to VLANs. I have read through a number of posts here and am about to start writing up my own file to implement in my home network. I am still in the learning curve of Mikrotik language so I just wanted to ask about a few of the things stated within the how-tos.

I have a RB4011iGS+5HacQ2HnD so I am trying to implement the method suggested in post #3. While reading through the RouterSwitchAP.rsc, there are a few things I am not sure how to do.
While configuring:
Access Ports: "L3 switching":
What does it mean to [find vlan-ids=10]?
IP Addressing & Routing: DNS Server:
Do I put my preferred DNS here or do I put 9.9.9.9?
IP Services: /ip dhcp-server network add address=10.0.10.0/24 dns-server=192.168.0.1 gateway=10.0.10.1
How is the dns-server=x.x.0.1? Is this defined somewhere that I missed? I haven't loaded the RB without default config yet so I am a bit uncertain how this setting works from a fresh start.

This is about as far as I've gotten through the file so far before I had enough questions that I feel comfortably lost. Figured I'd post now and get more knowledge before moving forward.

I more than likely will need to post my own topic to get more advice on how to proceed with the way I want my network laid out, but I wan to at least understand this current topic as much as I can before doing so. I've attached my network diagram (very skeleton) for ref.

Thank you so much in advance!! I've been learning so much already and have mustered enough courage to at least post something here in hopes that you fine folk can lend some expertise.

anav · Thu Mar 26, 2020 2:15 pm

Yes please take your diagram and post to a new thread and I would like to help after that.

spi43458 · Fri Mar 27, 2020 2:17 pm

Yes please take your diagram and post to a new thread and I would like to help after that.

Please share a direct link to the new post then...

hahnhell · Fri Mar 27, 2020 3:56 pm

Good day everyone,

I'm new to Mikrotik and very new to VLANs. I have read through a number of posts here and am about to start writing up my own file to implement in my home network. I am still in the learning curve of Mikrotik language so I just wanted to ask about a few of the things stated within the how-tos.

I have a RB4011iGS+5HacQ2HnD so I am trying to implement the method suggested in post #3. While reading through the RouterSwitchAP.rsc, there are a few things I am not sure how to do.
While configuring:
Access Ports: "L3 switching":
What does it mean to [find vlan-ids=10]?
IP Addressing & Routing: DNS Server:
Do I put my preferred DNS here or do I put 9.9.9.9?
IP Services: /ip dhcp-server network add address=10.0.10.0/24 dns-server=192.168.0.1 gateway=10.0.10.1
How is the dns-server=x.x.0.1? Is this defined somewhere that I missed? I haven't loaded the RB without default config yet so I am a bit uncertain how this setting works from a fresh start.

This is about as far as I've gotten through the file so far before I had enough questions that I feel comfortably lost. Figured I'd post now and get more knowledge before moving forward.

I more than likely will need to post my own topic to get more advice on how to proceed with the way I want my network laid out, but I wan to at least understand this current topic as much as I can before doing so. I've attached my network diagram (very skeleton) for ref.

Thank you so much in advance!! I've been learning so much already and have mustered enough courage to at least post something here in hopes that you fine folk can lend some expertise.

I posted a new topic here: viewtopic.php?f=13&t=159184

Thanks guys!

Spe · Tue Jul 14, 2020 11:05 pm

Thanks everyone for this great topic! It helped me set up my own network where I have a combined router+switch in one with a trunk port to my VLAN-aware access point. I have two questions I hope you can help me with

In my situation, should I have L2 or L3 switch? I.e. should bridge1 be tagged on all VLANs or not? Why?
How do I know whether I use 'hardware acceleration' or not? I'm a bit confused by the many webfig/terminal locations where 'vlan' appears.

My setup is as follows:

VLAN99 is management (172.16.99.0/24), VLAN20 for IoT (no WAN access, only access to server in VLAN99, 172.16.20.0/24), VLAN10 for guest use (only WAN access, 172.16.10.0/24)
ether1 is used as trunk with VLAN 10 & 20 tagged and VLAN99 untagged for connection to my access point
ether3 & ether4 are part of VLAN 10, all other ethers are part of VLAN99
The access point broadcasts one SSID for each VLAN 10, 20, 99
sfp1 is used for WAN and tagged with VLAN34 (dictated by ISP)
I'm running an IPSec server (not shown here) serving clients on 172.16.30.0/24, hence for some firewall rules filter on 172.16.0.0/16 to distinguish WAN and VPN traffic

My config:

###############################################################################
# Topic: Using RouterOS to VLAN your network
# Example: Router-Switch-AP all in one device
# Web: viewtopic.php?t=143620
# RouterOS: 6.43.12
# Date: Mar 28, 2019
# Notes: Start with a reset (/system reset-configuration)
# Thanks: mkx, sindy
###############################################################################

#######################################
# Naming
#######################################

# name the device being configured
/system identity set name="rb2011"

#######################################
# VLAN Overview
#######################################

# 10 = Guest
# 20 = IoT
# 99 = BASE (MGMT) VLAN

#######################################
# Bridge
#######################################

# create one bridge, set VLAN mode off while we configure
/interface bridge add name=bridge1 protocol-mode=none vlan-filtering=no

#######################################
#
# -- Access Ports --
#
#######################################

# ingress behavior
/interface bridge port

# Purple Trunk to AP. PVID is only needed when combining tagged + untagged
# trunk (vs fully tagged), but does not hurt so enable.
add bridge=bridge1 interface=ether1 pvid=99

# Guest VLAN
add bridge=bridge1 interface=ether3 pvid=10
add bridge=bridge1 interface=ether4 pvid=10

# IoT VLAN

# BASE_VLAN / Full access
add bridge=bridge1 interface=ether2 pvid=99
add bridge=bridge1 interface=ether5 pvid=99
add bridge=bridge1 interface=ether6 pvid=99
add bridge=bridge1 interface=ether7 pvid=99
add bridge=bridge1 interface=ether8 pvid=99
add bridge=bridge1 interface=ether9 pvid=99
add bridge=bridge1 interface=ether10 pvid=99

# Tim: WAN VLAN tagging is not set here because it's not part of bridge

#
# egress behavior
#
/interface bridge vlan

# Guest, IoT, & BASE VLAN + Purple uplink trunk (ether1)
# L3 switching so Bridge must be a tagged member
# In case of fully tagged trunk, set ether1 to tagged for vlan 99 as well (instead of untagged)
add bridge=bridge1 vlan-ids=10 tagged=bridge1,ether1 untagged=ether3,ether4
add bridge=bridge1 vlan-ids=20 tagged=bridge1,ether1
add bridge=bridge1 vlan-ids=99 tagged=bridge1 untagged=ether1,ether2,ether5,ether6,ether7,ether8,ether9,ether10

#######################################
# IP Addressing & Routing
#######################################

# LAN facing router's IP address on the BASE_VLAN
/interface vlan add interface=bridge1 name=BASE_VLAN vlan-id=99
/ip address add address=172.16.99.1/24 interface=BASE_VLAN

# DNS server, set to cache for LAN
/ip dns set allow-remote-requests=yes servers="172.16.99.1"

# From viewtopic.php?t=90052#p452139
/interface vlan add interface=sfp1 name=WAN_VLAN vlan-id=34

# Set DHCP WAN client on ether6 AND WAN_VLAN
/ip dhcp-client
add disabled=no interface=WAN_VLAN

#######################################
# IP Services
#######################################

# Guest VLAN interface creation, IP assignment, and DHCP service
/interface vlan add interface=bridge1 name=GUEST_VLAN vlan-id=10
/ip address add interface=GUEST_VLAN address=172.16.10.1/24
/ip pool add name=GUEST_POOL ranges=172.16.10.100-172.16.10.254
/ip dhcp-server add address-pool=GUEST_POOL interface=GUEST_VLAN name=GUEST_DHCP disabled=no
/ip dhcp-server network add address=172.16.10.0/24 dns-server=172.16.99.1 gateway=172.16.10.1

# IoT VLAN interface creation, IP assignment, and DHCP service
/interface vlan add interface=bridge1 name=IoT_VLAN vlan-id=20
/ip address add interface=IoT_VLAN address=172.16.20.1/24
/ip pool add name=IoT_POOL ranges=172.16.20.100-172.16.20.254
/ip dhcp-server add address-pool=IoT_POOL interface=IoT_VLAN name=IoT_DHCP disabled=no
/ip dhcp-server network add address=172.16.20.0/24 dns-server=172.16.99.1 gateway=172.16.20.1

# Optional: Create a DHCP instance for BASE_VLAN. Convenience feature for an admin.
/ip pool add name=BASE_POOL ranges=172.16.99.100-172.16.99.254
/ip dhcp-server add address-pool=BASE_POOL interface=BASE_VLAN name=BASE_DHCP disabled=no
/ip dhcp-server network add address=172.16.99.0/24 dns-server=172.16.99.1 gateway=172.16.99.1

#######################################
# Firewalling & NAT
# A good firewall for WAN. Up to you
# about how you want LAN to behave.
#######################################

# Use MikroTik's "list" feature for easy rule matchmaking.

/interface list add name=WAN
/interface list add name=VLAN2WAN
/interface list add name=VLAN
/interface list add name=BASE

/interface list member
add interface=sfp1 list=WAN
add interface=WAN_VLAN list=WAN
add interface=BASE_VLAN list=VLAN2WAN
add interface=GUEST_VLAN list=VLAN2WAN
# add interface=IoT_VLAN list=VLAN2BASE
add interface=BASE_VLAN list=BASE

add interface=BASE_VLAN list=VLAN
add interface=GUEST_VLAN list=VLAN
add interface=IoT_VLAN list=VLAN

# VLAN aware firewall. Order is important.

##################
# INPUT CHAIN
##################
/ip firewall filter
add chain=input action=accept connection-state=established,related comment="Allow Estab & Related"

# Allow BASE_VLAN full access to the device for Winbox, etc.
add chain=input action=accept in-interface-list=BASE comment="Allow BASE VLAN router access"

# Allow IKEv2 VPN server on router
add action=accept chain=input comment="defconf: accept IKE" dst-port=500,4500 protocol=udp
add action=accept chain=input comment="defconf: accept ipsec AH" protocol=ipsec-ah
add action=accept chain=input comment="defconf: accept ipsec ESP" protocol=ipsec-esp

# Allow clients to do DNS, for both TCP and UDP
add chain=input action=accept dst-port=53 src-address=172.16.0.0/16 proto=tcp comment="Allow all LAN and VPN clients to access DNS"
add chain=input action=accept dst-port=53 src-address=172.16.0.0/16 proto=udp comment="Allow all LAN and VPN clients to access DNS"

add chain=input action=drop comment="Drop"

##################
# FORWARD CHAIN
##################
/ip firewall filter
add chain=forward action=accept connection-state=established,related comment="Allow Estab & Related"

# Allow selected VLANs to access the Internet
add chain=forward action=accept connection-state=new in-interface-list=VLAN2WAN out-interface-list=WAN comment="VLAN Internet Access only"

# Allow IoT IoT_VLAN to access server in BASE_VLAN, but no WAN.
add chain=forward action=accept connection-state=new in-interface=IoT_VLAN out-interface=BASE_VLAN dst-address=172.16.99.2 comment="Allow IoT_VLAN -> server in BASE_VLAN"
add chain=forward action=accept connection-state=new in-interface=BASE_VLAN out-interface=IoT_VLAN comment="Allow all of BASE_VLAN -> IoT_VLAN"

# Allow IPSec traffic from 172.16.30.0/24
add action=accept chain=forward comment="DEFAULT: Accept In IPsec policy." ipsec-policy=in,ipsec src-address=172.16.30.0/24
add action=accept chain=forward comment="DEFAULT: Accept Out IPsec policy." disabled=yes ipsec-policy=out,ipsec

add chain=forward action=drop comment="Drop"

##################
# NAT
##################
/ip firewall nat
add chain=srcnat action=masquerade out-interface-list=WAN comment="Default masquerade"
add action=masquerade chain=srcnat comment="Hairpin NAT https://www.steveocee.co.uk/mikrotik/hairpin-nat/" dst-address=172.16.99.2 out-interface=BASE_VLAN src-address=172.16.0.0/16

##################
# Disable unused service ports, whatever this is
##################
/ip firewall service-port
set ftp disabled=yes
set tftp disabled=yes
set irc disabled=yes
set h323 disabled=yes
set sip disabled=yes
set pptp disabled=yes
set udplite disabled=yes
set sctp disabled=yes

#######################################
# VLAN Security
#######################################

# Only allow ingress packets without tags on Access Ports
/interface bridge port
# Only
set bridge=bridge1 ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged [find interface=ether2]
set bridge=bridge1 ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged [find interface=ether3]
set bridge=bridge1 ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged [find interface=ether4]
set bridge=bridge1 ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged [find interface=ether5]
set bridge=bridge1 ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged [find interface=ether6]
set bridge=bridge1 ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged [find interface=ether7]
set bridge=bridge1 ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged [find interface=ether8]
set bridge=bridge1 ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged [find interface=ether9]
set bridge=bridge1 ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged [find interface=ether10]

/interface bridge port

# For tagged + untagged trunk (management VLAN being untagged), we allow both type of frames
set bridge=bridge1 ingress-filtering=yes frame-types=admit-all [find interface=ether1]
# Only allow tagged packets on WAN port
set bridge=bridge1 ingress-filtering=yes frame-types=admit-only-vlan-tagged [find interface=sfp1]

#######################################
# MAC Server settings
#######################################

# Ensure only visibility and availability from BASE_VLAN, the MGMT network
/ip neighbor discovery-settings set discover-interface-list=BASE
/tool mac-server mac-winbox set allowed-interface-list=BASE
/tool mac-server set allowed-interface-list=BASE

#######################################
# Turn on VLAN mode
#######################################
/interface bridge set bridge1 vlan-filtering=yes

anav · Tue Sep 08, 2020 4:16 pm

If you want assistance start a new thread, diagrams help and your exported config.

@PCUNITE (and/or sob, mkx, xvo ) As for the author of this fantabulous guide, getting some pushback of late on the use of pvid and the associated bridge vlan settings:
"The VLAN configuration is fine. Per my previous posts (and the Mikrotik Wiki) it is not necessary to specify untagged= under /interface bridge vlan as these are dynamically generated from the pvid= settings under /interface bridge port.
You can specify both, but if they do not match it causes wierd connectivity issues - this becomes more likely when you are reconfiguring the VLAN on an access port and change one but not the other."

Question: I dont question the validity of the statement but personally I think its clearer when configuring and reading to have the bridge vlan settings visible. Is there any downside to RELYING on the dynamically generated settings??

pcunite · Tue Sep 08, 2020 11:39 pm

... getting some pushback of late on the use of pvid and the associated bridge vlan settings ... personally I think its clearer when configuring and reading to have the bridge vlan settings visible. Is there any downside to RELYING on the dynamically generated settings?

This is why I initially showed pvid getting set to the default of "1". While is not necessary in practice, I thought it would prevent confusion. When there are to many automatic settings being done for you, I think its hard to show the general VLAN concept as well.

After the student has a good understanding, by all means encourage them to configure using brief one-liners. This article is not for illustrating the shortest or even "best" syntax. Rather, its for showing the "clearest" example of VLAN to someone new to MikroTik. Before one can fly, they must walk first.

I acquiesce to the forum's desire for the "clearest" way. Perhaps an updated section for shortest way would be in order.

Sob · Wed Sep 09, 2020 12:45 am

You can specify both, but if they do not match it causes wierd connectivity issues ...

I don't know about this. I got the new config pretty quickly, so I didn't explore dead ends much. :) But if it breaks something, then RouterOS could at least warn about it (similar to warnings in other places).

In any case, current bridge vlan UI in WinBox could use some improvements. So far my idea was that instead of having to select ports one by one from possibly quite long dropdowns, it would be more admin friendly to list all available ports (perhaps only those that are actually part of current bridge), with simple choice between tagged/untagged/excluded using radio buttons for each of them. But if mismatched pvid doesn't make sense for any config (I'm not sure, I haven't tried everything), it could be streamlined even more.

mkx · Wed Sep 09, 2020 2:06 pm

In theory mismatched PVID doesn't necessarily break things. However, it is odd and good practice is to avoid it.

When I first joined this forum, it was because I was abusing a feature, available in other vendor's managed switch, and I was asking how to do it in ROS. The feature I was asking about is something that allows mismatched PVID settings (they even have name for it: asymmetric VLAN) and it can be used in similar manner as bridge IP firewall or bridge horizon .... to prevent certain devices from being able to talk to each other, while the rest can freely communicate to each other.

Consider this scenario:

(ordinary) router, connected to port1.
TV set, allowed only to talk to the rest of LAN, connected to port2
other LAN devices, allowed to talk all over the place, connected to ports 2-5

With mismatched PVID settings this could be achieved in the following manner:

configure port1 with PVID 60 and add the same port as untagged member of VIDs 60 and 80
configure port2 with PVID 70 and add the same port as untagged member of VIDs 70 and 80
configure ports 3-5 with PVID 80 and add same ports as untagged members of VIDs 60, 70 and 80

Now how does it work?

When TV wants to talk to any other device, it sends untagged packet. Due to PVID setting, switch tags that packet with VID=70 on ingress. Let's say switch doesn't know the destination port (yet) and forwards the packet to all ports, members of VLAN 70 ... which are (apart from port2) ports 3 to 5. Those ports are configured as untagged members of said VLAN and packet gets untagged on egress. Let's say that target device is connected to port4. When it responds with untagged packet, that packet gets tagged with VID 80 on ingress and switch forwards it to port2 where it gets untagged on egress.

When TV wants to talk to internet, it sends packet towards router. However, port1 is not member of VLAN 70 and switch doesn't forward packet there.

It is very awkward way of configuration things, but it can help if router is extremely dumb and switch doesn't support horizons (or similar feature)... neither is true for Mikrotik gear. It gets complicated with more pairs of devices which must not communicate with each other (adding plenty more VLAN ID into the mix), but it is more flexible than bridge horizon and done by switch chip (hence HW offloaded).

I must admit that I didn't test it on Mikrotik. I guess it might work with VLANs configured on switch chip and setting independent-learning=no on all involved ports. Quite probably the above described functioning is not possible with bridge vlan-filtering as it uses IVL mode.

anav · Wed Sep 09, 2020 3:55 pm

I much prefer to fantasize about Sobs interesting ways of displaying choices to the admin for vlan filtering then try to understand that kludgy vlan method just described. I feel soiled almost. ;-)

MugenChikara · Wed Oct 07, 2020 12:59 pm

OMG guys, I posted several days before.I am very novice in this, however, I tried so much that somehow I have make the supplicant method work using the RB4011GS+RM . I know there is an issue about the VLAN not been able to handle VLAN 0 tags or something like this. However, I want to share exactly what I did so that it might help people struggling as much as I did. I will try to explain even the most simple staff that people take for granted that others people know, but like in my case we have no idea, when we start...

The router I used was the RB4011GS+RM. Please help me polish this instructions as simple and as much as possible so that anyone that uses it even a noob like myself would have been able to accomplish the task. Thanks to anyone that helps.

Before anything for the supplicant method you need to extract the certificates of your ATT RG (this is the big box usually black and that has 4 Ethernet ports, and not the one that is small that only have one Ethernet port(how exactly this is done with the BG210-700 is explained in this following link https://www.dupuis.xyz/bgw210-700-root-and-certs/ . If they take down the website try to look for a copy of the instruction on Reddit or somewhere else (you can also buy them in eBay but I do not know how reliable this is so I do not recommend it).

A summary you need to extract 6 public certificates from your modem(or these public ones can be even found on the internet and it would work if they are the authentic ones of course) and then you need to extract a file called mfg.dat. This is a encrypted file that contains your private certificate key for your ATT RG. After you have extracted those files from your ATT RG you need to use a program made by devicelocksmith that can be found in this following website https://www.devicelocksmith.com/2018/12 ... g-and.html
to convert those files into 3 .pem certificate files that you will then use to import to the Microtik router (make sure you put all the 6 public certificates and the mfg.dat in the same folder of the devicelocksmith program to covert this certificate correctly)

After you have the certificates and from a fresh configuration ( go to system reset configuration dont check anything and apply):

1. Manually Set the System Clock: A note about setting the clock time using the winbox there is two tabs time and manual time zone. In the tab time, first make sure that the time and date are correct with your zone. I have clicked time zone auto-detect and DTS active,however, make sure that the time and date of your computer are also correctly adjusted to your zone. Now in the manual time zone also adjust the time as you just did with the last tab where its says time zone it should be exactly the same as what is in the GMT offset of your time tab.

2. Import Certificate Files: A note about importing the certificates. First upload them with the winbox to the Microtik router. Then, import them by going to system then certificates then import. Follow the order that this step says. First import the ca.xxxxx.pem certificate when you import this certificate alone you will see that 4 other certificate show up in the certificates. You should have a T initial letter at the beginning of all this certificates meaning they are trusted. if you dont get the T which means trusted something is off and you should see if may be you did not extracted the certificates correctly or anything else. Then, import the clientcertificate.pem when you import this you only get one certificate however instead of a T you should have a KT as an initial so you know you are going in the right direction(between the way this is the certificate that you will later use in the DOTx1 for authentication. Last, import the Privatekey.pem certificate and you will get one more certificate this one also should have a initial T at the beginning. In summary you should end up with 6 certificates when you import the 3 .pem certificates keys and 5 of them should have a T initial at the beginning and one of them a KT initial at the beginning. After, importing them click on setting in the same certificates section ad make sure that both CRL Donwload and USE CRL are uncheked hit apply and then ok and move to the next step.

3. Configure your WAN port: A note here first I did a notepad file and I copied the most basic settings I do not set up firewall or anything so that is a short and clean as possible. After you successfully connect to the internet then you can set up other things like firewall etc. you can name the file whatever you want in the file I have the following: (simply replace the mac address xx:xx:xx:xx:xx:xx with the mac address of your ATT RG in the 3 fields below, and use the exact name that is in your Microtik certificate section for the client.pem file). Save this file. now go to system scripts and hit the blue + tab and in name put anything you want leave the other fields as they are, and in the withe box at the end where it says source copy and paste the settings just below changing what I already noted. Now hit apply then ok then you can close it. You do not need to hit run script.

interface ethernet
set [ find default-name=ether1 ] mac-address=xx:xx:xx:xx:xx:xx

/interface ethernet switch port
set 0 default-vlan-id=0
set 1 default-vlan-id=0

/certificate settings
set crl-use=no
set crl-download=no

/interface dot1x client
add anon-identity=xx:xx:xx:xx:xx:xx certificate=\
Client_xxxxxx-xxxxxxxxxxxxxx.pem_0 eap-methods=eap-tls identity=\
10:93:97:36:D3:81 interface=ether1

/ip dhcp-client
add disabled=no interface=ether1

/interface ethernet switch port set ether1 vlan-mode=fallback

4. Configure the Dot1x interface: Notes about this. although you can see I added the dot1x in the script in the last step I also used the GUI. So go to winbox then dot1x hit the blue + sign and select interface ether1, then in the identity and anon.identity again put the same mac adress of the ATT RG as you used in the last step. yes the same in both, now in certificate select the certificate that says client.xxxx.xxxxx.pem_0, and lastly in the EAP Methods select EAP TLS . lastly hit apply then OK. Now connect the ONT cable that goes directly from the small box that only have one Ethernet port to the port Ethernet one of the Microtik and connect your PC to any of the other ports. You should get authenticated fairly quickly you dont even have to reboot. If the authentication is trapped in authenticated then connecting loop something is wrong, if the authentication says authenticated without a server something is wrong.

Now the only problem I have right now is that although I have 1GB of internet speed I am only getting 100, however, I know is something in the configuration that I did because when I plug it in the PC the maximum speed it says is 100mbs unlike a 1GB when is connected the other way. Now I know the RB4011GS+RM is capable of 1GB speed or so I read in the description when I bought the product. Can someone be so gentle and help me adjust this setting so I can get the full speed I am paying for. I would greatly appreciate any help with this. Also, how do I set a good secure firewall. I do not plan on using IPv6. However, how would you set up IPv6 is something that some people is asking about and I also do not know how to do.

Hope this guide help someone and also people help to improve it, and I hope someone can help me adjust the setting so I can get the full speed of 1GB.

grumpazoid · Fri Oct 16, 2020 8:09 pm

Thank you for an excellent guide. With the help of this and some help forum members I have been able to extend my network with VLANs.

I have one question. In the first example, router & switch, where would the admin plug a PC in to connect to the base VLAN? All ports on the switch are set for red, green or blue, so a DHCP client would be put onto one of those networks? I am guessing you would assign a port to the base VLAN in order to be assigned a base VLAN IP address?

anav · Fri Oct 16, 2020 9:08 pm

Correct, designate one of the ports on the switch (ex. pink) as BASE VLAN PORT, and in this case to a 'dumb device' (cannot read tags), it would an access port. The BASE VLAN would be one of the vlans coming into the switch on a TRUNK Port (purple).

grumpazoid · Sun Oct 18, 2020 4:15 pm

@anav Thanks. Good to know I hadn't missed something.

incagarcilaso · Mon Dec 07, 2020 9:59 am

Fabulous post. Clear, to the point and so well organised. I have been searching for days for something like this in order to configure a CRS328 and CRS326 plus two CAPacs on an existing network with VLANs.
One question about the attached .rsc files. I have opened them in an ASCII editor but are they designed to script straight in to devices? Or is it cutting and pasting (with necessary edits of course)?
Many thanks.

mducharme · Sun Dec 13, 2020 10:33 pm

One thing I do not like about the configuration shown in the examples up at the top (which are otherwise very good) is that it has unnecessary use of the "untagged" setting. You never really have to set anything as untagged manually like that, unless you are using something like MAC-based VLAN assignment. For 99% of situations, setting untagged ports for an /interface bridge vlan really just makes the configuration more complicated and doesn't really do anything.

elter · Thu Dec 31, 2020 12:37 am

Is there a particular reason to apply ingress filtering to access ports when "admit only untagged" is set? On the surface, igress filtering looks unnecessary here.

linuswue · Fri Jan 15, 2021 2:51 pm

I tried to implement the great tutorial, unfortunately I get an error when defining the WAN IP

# Yellow WAN facing port with IP Address provided by ISP
/ip address add interface=ether1 address=a.a.a.a/aa network=a.a.a.0

get me this error back
"error while running run-after-reset script: invalid value for argument address"

a manual change also results in an error message. I am grateful for any help.

greetings Sven

incagarcilaso · Thu Jan 28, 2021 10:59 am

One thing I do not like about the configuration shown in the examples up at the top (which are otherwise very good) is that it has unnecessary use of the "untagged" setting. You never really have to set anything as untagged manually like that, unless you are using something like MAC-based VLAN assignment. For 99% of situations, setting untagged ports for an /interface bridge vlan really just makes the configuration more complicated and doesn't really do anything.

Just to be clear are you saying that the reason setting untagged ports explicitly doesn't do anything because when you add an access port to a vlan by setting its pvid it is automatically added to the vlan table as an untagged port for that vlan. Is that correct?

erlinden · Thu Jan 28, 2021 11:28 am

Is that correct?

Yes

I tried to implement the great tutorial, unfortunately I get an error when defining the WAN IP

# Yellow WAN facing port with IP Address provided by ISP
/ip address add interface=ether1 address=a.a.a.a/aa network=a.a.a.0

get me this error back
"error while running run-after-reset script: invalid value for argument address"

a manual change also results in an error message. I am grateful for any help.

greetings Sven

I hope you are not literally trying to set the address to a.a.a.a? Either set the address the ISP provided to you or add a DHCP client if the ISP is providing dynamic IP addresses.

Halfeez92 · Thu Feb 04, 2021 8:48 pm

I tried to implement the great tutorial, unfortunately I get an error when defining the WAN IP

# Yellow WAN facing port with IP Address provided by ISP
/ip address add interface=ether1 address=a.a.a.a/aa network=a.a.a.0

get me this error back
"error while running run-after-reset script: invalid value for argument address"

a manual change also results in an error message. I am grateful for any help.

greetings Sven

Basically you don't need to set up this one. Most ISPs are assigning public IP automatically. Only those who with leased line need to set up the default route and set up WAN facing interface with public IP. Ignore this one or you can see whether the default route is already there, try typing /ip route print if there a value with number 0.0.0.0/0 then you are good to go.

pcunite · Thu Feb 18, 2021 11:11 pm

One thing I do not like about the configuration shown in the examples up at the top (which are otherwise very good) is that it has unnecessary use of the "untagged" setting.

@mducharme
What if I put in a disclaimer, stating it was unnecessary and handled automatically? This article series is primarily about learning the VLAN concept on MikroTik hardware, not RouterOS syntax. In fact, I try to take a most verbose approach with the syntax to slow everything down and make it clear what is happening.

newyork10023 · Thu Feb 25, 2021 9:13 pm

Can this be done in the GUI? Can this be done in the GUI of SwitchOS?

(Why does MikroTik not provide explanations with specific examples using *both* CLI and GUI?)

Specifically, when I use the SwitchOS GUI to configure a CRS326-24G-2S+ with an SFP+ uplink to a CRS305-1G-4S+ (also configured with SwitchOS GUI), as soon as I plug in the uplink I lose connectivity to the CRS305. The management interface for the CRS305 is on a separate VLAN from those configured on the uplink although the management interface is connected to a port on the CRS326 (again on the separate, isolated VLAN).

I am currently using VLAN 1 for management of the router (pfSense on ESXi). I intend to move this to a different VLAN at next opportunity.

rodpp · Mon Mar 01, 2021 6:15 am

@pcunite
I would like to thank you very much!
The best article about VLANs in RouterOS that I found, by a large margin.
I configured my network following your instructions, everything works as expected.
Excellent job.

torgr2019 · Sun Mar 14, 2021 9:49 am

Thank you so much for this excellent review of VLANs @ Mikrotik.

I need your help regarding my simple home setup:

Internet >> RB4011 (router) >> hAP ac2 (bridge mode AP)

RB4011: base network and vlan aware port 6 that is connected to hap ac2.
hap AC2:
port 2,3,4 are vlan 120
wlan-mp2 (2.4) and wlan-mp5 (5Ghz) are vlan 130

Everything is working as it should except:

When i have enabled the vlan awareness to the bridge of ac2 (that contains ether 2,3,4 and all wlans), i lost connectivity to my ac2 from winbox.
The interesting thing is that ONLY WINBOX is not working that way, i mean if i connect a laptop to one of the ports 2,3,4 everything is running smoothly (devices getting the correct ip, in the correct vlan, have access to internet and so on), except WINBOX.
So after reset i created another bridge (bridge_ap_management) that is NOT vlan aware and has port 5 and i am managing the ac2 through that.
When i connect my laptop to that bridge (management) WINBOX is working perfectly but nothing else is working anymore (through ether 5 i mean, ether 2,3,4 and wifis continuing to work fine).

Obviously i have something wrong in my config.

Any ideas?

How the vlan awareness make that conflict?

(if i uncheck the vlan awareness of the bridge, WINBOX is working if its connected to ether 2,3,4 but then nothing else is working - obviously).

Here is my config:

/interface bridge
add admin-mac=******** auto-mac=no comment=defconf \
ingress-filtering=yes name=bridge vlan-filtering=yes
add name=bridge_ap_management

/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN

/interface wireless security-profiles
set [ find default=yes ] authentication-types=wpa2-psk mode=dynamic-keys \
supplicant-identity=MikroTik
add authentication-types=wpa2-psk eap-methods="" mode=dynamic-keys name=\
sec-profile supplicant-identity=""
add authentication-types=wpa2-psk eap-methods="" mode=dynamic-keys name=test \
supplicant-identity=""

/interface wireless
set [ find default-name=wlan1 ] band=2ghz-b/g/n channel-width=20/40mhz-XX \
country=greece disabled=no distance=indoors frequency=auto installation=\
indoor mode=ap-bridge name=wlan-mp2 security-profile=sec-profile \
ssid=mp2 vlan-id=130 vlan-mode=use-tag wireless-protocol=802.11 wps-mode=\
disabled
set [ find default-name=wlan2 ] band=5ghz-a/n/ac channel-width=\
20/40/80mhz-XXXX country=greece disabled=no distance=indoors frequency=\
auto installation=indoor mode=ap-bridge name=wlan-mp5 security-profile=\
sec-profile ssid=mp5 vlan-id=130 vlan-mode=use-tag \
wireless-protocol=802.11 wps-mode=disabled
add disabled=no mac-address=******** master-interface=wlan-mp2 name=\
wlan3 security-profile=test ssid=test

/ip hotspot profile
set [ find default=yes ] html-directory=flash/hotspot

/interface bridge port
###### LAN ports vlan 120 #####
add bridge=bridge comment=defconf frame-types=\
admit-only-untagged-and-priority-tagged ingress-filtering=yes interface=\
ether2 pvid=120
add bridge=bridge comment=defconf frame-types=\
admit-only-untagged-and-priority-tagged ingress-filtering=yes interface=\
ether3 pvid=120
add bridge=bridge comment=defconf frame-types=\
admit-only-untagged-and-priority-tagged ingress-filtering=yes interface=\
ether4 pvid=120

######## wlan ports ######
##### the vlan tagging for wlan-mp2 and wlan-mp5 has been done at interface level. It is working also if i tag the packets at the port level but not at both sites.##############
######### wlan 3 tagging is not working neither at interface level or port level, regardless of where i have tag the master interface ########################
add bridge=bridge comment=defconf frame-types=admit-only-vlan-tagged \
ingress-filtering=yes interface=wlan-mp2
add bridge=bridge comment=defconf frame-types=admit-only-vlan-tagged \
ingress-filtering=yes interface=wlan-mp5
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
interface=wlan3 pvid=140

############# root port to RB4011 #########################
add bridge=bridge frame-types=admit-only-vlan-tagged ingress-filtering=yes \
interface=ether1

###### custom created management port
add bridge=bridge_ap_management comment=defconf interface=ether5

/ip neighbor discovery-settings
set discover-interface-list=LAN

/interface bridge vlan
add bridge=bridge tagged=bridge,ether1 untagged=ether2,ether3,ether4 \
vlan-ids=120
add bridge=bridge tagged=bridge,ether1,wlan-mp2,wlan-mp5 vlan-ids=130
add bridge=bridge tagged=bridge,ether1 untagged=wlan3 vlan-ids=140

/interface list member
add interface=ether2 list=LAN
add interface=ether3 list=LAN
add interface=ether4 list=LAN
add interface=ether5 list=LAN
add interface=wlan-mp5 list=LAN
add interface=wlan-mp2 list=LAN
add interface=ether1 list=WAN

/ip address
add address=192.168.100.2/24 interface=ether2 network=192.168.100.0

/ip dhcp-client
add comment=defconf interface=bridge

/ip dhcp-server network
add address=0.0.0.0/24 comment=defconf gateway=0.0.0.0 netmask=24

/ip dns static
add address=192.168.100.2 comment=defconf name=router.lan
#### i have disable all firewall rules in my AP since it is in bridge mode######
/ip firewall filter
## all rules disabled
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" \
ipsec-policy=out,none out-interface-list=WAN
/ip route
add distance=1 gateway=192.168.100.1
/ip service
set telnet disabled=yes
set ftp disabled=yes
set ssh disabled=yes
set api disabled=yes
set api-ssl disabled=yes

/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN

mducharme · Mon Apr 05, 2021 12:10 am

Just to be clear are you saying that the reason setting untagged ports explicitly doesn't do anything because when you add an access port to a vlan by setting its pvid it is automatically added to the vlan table as an untagged port for that vlan. Is that correct?

Yes, that is correct - by setting the PVID it is dynamically added as an untagged port for the VLAN. All you are doing by statically setting it as an untagged port for that VLAN is making it so that you have to change the untagged VLAN in two places instead of one. It makes it more error prone because if you ever change the PVID and forget to remove the associated untagged setting, you may then have both the old and new vlans untagged on egress for the same port which can make weird things happen.

mducharme · Mon Apr 05, 2021 12:29 am

@mducharme
What if I put in a disclaimer, stating it was unnecessary and handled automatically? This article series is primarily about learning the VLAN concept on MikroTik hardware, not RouterOS syntax. In fact, I try to take a most verbose approach with the syntax to slow everything down and make it clear what is happening.

Yes, I think that would be good. I have the same problem with the MikroTik documentation actually. The reason I feel it is bad practice to unnecessarily set the "untagged" port statically in addition to the PVID is when it comes time to make changes, you have to remember to make the change in two different places.

I've actually had people tell me before that they don't like and don't use MikroTik switches because they force you to set the untagged VLAN in two different places instead of being able to change it in one place. I had to explain to them that isn't actually the case and that you can just change it in one place by setting the PVID. Also I'm concerned about the possible side effects of having PVID and static untagged for different VLANs - you could have a situation where two VLANs are both being untagged on egress, but of course only one on ingress. I've had issues with this before with built in switches in VoIP phones where you have a voice VLAN, and when you plug in a computer you get the PC VLAN untagged in both directions, but the phone leaks untagged traffic from the voice VLAN unidirectionally to the computer. With IPv4 perhaps this doesn't cause major problems, but with IPv6, the computer will get an IPv6 address from both the voice VLAN and the main VLAN, but the voice VLAN IPv6 address will not provide connectivity because the traffic is unidirectional for that VLAN through the phone port - egress only. I haven't personally had this exact issue happen with MikroTik bridge vlan filtering before, but having to change the setting in two places increases the chance of someone making a mistake and theoretically making both VLANs untagged at the same time on the same interface.

mducharme · Mon Apr 05, 2021 12:40 am

As an example, here I have created an issue on purpose by setting a port with PVID 99 as statically untagged on VLAN 5:

vlan-issue.JPG

The device on that port will receive untagged packets from both VLANs on egress as a result of this misconfiguration.

pcunite · Thu Apr 15, 2021 7:28 pm

Yes, I think that would be good. I have the same problem with the MikroTik documentation actually. The reason I feel it is bad practice to unnecessarily set the "untagged" port statically in addition to the PVID is when it comes time to make changes, you have to remember to make the change in two different places.

@mducharme
Examples updated

anav · Thu Apr 15, 2021 9:17 pm

I disagree, I find it very confusing to have set PVID on the bridge ports and then not put the associated untagged entries on the bridge vlan.
When reading a config its dirt easy visually to see what a person has done.
Its so difficult to have to double check a config when not seeing the config, especially when they use hybrid ports.

This is highlighted to me time and time again when I am looking at a config in winbox,
For example if a port is not at the moment dynamically untagged by the router there is no indication that it is an untagged port.
If I have physically untagged it, it is always there to confirm, whether the port vlan is being used or not.

I think it suffices to say that the Router automatically assigns untagged ports in the bridge vlan settings and its up to the user to decide if not or to insert them in the bridge vlan configuration.
So far I have not seen any input to change my mind.

mducharme · Thu Apr 15, 2021 9:39 pm

I disagree, I find it very confusing to have set PVID on the bridge ports and then not put the associated untagged entries on the bridge vlan.
When reading a config its dirt easy visually to see what a person has done.
Its so difficult to have to double check a config when not seeing the config, especially when they use hybrid ports.

You shouldn't use this "untagged" setting as a sort of documentation for how things are set up. You can always add a comment to the bridge vlan (ex. "pvid ether1-ether23") if you are concerned about documentation purposes as a reminder for yourself. At least then if you forget to change the comment it won't cause a problem.

It is normal with most switches to simply have to change the PVID for the port and that takes care of both egress and ingress. That is the case with MikroTik too, except if you also use the "untagged" then you have to change it in two places. If you have some network person who is used to working with HPE or Cisco or other major vendor switches they will likely change the PVID only and not realize that they have potentially created a problem. If they do create a problem, they will likely blame MikroTik for their non standard configuration to have to set the untagged VLAN in two places which nobody else requires.

pcunite · Fri Apr 16, 2021 1:23 am

I disagree, I find it very confusing to have set PVID on the bridge ports and then not put the associated untagged entries on the bridge vlan.
When reading a config its dirt easy visually to see what a person has done. It's so difficult to have to double check a config when not seeing the config, especially when they use hybrid ports ... So far I have not seen any input to change my mind.

I'm kinda in the middle. I think for examples, it looks good which is why I kept it included. However, out in the field, when I'm making changes, I find it error prone to make edits on live systems. So, I prefer the automatic egress behavior for Access ports in a production environments. To your point, I see why it is helpful debugging posted configurations in these forums.

anav · Fri Apr 16, 2021 2:10 am

Hi mud, you do make some points there in terms of cross vendors but let me point you to the jestream switches I use from TPLINK.
I set the PVID in one section and in another I set both Tagged and Untagged ports. I have to set untagged ports. Therefore it is MORE NORMAL for me to do it on the MT. :-)
Other switches i have used such as Netgear, one also has to note which are tagged and untagged, no shortcuts.

I think its fine to state the facts and let the user decide which way they want to go.

tmoneymikrotik · Sat Apr 24, 2021 4:15 am

I like the idea of using vlans to partition and isolate network traffic using ROUTEROS. You're contribution to this article is much appreciated @PCUNITE, MKX, SINDY. I also hope you generate enough traction for this to make it into the Wiki. Thank you ahead of time. Could you kindly show me how to modify the router and switchOS config in order to distribute the vlan information to several AP's using CAPsMan? Assuming you have already tried it. If you haven't it all good. I'm kind of embarrassed for saying this, so I'll just be straight up.... No offense ANAV, and with all due respect, please kindly refrain from lecturing me as to why it won't be possible. A simple no will suffice. Yes and NO are both answers to me.

Regards T Navarrete (tmoneymikrotik)

Mikrotik SOHO Devices: purchased 1 day ago.
1 x Non Wireless - POE Router (RouterOS)
1 x Poe Switch (SwitchOS)
2 x CAPs AC (RouterOS)

sindy · Mon Apr 26, 2021 11:17 am

Not sure it belongs here (as you've properly stated, this topic should actually be a wiki article). However:
There is no equivalent of Cisco's VTP on Mikrotik, so you cannot dynamically distribute VLAN configuration across wired network from a single device. But if you are interested solely in cAPs, you can keep the bridges on them VLAN-agnostic (vlan-filtering=no), which means that they will forward both tagless and tagged frames among ports without tagging/untagging them and use a single forwarding table, and you can use caps-man datapath settings to let the individual wireless interfaces tag/untag the traffic as forwarding it to/from the local bridge if you use local-forwarding=yes. With local-forwarding=no, all the client traffic between the CAPsMAN device an the cAPs runs encapsulated into transport frames and virtual wireless interfaces are created on the CAPsMAN machine, so use of VLANs may not be necessary at all in this case.

anav · Mon Apr 26, 2021 7:41 pm

I like the idea of using vlans to partition and isolate network traffic using ROUTEROS. You're contribution to this article is much appreciated @PCUNITE, MKX, SINDY. I also hope you generate enough traction for this to make it into the Wiki. Thank you ahead of time. Could you kindly show me how to modify the router and switchOS config in order to distribute the vlan information to several AP's using CAPsMan? Assuming you have already tried it. If you haven't it all good. I'm kind of embarrassed for saying this, so I'll just be straight up.... No offense ANAV, and with all due respect, please kindly refrain from lecturing me as to why it won't be possible. A simple no will suffice. Yes and NO are both answers to me.

Regards T Navarrete (tmoneymikrotik)

Mikrotik SOHO Devices: purchased 1 day ago.
1 x Non Wireless - POE Router (RouterOS)
1 x Poe Switch (SwitchOS)
2 x CAPs AC (RouterOS)

PCUNITEs article addresses vlans and the various equipment combinations. It does not address the use of capsman.
Whether or not he includes capsman in this article or creates one separate for capsman or NOT at all is up to him.
My advice is the same for all cases, if its 1-3 units, i dont see the value in attempting capsman right away due to the added layer of complexity and overhead. I still think its best to setup the vlans and understand the standard bridge vlan filtering setup for both wired and wireless first. Then one can tackle the capsman with a solid background in how wireless works and vlans work. Just advice......... Finally, if you want assistance start a new thread and I am sure the plethora of experienced capsman users will help you defing the config you desire.

mducharme · Tue Apr 27, 2021 4:48 am

As sindy suggested, for any CAPs you are using, I would generally recommend *not* using bridge VLAN filtering on the CAP itself. Use it on the routers and the switches, but not the CAP. The issue is that bridge VLAN filtering artificially limits what you can do with the CAP. For instance, normally you can do per client VLAN assignments for individual clients if you wish, but as soon as you enable bridge VLAN filtering on the CAP itself, that feature becomes, if not impossible, much more difficult to accomplish.

anav · Tue Apr 27, 2021 8:12 pm

As sindy suggested, for any CAPs you are using, I would generally recommend *not* using bridge VLAN filtering on the CAP itself. Use it on the routers and the switches, but not the CAP. The issue is that bridge VLAN filtering artificially limits what you can do with the CAP. For instance, normally you can do per client VLAN assignments for individual clients if you wish, but as soon as you enable bridge VLAN filtering on the CAP itself, that feature becomes, if not impossible, much more difficult to accomplish.

Hi Mudharm, I use capac and bridge vlan filtering with great success (and no capsman). I use a vlan per SSID to separate users.
What am I missing here??

mducharme · Wed Apr 28, 2021 6:39 pm

Hi Mudharm, I use capac and bridge vlan filtering with great success (and no capsman). I use a vlan per SSID to separate users.
What am I missing here??

You are talking about per-SSID VLANs - those work fine with bridge VLAN filtering. I'm talking about per-user VLANs with a single SSID - that does not work so well with bridge VLAN filtering. There are workarounds you could potentially use, but I find it easier to just not use bridge VLAN filtering on a CAP in the first place.

anav · Fri Apr 30, 2021 4:19 am

Hi Mudharm, I use capac and bridge vlan filtering with great success (and no capsman). I use a vlan per SSID to separate users.
What am I missing here??
You are talking about per-SSID VLANs - those work fine with bridge VLAN filtering. I'm talking about per-user VLANs with a single SSID - that does not work so well with bridge VLAN filtering. There are workarounds you could potentially use, but I find it easier to just not use bridge VLAN filtering on a CAP in the first place.

Ah okay got it, capsman and vlans is like mixing beer and wine.......and then drinking vodka LOL

mducharme · Sat May 01, 2021 7:33 am

Ah okay got it, capsman and vlans is like mixing beer and wine.......and then drinking vodka LOL

It isn't only with CAPsMAN - you can also assign VLANs to different clients on a single SSID without CAPsMAN using an access list that assigns the VLAN tag based on the MAC, or with RADIUS assigning per-user VLANs outside of CAPsMAN. The issue is that in either of those cases, the bridge VLAN filtering function is going to be blissfully unaware of what VLAN tags are being assigned to users based on either their MAC (in the ACL) or some RADIUS attribute, and are not going to allow those to pass to the switch by default as a result. But, if you do not enable bridge VLAN filtering on the CAP, all VLANs are passed, so this issue will not occur in the first place.

Jotne · Mon May 03, 2021 11:40 am

@pcunite

Nice guide
I do suggest you edit your header to

Using RouterOS(6.41+) to VLAN your network.

And

Title:
Using RouterOS to VLAN your network the new way with RouterOS 6.41+

This to make i clear what type of VLAN implementation you are using in this guid.

In Router-Switch-AP (all in one) you do use VLAN 99 as BASE/Native VLAN.
That is OK for learning, but my experience tells me that most starts off with VLAN 1 only and then later add one or more VLAN.
This will then make VLAN 1 as BASE/Native VLAN for the most of the people with small home router.

Aubey · Wed May 12, 2021 8:45 pm

VLAN beginner here - why do you disable RSTP on BR1 in the ROAS example?

anav · Thu May 13, 2021 7:48 pm

@pcunite

Nice guide
I do suggest you edit your header to

Using RouterOS(6.41+) to VLAN your network.
And

Title:
Using RouterOS to VLAN your network the new way with RouterOS 6.41+
This to make i clear what type of VLAN implementation you are using in this guid.

In Router-Switch-AP (all in one) you do use VLAN 99 as BASE/Native VLAN.
That is OK for learning, but my experience tells me that most starts off with VLAN 1 only and then later add one or more VLAN.
This will then make VLAN 1 as BASE/Native VLAN for the most of the people with small home router.

Negative as a homeowner, don't agree and it leads to nothing but problems.
keeping it default mirrors all other vendor managed switches which use vlan1 as a background default vlan, not the management vlan
You do get a lollipop for making a suggestion, but the flavour is moldy warts, a Hogwarts Candy ;-P

Jotne · Thu May 13, 2021 9:33 pm

Negative as a homeowner, don't agree and it leads to nothing but problems.

I totally agree with you. This was just from what I do see from real life situation. Most starts off with a basic router with all in VLAN 1, then add more VLANs as needed. In a good deign, management VLAN should be it own VLAN not one that are used for normal traffic.

camabeh · Sat May 15, 2021 10:21 pm

Hello, I've tried to replicate switch.rsc and router.rsc in GNS3 2.2.21 but it didn't work. I am using MikroTik firmware version v6.48.2.

I had to modify this section:
# Purple Trunk. L2 switching only, Bridge not needed as tagged member (except BASE_VLAN)
set bridge=BR1 tagged=sfp1,sfp2 [find vlan-ids=10]
set bridge=BR1 tagged=sfp1,sfp2 [find vlan-ids=20]
set bridge=BR1 tagged=sfp1,sfp2 [find vlan-ids=30]
add bridge=BR1 tagged=BR1,sfp1,sfp2 vlan-ids=99

With this to get it working:
# Purple Trunk. L2 switching only, Bridge not needed as tagged member (except BASE_VLAN)
set bridge=BR1 tagged=sfp1,sfp2 untagged=ether1,ether2,... vlan-ids=10
set bridge=BR1 tagged=sfp1,sfp2 untagged=ether9,ether10,... vlan-ids=20
set bridge=BR1 tagged=sfp1,sfp2 untagged=ether17,ether18,... vlan-ids=30
add bridge=BR1 tagged=BR1,sfp1,sfp2 vlan-ids=99

Any idea why it doesn't work?

DragonQ · Sun May 23, 2021 10:52 pm

Hi, I'm trying to use the RoaS approach and I've got most of it behaving as I want (I think). However, I can't seem to be able to ping the switch's IP address after assigning a management VLAN to the switch itself. Here's my config:

/interface bridge
add name=bridge1 protocol-mode=none vlan-filtering=no

/interface bridge port
add hw=yes bridge=bridge1 interface=ether1 pvid=399 comment="Switch management"
add hw=yes bridge=bridge1 interface=ether3 pvid=399 comment="Modem management"

/interface bridge vlan
add bridge=bridge1 untagged=ether3,ether1 vlan-ids=399
set [find bridge=bridge1 vlan-ids=399] tagged=bridge1

/interface vlan
add interface=bridge1 name=MGMT_VLAN vlan-id=399
/ip address
add address=192.168.3.1/28 interface=MGMT_VLAN

My desktop is plugged into ether1 (untagged VID 399) with IP set to 192.168.3.2/28. The switch has IP set to 192.168.3.1/28 on MGMT_VLAN interface, which has a VID of 399. Neither device can ping the other. What am I doing wrong here?

DragonQ · Sun May 23, 2021 10:56 pm

Hello, I've tried to replicate switch.rsc and router.rsc in GNS3 2.2.21 but it didn't work. I am using MikroTik firmware version v6.48.2.

I had to modify this section:
# Purple Trunk. L2 switching only, Bridge not needed as tagged member (except BASE_VLAN)
set bridge=BR1 tagged=sfp1,sfp2 [find vlan-ids=10]
set bridge=BR1 tagged=sfp1,sfp2 [find vlan-ids=20]
set bridge=BR1 tagged=sfp1,sfp2 [find vlan-ids=30]
add bridge=BR1 tagged=BR1,sfp1,sfp2 vlan-ids=99

With this to get it working:
# Purple Trunk. L2 switching only, Bridge not needed as tagged member (except BASE_VLAN)
set bridge=BR1 tagged=sfp1,sfp2 untagged=ether1,ether2,... vlan-ids=10
set bridge=BR1 tagged=sfp1,sfp2 untagged=ether9,ether10,... vlan-ids=20
set bridge=BR1 tagged=sfp1,sfp2 untagged=ether17,ether18,... vlan-ids=30
add bridge=BR1 tagged=BR1,sfp1,sfp2 vlan-ids=99

Any idea why it doesn't work?

The first time you refer to vlan-id, you need to use this syntax:

/interface bridge vlan
add bridge=bridge1 untagged=sfp-sfpplus1,sfp-sfpplus2,sfp-sfpplus3,sfp-sfpplus4,ether13,ether18,ether19,ether22,ether23 vlan-ids=100
add bridge=bridge1 untagged=ether11 vlan-ids=213

Any subsequent times you need to use this syntax:

/interface bridge vlan
set [find bridge=bridge1 vlan-ids=100] tagged=ether2
set [find bridge=bridge1 vlan-ids=211,212,213,311,399] tagged=ether4

anav · Mon May 24, 2021 1:38 pm

Start a thread in the general or beginner forum and stop polluting this thread with your issues please.

s00hr7 · Tue Jun 01, 2021 11:12 pm

First of all, thank you for this awesome topic, it helped me a lot when trying to set up my Mikrotik router and APs.

I have a question about security or probably best practices when it comes to VLANs with WIFI:

In your examples, you set up the wireless interfaces without setting "vlan-id" and "vlan-mode" to "use-tag" but you set the PVID on the bridge port. Thus you can handle the wifi interfaces as access ports and set "admit-only-untagged-and-priority-tagged" as for the ethernet ports.

It took me quite a while to figure out why this didn't work for me. It was because I used "vlan-mode=use-tag" in my CAPsMAN Datapath configuration (you can do it also on the wireless interface, without using CAPsMAN). In that case, the packets seem to enter the bridge already tagged, so I had to set "admit-only-vlan-tagged" on the bridge port, which makes it looks more like a trunk port.

Both configurations work, but I was wondering if there is a difference in how secure these two options are. Just from a readability point of view, I guess setting all access ports to "admit-only-untagged-and-priority-tagged" is clearer, but is there an actual impact on network security here, or are those just two ways to do the same thing?

pcunite · Thu Jun 10, 2021 5:47 am

I have a question about security or probably best practices when it comes to VLANs with WIFI:

I guess setting all access ports to "admit-only-untagged-and-priority-tagged" is clearer, but is there an actual impact on network security here, or are those just two ways to do the same thing?

Security is a topic I don't feel qualified to speak on. Nevertheless, the way you handle frames, tagged or not, matters a great deal. The security mindset thinks about the packet flow and where can they all get to. The VLAN mindset, a lot of thinking is about the source of packets, where did they come from? So, it is not the same thing. Access ports (this is just terminology) are what the industry calls a port in which packets are arriving without a tag present. Trunk ports are therefore classified as being the source of packets in which tags are expected, indeed required.

Using settings admit-only-untagged-and-priority-tagged or admit-only-vlan-tagged ensure the port acts as you expect and thus drop packets that don't comply. If you don't enforce VLAN, then the security benefits, however small they may be, are removed all together.

anav · Thu Jun 10, 2021 6:55 pm

This is NOT a wifi thread, nor a capsman thread, its a vlan thread and vlan security is covered in terms of best security practices which is the same as per any other vendor!
For WIFI, the standard is WPA2 (or whatever comes next) and if you want can add a radius server for additional security and finally do wifi over a VPN for example.

bcollie · Sat Jul 17, 2021 7:11 am

Noob alert...
Re the FirewallCustom.rsc file in Post#5

Lines 22 and 23 create new 'list' names of 'WAN' and 'VLAN'
/interface list add name=WAN
/interface list add name=VLAN

I see these used in the next group under '/interface list member' - makes sense so far.

However the last line (31) in this group shows:
add interface=BASE_VLAN list=BASE (my underlining)

Can you tell me where/when the 'list' item of 'BASE' was created?

Many thanks for your excellent tutorial material.

anav · Sun Jul 18, 2021 3:51 pm

Interface VLAN simply replaces Interface LAN, he could have kept it at LAN which is usually used to describe all subnets behind the router.
I have used VLAN and LAN separately to separate subnets out on a config, similiary I have used VLANW1 and VLANW0 to distinguish subnets with internet access and those without.
So lets ignore the VLAN one.

The BASE interface list is normally used (could be any name) to identify the trusted subnet, could be the homelan or the managmentlan etc.
Its just a way of identifying the trusted subnets, although usually one, in the interface list set.
WHy, because we can then use that easily for multiple reasons such as for firewall rules but also in tools mac winmac server to identify which interface list has access to winbox via mac address!

By the way in the input chain rule for access to the router via base inteface list, I typically add a firewall address list to narrow down the trusted interfaces to trusted IPs.............
source-address-list=adminaccess

where
add IPofadminDesktop list=adminaccess
add IPofadmingLaptop list=adminaccess
add IPofadminIpad list=adminaccess
add IPofadminSmartphone list=adminaccess

bojanpotocnik · Sun Aug 22, 2021 11:38 am

Am I missing something, or why in the switch.rsc file from the first post, the following does nothing:

# egress behavior
/interface bridge vlan

# Purple Trunk. L2 switching only, Bridge not needed as tagged member (except BASE_VLAN)
set bridge=BR1 tagged=sfp1,sfp2 [find vlan-ids=10]
set bridge=BR1 tagged=sfp1,sfp2 [find vlan-ids=20]
set bridge=BR1 tagged=sfp1,sfp2 [find vlan-ids=30]

also

/interface/bridge/vlan
:put [find vlan-ids=10]

outputs nothing.

Only the following line

add bridge=BR1 tagged=BR1,sfp1,sfp2 vlan-ids=99

adds a single entry under Bridge/VLANs tab.

I saw @DragonQ answer 6 post above which makes sense, however I have a feeling that example scripts shall work "out of the box". What is the expected effect of these 3 lines in the very first switch.rsc?

Additionally, the file switch_hybrid.rsc from the same post contains the following:

# egress behavior
/interface bridge vlan

# Purple Trunk. L2 switching only, Bridge not needed as tagged member (except BASE_VLAN)
add bridge=BR1 tagged=sfp1,sfp2 vlan-ids=10
add bridge=BR1 tagged=sfp1,sfp2 vlan-ids=20
add bridge=BR1 tagged=sfp1,sfp2 vlan-ids=30
add bridge=BR1 tagged=BR1,sfp1,sfp2 vlan-ids=99

which makes more sense.

Thank you

iegg · Thu Sep 02, 2021 9:37 am

Hi @pcunite ! Thanks for this comprehensive guide. Really helped me a lot in order to understand vlans and also to correctly config my MT

.

I have a question regarding VLAN security: There is also an ingress filtering/frame-type setting on the bridge itself, however it seems you did not configure this but only for the individual bridge ports. In my understanding the VLAN interface 99 for the router is bound to the bridge port (can you confirm?). If that is the case don't we also need to set ingress filtering/admit frame-types for the bridge, which seems to act as a trunk port (since we had to add the bridge as tagged member for VLAN99 for the router)?

PS: I really wish Mikrotik wouldn't have chosen the name bridge for the switch-like grouping of ports AND for the Layer 3 (CPU-Port) capabilities. It is very confusing. A different name in order to make things more clear would solve so many comprehension issues, especially for beginners.

Thank you all for your responses.

ofekd · Thu Sep 30, 2021 11:49 am

Thanks for the excellent guide.

I've posted a new topic about a problem I have but an admin didn't get to approve it yet. I hope posting here doesn't have the same restrictions.

Anything connected to the switch does not get an IP address from the router. I have looked at the leases and while the other networks (all connected through wifi) work fine, the devices connected to the switch are not.

Connecting to the wifi access point associated with the same VLAN as the ports on the switch works fine.

Router `ehter1` is connected to the modem, `ether2` connected to switch
Switch `ether1` connected to the router, with clients on `ether2` and `ether4`.

Scripts below.

Thank you!

Router (hap ac2):

###############################################################################
# Topic:		Using RouterOS to VLAN your network
# Example:		Switch with a separate router (RoaS)
# Web:			https://forum.mikrotik.com/viewtopic.php?t=143620
# RouterOS:		6.43.12
# Date:			Mar 28, 2019
# Notes:		Start with a reset (/system reset-configuration no-defaults=yes skip-backup=yes run-after-reset=flash/router.rsc)
# Thanks:		mkx, sindy
###############################################################################

:delay 30s

#######################################
# Housekeeping
#######################################

# name the device being configured
/system identity set name="MainRouterSwitch"

/system clock set time-zone-name=Asia/Jerusalem


#######################################
# VLAN Overview
#######################################

# 60 = GUEST (GREEN)
# 70 = RED
# 80 = BLUE
# 99 = BASE (MGMT) VLAN


#######################################
# Bridge
#######################################

# create one bridge, set VLAN mode off while we configure
/interface bridge add name=BR1 protocol-mode=none vlan-filtering=no

#######################################
#
# WIFI Setup
#
#######################################

# BASE SSID, admin level access to Winbox the device. Use a local ethernet port if preferred.
/interface wireless security-profiles set [ find default=yes ] authentication-types=wpa2-psk mode=dynamic-keys wpa2-pre-shared-key=""
/interface wireless set [ find default-name=wlan1 ] ssid=Home frequency=auto mode=ap-bridge disabled=no distance=indoors band=2ghz-b/g/n channel-width=20/40mhz-XX wireless-protocol=802.11
/interface wireless set [ find default-name=wlan2 ] ssid=Home frequency=auto mode=ap-bridge disabled=no distance=indoors band=5ghz-a/n/ac channel-width=20/40/80mhz-XXXX wireless-protocol=802.11

# GUEST SSID
/interface wireless security-profiles add name=HomeGuest authentication-types=wpa2-psk mode=dynamic-keys wpa2-pre-shared-key=""
/interface wireless add name=wlan3 ssid=HomeGuest master-interface=wlan1 security-profile=HomeGuest disabled=no
/interface wireless add name=wlan4 ssid=HomeGuest master-interface=wlan2 security-profile=HomeGuest disabled=no

# RED SSID
/interface wireless security-profiles add name=HomeUntrusted authentication-types=wpa2-psk mode=dynamic-keys wpa2-pre-shared-key=""
/interface wireless add name=wlan5 ssid=HomeUntrusted master-interface=wlan1 security-profile=HomeUntrusted disabled=no
/interface wireless add name=wlan6 ssid=HomeUntrusted master-interface=wlan2 security-profile=HomeUntrusted disabled=no

# BLUE SSID
/interface wireless security-profiles add name=HomeSafe authentication-types=wpa2-psk mode=dynamic-keys wpa2-pre-shared-key=""
/interface wireless add name=wlan7 ssid=HomeSafe hide-ssid=yes master-interface=wlan1 security-profile=HomeSafe disabled=no
/interface wireless add name=wlan8 ssid=HomeSafe hide-ssid=yes master-interface=wlan2 security-profile=HomeSafe disabled=no

#######################################
#
# -- Access Ports --
#
#######################################

# ingress behavior
/interface bridge port

# BASE VLAN
add bridge=BR1 interface=wlan1 pvid=99
add bridge=BR1 interface=wlan2 pvid=99

# GUEST
add bridge=BR1 interface=wlan3 pvid=60
add bridge=BR1 interface=wlan4 pvid=60

# RED
add bridge=BR1 interface=wlan5 pvid=70
add bridge=BR1 interface=wlan6 pvid=70

# BLUE
add bridge=BR1 interface=wlan7 pvid=80
add bridge=BR1 interface=wlan8 pvid=80

# egress behavior, handled automatically

#######################################
#
# -- Trunk Ports --
#
#######################################

# ingress behavior
/interface bridge port

# Purple Trunk. Leave pvid set to default of 1
add bridge=BR1 interface=ether2
add bridge=BR1 interface=ether3
add bridge=BR1 interface=ether4
add bridge=BR1 interface=ether5

# egress behavior
/interface bridge vlan

# Purple Trunk. These need IP Services (L3), so add Bridge as member
add bridge=BR1 tagged=BR1,ether2,ether3,ether4,ether5 vlan-ids=60
add bridge=BR1 tagged=BR1,ether2,ether3,ether4,ether5 vlan-ids=70
add bridge=BR1 tagged=BR1,ether2,ether3,ether4,ether5 vlan-ids=80
add bridge=BR1 tagged=BR1,ether2,ether3,ether4,ether5 vlan-ids=99


#######################################
# IP Addressing & Routing
#######################################

# LAN facing router's IP address on the BASE_VLAN
/interface vlan add interface=BR1 name=BASE_VLAN vlan-id=99
/ip address add address=192.168.0.1/24 interface=BASE_VLAN

# DNS server, set to cache for LAN
/ip dns set allow-remote-requests=yes servers="1.1.1.1,1.0.0.1"

# PPoE used instead of the config below
/interface pppoe-client
add add-default-route=yes disabled=no interface=ether1 name=pppoe-out1 \
    password=... use-peer-dns=no user=...

# WAN facing port with IP Address provided by ISP
# /ip address add interface=ether1 address=a.a.a.a/aa network=a.a.a.0

# router's gateway provided by ISP
# /ip route add distance=1 gateway=b.b.b.b


#######################################
# IP Services
#######################################

# GUEST VLAN interface creation, IP assignment, and DHCP service
/interface vlan add interface=BR1 name=GUEST_VLAN vlan-id=60
/ip address add interface=GUEST_VLAN address=10.0.60.1/24
/ip pool add name=GUEST_POOL ranges=10.0.60.2-10.0.60.254
/ip dhcp-server add address-pool=GUEST_POOL interface=GUEST_VLAN name=GUEST_DHCP disabled=no
/ip dhcp-server network add address=10.0.60.0/24 dns-server=192.168.0.1 gateway=10.0.60.1

# RED VLAN interface creation, IP assignment, and DHCP service
/interface vlan add interface=BR1 name=RED_VLAN vlan-id=70
/ip address add interface=RED_VLAN address=10.0.70.1/24
/ip pool add name=RED_POOL ranges=10.0.70.2-10.0.70.254
/ip dhcp-server add address-pool=RED_POOL interface=RED_VLAN name=RED_DHCP disabled=no
/ip dhcp-server network add address=10.0.70.0/24 dns-server=192.168.0.1 gateway=10.0.70.1

# BLUE VLAN interface creation, IP assignment, and DHCP service
/interface vlan add interface=BR1 name=BLUE_VLAN vlan-id=80
/ip address add interface=BLUE_VLAN address=10.0.80.1/24
/ip pool add name=BLUE_POOL ranges=10.0.80.2-10.0.80.254
/ip dhcp-server add address-pool=BLUE_POOL interface=BLUE_VLAN name=BLUE_DHCP disabled=no
/ip dhcp-server network add address=10.0.80.0/24 dns-server=192.168.0.1 gateway=10.0.80.1
/ip dhcp-server lease add address=10.0.80.2 mac-address=... server=BLUE_DHCP

# Optional: Create a DHCP instance for BASE_VLAN. Convenience feature for an admin.
/ip pool add name=BASE_POOL ranges=192.168.0.10-192.168.0.254
/ip dhcp-server add address-pool=BASE_POOL interface=BASE_VLAN name=BASE_DHCP disabled=no
/ip dhcp-server network add address=192.168.0.0/24 dns-server=192.168.0.1 gateway=192.168.0.1


#######################################
# Firewalling & NAT
# A good firewall for WAN. Up to you
# about how you want LAN to behave.
#######################################

# Use MikroTik's "list" feature for easy rule matchmaking.

/interface list add name=WAN
/interface list add name=RED
/interface list add name=BLUE
/interface list add name=BASE

/interface list member
# WAN/internet (was ether1, but ISP uses pppoe)
add interface=pppoe-out1    list=WAN

# Access internet, RED from each other
add interface=BASE_VLAN     list=RED
add interface=GUEST_VLAN    list=RED
add interface=RED_VLAN  list=RED

# BLUE is REDd and has no internet access
add interface=BLUE_VLAN     list=BLUE

# Base can access everything
add interface=BASE_VLAN     list=BASE

# VLAN aware firewall. Order is important.
/ip firewall filter


##################
# INPUT CHAIN
##################
add chain=input action=accept connection-state=established,related comment="Allow Estab & Related"

# Allow VLANs to access router services like DNS, Winbox.
add chain=input action=accept in-interface-list=RED comment="Allow VLAN"

# Allow BASE_VLAN full access to the device for Winbox, etc.
add chain=input action=accept in-interface=BASE_VLAN comment="Allow Base_Vlan Full Access"

# Allow server to access router services like DNS, Winbox.
add chain=input action=accept src-address=10.0.80.2 src-mac-address=... comment="Allow Server"

# Allow router services for BLUE
add chain=input action=accept in-interface-list=BLUE comment="Allow VLAN"

add chain=input action=drop comment="Drop"


##################
# FORWARD CHAIN
##################
add chain=forward action=accept connection-state=established,related comment="Allow Estab & Related"

# Allow RED VLANs to access the Internet only, NOT each other
add chain=forward action=accept connection-state=new in-interface-list=RED out-interface-list=WAN comment="VLAN Internet Access only"

# Allow BASE VLAN to access everything
add chain=forward action=accept connection-state=new in-interface=BASE_VLAN comment="BASE VLAN all access"

# Allow server to access the Internet only, NOT other VLANs
add chain=forward action=accept connection-state=new src-address=10.0.80.2 src-mac-address=... out-interface-list=WAN comment="Allow Server"

add chain=forward action=drop comment="Drop"


##################
# NAT
##################
/ip firewall nat add chain=srcnat action=masquerade out-interface-list=WAN comment="Default masquerade"


#######################################
# VLAN Security
#######################################

# Only allow packets with tags over the Trunk Ports
/interface bridge port
set bridge=BR1 ingress-filtering=yes frame-types=admit-only-vlan-tagged [find interface=ether2]
set bridge=BR1 ingress-filtering=yes frame-types=admit-only-vlan-tagged [find interface=ether3]
set bridge=BR1 ingress-filtering=yes frame-types=admit-only-vlan-tagged [find interface=ether4]
set bridge=BR1 ingress-filtering=yes frame-types=admit-only-vlan-tagged [find interface=ether5]


#######################################
# MAC Server settings
#######################################

# Ensure only visibility and availability from BASE_VLAN, the MGMT network
/ip neighbor discovery-settings set discover-interface-list=BASE
/tool mac-server mac-winbox set allowed-interface-list=BASE
/tool mac-server set allowed-interface-list=BASE


#######################################
# Turn on VLAN mode
#######################################
/interface bridge set BR1 vlan-filtering=yes

Switch (CRS112-8P-4S-IN):

###############################################################################
# Topic:		Using RouterOS to VLAN your network
# Example:		Switch with a separate router (RoaS)
# Web:			https://forum.mikrotik.com/viewtopic.php?t=143620
# RouterOS:		6.43.13
# Date:			April 15, 2021
# Notes:		Start with a reset (/system reset-configuration no-defaults=yes skip-backup=yes run-after-reset=flash/switch.rsc)
# Thanks:		mkx, sindy
###############################################################################

:delay 30s

#######################################
# Naming
#######################################

# name the device being configured
/system identity set name="CameraSwitch"

/system clock set time-zone-name=Asia/Jerusalem

#######################################
# VLAN Overview
#######################################

# 80 = BLUE
# 99 = BASE (MGMT) VLAN

# Other VLANS, not used here, may be defined elsewhere


#######################################
# Bridge
#######################################

# create one bridge, set VLAN mode off while we configure
/interface bridge add name=BR1 protocol-mode=none vlan-filtering=no


#######################################
#
# -- Access Ports --
#
#######################################

# ingress behavior
/interface bridge port

# BLUE VLAN
add bridge=BR1 interface=ether2 pvid=80
add bridge=BR1 interface=ether3 pvid=80
add bridge=BR1 interface=ether4 pvid=80
add bridge=BR1 interface=ether5 pvid=80
add bridge=BR1 interface=ether6 pvid=80
add bridge=BR1 interface=ether7 pvid=80
add bridge=BR1 interface=ether8 pvid=80

# egress behavior, handled automatically


#######################################
#
# -- Trunk Ports --
#
#######################################

# ingress behavior
/interface bridge port

# Purple Trunk. Leave pvid set to default of 1
add bridge=BR1 interface=ether1
add bridge=BR1 interface=sfp9
add bridge=BR1 interface=sfp10
add bridge=BR1 interface=sfp11
add bridge=BR1 interface=sfp12

# egress behavior
/interface bridge vlan

# Purple Trunk. L2 switching only, Bridge not needed as tagged member (except BASE_VLAN)
set bridge=BR1 tagged=ether1,sfp9,sfp10,sfp11,sfp12 [find vlan-ids=80]
add bridge=BR1 tagged=BR1,ether1,sfp9,sfp10,sfp11,sfp12 vlan-ids=99


#######################################
# IP Addressing & Routing
#######################################

# LAN facing Switch's IP address on a BASE_VLAN
/interface vlan add interface=BR1 name=BASE_VLAN vlan-id=99
/ip address add address=192.168.0.2/24 interface=BASE_VLAN

# The Router's IP this switch will use
/ip route add distance=1 gateway=192.168.0.1


#######################################
# IP Services
#######################################
# We have a router that will handle this. Nothing to set here.


#######################################
# VLAN Security
#######################################

# Only allow ingress packets without tags on Access Ports
/interface bridge port
set bridge=BR1 ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged [find interface=ether2]
set bridge=BR1 ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged [find interface=ether3]
set bridge=BR1 ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged [find interface=ether4]
set bridge=BR1 ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged [find interface=ether5]
set bridge=BR1 ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged [find interface=ether6]
set bridge=BR1 ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged [find interface=ether7]
set bridge=BR1 ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged [find interface=ether8]

# Only allow ingress packets WITH tags on Trunk Ports
set bridge=BR1 ingress-filtering=yes frame-types=admit-only-vlan-tagged [find interface=ether1]
set bridge=BR1 ingress-filtering=yes frame-types=admit-only-vlan-tagged [find interface=sfp9]
set bridge=BR1 ingress-filtering=yes frame-types=admit-only-vlan-tagged [find interface=sfp11]
set bridge=BR1 ingress-filtering=yes frame-types=admit-only-vlan-tagged [find interface=sfp11]
set bridge=BR1 ingress-filtering=yes frame-types=admit-only-vlan-tagged [find interface=sfp12]


#######################################
# MAC Server settings
#######################################

# Ensure only visibility and availability from BASE_VLAN, the MGMT network
/interface list add name=BASE
/interface list member add interface=BASE_VLAN list=BASE
/ip neighbor discovery-settings set discover-interface-list=BASE
/tool mac-server mac-winbox set allowed-interface-list=BASE
/tool mac-server set allowed-interface-list=BASE


#######################################
# Turn on VLAN mode
#######################################
/interface bridge set BR1 vlan-filtering=yes

anoldboy · Fri Oct 01, 2021 3:30 pm

Hi,

great guide to start understanding vlans!

My usual setup is:
routerOS (RoaS) <--> unmanaged switch <--> wifi access points (with vlan feature on every SSID)

How to build my setup in RouterOs in order the devices of wifi access points is getting ip address from the BASE_VLAN and the wifi will be able to have one SSID with BASE_VLAN and one SSID with GUESTS_VLAN? How to use bridge vlan filtering for the above configuration? My purpose is when plug a device on the RouterOS ethernets to connected to the BASE_VLAN and can managing all the access points connected to it and the same time the guests vlan will be able to pass on ssid.

Although I have understand how to create different access ports or trunk ports, I can't completely understand how to make the setup I have just mentioned.

Kind Regards!

sindy · Fri Oct 01, 2021 3:34 pm

Please create a new topic for this, preferably in the General subforum.

anav · Fri Oct 01, 2021 6:48 pm

Hi @pcunite ! Thanks for this comprehensive guide. Really helped me a lot in order to understand vlans and also to correctly config my MT .

I have a question regarding VLAN security: There is also an ingress filtering/frame-type setting on the bridge itself, however it seems you did not configure this but only for the individual bridge ports. In my understanding the VLAN interface 99 for the router is bound to the bridge port (can you confirm?). If that is the case don't we also need to set ingress filtering/admit frame-types for the bridge, which seems to act as a trunk port (since we had to add the bridge as tagged member for VLAN99 for the router)?

PS: I really wish Mikrotik wouldn't have chosen the name bridge for the switch-like grouping of ports AND for the Layer 3 (CPU-Port) capabilities. It is very confusing. A different name in order to make things more clear would solve so many comprehension issues, especially for beginners.

Thank you all for your responses.

Good question, I was told more than once, but one easily forgets things when older.
My understanding is as follows.
Setting ingress filtering on a bridge port is akin to saying, ONLY vlans assigned to the is port are allowed to ingress this port.
Setting ingress filtering on the bridge is less powerful and basically states allow only vlans that have been assigned to the router as a whole.

WIth that in mind. if you used ingress filtering on the bridge and not the ports, the result would be
a. any vlan that is identified on the bridge would be allowed to ingress on any bridge port.

b. You then can narrow down control of ports by stating the frame type.........
So only tagged frames would be allowed to ingress the port or only untagged frames etc....

c. finally one can more surgically allow ONLY specific vlans to specific ports by using ingress filtering on the bridge port itself.

This is how I see it working, but I know that is not correct. I may even have it backwards.
Based on my less than stellar understanding of switches.

sindy · Fri Oct 01, 2021 8:12 pm

I really wish Mikrotik wouldn't have chosen the name bridge for the switch-like grouping of ports AND for the Layer 3 (CPU-Port) capabilities. It is very confusing.

@iegg, please have a look at this post and tell me whether it helps remove some of that confusion.

dkomarov · Sat Oct 23, 2021 10:39 am

So do you mean wired or actually weird

Thank you, no I actually mean weird (using because noun phrasing) because I find it confusing to have bridge access set this way at this point in the syntax. The stated reasons, explain why, but I feel that port vs bridge (the bridge is a virtual switch or container for your ports) should be separate concepts. When setting up individual ports, why have this ungainly bridge thingy thrown in? Nevertheless, without understand this, unexpected behavior is the result. So, we have to document it.
...
I think my config file comments should probably be rewritten to be more clear:
Because weird, we "also" add the Bridge itself as a tagged member! This is required to control which packets get access to the Bridge itself.

Hello!
Think of the bridge itself as also a loopback interface.
You can assign an IP address to this loopback interface.

iegg · Thu Oct 28, 2021 6:20 pm

Thank you @sindy et al.. The bridge for myself is more or less clear now, however for beginners it is really hard to grasp the bridge concept.

@anav: I see the bridge also as a 'connection' between the vlan interface (not port) and the switch. So if i have a vlan interface i want to allow only tagged frames over the bridge 'connection' to the interface. Like that it would act as a trunk and in this case would disallow untagged frames to reach the vlan interface. Not sure if this is correct, but at least seems like a good idea;)

bojanpotocnik · Fri Nov 26, 2021 2:19 pm

Does the Router-Switch-AP (all in one) example also exists for Other devices with built-in switch chip (e.g. RB2011) where the recommended configuration is using the switch chip instead of setting

vlan-filtering=yes

(ether5 and ether6 connected with cable)?

SiB · Wed Feb 02, 2022 2:47 am

Does "Switch with Hybrid Ports" can be used at RB2011 ?
What with using ports from differ switch chips together ?
Maybe you can help answer at RB2011 How connect ports from differ HW switch ?

Dizzydude · Fri Feb 11, 2022 8:40 pm

VLAN beginner here - why do you disable RSTP on BR1 in the ROAS example?

I'd like to also ask this question. I have an RB5009 running ROSv7 and have seen in comments that maybe having the bridge set in RSTP or MSTP is better? I am a beginner, could someone please explain how this affects things in layman terms, and if in my hardware situation that might be the case to run it in RTSP or MSTP? Please let me know which is best. Happy to provide more info if required.

Thanks!

dbelliveau · Sun Mar 20, 2022 5:48 am

I'd like to also ask this question. I have an RB5009 running ROSv7 and have seen in comments that maybe having the bridge set in RSTP or MSTP is better?

A couple of things to consider here. How many switches do you have in your topology, how many vlans. Do you employ a topology that could possibly form a loop?
I.E.:

Screen Shot 2022-03-19 at 11.46.28 PM.png

(@sindy, @pcunite @Chupaka @avnav @sob @mkx please feel free to interject here, but even with a topology like this you could in theory just disable a protocol-mode and suppress loops from forming by forcing ingress to tagged-only discarding any untagged frames and suppressing any outbound that do not match your bridge vlan policy, and only mapping vlans to traverse ports that are needed directly from one router to another through your switch-centric infrastructure, in essence point-to-point L2 pathways that aren't freely flowing about your whole network, thus using some point to point IP space to configure a routing protocol, etc.) route all the time, switch when you have to.

Are you trying to integrate with Cisco, in particular, PVST+ is not operable with ROS, and you will need to use common protocol 802.1s (MST).

MST creates multiple instances of spanning tree and allows for multiple different topologies to inject where the break point is for loops in say a triangular or square network of bridges.
Here is a good link https://mum.mikrotik.com/presentations/ ... 905587.pdf

RSTP is by default configured and should work fine in most cases. If you are trying to predict your traffic flow during failure or control it, I would suggest delving deeper into the fundamentals of the protocol. MST can be added complexity.

If not, and I would guess for most users here, they do not have a potential for forming a loop on their hub and spoke topologies, and it can safely be disabled, just don't plug two ports between two bridges, unless you put them in a bond.
I.E.:

Screen Shot 2022-03-19 at 11.32.34 PM.png

Also 88639X chipset on the 5009 is on of the more impressive chips out there with few limitations, and especially since ROS7 updates.

See the first few tables here
https://help.mikrotik.com/docs/display/ ... p+Features

And the hardware offloading guide here
https://help.mikrotik.com/docs/display/ ... Offloading

StubArea51 · Wed Mar 23, 2022 2:24 pm

VLAN beginner here - why do you disable RSTP on BR1 in the ROAS example?
I'd like to also ask this question. I have an RB5009 running ROSv7 and have seen in comments that maybe having the bridge set in RSTP or MSTP is better? I am a beginner, could someone please explain how this affects things in layman terms, and if in my hardware situation that might be the case to run it in RTSP or MSTP? Please let me know which is best. Happy to provide more info if required.

Thanks!

In general, I recommend MSTP when a loop prevention protocol is needed because it is the most interoperable and scales much larger than RSTP.

I would also add that you want to understand the layer you're adding loop prevention for.

When you're connecting routers, you don't want to also be running spanning tree as you've not got two convergence domains - one for L2 and one for L3 dynamic routing protocols. I've worked on a lot of networks built like this and it often ends badly. Build PTP VLANs so that STP can be disabled.

When connecting hosts or other switches at L2, spanning tree makes more sense to prevent loops.

anav · Wed Mar 23, 2022 4:50 pm

Not an engineer or IT trained but I like rule of thumbs and I thought it was ---> use RTSP for MT devices, & use MTSP when using mixed devices???