Community discussions

 
User avatar
pcunite
Forum Veteran
Forum Veteran
Topic Author
Posts: 945
Joined: Sat May 25, 2013 5:13 am
Location: USA

Using RouterOS to VLAN your network

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 and Trunk 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.

vlanlogo.png

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.

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. When you have that understood, at least idealistically, you are ready to move on to IP Addressing & Routing.

Native, Base, & MGMT (management) VLAN:
Before designing IP Addressing & Routing, you'll need to choose a VLAN scheme. To get your VLAN going you have to start somewhere and that's usually something termed the Native VLAN. This would be the base network that you used to initiate your first connection to a router or switch. The Native VLAN is not a requirement but rather something that continues to exist if you allow it. Think of the Native VLAN as a term used to describe packets without a VLAN tag that move between your equipment and network. Whether or not this is a good thing is up to you. In our examples, we do not allow for this scenario. Instead we implement a Base VLAN (our name for the management VLAN). Over this network will be device to device traffic (routing, etc.). We also default Winbox availability here as well.

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 inter VLAN 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.
You do not have the required permissions to view the files attached to this post.
Last edited by pcunite on Thu Mar 28, 2019 5:13 pm, edited 20 times in total.
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Topic Author
Posts: 945
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: Using RouterOS to VLAN your network

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, router-on-a-stick) will facilitate those requests. Otherwise, only devices on the same VLAN can communicate with each other.

Switch Configuration at a glance:
switch.png

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.

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 we 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:
router.png

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 spins up a Blue DHCP server running on a configured Blue VLAN interface. It responds to the request, sending the packet back out its Trunk port.

Meanwhile, a PC plugged into the Green 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 inter VLAN access.


Switch Config File:
switch.rsc

Router Config File:
router.rsc
You do not have the required permissions to view the files attached to this post.
Last edited by pcunite on Mon Apr 01, 2019 5:45 am, edited 33 times in total.
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Topic Author
Posts: 945
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: Using RouterOS to VLAN your network

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:
wifi_router.png

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, instead we opt for a Green VLAN. If whatever is plugged into the single Green ethernet port is VLAN aware, it does not really matter. Once it hits our router/switch, its Green to us. It might be tempting to simply setup a separate bridge for your Guest network. For tiny all-in-one networks like this that is certainly a valid option.

But you wanted to learn VLAN so let's give you a better reason. Let's say that you do care about more than one VLAN aware device(s) on Green because there is a switch plugged in. If so, change the Green port into a Purple Trunk port managing a Red VLAN. Now, you have the option of at least three networks you could manage: your Blue home, Green guests, and Red for IoT devices and such. When they all come into the router, you can QoS and segment them differently because you have three VLAN interfaces to work with.

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
You do not have the required permissions to view the files attached to this post.
Last edited by pcunite on Thu Mar 28, 2019 4:55 pm, edited 24 times in total.
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Topic Author
Posts: 945
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: Using RouterOS to VLAN your network

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_point.png

Access Ports:
Do these have Access ports? Yes, the invisible kind! It's best to 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
You do not have the required permissions to view the files attached to this post.
Last edited by pcunite on Sun Mar 31, 2019 8:45 am, edited 18 times in total.
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Topic Author
Posts: 945
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: Using RouterOS to VLAN your network

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 inter VLAN 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:
router.png

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
You do not have the required permissions to view the files attached to this post.
Last edited by pcunite on Thu Mar 28, 2019 4:56 pm, edited 9 times in total.
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Topic Author
Posts: 945
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: Using RouterOS to VLAN your network

Sat Jan 05, 2019 1:08 am

Security

UNFINISHED TOPIC - WORK IN PROGRESS

Overview
In following this guide you may have noticed a lack of security related techniques being employed along the way. This was to focus on the VLAN configuration in a pure form. Now, we consecrate on tightening up several loose ends that will be necessary for deploying VLAN out in the wild.

To properly configure VLAN networks, or any form of a network, we must think about packet identity, direction, flow, permissions, and utilization. As we deep dive into these concepts you may feel like you're learning more than you ever thought you needed to. Depending on the level of value your network has to you, you only need to learn up to that level. I will endeavor to keep the example configurations simple enough to where you can apply only the parts you need.

packets.png

Security Utopia
Do understand that 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 have something in common. Both can be broken into! However, 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 implementing 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 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. Your concern should not be about how to stop credential theft. Instead, be aware and plan for when a staff id goes rogue. There are also several other Layer 2 related things you need to know about because they will be coming in through these Access ports. Always drop ingress packets that 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 must be capable of locating the tap. Do not utilize automated Trunk port configuration, without also notifying yourself when such events occur. Always drop ingress packets that don't have tags.

