VLAN configuration doesn't work after 6.49 -> 7.2 update

Hello,
I’ve tried to migrate from 6 stable to latest 7.x firmware several times, but always rolled back as I can’t solve the issue with my VLANs.

Immediately after update, everything stops to work except management VLAN

  • no DHCP from Mikrotik
  • allowed inter-vlan traffic ceases to flow.
  • gateway not available.

I’ve reviewed my setup several times, compared it to Mikrotik VLAN Wiki, but failed to see any flaws.
Physically, router has 2 trunk ports on eth1 and eth2, uplinks are eth4 and eth5 (disabled).

eth1 trunk receives bunch of VLANs from CRS switch, eth2 goes to server (VLAN4 and VLAN5).

/interface bridge
add fast-forward=no frame-types=admit-only-vlan-tagged ingress-filtering=yes name=bridge vlan-filtering=yes
/interface ethernet
set [ find default-name=ether2 ] comment=Server
set [ find default-name=ether5 ] disabled=yes
set [ find default-name=sfp1 ] disabled=yes
/interface vlan
add interface=ether2 name=vlan-4 vlan-id=4
add interface=ether2 name=vlan-5 vlan-id=5
add interface=ether1 name=vlan-14 vlan-id=14
add interface=ether1 name=vlan-15 vlan-id=15
add interface=ether1 name=vlan-16 vlan-id=16
add interface=ether1 name=vlan-17 vlan-id=17
add interface=ether1 name=vlan-20 vlan-id=20
add interface=bridge name=vlan-80 vlan-id=80
/interface list
add name=CONTROL
add name=INSIDE
add name=WAN_BACKUP
add include=WAN_BACKUP name=WAN
/ip pool
add comment=Management name=vlan-80-pool ranges=10.0.80.100-10.0.80.200
add comment=Camera name=vlan-20-pool ranges=10.0.20.100-10.0.20.200
add comment=WiFi name=vlan-15-pool ranges=10.0.15.100-10.0.15.200
add comment="Guest WiFi" name=vlan-16-pool ranges=10.0.16.100-10.0.16.200
add comment=IOT name=vlan-14-pool ranges=10.0.14.100-10.0.14.200
add comment="Servers pool" name=vlan-4-pool ranges=10.0.4.100-10.0.4.200
add comment="Isolated Servers Pool" name=vlan-5-pool ranges=10.0.5.100-10.0.5.200
add comment="IOT VPN" name=vlan-17-pool ranges=10.0.17.100-10.0.17.200
/ip dhcp-server
add address-pool=vlan-80-pool disabled=no interface=vlan-80 lease-time=1h name=vlan-80-dhcp
add address-pool=vlan-20-pool disabled=no interface=vlan-20 lease-time=1h name=vlan-20-dhcp
add address-pool=vlan-15-pool disabled=no interface=vlan-15 lease-time=1h name=vlan-15-dhcp
add address-pool=vlan-16-pool disabled=no interface=vlan-16 lease-time=1h name=vlan-16-dhcp
add address-pool=vlan-14-pool disabled=no interface=vlan-14 lease-time=1h name=vlan-14-dhcp
add address-pool=vlan-4-pool disabled=no interface=vlan-4 lease-time=1h name=vlan-4-dhcp
add address-pool=vlan-5-pool disabled=no interface=vlan-5 lease-time=1h name=vlan-5-dhcp
add address-pool=vlan-17-pool disabled=no interface=vlan-17 lease-time=1h name=vlan-17-dhcp
/interface bridge port
add bridge=bridge frame-types=admit-only-vlan-tagged ingress-filtering=yes interface=ether1
add bridge=bridge frame-types=admit-only-vlan-tagged ingress-filtering=yes interface=ether2
add bridge=bridge interface=ether3 pvid=80
/ip settings
set allow-fast-path=no
/interface bridge vlan
add bridge=bridge tagged=bridge,ether1 untagged=ether3,ether4 vlan-ids=80
add bridge=bridge comment=camera tagged=ether1 vlan-ids=20
add bridge=bridge tagged=ether1 untagged=ether4 vlan-ids=15
add bridge=bridge tagged=ether1 vlan-ids=16
add bridge=bridge tagged=ether1 vlan-ids=14
add bridge=bridge tagged=ether2 vlan-ids=4
add bridge=bridge tagged=ether2 vlan-ids=5
add bridge=bridge comment="IOT VPN" tagged=ether1 vlan-ids=17
/interface list member
add interface=ether4 list=WAN
add interface=ether1 list=INSIDE
add interface=bridge list=CONTROL
add interface=ether5 list=WAN_BACKUP
/ip address
add address=10.0.80.222/24 comment="Management network" interface=vlan-80 network=10.0.80.0
add address=10.0.20.222/24 comment="Camera network" interface=vlan-20 network=10.0.20.0
add address=10.0.15.222/24 comment="WiFi network" interface=vlan-15 network=10.0.15.0
add address=10.0.16.222/24 comment="Guest WiFi network" interface=vlan-16 network=10.0.16.0
add address=10.0.4.222/24 comment="Servers network" interface=vlan-4 network=10.0.4.0
add address=10.0.14.222/24 comment="TV WiFi" interface=vlan-14 network=10.0.14.0
add address=10.0.5.222/24 comment="Isolated Servers" interface=vlan-5 network=10.0.5.0
add address=10.0.17.222/24 comment="IOT VPN" interface=vlan-17 network=10.0.17.0
/ip dhcp-client
add default-route-distance=10 disabled=no interface=ether5 use-peer-dns=no use-peer-ntp=no
add default-route-distance=20 disabled=no interface=ether4
/ip dhcp-server network
add address=10.0.4.0/24 comment="Servers DHCP" dns-server=10.10.1.1 domain=-snip- gateway=10.0.4.222 ntp-server=10.0.4.222
add address=10.0.5.0/24 comment="Isolated Servers DHCP" dns-server=208.67.222.222,208.67.220.220 domain=-snip- gateway=10.0.5.222
add address=10.0.14.0/24 comment="TV WiFi" dns-server=10.0.14.222 domain=-snip- gateway=10.0.14.222 ntp-server=10.0.14.222
add address=10.0.15.0/24 comment=WiFi dns-server=10.10.1.1 domain=-snip- gateway=10.0.15.222 ntp-server=10.0.15.222
add address=10.0.16.0/24 comment="Guest WiFi" dns-server=10.0.16.222 domain=-snip- gateway=10.0.16.222 ntp-server=10.0.16.222
add address=10.0.17.0/24 comment="IOT VPN" dns-server=208.67.222.222,208.67.220.220 gateway=10.0.17.222
add address=10.0.20.0/24 comment=Camera dns-server=10.0.20.222 domain=-snip- gateway=10.0.20.222 ntp-server=10.0.20.222
add address=10.0.80.0/24 caps-manager=10.0.80.222 comment=Management dns-server=10.10.1.1 domain=-snip- gateway=10.0.80.222 ntp-server=10.0.80.222
/ip dns
set allow-remote-requests=yes servers=208.67.222.222,208.67.220.220
/ip firewall filter
add action=accept chain=input connection-state=established,related
add action=drop chain=input connection-state=invalid
add action=accept chain=input icmp-options=8:0-255 protocol=icmp src-address-list=local
add action=accept chain=input dst-port=53,123 protocol=udp src-address-list=local
add action=accept chain=input dst-address=10.0.80.222 dst-port=80,22 protocol=tcp src-address-list=management
add action=accept chain=input dst-address=10.0.80.222 dst-port=5246,5247 protocol=udp src-address-list=management
add action=accept chain=input dst-port=22 in-interface-list=WAN protocol=tcp src-address-list=admin
add action=drop chain=input
add action=accept chain=forward connection-state=established,related
add action=drop chain=forward connection-state=invalid
add action=accept chain=forward comment=Ipsec ipsec-policy=in,ipsec
add action=accept chain=forward ipsec-policy=out,ipsec
add action=accept chain=forward in-interface=vlan-5 out-interface-list=WAN
add action=accept chain=forward in-interface=vlan-14 out-interface-list=WAN
add action=accept chain=forward in-interface=vlan-15 out-interface-list=WAN
add action=accept chain=forward in-interface=vlan-16 out-interface-list=WAN
add action=accept chain=forward in-interface=vlan-17 out-interface-list=WAN
add action=accept chain=forward in-interface=vlan-15 out-interface=vlan-20
add action=accept chain=forward in-interface=vlan-15 out-interface=vlan-5
add action=drop chain=forward comment="Default drop" in-interface=vlan-20 out-interface-list=WAN
add action=drop chain=forward in-interface=vlan-80 out-interface-list=WAN
add action=drop chain=forward
/ip firewall nat
add action=masquerade chain=srcnat ipsec-policy=out,none out-interface-list=WAN
/ip service
set telnet disabled=yes
set ftp disabled=yes
set api disabled=yes
set api-ssl disabled=yes
/ip ssh
set forwarding-enabled=both

