Hello forum, and Happy New Year

For a while I've been playing with a MT RB750GR3, running 7.1. I've managed to get an IPSEC VPN going for my IP phone to connect to the office and I was able to get a Wireguard VPN going that still needs some work, but that is not my concern at the moment.

Since I only have access to one managed PoE (DLINK) switch, it is segmented (VLAN'd) off into five VLANS:

VLAN 10 - 192.168.10.0/24 - LAN
VLAN 20 - 192.168.20.0/24 - Wifi
VLAN 30 - 192.168.30.0/24 - Guest Wifi
VLAN 40 - 192.168.40.0/24 - Voice
VLAN 50 - 192.168.40.0/24 - Spouse's "work from home" network

The above VLANs use a total of 9 access ports on the switch. The 10th and last port is a trunk port on the switch that connects to the MT on ethernet 2. Essentially, I have created a ROS set up, however, I need to stop traffic between the VLANs, with the exception of VLAN 10 needing access to everything since I will use my PC on that subnet to manage Access Points on the other VLANs/subnets.

To complicate matters, I have setup Pi-hole on a raspberry Pi. All networks use its IP address, 192.168.10.11, for DNS. With tutorials and articles online, I was able to set it up that no matter what a (savvy) user would change on their system, they will always wind up using Pi-hole for DNS. I would like this to stay the same also, so that doesn't make things easier, I think.

The articles I've read so far are confusing to me in that I don't know if my model of MT should be able to separate the traffic between the VLANs in this ROS setup, or not? If it should automatically do so, something is definitely wrong in my configuration.
And I have not created a bridge. Articles I've read (https://wiki.mikrotik.com/wiki/Manual:Bridge_VLAN_Table) shows a diagram of what looks like to be a ROS setup but then the configuration steps go on to say:

/interface bridge port
add bridge=bridge1 interface=ether1
add bridge=bridge1 interface=ether2 pvid=20
add bridge=bridge1 interface=ether3 pvid=30


... which is confusing the heck out of me - why are now more than one interface involved, when only one interface is involved in a ROS setup?

I have tried to block traffic between ie. VLAN 10 and VLAN 20 by adding the following, without success in blocking the traffic from VLAN 20 to VLAN 10:
action=drop chain=forward connection-nat-state="" connection-state=new dst-address=192.168.10.0/24 src-address=192.168.20.0/24

I would like to know if I should be creating a bridge when only one interface is being used, or am I going about this the wrong way altogether? Clearly I am missing some important steps, but I can't wrap my head around what I am not doing, or doing correct.

Here is my complete current configuration (added comments and spaces in between sections for clarity)

#==========================================================

# jan/03/2022 11:56:09 by RouterOS 7.1
# software id = 72VR-1FM3
#
# model = RB750Gr3
# serial number = D5030E3E8970

/interface ethernet
set [ find default-name=ether1 ] name=ether1-WAN
set [ find default-name=ether5 ] comment="Management port" name=ether5-access

/interface wireguard
add listen-port=13231 mtu=1420 name=wireguard1

#VLAN interfaces:
/interface vlan
add interface=ether2 name=GuestWifi vlan-id=30
add interface=ether2 name=LAN vlan-id=10
add interface=ether2 name=Phone vlan-id=40
add interface=ether2 name=Spouse-work vlan-id=50
add interface=ether2 name=Wifi vlan-id=20

/interface lte apn
set [ find default=yes ] ip-type=ipv4

/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik

# IPSEC section;
/ip ipsec peer
add address=184.69.46.238/32 local-address=184.68.82.26 name=XXXXXXXXXX
/ip ipsec profile
set [ find default=yes ] dh-group=modp1024 dpd-interval=10s enc-algorithm=3des hash-algorithm=md5 lifetime=8h name=XXXXXXXXXX nat-traversal=no
/ip ipsec proposal
set [ find default=yes ] disabled=yes
add enc-algorithms=3des lifetime=8h name=XXXXXXXXXX

/ip pool
add comment=VLAN-10 name=LAN ranges=192.168.10.40-192.168.10.60
add comment=Management name=Ether5-access ranges=192.168.100.10-192.168.100.20
add comment=VLAN-20 name=Wifi ranges=192.168.20.2-192.168.20.254
add comment=VLAN-30 name=GuestWifi ranges=192.168.30.2-192.168.30.254
add comment=VLAN-40 name=Phone ranges=192.168.40.2-192.168.40.254
add comment=VLAN-50 name=Spouse-work ranges=192.168.50.2-192.168.50.254

/ip dhcp-server
add address-pool=LAN interface=LAN name=LAN
add address-pool=Ether5-access interface=ether5-access name=dhcp1
add address-pool=Wifi interface=Wifi name=Wifi
add address-pool=GuestWifi interface=GuestWifi name=GuestWifi
add address-pool=Phone interface=Phone name=Phone
add address-pool=Spouse-work interface=Spouse-work name=dhcp2

/port
set 0 name=serial0
/routing bgp template
set default as=65530 disabled=no name=default output.network=bgp-networks
/routing ospf instance
add name=default-v2
/routing ospf area
add disabled=yes instance=default-v2 name=backbone-v2

/ipv6 settings
set disable-ipv6=yes max-neighbor-entries=8192

/interface wireguard peers
add allowed-address=192.168.60.2/24,192.168.60.3/24 interface=wireguard1 public-key="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX="

/ip address
add address=172.16.16.1/24 disabled=yes interface=ether5-access network=172.16.16.0
add address=192.168.10.1/24 interface=LAN network=192.168.10.0
add address=192.168.20.1/24 interface=Wifi network=192.168.20.0
add address=192.168.30.1/24 interface=GuestWifi network=192.168.30.0
add address=192.168.40.1/24 interface=Phone network=192.168.40.0
add address=192.168.50.1/24 interface=Spouse-work network=192.168.50.0
add address=192.168.60.1/24 interface=wireguard1 network=192.168.60.0
add address=184.68.82.26/29 interface=ether1-WAN network=184.68.82.24
add address=192.168.100.1/24 interface=ether5-access network=192.168.100.0

/ip dhcp-server lease
add address=192.168.10.4 client-id=1:18:c0:4d:26:b8:1d comment="Marcel's PC" mac-address=18:C0:4D:26:B8:1D server=LAN
add address=192.168.10.2 client-id=ff:5e:4f:ac:2d:0:1:0:1:29:60:9d:fc:e0:d5:5e:4f:ac:2d comment="File server" mac-address=E0:D5:5E:4F:AC:2D server=LAN

/ip dhcp-server network
add address=192.168.10.0/24 dns-server=192.168.10.11 gateway=192.168.10.1
add address=192.168.20.0/24 dns-server=192.168.10.11 gateway=192.168.20.1
add address=192.168.30.0/24 dns-server=192.168.10.11 gateway=192.168.30.1
add address=192.168.40.0/24 dns-server=192.168.10.11 gateway=192.168.40.1
add address=192.168.50.0/24 dns-server=192.168.10.11 gateway=192.168.50.1
add address=192.168.100.0/24 dns-server=8.8.8.8 gateway=192.168.100.1

/ip dns
set servers=192.168.10.11

/ip firewall filter
add action=accept chain=input dst-port=13231 protocol=udp
add action=accept chain=forward
add action=drop chain=forward connection-nat-state="" connection-state=new dst-address=192.168.10.0/24 src-address=192.168.20.0/24
add action=drop chain=forward connection-nat-state="" connection-state=new dst-address=192.168.10.0/24 src-address=192.168.30.0/24
add action=drop chain=forward connection-state=established dst-address=192.168.10.0/24 src-address=192.168.40.0/24
add action=drop chain=forward connection-state=established dst-address=192.168.10.0/24 src-address=192.168.50.0/24
add action=drop chain=forward disabled=yes dst-address=192.168.10.0/24 src-address=192.168.60.0/24

/ip firewall nat
add action=accept chain=srcnat comment="IP phone NAT rule" dst-address=10.1.2.0/24 src-address=192.168.40.0/24
add action=masquerade chain=srcnat comment="LAN to Internet MASQuerading"
add action=dst-nat chain=dstnat comment=Pihole dst-address=!192.168.10.11 dst-port=53 in-interface=!ether1-WAN protocol=udp src-address=!192.168.10.11 to-addresses=192.168.10.11
add action=dst-nat chain=dstnat comment=Pihole dst-address=!192.168.10.11 dst-port=53 in-interface=!ether1-WAN protocol=tcp src-address= !192.168.10.11 to-addresses=192.168.10.11
add action=masquerade chain=srcnat comment=Pihole dst-address=192.168.10.11 dst-port=53 protocol=udp src-address=192.168.10.0/24
add action=masquerade chain=srcnat comment=Pihole dst-address=192.168.10.11 dst-port=53 protocol=tcp src-address=192.168.10.0/24

#This is added for the IP phone to have two-way voice traffic:
/ip firewall raw
add action=notrack chain=prerouting dst-address=10.1.2.0/24 src-address=192.168.40.0/24
add action=notrack chain=prerouting dst-address=192.168.40.0/24 src-address=10.1.2.0/24

/ip firewall service-port
set ftp disabled=yes
set tftp disabled=yes
set irc disabled=yes
set h323 disabled=yes
set sip disabled=yes
set pptp disabled=yes
set udplite disabled=yes
set dccp disabled=yes
set sctp disabled=yes
/ip ipsec identity
add peer=XXXXXXXXXX

/ip ipsec policy
add dst-address=10.1.2.0/24 peer=XXXXXXXXXX proposal=XXXXXXXXXX src-address=192.168.40.0/24 tunnel=yes
set 1 disabled=yes

/ip route
add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=184.68.82.25 pref-src="" routing-table=main scope=30 suppress-hw-offload=no target-scope=10

/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set ssh disabled=yes
set api disabled=yes
set api-ssl disabled=yes

/system clock
set time-zone-name=America/Winnipeg

/tool sniffer
set file-name=Wireshark filter-interface=ether1-WAN memory-limit=1000KiB

#==========================================================

Thank you in advance for taking the time to point me in the right direction.

VLAN setup is fine. You only have to use bridge if you want to use RB750Gr3 in a switch-like fashion.

The firewall section could use some improvements. The problem with "allow unless blocked" approach (the way your firewall is done now) is that it's extremely hard to remember all the things that should be blocked. It is much easier to do it the other way around: make a general "drop all" rule (keep it the last on the rule list) and add more specific "allow" rule before it. In your case, however, your blocking rules are all made irrelevant by the second rule (action=accept chain=forward).

E.g. you current firewall allows all traffic between arbitrary pair of VLANs, only VLAN 10 is protected from others. So if you went with the "drop the rest" concept, you would have to allow traffic from VLAN10 everywhere, allow traffic leaving router through WAN interface(s) (i.e. ether1-wan and possibly wireguard1) ... and block all traffic (as the last rule).

Thank you for the quick response.

"only VLAN 10 is protected from others" - I understand. This rule does nothing to prevent traffic between VLANs 20 - 50.

The "drop all" rule concept at the end, and add allowed traffic above it is logic and seems practical, however, I do also have to consider that all VLANs need to be able to get to DNS, which is currently on VLAN10. Could I make it easier on myself if the Pi-hole DNS server was connected to ie ethernet 3, on another subnet? Or would that not matter?

Could you give me an example config line(s) of how I would accomplish a "drop all" as you suggested and allow necessary WAN access for everything?

Example of a drop all rule on the input chain while allowing just what we need before that...
https://help.mikrotik.com/docs/display/ ... uteritself

Thanks, I'll take a good look at that, maybe later today or evening.

This is the standard for setting up vlans
viewtopic.php?t=143620

One bridge,
Define vlans and their interface is the bridge.
Each vlan gets an IP address, ip pool, dhcp server, dhcp server network./

Interface bridge ports.
1. Where you assign ports to the bridge (typically 1 is WAN, eth2 in your case to the switch.
2. Where you detail which ones are trunk, access or hybrid ports (trunk carry one or more vlans tagged, access untag packets to the dumb device and tag packets coming from the dumb device).
3. each port should have ingress filtering assigned, trunk ports frames allowed - only tagged, access ports frames allowed - only priority and untagged.
4. In addition the interface access ports also require pvid setting = vlan number.

Interface bridge vlans.
1. where each line refers to a vlan-id(vlan).
2. All trunk ports should be tagged for a vlan they are carrying
3. Bridge should be tagged on every line
4. All access ports are dynamically tagged by the router (if they have a pvid ID assigned on the bridge port) and do not require to show as being untagged **
5. The exception is if the vlan has no tagged ports, the vlan-ids still requires a line with at least the bridge tagged.

****** I personally prefer to show all the untagged ports in the config (manually inserted) and that way I can more easily cross check my config.

- getting interface lists right is important
- getting firewall rules right is important.

Firewall rules are weak .....
In addition as noted, its best to have drop all rules at the end of the input and forward chains and thus
besides most of the default rules, the admin only needs to worry about what is allowed flow. Much simpler.

This is the basic safe firewall ruleset one should start with:
/ip firewall filter
add action=accept chain=input comment="default configuration" \
connection-state=established,related,untracked
add action=drop chain=forward comment="default configuration" \
connection-state=invalid
add action=accept chain=input dst-port=13231 protocol=udp in-interface=ether1-WAN
add action=accept chain=input comment="default configuration" protocol=icmp
add action=accept chain=input in-interface-list=LAN ***********
add action=accept chain=input comment="Allow LAN DNS queries-UDP" \
connection-state=new dst-port=53 in-interface-list=LAN protocol=udp
add action=accept chain=input comment="Allow LAN DNS queries - TCP" \
connection-state=new dst-port=53 in-interface-list=LAN protocol=tcp
add action=drop chain=input comment="drop all else"
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=fasttrack-connection chain=forward comment="default configuration" \
connection-state=established,related
add chain=forward comment="default configuration" connection-state=\
established,related,untracked
add action=drop chain=forward comment="default configuration" \
connection-state=invalid
add action=accept chain=forward in-interface-list=LAN out-interface-list=WAN
add action=accept chain=forward in-interface=vlan10 out-interface-list=LAN
add action=accept chain=forward comment="allow port forwarding" \
connection-nat-state=dstnat connection-state=new in-interface-list=WAN
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
add action=drop chain=forward comment="drop all else"

Where the +++++++ indicates where to put additional allow rules for traffic.

************ This is noted because you should see that we allow all the LAN access to the router and then after that allow all the LAN access to DNS services.
THe idea is to change the LAN interface list, to a MANAGMENT interface list, typically interfaces that the admin will use (trusted) to config the router and where he/she normally resides.

So for example BEFORE making firewall rule changes FIRST make the interface list MANAGMENT
add interface=vpn interface list=MANAGEMENT {assuming using vpn to remotely access and configure the router}
add interface=wireguard interface list=MANAGEMENT { {assuming using wg to remotely access and configure the router}
add interface=trusted vlan (20?) list=MANAGEMENT {assuming this is where the admin resides normally to access the router for config}
add interface=ether5-access list=MANAGMENT { this will allow OFF BRIDGE access to the router).

Then the input chain, rule would change from
add action=accept chain=input in-interface-list=LAN
TO
add action=accept chain=input in-interface-list=MANAGEMENT

tools/macserver/winmacserver entry would be MANAGEMENT
ip neighbours discovery entry would be MANAGEMENT
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

What I recommend is that you would assign ether4 on your router an access port for the trusted vlan, to allow access to the router FROM the BRIDGE
I recommend taking ether 5 off the bridge and creating access OFF the bridge to the router, in case the bridge config blows up on you.......may be easier just to config from here normallly.
viewtopic.php?t=181718 ( I see you already have an IP for this and everything so almost already there!!! )

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

THE DNS rules in the forward chain in green may not be required if PI is doing the DNS........

I didnt quite get the purpose of these rules so left them out for now........
add action=drop chain=forward connection-nat-state="" connection-state=new dst-address=192.168.10.0/24 src-address=192.168.20.0/24
add action=drop chain=forward connection-nat-state="" connection-state=new dst-address=192.168.10.0/24 src-address=192.168.30.0/24

Hello Anav and mkx,

Thank you both for your input. Lots to read and review in what you presented to me.

I'm right away struck by the seemingly different approaches. mkx writes "You only have to use bridge if you want to use RB750Gr3 in a switch-like fashion" whereas Anav seems to recommend creating a bridge.

I understand that there is likely more than one way to get to my end result, however you can imagine my hesitancy when I start out bewildered with what I should be doing, and then get presented with two options. I certainly do not want to pit two opposing views against one another when I ask if one solution is for all intents and purposes the better approach.

In the meantime, while you consider if you even want to respond, I'll go on reading more material - luckily most I've read before, but will try to re-read with an open and fresh mind.

Thank you.

@anav is known for his desire that everybody configure their gear as similar to his configs as possible so that he can then share his wisdom. Obviously he's got VLAN-filtering on bridges everywhere.

Again, your ethernet / VLAN / IP setup is fine, but your firewall needs a revamp. Advices on firewall by @anav apply regardless how you configure ethernet ports because those rules work on IP level and if you get IP addresses right it doesn't matter how packets arrive to firewall.

What I'd do regarding firewall is to have a good look at defaults, you can always get them by executing /system default-config print in a really wide terminal window (long lines get truncated). After you read through /ip firewall section and you understand it, go through it again. You'll notice that technically default firewall doesn't follow the "deny everything else" because the last rule has some conditions in it, but the way default setup is done, those conditions effectively work as "deny everything else" if there was another rule right before it. So if you rework default firewall (replace the last rule with two, more straight-forward ones) and add some rules specific to your use case with quite a few IP subnets, it should work fine. Just remember that firewall rules in each chain are checked top-to-bottom and first rule matching executes (skipping the rest) which means that more specific rules have to come higher on the list (if you use deny everything else concept, this means specific allow rules have to be higher than the ultimate deny rule).
When you get there, you can post then-actual config here for review.

Since you are using vlans, I opted to go for the method described by PCUNITE ( not by me - just in case MKX forgot ;-P )
Either way is fine and no offence taken if you opt for alternate methods.

@anav, you're forgetting what's guide by @pcunite about ... it's about configuring routerboard devices without switch chips to do VLAN-aware switching/bridging in the new/better way (as opposed to using bridge per VLAN and heaps of vlan interfaces). However, OP doesn't need switching/bridging, he is after router on a stick ... and for that bridge is out of picture (he's using single interface as VLAN trunk towards LAN).

Let me show the difference (will only show with two VLANs):

Without bridge:

/interface vlan
add name=vlan10 interface=ether2 vlan-id=10
add name=vlan20 interface=ether2 vlan-id=20
/ip address
add interface=vlan10 address=192.168.10.1/24
add interface=vlan20 address=192.168.20.1/24

With bridge (with differences highlited):

/interface bridge
add name=bridge1 vlan-filtering=yes
/interface bridge port
add bridge=bridge1 interface=ether2 frame-types=allow-only-tagged
/interface bridge vlan
add bridge=bridge1 tagged=bridge1,ether2 vlan-ids=10,20
/interface vlan
add name=vlan10 interface=bridge1 vlan-id=10
add name=vlan20 interface=bridge1 vlan-id=20
/ip address
add interface=vlan10 address=192.168.10.1/24
add interface=vlan20 address=192.168.20.1/24

The rest of config (IP addresses, routes, firewall filters, ...) is identical in both cases as long as vlan interface names (e.g. vlan10, vlan20) used are identical.

Now, I agree that the bridge way is future-proof ... it's extremely easy to add another port either as untagged access port to one of VLANs or a trunk port if bridge is used already initially (specially so if one sets bridge MAC manually) ... a few extra switch ports can come handy some times.

But if we stick to OP's requirements, use of bridge is unnecessary. So @anav, no need for you to sit behind the fence and pout ... come back and help @HandyDutchGuy fix his firewall rules (I bow to your ability to make things work for newbies).

No worries, LOL,
I have no idea what router on a stick means.
However I have a spare hex and I used duct tape to attach to a branch from a nearby tree, but it doesnt work, since its not plugged into any outlet.

If you mean simplest config, yes no bridge does make things a bit easier, and its important to stick (pun intended) with what the OP wants.

I have not idea what router on a stick means.
However I have a spare hex and I used duct tape to attach to a branch from a nearby tree, but it doesnt work, since its not plugged into any outlet.

As you guessed right, you did it wrong. Router on a stick means that you take your spare hex and stick a stick into one of ether ports (don't try to stick the stick through two or more ports, you need a bridge for that). If you do it properly, then router works ... as a scarecrow

OK, lets go back on topic and help OP to make his setup better.

Thank you both for your input, and sense of humour! I have less time than I would like to study everything as I should, but I'm plugging away at it when I have time. I also found this thread - viewtopic.php?t=153581 - where you both imparted additional wisdom.

Rest assured I'm doing my homework. Just wanted to let you know I'm not taking your (free) advice and support for granted.

@anav,
Router on a stick, is simply a Router that has only one physical ( or logical ) connection with a Switch ( Trunk Port ) and does the Routing between the VLANs, InterVLAN Routing...

^ This is correct. Now, what I would like to accomplish is to disable the inter VLAN routing... and while I'm working on the security aspect of the router, I will also need to figure out how to achieve the rest of my requirements. See first post. Fun and games...

@anav,
Router on a stick, is simply a Router that has only one physical ( or logical ) connection with a Switch ( Trunk Port ) and does the Routing between the VLANs, InterVLAN Routing...

So let me get this straight the topology is ISP modem --------> Router1 -------> Switch --------->MT DEVICE/Router

Where Router 1, only handles IP DHCP client aspect of routing then carries traffic to switch and then to MT Device on a private subnet IP.

Switch (lets say 24 port)
- Gets internet on ether1 (access port) (vlan10)
- Rest of ports are detailed in its vlan settings
- Passes internet all VLAN traffic (for L3/DHCP/internet) to MT device on stick on port 24

MT on a stick (acting as a router).
ether 1 is a Trunk Port connecting to port 24 on the switch.
IP DHCP Client is vlan10 interface is ether1 (static IP address private)
All other vlans are assigned, IP address with interface ether 1, IP pool, Dhcp-server, dhcp-server network
Determine necessary firewall rules.

interface list
LAN ----- all vlans save10
WAN ------vlan10
CLOSE?

Router lives to route, it will route anything it knows how. If you want to spoil its fun, firewall is your friend:

@sob, you prefer to reject than drop ?

Yes, it helps with debugging. If something doesn't work because I forgot to allow it through firewall, it's nice if router tells me about it. Better than scratching my head and wondering why packets mysteriously disappear.

It may not be ideal if there are some spoofed packets. But few small icmp responses are not good for any amplification attack, so it's one reason why it's not very likely to be abused. With typical client router, it's very unlikely that any spoofed packets from internet would reach it at all. It's forward chain, so the destination would have to be something else than router's public address, ISP won't normally send anything like that. And I mostly trust internal networks. I mean, it can be improved, do drops for traffic from internet, also for internal networks it can be checked is source is allowed local subnet and do reject only if it is. But even unconditional reject should be good enough for client router.

So recommending....... where LAN = all internal subnets.
FROM
add chain=input action=drop
TO
add chain=input action=reject interface-list=LAN reject-with=icmp-admin-prohibited
add chain=input action=drop

And
FROM
add chain=forward action=drop
TO
add chain=input action=reject interface-list=LAN reject-with=icmp-admin-prohibited
add chain=input action=drop

So let me get this straight the topology is ISP modem --------> Router1 -------> Switch --------->MT DEVICE/Router

Where Router 1, only handles IP DHCP client aspect of routing then carries traffic to switch and then to MT Device on a private subnet IP.

Switch (lets say 24 port)
- Gets internet on ether1 (access port) (vlan10)
- Rest of ports are detailed in its vlan settings
- Passes internet all VLAN traffic (for L3/DHCP/internet) to MT device on stick on port 24

MT on a stick (acting as a router).
ether 1 is a Trunk Port connecting to port 24 on the switch.
IP DHCP Client is vlan10 interface is ether1 (static IP address private)
All other vlans are assigned, IP address with interface ether 1, IP pool, Dhcp-server, dhcp-server network
Determine necessary firewall rules.

interface list
LAN ----- all vlans save10
WAN ------vlan10
CLOSE?

Close. I do not have a "router 1", so it's actually much simpler:

Internet -> Cable mode (in bridge mode) -> MT (WAN on eth1)
MT, eth2 (has all VLANs as per config: 10, 20, 30, 40, 50, all with their own DHCP server, all looking to 192.168.10.11 for DNS) -> switch trunk port

@sob, that's what i had in mind, drop the traffic coming from the Internet and reject the internal traffic...

Here is a waterproof VLAN tutorial:
https://administrator.de/contentid/367186

Really? I drowned trying to read it.

As MK stated, this is a clear case of Bridgephobia ;-PP

a. identify all vlans and give them a parent interface of ether2
b. all vlans get IP pool, IP address, dhcp-server, dhcp-server network
c. Apply firewall rules
d. done.

other dribs and drabs.
ensure each vlan is added to the LAN interface.
Not sure why you are complicating life by using vlan10 for ether1 (access to bridged modem/router).
Assuming you are getting a private IP??
....................
.................

if any communication is to be allowed between vlans, make the necessary rules.

For example if the admin on vlanXX needs access to all the vlans.
add chain=forward action=accept in-interface=vlanXX out-interface-list=LAN src-address=IPofAdminPC (or src-address-list if the admin has several devices)

For example if there is a shared device such as a printer on vlan YY
add chain=forward action=accept in-interface-list=LAN out-interface=VLANYY dst-address=IP of printer (protocol= if required).

Hi,
I would say, that's a lengthy tutorial, which is not bad for bridge VLAN filtering, but a device like the RB750GR3 does not have a switch chip with HW Offloading, so that would work, but all bridging is done using the CPU.
To use the built in switch chip for trunking, bridging on must not configure a bridge with vlan filtering enabled.
I have found the following videos very helpful on VLANs on MT:
Configure VLAN on built-in switch chip in MikroTik (this explains exactly, what you want to have):
https://www.youtube.com/watch?v=rvQ6o4R ... z&index=20
This guy compares all the possible VLAN config types in these videos:
https://www.youtube.com/watch?v=4BOYqtV ... Mj&index=1
https://www.youtube.com/watch?v=TAGW_XC ... Mj&index=2

I am not affiliated with any of the guys creating those videos, but I wish I had those available before I have set up my MTs.

Here is a waterproof VLAN tutorial:
https://administrator.de/contentid/367186

I would say, that's a lengthy tutorial, which is not bad for bridge VLAN filtering, but a device like the RB750GR3 does not have a switch chip with HW Offloading, so that would work, but all bridging is done using the CPU.
To use the built in switch chip for trunking, bridging on must not configure a bridge with vlan filtering enabled.

Switch chip used in RB750Gr3 can not be configured for VLAN stuff under ROS v6. Under ROS v7 it received the bridge hw offliading so again it has to be configured with bridge vlan-filtering.

Hi mkx,
thanks, I hate to write, but I think you are wrong.

-According to here: https://help.mikrotik.com/docs/display/ ... p+Features
HEX has MT7621 and has a VLAN table.
It also says:

Bridge HW vlan-filtering was added in the RouterOS 7.1rc1 (for RTL8367) and 7.1rc5 (for MT7621) versions. The switch does not support other ether-type 0x88a8 or 0x9100 (only 0x8100 is supported) and no tag-stacking. Using these features will disable HW offload.

-That means, Bridge HW vlan filtering was added from 7.1rc1. Of course you can still configure it's switch chip in any recent 6.xx. You can also use bridge vlan filtering in 6.xx, just without HW acceleration.

-I have no HEX, but a HEX S, which has the same switch chip. I have a vlan config on it based on switch chip (admittedly not very extensive as it's sole purpose is running Capsman). But this proves, that you can use the switch chip for tagging/trunks : BR
Woland

I would say, that's a lengthy tutorial, which is not bad for bridge VLAN filtering, but a device like the RB750GR3 does not have a switch chip with HW Offloading, so that would work, but all bridging is done using the CPU.
To use the built in switch chip for trunking, bridging on must not configure a bridge with vlan filtering enabled.

Switch chip used in RB750Gr3 can not be configured for VLAN stuff under ROS v6. Under ROS v7 it received the bridge hw offliading so again it has to be configured with bridge vlan-filtering.

Could be that switch chip setup indeed started to work in some late v6 release. The old documentation about switch chip features however states no VLAN support on MT7621. I'll have to trust you when saying that in 6.49.4 VLANs are properly dealt with by switch chip. Because the config snippet you're showing is far from complete for AR8327 or QCA8327 (i.e. you can write anything you want under /interface ethernet switch vlan but nothing is enforced without setting things under /interface ethernet switch port, property vlan-mode=secure).

Sadly documentation on MT site mostly lacks information about which ROS version changed some feature set.

Hi mkx,
yes I have a second setup with a HEX S , where some more sophisticated VLAN config is also functioning. Also some HEX PoEs of mine are working fine with some more complicated VLAN setups.
I can only speak about my experience in the time interval between last summer and today. I think I have set up my HEX S with 6.46.x first and it was working since. I also remember to have read something about Mediatek and VLAN support, but I can´t find that anymore.

I definitely agree with you about the confusing MT manuals. Also I am no beginner with VLANs, I have used many different solutions from many vendors, but no vendor I know of, has managed to make VLANs so confusing as MTs implementation.

I still do enjoy playing with MT.

W

Hello again.

Finally - had time again to revisit my firewall. This is what I have now. The good news - the major stuff is working. I haven't spent time yet on getting my Wireguard VPN working, but that's not a big issue at the moment. What I AM happy about is that I figured out how to implement firewall rules to separate the VLAN traffic where I need to.

Here is my config, exported with hide-sensitive and further cleaned up by using xx in IP addresses and names:

# mar/20/2022 13:56:55 by RouterOS 7.1
# software id = 72VR-1FM3
#
# model = RB750Gr3
# serial number = D5030E3E8970
/interface ethernet
set [ find default-name=ether1 ] name=ether1-WAN
set [ find default-name=ether5 ] comment="Management port" name=ether5-access

/interface wireguard
add listen-port=13231 mtu=1420 name=wireguard1

/interface vlan
add interface=ether2 name=GuestWifi vlan-id=30
add interface=ether2 name=LAN vlan-id=10
add interface=ether2 name=Phone vlan-id=40
add interface=ether2 name=Tina-TWORK vlan-id=50
add interface=ether2 name=Wifi vlan-id=20

/interface list
add comment="All VLANs list" name=VLANs
add comment=WAN name=WAN
add name=VLAN30
add name=VLAN10

/interface lte apn
set [ find default=yes ] ip-type=ipv4

/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik

/ip ipsec peer
add address=184.xx.xx.xx/32 local-address=184.xx.xx.xx name=WORK

/ip ipsec profile
set [ find default=yes ] dh-group=modp1024 dpd-interval=10s enc-algorithm=3des hash-algorithm=md5 lifetime=8h name=WORK nat-traversal=no

/ip ipsec proposal
set [ find default=yes ] disabled=yes
add enc-algorithms=3des lifetime=8h name=WORK

/ip pool
add comment=VLAN-10 name=LAN ranges=192.168.10.40-192.168.10.60
add comment=Management name=Ether5-access ranges=192.168.100.10-192.168.100.20
add comment=VLAN-20 name=Wifi ranges=192.168.20.2-192.168.20.254
add comment=VLAN-30 name=GuestWifi ranges=192.168.30.2-192.168.30.254
add comment=VLAN-40 name=Phone ranges=192.168.40.2-192.168.40.254
add comment=VLAN-50 name=Tina-TWORK ranges=192.168.50.2-192.168.50.254

/ip dhcp-server
add address-pool=LAN interface=LAN name=LAN
add address-pool=Ether5-access interface=ether5-access name=dhcp1
add address-pool=Wifi interface=Wifi name=Wifi
add address-pool=GuestWifi interface=GuestWifi name=GuestWifi
add address-pool=Phone interface=Phone name=Phone
add address-pool=Tina-TWORK interface=Tina-TWORK name=dhcp2

/port
set 0 name=serial0

/routing bgp template
set default as=65530 disabled=no name=default output.network=bgp-networks

/routing ospf instance
add name=default-v2

/routing ospf area
add disabled=yes instance=default-v2 name=backbone-v2

/ipv6 settings
set disable-ipv6=yes max-neighbor-entries=8192

/interface list member
add interface=LAN list=VLANs
add interface=Wifi list=VLANs
add interface=GuestWifi list=VLANs
add interface=Phone list=VLANs
add interface=Tina-TWORK list=VLANs
add interface=ether1-WAN list=WAN
add interface=GuestWifi list=VLAN30
add interface=LAN list=VLAN10

/interface wireguard peers
add allowed-address=192.168.60.2/24,192.168.60.3/24 interface=wireguard1 public-key="fvSavRzRKl7cZvMKwfkpI/GfAVG2FXsMarP+NCHKpgI="

/ip address
add address=172.16.16.1/24 disabled=yes interface=ether5-access network=172.16.16.0
add address=192.168.10.1/24 comment=VLAN10 interface=LAN network=192.168.10.0
add address=192.168.20.1/24 comment=VLAN20 interface=Wifi network=192.168.20.0
add address=192.168.30.1/24 comment=VLAN30 interface=GuestWifi network=192.168.30.0
add address=192.168.40.1/24 comment=VLAN40 interface=Phone network=192.168.40.0
add address=192.168.50.1/24 comment=VLAN50 interface=Tina-TWORK network=192.168.50.0
add address=192.168.60.1/24 interface=wireguard1 network=192.168.60.0
add address=184.68.82.26/29 interface=ether1-WAN network=184.xx.xx.xx
add address=192.168.100.1/24 interface=ether5-access network=192.168.100.0

/ip dhcp-server lease
add address=192.168.10.4 client-id=1:18:c0:4d:26:b8:1d comment="Marcel's PC" mac-address=18:C0:4D:26:B8:1D server=LAN
add address=192.168.10.2 client-id=ff:5e:4f:ac:2d:0:1:0:1:29:60:9d:fc:e0:d5:5e:4f:ac:2d comment="File server" mac-address=E0:D5:5E:4F:AC:2D server=LAN

/ip dhcp-server network
add address=192.168.10.0/24 dns-server=192.168.10.11 gateway=192.168.10.1
add address=192.168.20.0/24 dns-server=192.168.10.11 gateway=192.168.20.1
add address=192.168.30.0/24 dns-server=192.168.10.11 gateway=192.168.30.1
add address=192.168.40.0/24 dns-server=192.168.10.11 gateway=192.168.40.1
add address=192.168.50.0/24 dns-server=192.168.10.11 gateway=192.168.50.1
add address=192.168.100.0/24 dns-server=8.8.8.8 gateway=192.168.100.1

/ip dns
set servers=192.168.10.11

/ip firewall address-list
add address=0.0.0.0/8 comment="defconf: RFC6890" list=no_forward_ipv4
add address=169.254.0.0/16 comment="defconf: RFC6890" list=no_forward_ipv4
add address=224.0.0.0/4 comment="defconf: multicast" list=no_forward_ipv4
add address=255.255.255.255 comment="defconf: RFC6890" list=no_forward_ipv4
add address=127.0.0.0/8 comment="defconf: RFC6890" list=bad_ipv4
add address=192.0.0.0/24 comment="defconf: RFC6890" list=bad_ipv4
add address=192.0.2.0/24 comment="defconf: RFC6890 documentation" list=bad_ipv4
add address=198.51.100.0/24 comment="defconf: RFC6890 documentation" list=bad_ipv4
add address=203.0.113.0/24 comment="defconf: RFC6890 documentation" list=bad_ipv4
add address=240.0.0.0/4 comment="defconf: RFC6890 reserved" list=bad_ipv4
add address=0.0.0.0/8 comment="defconf: RFC6890" list=not_global_ipv4
add address=10.0.0.0/8 comment="defconf: RFC6890" list=not_global_ipv4
add address=100.64.0.0/10 comment="defconf: RFC6890" list=not_global_ipv4
add address=169.254.0.0/16 comment="defconf: RFC6890" list=not_global_ipv4
add address=172.16.0.0/12 comment="defconf: RFC6890" list=not_global_ipv4
add address=192.0.0.0/29 comment="defconf: RFC6890" list=not_global_ipv4
add address=192.168.0.0/16 comment="defconf: RFC6890" list=not_global_ipv4
add address=198.18.0.0/15 comment="defconf: RFC6890 benchmark" list=not_global_ipv4
add address=255.255.255.255 comment="defconf: RFC6890" list=not_global_ipv4
add address=224.0.0.0/4 comment="defconf: multicast" list=bad_src_ipv4
add address=255.255.255.255 comment="defconf: RFC6890" list=bad_src_ipv4
add address=0.0.0.0/8 comment="defconf: RFC6890" list=bad_dst_ipv4
add address=224.0.0.0/4 comment="defconf: RFC6890" list=bad_dst_ipv4
add address=192.168.10.1-192.198.10.254 comment="Inverse VLAN-30 group" list="Inverse VLAN-30"
add address=192.168.20.2-192.198.20.254 list="Inverse VLAN-30"
add address=192.168.40.2-192.198.40.254 list="Inverse VLAN-30"
add address=192.168.50.2-192.198.50.254 list="Inverse VLAN-30"
add address=192.168.10.2-192.198.10.254 comment="Inverse VLAN-40 group" list="Inverse VLAN-40"
add address=192.168.20.2-192.198.20.254 list="Inverse VLAN-40"
add address=192.168.30.2-192.198.30.254 list="Inverse VLAN-40"
add address=192.168.50.2-192.198.50.254 list="Inverse VLAN-40"
add address=192.168.10.2-192.198.10.254 comment="Inverse VLAN-20 group" list="Inverse VLAN-20"
add address=192.168.30.2-192.198.30.254 list="Inverse VLAN-20"
add address=192.168.40.2-192.198.40.254 list="Inverse VLAN-20"
add address=192.168.50.2-192.198.50.254 list="Inverse VLAN-20"
add address=192.168.10.2-192.198.10.254 comment="Inverse VLAN-50 group" list="Inverse VLAN-50"
add address=192.168.20.2-192.198.20.254 list="Inverse VLAN-50"
add address=192.168.30.2-192.198.30.254 list="Inverse VLAN-50"
add address=192.168.40.2-192.198.40.254 list="Inverse VLAN-50"
add address=192.168.10.0/24 list="All VLANs"
add address=192.168.20.0/24 list="All VLANs"
add address=192.168.30.0/24 list="All VLANs"
add address=192.168.40.0/24 list="All VLANs"
add address=192.168.50.0/24 list="All VLANs"

/ip firewall filter
add action=accept chain=input comment="Wireguard UDP" connection-state="" dst-port=13231 protocol=udp
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=drop chain=input comment="defconf: drop all not coming from VLANs" in-interface-list=!VLANs
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" psec-policy=out,ipsec
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=accept chain=forward comment="All VLANs to DNS" connection-nat-state="" connection-state="" dst-address=192.168.10.11 src-address-list="All VLANs"
add action=accept chain=forward comment="Allow VLAN-10 to other VLANs" connection-nat-state="" connection-state="" disabled=yes dst-address=192.168.30.0/24 log=yes src-address=192.168.10.0/24
add action=drop chain=forward comment="Block VLAN-20 to other VLANs" connection-nat-state="" connection-state="" dst-address-list="Inverse VLAN-20" src-address=192.168.20.0/24
add action=drop chain=forward comment="Block VLAN-30 to other VLANs" connection-nat-state="" connection-state="" dst-address-list="Inverse VLAN-30" src-address=192.168.30.0/24
add action=drop chain=forward comment="Block VLAN-40 to other VLANs" connection-nat-state="" connection-state="" dst-address-list="Inverse VLAN-40" src-address=192.168.40.0/24
add action=drop chain=forward comment="Block VLAN-50 to other VLANs" connection-nat-state="" connection-state="" dst-address-list="Inverse VLAN-50" src-address=192.168.50.0/24
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related hw-offload=yes
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN

/ip firewall nat
add action=accept chain=srcnat comment="IP phone NAT rule" dst-address=10.1.2.0/24 src-address=192.168.40.0/24
add action=masquerade chain=srcnat comment="LAN to Internet MASQuerading"
add action=dst-nat chain=dstnat comment=Pihole dst-address=!192.168.10.11 dst-port=53 in-interface=!ether1-WAN protocol=udp src-address=!192.168.10.11 to-addresses=192.168.10.11
add action=dst-nat chain=dstnat comment=Pihole dst-address=!192.168.10.11 dst-port=53 in-interface=!ether1-WAN protocol=tcp src-address=!192.168.10.11 to-addresses=192.168.10.11
add action=masquerade chain=srcnat comment=Pihole dst-address=192.168.10.11 dst-port=53 protocol=udp src-address=192.168.10.0/24
add action=masquerade chain=srcnat comment=Pihole dst-address=192.168.10.11 dst-port=53 protocol=tcp src-address=192.168.10.0/24

/ip firewall raw
add action=notrack chain=prerouting dst-address=10.1.2.0/24 src-address=192.168.40.0/24
add action=notrack chain=prerouting dst-address=192.168.40.0/24 src-address=10.1.2.0/24

/ip firewall service-port
set ftp disabled=yes
set tftp disabled=yes
set irc disabled=yes
set h323 disabled=yes
set sip disabled=yes
set pptp disabled=yes
set udplite disabled=yes
set dccp disabled=yes
set sctp disabled=yes

/ip ipsec identity
add peer=WORK

/ip ipsec policy
add dst-address=10.1.2.0/24 peer=WORK proposal=WORK src-address=192.168.40.0/24 tunnel=yes
set 1 disabled=yes

/ip route
add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=184.xx.xx.xx pref-src="" routing-table=main scope=30 suppress-hw-offload=no target-scope=10

/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set ssh disabled=yes
set api disabled=yes
set api-ssl disabled=yes

/system clock
set time-zone-name=America/Winnipeg

/tool sniffer
set file-name=Wireshark filter-interface=Tina-TWORK memory-limit=1000KiB


Hopefully this is much closer to a safer firewall than before. As always, suggestions are appreciated.

I am new owner of a hEX S, so I never saw this until this month.

Bridge Hardware Offloading has the following in footnote 3.
HW vlan-filtering was added in the RouterOS 7.1rc1 (for RTL8367) and 7.1rc5 (for MT7621) versions. The switch does not support other ether-type 0x88a8 or 0x9100 (only 0x8100 is supported) and no tag-stacking. Using these features will disable HW offload.

At this time, the MT7621 and RTL8367 can do some things the Atheros/Qualcomm chips can't (Bridge vlan offloading) but they can't do Bridge dhcp snooping. For me, the vlan offloading is a much more useful feature.

And the v7.2 testing versions have added more bug/feature fixes for bridge hardware offloading. I just updated to the bleeding edge v7.2rc5 about 4 hours ago on my hEX S. More info about v7.2 fixes here Testing release tree Some bridge highlights follow:

What's new in 7.2rc5 (2022-Mar-23 12:04):
*) bridge - fixed firewall "ingress-priority" matcher and "new-priority=from-ingress" action settings from VLAN tagged frames;
What's new in 7.2rc4 (2022-Feb-22 13:37):
*) bridge - fixed FastPath when using "frame-types=admit-only-untagged-and-priority-tagged" setting;
*) bridge - fixed IP address on untagged bridge interface when vlan-filtering is enabled (introduced in v7.2rc2);
*) bridge - fixed PPPoE packet forwarding when using "use-ip-firewall-for-pppoe" setting;
*) bridge - fixed destination NAT when using "use-ip-firewall" setting;
*) bridge - fixed filter and NAT "set-priority" on ARM64 devices;
*) bridge - fixed filter rules when using interface lists;
*) bridge - fixed priority tagged frame forwarding when using "frame-types=admit-only-untagged-and-priority-tagged" setting;
What's new in 7.2rc3 (2022-Jan-28 16:33):
) bridge - fixed filter and NAT "set-priority" action;
What's new in 7.2rc2 (2022-Jan-28 11:00):
*) bridge - added fast-path and inter-VLAN routing FastTrack support when vlan-filtering is enabled;