Take the opportunity to understand and document the types of VLAN interfaces you are managing. You should always have at least one VLAN per department, per building, or even per floor, even if you don't plan to segment the traffic. 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. I 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 only has the necessary access to different resources, however, can be a daunting task. For this topic, we show different levels of Security, each progressing further and further in complexity.

Security Level 1
In this level ...
You do not have the required permissions to view the files attached to this post.
Last edited by pcunite on Thu Apr 04, 2019 4:37 pm, edited 14 times in total.
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Topic Author
Posts: 945
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: Using RouterOS to VLAN your network

Sat Jan 05, 2019 1:10 am

Reserved
 
mkx
Forum Guru
Forum Guru
Posts: 2828
Joined: Thu Mar 03, 2016 10:23 pm

Re: Using RouterOS to VLAN your network

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.
BR,
Metod
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Topic Author
Posts: 945
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: Using RouterOS to VLAN your network

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
Forum Guru
Forum Guru
Posts: 3806
Joined: Mon Dec 04, 2017 9:19 pm

Re: Using RouterOS to VLAN your network

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.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Topic Author
Posts: 945
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: Using RouterOS to VLAN your network

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.
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8305
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

Re: Using RouterOS to VLAN your network

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
Russian-speaking forum: https://forum.mikrotik.by/. Welcome!

For every complex problem, there is a solution that is simple, neat, and wrong.

MikroTik. Your life. Your routing.
 
Dude2048
Frequent Visitor
Frequent Visitor
Posts: 81
Joined: Thu Sep 01, 2016 4:04 pm

Re: Using RouterOS to VLAN your network

Wed Feb 06, 2019 6:32 pm

Great work. Normis, make this topic sticky..
 
anav
Forum Guru
Forum Guru
Posts: 2940
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Using RouterOS to VLAN your network

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??
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
User avatar
mozerd
Member Candidate
Member Candidate
Posts: 255
Joined: Thu Oct 05, 2017 3:39 pm
Location: Canada
Contact:

Re: Using RouterOS to VLAN your network

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
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Topic Author
Posts: 945
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: Using RouterOS to VLAN your network

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
Forum Guru
Forum Guru
Posts: 2828
Joined: Thu Mar 03, 2016 10:23 pm

Re: Using RouterOS to VLAN your network

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:
  1. I guess the old (legacy) way is to configure
    /interface wireless set [ find name=wlan1 ] vlan-mode=use-tag vlan-id=BLUE
    and configure wlan1 interface as tagged member port of bridge
  2. 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?
BR,
Metod
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Topic Author
Posts: 945
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: Using RouterOS to VLAN your network

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:
  1. vlan-mode=use-tag vlan-id=BLUE
  2. 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!
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Topic Author
Posts: 945
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: Using RouterOS to VLAN your network

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
Forum Guru
Forum Guru
Posts: 2828
Joined: Thu Mar 03, 2016 10:23 pm

Re: Using RouterOS to VLAN your network

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 :lol:
BR,
Metod
 
mkx
Forum Guru
Forum Guru
Posts: 2828
Joined: Thu Mar 03, 2016 10:23 pm

Re: Using RouterOS to VLAN your network

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 ...
BR,
Metod
 
anav
Forum Guru
Forum Guru
Posts: 2940
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Using RouterOS to VLAN your network

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. :-P
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
mkx
Forum Guru
Forum Guru
Posts: 2828
Joined: Thu Mar 03, 2016 10:23 pm

Re: Using RouterOS to VLAN your network

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.
BR,
Metod
 
anav
Forum Guru
Forum Guru
Posts: 2940
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Using RouterOS to VLAN your network

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 :-P

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....
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Topic Author
Posts: 945
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: Using RouterOS to VLAN your network

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
Forum Guru
Forum Guru
Posts: 2940
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Using RouterOS to VLAN your network

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..........
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Topic Author
Posts: 945
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: Using RouterOS to VLAN your network

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
Forum Guru
Forum Guru
Posts: 2940
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Using RouterOS to VLAN your network

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!!
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
mkx
Forum Guru
Forum Guru
Posts: 2828
Joined: Thu Mar 03, 2016 10:23 pm

Re: Using RouterOS to VLAN your network

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.
BR,
Metod
 