The reason why management VLAN is operational is CPU (bridge) as tagged interface in bridge vlan settings. If I add bridge to any VLAN as tagged port, it immediately starts to work - DHCP, traffic - everything. The problem is that it should work without this, and as I said, everything works on 6.49. Maybe I’m using some outdated features?

I’ve tried 7.1 on my previous attempt to migrate to 7.x - it was the same issue.

When ether1 and ether2 are bridge ports, all VLAN interfaces should be on bridge, not on ether1 and ether2.

Couple of things to try…

(1) Remove this from the actual bridge definition
frame-types=admit-only-vlan-tagged ingress-filtering=yes
so it looks like
/interface bridge
add fast-forward=no name=bridge vlan-filtering=yes

(2) CHANGE ALL VLANS to be members of the INTERFACE bridge (not the ports)

(3) Bridge ports are fine slight modification to ether3 and added ether4
/interface bridge port
add bridge=bridge frame-types=admit-only-vlan-tagged ingress-filtering=yes interface=ether1
add bridge=bridge frame-types=admit-only-vlan-tagged ingress-filtering=yes interface=ether2
add bridge=bridge interface=ether3 pvid=80 frame-types=admit-only-priority-and-untagged ingress-filtering=yes
add bridge=bridge interface=ether4 pvid=15 frame-types=admit-only-priority-and-untagged ingress-filtering=yes