I am a big proponent of configuring the bridge if you are using vlans, and since v7.1rc5 the bridge on the MT7621A devices (RB750Gr3 and RB760iGS) will do this without a significant performance penalty.

Before hardware offloading for the bridge was available, trying to use the hEX as a replacement for the ER-X was a non-starter for me, because I use vlans heavily. Now the hEX has some switching features that ER-X doesn't, but I haven't tried them all yet (I haven't tried using the mirror feature or port isolation features on the hEX). The ER-X evidently allows setting up a mirror port using the undocumented /bin/switch utility, but there is no way to configure this in /config/config.boot, so the only way to get reboot persistence would be a script. And I am not aware of any way to do port isolation on the ER-X (at switch-port level). There are a lot more knobs to turn in RouterOS than on the ER-X, so for some things RouterOS is more flexible, but more complex than EdgeOS.

@HandyDutchGuy If you never plan to use ether3 or ether4, then it really makes no difference, but if the bridge is configured, it makes it very easy to "attach" an unused ethernet port to any vlan you want. It essentially turns the hEX bridge ports into a mini-vlan-aware switch.

So for example, if you wanted to test what the guest Wifi had access to, you could add ether3 as an access port for vlan 30, and if you plugged a Raspberry Pi into the port it would be on the guest network. It can also be a big advantage when something isn't working on the managed switch connected to ether2.

It probably isn't worth changing (unless it is currently in a lab situation), but using the bridge has few downsides once you get past the hurdle of wrapping your head around how the bridge works.

The links in this post were helpful to me, when I was trying to learn the new "language" of RouterOS bridges, coming from knowledge about how vlans work on EdgeOS and the vlan-aware switch0 on the ER-X.

The manual is clear that MT7621 has no VLAN Table support...https://wiki.mikrotik.com/wiki/Manual:S ... p_Features
Bridge HW offload on VLANs was added on ROS v7.1rc5 https://help.mikrotik.com/docs/display/ ... p+Features
Also the changelog https://mikrotik.com/download/changelogs has no reference at all on MT7621 adding support of Switch based VLANs on ROS v6.

The manual is clear that MT7621 has no VLAN Table support...https://wiki.mikrotik.com/wiki/Manual:S ... p_Features
Bridge HW offload on VLANs was added on ROS v7.1rc5 https://help.mikrotik.com/docs/display/ ... p+Features
Also the changelog https://mikrotik.com/download/changelogs has no reference at all on MT7621 adding support of Switch based VLANs on ROS v6.

Summary: If you want to use vlans on the RB750Gr3 or RB760iGS using the device independent "bridge with vlan-filtering" method, you will need to use something > v7.1rc5, but preferably v7.2rc5 or higher, as more and more features are being fixed in bridge support in v7.

It is also clear that the wiki.mikrotik.com version is obsolete.
The new help page which was in the second link, does have the MT7621 with vlan table. so I am surprised you posted that link if you think the MT7621 doesn't work with vlans in hardware. It just requires at least v7.1rc5 to program the features on the switch chip.
The MT7621A chip has always supported vlan tables, but RouterOS didn't use them until v7.1rc5 The Ubiquiti ER-X uses the same chip, and it has had a hardware assisted vlan-aware switch0 device at least since 2016 in EdgeOS v1.8.5. The point is, it is not a limitation of the MT7621A SOC, it is a limitation of the software not using the SOC's integrated MT7530 compatible switch ASIC features.

Here's a 2016 Ben Pin youtube video where he demostrates how the vlan-aware switch can be used on the ER-X.

@Buckeye i am surprised too since i clearly mention that support on Bridge VLAN filtering in hardware is added on Ros v7... So i totally do not understand your point...
Also, if the switch chip itself has a VLAN table, but ROS does not use it ( on V6 for example ), this does not change the fact, that it still has no VLAN table...

Besides the fact of referencing old documentation.
This is the current documentation to reference.
https://help.mikrotik.com/docs/display/ ... p+Features

https://help.mikrotik.com/docs/display/ ... +Switching

We've been sidetracked by @woland who claimed his hEX S can be configured for VLANs on switch chip in ROS v6. I'm still not convinced that his setup actually works correctly - or rather that it works any better than a dumb switch..

But anyway, we all agree that OP, using v7, is correct to use bridge vlan filtering, which should be offloaded to hardware on hEX. So we can stop with this discussion and let's see if OP has solved his issues or not.

Hi all, "OP" here again...

I posted my current config a few posts above this one, and tbh, when I read ^:

"... OP, using v7, is correct to use bridge vlan filtering,.."

I must admit that I am not aware if I am indeed using bridge vlan filtering, or not. I 'think' not, since I have not configured a bridge.

The whole reason for my using only one ethernet port, is that with the setup I have, I only need ONE network cable to go to just ONE managed switch.
All the VLANs travel across that wire and have access to a DNS server on VLAN10 and I have figured out how to block traffic between VLANs where I need to do so.

In a large environment it is probably not very efficient for various reasons, but for a fairly low demand network design, it seems to work.

Remember, I opted for my model MT for a reason. If I would implement a MT in a higher demand type of network, I would likely (have to) select a more powerul router also.

I am far for being an expert in MT and will still gladly accept tips on improving my config. I will read up again on vlan bridge filtering to see if I would be better of using it; at this point, I'm clueless.

As a side note - I am very appreciative of the community and individual efforts to help out and assist with questions such as mine.

"... OP, using v7, is correct to use bridge vlan filtering,.."

I must admit that I am not aware if I am indeed using bridge vlan filtering, or not. I 'think' not, since I have not configured a bridge.

My bad, indeed you're using single interface. So neither switch chip nor bridge matter in this case. Things would change if you would start using hEX in role of switch.

Just a note (not that your current setup is inadequate or wrong): instead of using IP subnet addresses in firewall rules you could use (vlan) interfaces. I don't think it would make any observable difference though.

@Buckeye i am surprised too since i clearly mention that support on Bridge VLAN filtering in hardware is added on Ros v7... So i totally do not understand your point...
Also, if the switch chip itself has a VLAN table, but ROS does not use it ( on V6 for example ), this does not change the fact, that it still has no VLAN table...

@Zacharias I misunderstood your first comment as a statement that the old wiki documentation was correct. Please accept my apology for the inappropriate response.

I must admit that I am not aware if I am indeed using bridge vlan filtering, or not. I 'think' not, since I have not configured a bridge.

The whole reason for my using only one ethernet port, is that with the setup I have, I only need ONE network cable to go to just ONE managed switch.
All the VLANs travel across that wire and have access to a DNS server on VLAN10 and I have figured out how to block traffic between VLANs where I need to do so.

If you never plan to use your other ports on the RB750Gr3 to "be" on one of the vlans, then what you have is fine, and probably easier to understand. But what if you need to connect one more thing to your D-Link 10 port switch? If you used the bridge on the RB750Gr3, you could move your Raspberry Pi running Pi-Hole to an available port on the RB750Gr3 since the RPi is probably running "headless", so where it is physically probably doesn't matter. As long as the RB750Gr3 port the RPi is connected to has access to the same vlan(s) as it did when connected to the D-Link switch, everything would work identically. In other words, you can use the unused ports on the RB750Gr3 as a logical "extension" to the vlan-aware switch.

Using the bridge is another layer of abstraction between the ports and the CPU. The bridge allows having access to the vlan-aware switch built into the hEX, and then you configure the set of vlans using the "virtual" bridge interface as the base. That builds the "trunk" to the switch ASIC. With ROS you also need to "configure" the internal connections between the CPU and the switch in addition to the bridge port settings.

I am still not sure exactly how the connection from the CPU to a specific port like ether2 works internally. Especially when tagged vlans are being sent.

E.g.
/interface vlan
add interface=ether2 name=GuestWifi vlan-id=30
add interface=ether2 name=LAN vlan-id=10
add interface=ether2 name=Phone vlan-id=40
add interface=ether2 name=Tina-TWORK vlan-id=50
add interface=ether2 name=Wifi vlan-id=20

In other words, I expect that you could do the following, but it won't behave the way many people would expect it to.

/interface vlan add interface=ether3 name=eth3_tagged_10 vlan-id=10

It would create a new interface eth3_tagged_10 that you could add an ip address to, but it would not be connected in any way to your other tagged vlan 10 on ether2 at layer 2. i.e. it would be on an isolated broadcast domain separate from the vlan 10 on ether2.

The alternative method using the bridge interface, you can have multiple ports on the RB750Gr3 that are members of the same vlan, and you can even have some ports tagged for that vlan and some untagged (access ports).

Then if you wanted to add a second managed switch going in another direction from where the RB750Gr3 is, you could use another port on the RB750Gr3 for a second trunk link going to the new switch, using the same vlans as the other trunk port is using, and have the vlans be the same broadcast domain.

But if you have it working, there isn't a big need to change it now, it can be done later. But it would probably be easier to do it now if you think you would ever want to, because it is now "fresh" in your mind, and you won't have to reacquire the context a year from now when you find a need for using another port on the RB750Gr3 to access the existing vlans.

I always configure my ER-Xs using vlans instead of "individual ports removed from switch0" or in MikroTik lingo "ports off the bridge". It just makes future changes much easier and much more flexible.

It is similar to using a hypervisor between the server hardware and the OS; it allow more flexibility, but has the price of more complexity.

Thank you, Buckeye, you make some valid points. I especially like the idea of being able to free up a port on the switch and move the Pi to port on the MT.

I'll look into it.

Thank you, Buckeye, you make some valid points. I especially like the idea of being able to free up a port on the switch and move the Pi to port on the MT.

I'll look into it.

If you want to do this

• under files Backup your config and copy to something off the router

• export file=<somename> show-sensitive and copy to something secure off the router (this is not for sharing)

• upgrade to latest stable channel release (as of 2022-03-26 that is v7.1.5), or if you want the bleeding edge testing channel release v7.2rc5

after reboot, test to make sure everything still works as before. VPN, etc.
Then repeat backup/export with new file names
Then login from your off-bridge access port on ether5 to make changes to the bridge (so you don't saw off the branch you are sitting on)

The intent is to chage as little as possible, but since I am new to RouterOS there may be mistakes here, so make sure you have good backup! And hopefully someone else can point out any mistakes before you try. Most of the ideas for this taken from router.rsc from this Switch with a separate router (RoaS) Also from this post in this thread How to create most basic VLAN

#since we are working off bridge, enabling vlan-filtering up front.
/interface bridge add name=BR1 vlan-filtering=yes
# ingress behavior
/interface bridge port

# Only adding unused ports to bridge at this time. Leave pvid set to default of 1 for ether4 (new trunk to switch). Ether3 will be vlan 10 access port so pvid set to 10
add bridge=BR1 ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether3 pvid=10
add bridge=BR1 ingress-filtering=yes frame-types=admit-only-vlan-tagged interface=ether4

# egress behavior
/interface bridge vlan

# configure ether4 just like ether 2 was, ether 3 will be an access port for LAN (vlan 10) for RPi to be connected to
add bridge=BR1 tagged=BR1,ether4 untagged=ether3 vlan-ids=10
add bridge=BR1 tagged=BR1,ether4 vlan-ids=20
add bridge=BR1 tagged=BR1,ether4 vlan-ids=30
add bridge=BR1 tagged=BR1,ether4 vlan-ids=40
add bridge=BR1 tagged=BR1,ether4 vlan-ids=50

#Now the part I am least confident about, switching the vlan interfaces from ether5 to BR1 (you may want to make another backup before proceeding)
I am sure this can be done with the CLI, but I don't know the syntax (probably with [ find ...] but I will leave those instructions to someone that knows more about RouterOS scripting than I do.

I did it on my lab router by creating a vlan under my off bridge interface, then using winbox to change the interface


Hopefully by doing this, all the reset of the config will continue to work like it did before. You will have to move the trunk link from ether2 to ether4, then see if things are still working from connections on the D-Link switch. Also you should be able to plug a laptop into ether3 and it should behave like it did when connected to a LAN access port on the D-Link switch.

Anyone have any comments or warnings?

If this works then we can reconfigure ether2 as a trunk port, so you can move the cable from the D-Link switch back to ether2, and you can then reconfigure ether4 to be a spare access port for a wired connection to a vlan of your choice.