User avatar
mozerd
Member Candidate
Member Candidate
Posts: 255
Joined: Thu Oct 05, 2017 3:39 pm
Location: Canada
Contact:

Re: Using RouterOS to VLAN your network

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.
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Topic Author
Posts: 945
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: Using RouterOS to VLAN your network

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.
Last edited by pcunite on Sat Feb 09, 2019 4:33 pm, edited 1 time in total.
 
anav
Forum Guru
Forum Guru
Posts: 2940
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Using RouterOS to VLAN your network

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.
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
anav
Forum Guru
Forum Guru
Posts: 2940
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Using RouterOS to VLAN your network

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..............
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
ilkogd
just joined
Posts: 16
Joined: Wed Sep 05, 2018 3:48 pm

Re: Using RouterOS to VLAN your network

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
Forum Guru
Forum Guru
Posts: 2828
Joined: Thu Mar 03, 2016 10:23 pm

Re: Using RouterOS to VLAN your network

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:
  1. more specific rules have to come earlier not to mis-trigger on the more general rule
  2. 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.
BR,
Metod
 
sindy
Forum Guru
Forum Guru
Posts: 3806
Joined: Mon Dec 04, 2017 9:19 pm

Re: Using RouterOS to VLAN your network

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.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
anav
Forum Guru
Forum Guru
Posts: 2940
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Using RouterOS to VLAN your network

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
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
mkx
Forum Guru
Forum Guru
Posts: 2828
Joined: Thu Mar 03, 2016 10:23 pm

Re: Using RouterOS to VLAN your network

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 :wink:
BR,
Metod
 
anav
Forum Guru
Forum Guru
Posts: 2940
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Using RouterOS to VLAN your network

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 :wink:
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
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Topic Author
Posts: 945
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: Using RouterOS to VLAN your network

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
Forum Guru
Forum Guru
Posts: 2828
Joined: Thu Mar 03, 2016 10:23 pm

Re: Using RouterOS to VLAN your network

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?
BR,
Metod
 
anav
Forum Guru
Forum Guru
Posts: 2940
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Using RouterOS to VLAN your network

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
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
sindy
Forum Guru
Forum Guru
Posts: 3806
Joined: Mon Dec 04, 2017 9:19 pm

Re: Using RouterOS to VLAN your network

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?
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
anav
Forum Guru
Forum Guru
Posts: 2940
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Using RouterOS to VLAN your network

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. ;-)
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
mkx
Forum Guru
Forum Guru
Posts: 2828
Joined: Thu Mar 03, 2016 10:23 pm

Re: Using RouterOS to VLAN your network

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 ...
BR,
Metod
 
sindy
Forum Guru
Forum Guru
Posts: 3806
Joined: Mon Dec 04, 2017 9:19 pm

Re: Using RouterOS to VLAN your network

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.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Topic Author
Posts: 945
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: Using RouterOS to VLAN your network

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
Forum Guru
Forum Guru
Posts: 2828
Joined: Thu Mar 03, 2016 10:23 pm

Re: Using RouterOS to VLAN your network

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?
BR,
Metod
 
sindy
Forum Guru
Forum Guru
Posts: 3806
Joined: Mon Dec 04, 2017 9:19 pm

Re: Using RouterOS to VLAN your network

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.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
anav
Forum Guru
Forum Guru
Posts: 2940
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Using RouterOS to VLAN your network

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
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
mkx
Forum Guru
Forum Guru
Posts: 2828
Joined: Thu Mar 03, 2016 10:23 pm

Re: Using RouterOS to VLAN your network

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.
BR,
Metod
 
anav
Forum Guru
Forum Guru
Posts: 2940
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Using RouterOS to VLAN your network

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 ????
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
mkx
Forum Guru
Forum Guru
Posts: 2828
Joined: Thu Mar 03, 2016 10:23 pm

Re: Using RouterOS to VLAN your network

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).
Last edited by mkx on Mon Feb 11, 2019 4:02 pm, edited 1 time in total.
BR,
Metod
 
User avatar
mozerd
Member Candidate
Member Candidate
Posts: 255
Joined: Thu Oct 05, 2017 3:39 pm
Location: Canada
Contact:

Re: Using RouterOS to VLAN your network

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
Forum Guru
Forum Guru
Posts: 2940
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Using RouterOS to VLAN your network

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!!!!!
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
joystick
just joined
Posts: 12
Joined: Wed Jan 09, 2019 3:42 pm

Re: Using RouterOS to VLAN your network

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
Forum Guru
Forum Guru
Posts: 2940
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Using RouterOS to VLAN your network