OKAY you are confused. Ether4 is a problem.
It cannot be an access port for vlan15 if its already an access port for vlan80!!!
So will assume ether3 is in error and that ether 4 is strictly for vlan15
Also if ether1 and ether2 are carrying multiple vlans, aka trunk ports they should not have any untagged ports…

(4) Bridge vlans will take a while working on it.
/interface bridge vlan
add bridge=bridge tagged=bridge,ether1 untagged=ether3 vlan-ids=80
add bridge=bridge tagged=bridge,ether1 untagged=ether4 vlan-ids=15
add bridge=bridge tagged=bridge,ether1 vlan-ids=14,16,17,20
add bridge=bridge tagged=bridge,ether2 vlan-ids=4,5

(5) Not quite understanding your list members???
Firstly ether4 is associated with vlan 15 which is also coming through your trunk port ether1, not sure why its associated with WAN ???
also Use the vlans not ports to create your interface lists…

/interface list member
add interface=ether4 list=WAN
add interface=ether1 list=INSIDE
add interface=bridge list=CONTROL
add interface=ether5 list=WAN_BACKUP

add interface=vlans 14,15,16,17,20,80 list=INSIDE
add interface=vlan80 list=CONTROL

or something like that.

(6) OKAY after seeing this, its clear that ether4 is a WANPORT and thus remove from everything above bridge ports and vlans…
add default-route-distance=20 disabled=no interface=ether4

Thus remove the line from bridge ports that contains ether4
Thus remove from bridge vlans and modify this line accordingly!
add bridge=bridge tagged=bridge,ether1 vlan-ids=14,15,16,17,20

(7) To ensure I understand , 10.0.80.222 is your WAN IP? because the input chain is not the place for destination nat type rules ???
add action=accept chain=input dst-address=10.0.80.222 dst-port=80,22 protocol=tcp src-address-list=management
add action=accept chain=input dst-address=10.0.80.222 dst-port=5246,5247 protocol=udp src-address-list=management

(8) Assuming you are SSH into the router due to this rule…can you find a safer method?? Like wireguard!!
add action=accept chain=input dst-port=22 in-interface-list=WAN protocol=tcp src-address-list=admin

(9) Also convinced there may be a better way to approach the firewall forward chain rules… including the redundant one in orange since you already have a drop all rule at the end.
add action=accept chain=forward in-interface=vlan-5 out-interface-list=WAN
add action=accept chain=forward in-interface=vlan-14 out-interface-list=WAN
add action=accept chain=forward in-interface=vlan-15 out-interface-list=WAN
add action=accept chain=forward in-interface=vlan-16 out-interface-list=WAN
add action=accept chain=forward in-interface=vlan-17 out-interface-list=WAN
add action=accept chain=forward in-interface=vlan-15 out-interface=vlan-20
add action=accept chain=forward in-interface=vlan-15 out-interface=vlan-5
add action=drop chain=forward comment=“Default drop” in-interface=vlan-20 out-interface-list=WAN
add action=drop chain=forward in-interface=vlan-80 out-interface-list=WAN
add action=drop chain=forward

Why do you think these settings should be removed?

Having fun Picking cherries and worried about the wrong syllable…again! , I look at the whole config, and its non standard and no one has explained to me the effects or benefits of using those settings…
Feel free to but I am eliminating potential causes or complexity added that is NOT necessary and may contribute to problems.

eth4 is a mistake. Probably, not an issue in this particular setup, as it’s not a member of the bridge. eth4 is uplink port actually. The reason I missed it - it doesn’t show in bridge vlan settings in web interface. Can be the root of the problem in 7.x, but I’m not sure. I’ll definitely remove eth4 from there.

This will open CPU to all VLANS, not only management one.

I’ve stripped config here and there before posting it. I have issues with the basic connectivity, so I removed unnecessary parts. 80 is management VLAN.