Tue Feb 19, 2019 4:08 am

Go back to your original thread please for more assistance. :-)
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
anav
Forum Guru
Forum Guru
Posts: 2940
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Using RouterOS to VLAN your network

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!
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
mkx
Forum Guru
Forum Guru
Posts: 2828
Joined: Thu Mar 03, 2016 10:23 pm

Re: Using RouterOS to VLAN your network

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 ...
BR,
Metod
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Topic Author
Posts: 945
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: Using RouterOS to VLAN your network

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. : - )
Last edited by pcunite on Sat Feb 23, 2019 9:15 pm, edited 1 time in total.
 
anav
Forum Guru
Forum Guru
Posts: 2940
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Using RouterOS to VLAN your network

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.................
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
anav
Forum Guru
Forum Guru
Posts: 2940
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Using RouterOS to VLAN your network

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 ?????????????????????
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Topic Author
Posts: 945
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: Using RouterOS to VLAN your network

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
Forum Guru
Forum Guru
Posts: 2940
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Using RouterOS to VLAN your network

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??
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Topic Author
Posts: 945
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: Using RouterOS to VLAN your network

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
Forum Guru
Forum Guru
Posts: 2940
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Using RouterOS to VLAN your network

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.
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Topic Author
Posts: 945
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: Using RouterOS to VLAN your network

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
Forum Guru
Forum Guru
Posts: 2940
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Using RouterOS to VLAN your network

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).
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
anav
Forum Guru
Forum Guru
Posts: 2940
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Using RouterOS to VLAN your network

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.
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Topic Author
Posts: 945
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: Using RouterOS to VLAN your network

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
Forum Guru
Forum Guru
Posts: 2940
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Using RouterOS to VLAN your network

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.
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
mkx
Forum Guru
Forum Guru
Posts: 2828
Joined: Thu Mar 03, 2016 10:23 pm

Re: Using RouterOS to VLAN your network

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.
BR,
Metod
 
anttech
just joined
Posts: 12
Joined: Mon Jan 14, 2019 12:05 am

Re: Using RouterOS to VLAN your network

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
Forum Guru
Forum Guru
Posts: 3806
Joined: Mon Dec 04, 2017 9:19 pm

Re: Using RouterOS to VLAN your network

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).
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
mixig
Member Candidate
Member Candidate
Posts: 263
Joined: Thu Oct 27, 2011 2:19 pm

Re: Using RouterOS to VLAN your network

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
Forum Guru
Forum Guru
Posts: 2940
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Using RouterOS to VLAN your network

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.
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
plisken
Forum Guru
Forum Guru
Posts: 2409
Joined: Sun May 15, 2011 12:24 am
Location: Belgium
Contact:

Re: Using RouterOS to VLAN your network

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
Forum Guru
Forum Guru
Posts: 3806
Joined: Mon Dec 04, 2017 9:19 pm

Re: Using RouterOS to VLAN your network

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.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
HiltonT
Frequent Visitor
Frequent Visitor
Posts: 75
Joined: Mon Feb 07, 2011 4:24 am
Location: 'Srayamate
Contact:

Re: Using RouterOS to VLAN your network

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.
Regards,
Hilton Travis
 
benjaminhso
just joined
Posts: 5
Joined: Wed Jul 17, 2019 4:53 pm

Re: Using RouterOS to VLAN your network

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
Forum Guru
Forum Guru
Posts: 3806
Joined: Mon Dec 04, 2017 9:19 pm

Re: Using RouterOS to VLAN your network

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.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
marinaman
newbie
Posts: 39
Joined: Tue Jul 30, 2019 9:40 pm

Re: Using RouterOS to VLAN your network

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
Forum Guru
Forum Guru
Posts: 2940
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Using RouterOS to VLAN your network

Thu Aug 01, 2019 7:50 pm

I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
ZiadZone
just joined
Posts: 11
Joined: Tue Aug 27, 2019 10:37 am

Re: Using RouterOS to VLAN your network

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
Forum Guru
Forum Guru
Posts: 2940
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Using RouterOS to VLAN your network

Wed Aug 28, 2019 6:50 pm

start a new thread if you wish help on your configuration.
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
ZiadZone
just joined
Posts: 11
Joined: Tue Aug 27, 2019 10:37 am

Re: Using RouterOS to VLAN your network

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
just joined
Posts: 1
Joined: Fri Aug 09, 2019 10:41 pm

Re: Using RouterOS to VLAN your network

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.

Who is online

Users browsing this forum: No registered users and 22 guests