It’s been explained (perhaps not to you personally) multiple times. Those settings, when set on bridge, apply to bridge interface. They don’t affect the packets bridged between bridge ports at all, those settings only affect the way device interacts with bridged traffic.

And no, I’m not cherry picking. You explicitly advised to remove them and I just asked as to why.

@abi If you are using the device as only a switch I would agree with you however you are using the device as a ROUTER wan input.
You are using it to provide DHCP services.

So there is no way around it that I can see…

@mkx or sob lol – well too bad, obviously the explanation sucked because it didnt stick, and I am the perfect beginner, or your reality check :wink:

This looks like perspective advice. I rechecked WIKI and they do the same here https://wiki.mikrotik.com/wiki/Manual:Interface/Bridge#VLAN_Example_.233_.28InterVLAN_Routing_by_Bridge.29

/interface vlan
add interface=bridge1 name=VLAN200 vlan-id=200
add interface=bridge1 name=VLAN300 vlan-id=300
add interface=bridge1 name=VLAN400 vlan-id=400

You’re not beginner, you’re selfproclaimedfsckingllama, so you really should start paying some attention to what’s written … and the records show that sometimes you don’t register things even if thrown right between the eyes. So I’m passing this sour cherry back to you :wink:.

@abi: And @anav’s tagged=bridge,etherX is needed too, I missed that.

@mkx: Devil’s advocate, what is frame-types=admit-only-vlan-tagged ingress-filtering=yes on bridge interface good for? It shouldn’t hurt, but probably not very useful either. On bridge ports it’s useful, to control what comes from there. But there’s no outside connection to bridge interface.

How can it be ? This will definitely opens CPU to all VLANs, isn’t it ?

To put what @sob wrote so condensed into some more words: physical interfaces (and others, but let’s keep using ether ports as example to make things more clear) can be either used as logical interfaces for IP layer[*] or as bridge ports[**], but not both at the same time.
The same principle applies to all interfaces that can be made bridge ports (e.g. wireless interfaces or EoIP interfaces, etc.).

[*] this means adding IP address directly to physical interface (e.g. ether1) or use it as anchoring interface for vlan (pseudo)interface (as in /interface vlan add name=<vlan_interface_name> interface=<physical_interface_name> vlan-id=). As they say: one can only have one master (to accept orders from).

[**] bridge, in turn, has two personalities: 1) switch-like presonality which shifts packets between member ports according to L2 (ethernet) rules … and 2) interface which allows higher layers to interact with traffic otherwise present on bridge (the switch-like personality)

I’m not sure what exactly you mean by “opens CPU to all VLANs”, but if router has interfaces for those VLANs and should be able to communicate with connected devices, then it is (and must be) processed by CPU. When you’d use it only as switch like in this example:

https://wiki.mikrotik.com/wiki/Manual:Interface/Bridge#VLAN_Example_.231_.28Trunk_and_Access_Ports.29

then those VLANs don’t need to be tagged on bridge (and you wouldn’t have VLAN interfaces for them either).

So, theoretically, every VLAN can access management console if I expose services like DCHP ? I thought I can have both DHCP and designated VLAN for management.

You already have that, if it’s possible from those VLANs to access router’s DHCP, DNS or NTP servers, it’s possible to also access any other service on router from there. That’s unavoidable. Unless it’s blocked by firewall. You already have src-address-list=management, but if only management interface is used to access it, rather use in-interface=vlan-80 and it won’t be possible to connect from any other interface.

Wow, I’ve totally missed that. Looks like my setup shouldn’t work at all and that it’s actually work somehow gave me wrong understanding of things around. Thanks!

Yes an added points 8 and 9 to start addressing some of those items.
Your neighbours discovery interface-list entry should be CONTROL
Your tools mac server WINMAC SERVER interface-list entry should be CONTROL

Teehee, touched a nerve did I…(cooped up with Covid too long, eating poorly, not getting enough exercise)??. perhaps its time you take that vacation to the sunny beaches of Albania LOL.

(1) In terms of access to the router from within the router.

add chain=input action=accept in-interface-list=CONTROL src-address-list=authorized dst-port=actual-winboxport
Firewall address list typically could consist of all the admins device, desktop, laptop, ipad, smartphone OR even wireguard IP coming through a wireguard connection (if wireguard interface is added to the CONTROL list…
Many ways to skin the cat as rextended says!!!

(2) Can be synthesized to three rules!!!
add action=block chain=forward in-interface-list=NO-WWW out-interface-list=WAN
add action=accept chain=forward in-interface-list=INSIDE out-interface-list=WAN
add action=accept chain=forward in-interface=vlan15 out-interface-list=FROMV15
add action=drop chain=forward

where NO-WWW is AN INTERFACE LIST list comprised of vlans 4,20
Where FROMV15 is AN INTERFACE LIST comprised of vlans 5,20