SOLVED: Feature request: Selective Layer-2 forwarding of tagged VLANs from a non-bridge WAN interface

[Stahab]

Hello Mikrotik team,

I would like to request a feature that would simplify a common ISP deployment scenario and address a current limitation in RouterOS. I believe that I am presenting a common use case that will resonate with many Mikrotik users.
Forgive me for using some AI help to construct a cleaner post than what I would have done myself, since english is not my native language and my network knowledge is limited.

Use case

My ISP's locked 5G CPE has only one ethernet port that delivers the following services to my Mikrotik's WAN port (ether1):

• Untagged Ethernet: Internet access (DHCP for IPv4, SLAAC for IPv6)
• VLAN 100 (802.1Q tagged): VoIP service

I would like to:

• Keep ether1 as a standalone WAN interface.
• Run the IPv4 DHCP client and IPv6 SLAAC only on ether1.
• Transparently forward VLAN 100 (still tagged) from ether1 to one or more LAN ports for a VoIP gateway.
• Avoid adding ether1 to the bridge.

Why this is important for me

My ISP provides only a single IPv6 /64 via SLAAC and does not provide DHCPv6 Prefix Delegation.

If ether1 is added to a bridge, the bridge becomes the Layer 2 endpoint, and IPv6 Router Advertisements are received on the bridge instead of the physical WAN interface. This changes the WAN interface model and makes it impossible to keep native IPv6 SLAAC bound exclusively to ether1 not expose the bridge MAC in the WAN IPv6 SLAAC (using EUI-64).

Current limitation

As far as I understand, RouterOS currently offers two possibilities:

1. Add ether1 to a VLAN-aware bridge and use bridge VLAN filtering.
2. Create VLAN interfaces on ether1, which terminates the VLAN and does not provide transparent tagged forwarding.

There appears to be no mechanism to transparently forward selected tagged Ethernet frames from a standalone physical interface into a bridge while leaving the untagged traffic attached to the physical interface.

Requested functionality

It would be very useful if RouterOS supported selective Layer 2 forwarding of specific VLANs from a standalone interface into a bridge, for example:

• Forward VLAN 100 frames arriving on ether1 to bridge1 (or directly to selected bridge ports), preserving the VLAN tag.
• Continue delivering untagged traffic on ether1 to the router's networking stack.
• Allow IPv4 DHCP and especially IPv6 SLAAC to remain bound to the physical WAN interface.

The exact implementation is not important. It could be implemented as a bridge feature, a switch feature, or another mechanism, as long as it allows transparent forwarding of selected VLANs without requiring the physical WAN interface to become a bridge port.

Typical deployment

This would be particularly useful for ISPs that provide:

• Untagged Internet
• Tagged VoIP
• Tagged IPTV

on the same physical access port of their CPE.

Currently, the only practical workaround is to use an external managed switch to split the services before they reach the MikroTik router.

I believe this capability would make RouterOS much more flexible for several service-provider deployments while preserving the ability to keep the WAN interface independent for protocols such as IPv6 SLAAC.

Thank you for seriously considering this feature request.

EDIT:

SOLVED — Two ways to handle untagged WAN + tagged VoIP on the same port

Thanks to the valuable guidance from the forum members, I eventually realized that no new RouterOS feature is required for this setup.

There are two valid approaches. Solution A is useful when the physical WAN interface must remain outside the bridge. Solution B is the preferred approach for my RB760iGS/hEX S because the MT7621 switch chip can hardware-offload the VLAN-aware bridge.

I ultimately used Solution B.

For background on the RouterOS bridge/VLAN model:

RouterOS bridge mysteries explained

This topic is a reaction to the countless cases of confusion regarding why the bridge “itself” must be listed among tagged or untagged ports of a VLAN in some cases, why the VLAN interfaces must be attached to the “bridge” rather than to its member ports etc. The fact that both “interface” and “port” have multiple meanings in the networking vernacular contributes to that confusion. This topic does not deal with the details of the “new” way of handling multiple VLANs on a single bridge; for that…

Vlan-aware bridge mysteries

Setting up an RB5009 to upgrade a home office was pretty straight forward until I moved on to use vlans to separate guests IOT devices, personal PCs, and business PCs. Wrapping my head around the Mikrotik way of setting up the vlans has been interesting. I have found three great posts on this forum: @pcunite's using-routeros-to-vlan-your-network @sindy's routeros-bridge-mysteries-explained Question related to “RouterOS bridge mysteries explained” - @sindy's response I think best visually so I…

Solution A — WAN port outside the bridge

This is a valid solution when ether1 must remain a standalone L3 WAN interface.

Create a VLAN interface on ether1 for the ISP's tagged VoIP VLAN, and add that VLAN interface to the VLAN-filtered bridge:

/interface vlan
add comment="VoIP WAN" interface=ether1 name=VoIP-WAN vlan-id=100

/interface bridge port
add bridge=bridge1 edge=yes frame-types=admit-only-untagged-and-priority-tagged interface=VoIP-WAN pvid=100

/interface bridge vlan
add bridge=bridge1 comment="VoIP VLAN" tagged=bridge1,ether2 untagged=VoIP-WAN vlan-ids=100

The VLAN interface terminates VLAN 100 on ether1 and presents it to the bridge as untagged traffic. The bridge then classifies it into VLAN 100 and forwards it tagged to ether2.

Untagged Internet traffic remains directly on ether1, so the IPv4 DHCP client and IPv6 SLAAC can remain attached to the physical WAN interface.

edge=yes is used because the ISP-facing port is not intended to participate in the local STP topology.

This was originally pointed out by lurker888 and later explicitly confirmed by MikroTik Support:

SOLVED: Feature request: Selective Layer-2 forwarding of tagged VLANs from a non-bridge WAN interface

This is fully possible, so no new feature is needed to implement this. As you say, you may attach your dhcp client, receive slaac, do routing to/from ether1. At the same time you may also attach a vlan interface to the same ether1 with vlan id 100. There are a couple of possibilities from here, one of them is to enroll this vlan interface into a vlan filtered bridge as an untagged port with pvid 100. If you want to output the frames to say ether2 still tagged, you also enroll ether2 into the s…

SOLVED: Feature request: Selective Layer-2 forwarding of tagged VLANs from a non-bridge WAN interface

(Reposted because I accidentally deleted original post) Yesterday a new day dawned, much nicer than the previous 5-day torture for my ADHD brain (reason: preparing my annual tax statement). While recovering, I received an important email from the support, which stated the following solution: “Keep ether1 out of the bridge, create a VLAN interface on it (ether1.100), and add that VLAN interface as a bridge port. Untagged traffic stays on ether1 for DHCP and SLAAC, while VLAN 100 frames enter t…

The trade-off is that the tagged service uses the VLAN-interface/CPU path rather than direct hardware switching between physical bridge ports.

Solution B — VLAN-aware bridge with the WAN port included

This is the preferred solution for the RB760iGS/MT7621.

Add the physical WAN port to the same VLAN-filtered bridge as the LAN ports. The WAN port becomes a hybrid port:

• untagged ISP Internet → internal VLAN 1000

• tagged ISP VoIP → VLAN 100

/interface bridge port
add bridge=bridge1 comment="WAN" edge=yes interface=ether1 pvid=1000

/interface bridge vlan
add bridge=bridge1 comment="WAN VLAN" tagged=bridge1 untagged=ether1 vlan-ids=1000
add bridge=bridge1 comment="VoIP VLAN" tagged=ether1,ether2 vlan-ids=100

edge=yes is used because ether1 is the ISP-facing port and is not intended to form an STP path to another bridge.

The WAN VLAN entry is essential: ether1 is the untagged/access member of VLAN 1000, while bridge1 is the tagged router-facing member.

The untagged Internet service is therefore represented internally as VLAN 1000. The L3 WAN endpoint is a VLAN interface on the bridge:

/interface vlan
add comment="WAN VLAN" interface=bridge1 name=WAN-VLAN vlan-id=1000

The critical RouterOS concept is that the physical WAN port and the L3 WAN interface do not have to be the same interface. The bridge performs the Layer-2 switching, while WAN-VLAN is the Layer-3 endpoint for DHCP, IPv6 SLAAC/Router Advertisements, routing, firewalling, etc.

This was the key point explained by lurker888 and CGGXANNX:

SOLVED: Feature request: Selective Layer-2 forwarding of tagged VLANs from a non-bridge WAN interface

No problem. I'll write out my response and you can read it tomorrow. First of all, l2 hw offloading has very minimal impact with offloading only voip/iptv bridging. You might have misunderstood the ether1-fully-in-bridge setup. In this case you use only the vlan200 interface as your wan port. You do everything you would normally do on ether1, including slaac on it. It will work exactly the same as it did when you used ether1. You have to conceptualize it something like this: the untagged pack…

SOLVED: Feature request: Selective Layer-2 forwarding of tagged VLANs from a non-bridge WAN interface

Putting all ports, including the WAN port in a single VLAN-filtered bridge as @lurker888 said, is the easy and working way to achieve your configuration. You make that port a hybrid port, the untagged VLAN interface associated with that port will take the role of your current WAN interface (where DHCP, SLAAC, etc... are attached to). The other tagged VLANs on that port (can be multiple, not only for VoIP but IPTV too, for example) can be shared with other ports normally because you have a full V…

VLAN 100 does not require a VLAN interface because it is not routed by the MikroTik. It remains tagged and is transparently switched between ether1 and ether2.

MACVLAN and the WAN MAC address

The remaining issue in my particular setup was the WAN MAC identity.

My original concern with putting ether1 into the bridge was that IPv6 SLAAC using EUI-64 could expose the bridge MAC in the WAN IPv6 address. This was the main reason I initially considered it necessary to keep the physical WAN interface outside the bridge.

The solution was to create a MACVLAN on top of WAN-VLAN and use it as the L3 WAN interface:

/interface macvlan
add interface=WAN-VLAN name=WAN-MACVLAN mac-address=XX:XX:XX:XX:XX:XX

The explicit MAC address can also be omitted:

/interface macvlan
add interface=WAN-VLAN name=WAN-MACVLAN

The DHCP client, IPv6 SLAAC/Router Advertisements, WAN interface-list membership, etc. are then applied to WAN-MACVLAN instead of WAN-VLAN.

If WAN-VLAN or WAN-MACVLAN is used as the WAN interface, it should also replace ether1 in the RouterOS WAN interface list. This is important because firewall rules, NAT rules, and other configuration that reference the WAN interface list will then apply to the new L3 WAN endpoint rather than to the physical ether1 port.

For example, when using WAN-MACVLAN:

/interface list member
add interface=WAN-MACVLAN list=WAN

Existing firewall/NAT rules that use in-interface-list=WAN or out-interface-list=WAN will then continue to follow the actual L3 WAN interface without requiring every rule to be rewritten.

This provides a separate MAC identity for the L3 WAN endpoint while keeping the physical WAN port inside the VLAN-aware bridge.

CGGXANNX specifically described this approach when a separate WAN MAC is required:

SOLVED: Feature request: Selective Layer-2 forwarding of tagged VLANs from a non-bridge WAN interface

Putting all ports, including the WAN port in a single VLAN-filtered bridge as @lurker888 said, is the easy and working way to achieve your configuration. You make that port a hybrid port, the untagged VLAN interface associated with that port will take the role of your current WAN interface (where DHCP, SLAAC, etc... are attached to). The other tagged VLANs on that port (can be multiple, not only for VoIP but IPTV too, for example) can be shared with other ports normally because you have a full V…

A related example of the same single-bridge WAN/VLAN architecture is:

https://forum.mikrotik.com/t/raw-vlan-forwarding-between-wan-and-lan

That discussion also explains why a second bridge loses L2 hardware offloading, whereas keeping the relevant physical ports in one VLAN-filtered bridge allows the switch chip to perform the VLAN tagging/untagging and intra-VLAN forwarding.

Result

For this RB760iGS/MT7621 setup:

Solution A remains a valid option when the physical WAN interface must stay outside the bridge. It keeps ether1 as the L3 WAN interface, while a VLAN interface on ether1 provides the bridge path for the tagged VoIP VLAN.

Solution B is the preferred architecture when there is no such requirement. It allows the WAN port to participate in the VLAN-aware bridge and keeps the tagged VoIP traffic in the hardware-switched L2 path.

I ultimately used Solution B. The original assumption that the physical WAN interface also had to remain the L3 WAN endpoint was the key misunderstanding. Once the L3 endpoint was moved to WAN-VLAN, and a WAN-MACVLAN was used to provide a separate MAC identity, there was no longer a reason to keep the physical WAN port outside the bridge.

No new RouterOS feature is required for this particular deployment.

[m4rk3J]

It should be possible to add a VLAN 100 interface on ether1, add a second VLAN 100 interface on bridge1, and connect these VLAN interfaces via a software bridge. That should work.

However, I don't think that's standard practice among ISPs. So far, I've always seen that VoIP, Internet, and IPTV were carried on specific VLANs, and nothing untagged ran there.

[jaclaz]

JFYI, this Is a user forum, a feature request should be addressed at support@mikrotik.com
Though sometimes the forum Is read by Mikrotik personnel, there Is no guarantee that your feature request will be noticed.

[lurker888]

This is fully possible, so no new feature is needed to implement this.

As you say, you may attach your dhcp client, receive slaac, do routing to/from ether1.

At the same time you may also attach a vlan interface to the same ether1 with vlan id 100. There are a couple of possibilities from here, one of them is to enroll this vlan interface into a vlan filtered bridge as an untagged port with pvid 100. If you want to output the frames to say ether2 still tagged, you also enroll ether2 into the same bridge as a tagged member of 100.

Another usual way of doing the same is to also attach a vlan interface to ether2, again with id 100, and then bridge the two vlan interfaces with a non-vlan-filtered bridge.

BTW, this is not a unique or unusual request, nor is the setup to achieve this novel.

[Stahab]

I've tried that but It doesn't work because the untagged traffic from CPE gets tagged. Or I miss something?

Here in Greece it's a standard practice for the main ISPs to do what I have described. Unfortunately I have to work with what I get. Also I've seen other cheap routers like TP-link having this feature since many years. They NAT and route only untagged frames, while at he same time they bridge the tagged frames directly from WAN to LAN, keeping them tagged.

[lurker888]

Another way, which allows for hardware L2 offliading (which for voip or iptv is not usually necessary) is the following:

You create a single vlan filtered bridge, and enroll ether1 in it as a hybrid port, being a tagged member of vlan 100 and pvid, let's say, 200.

Then you enroll ether2 in the same bridge as tagged 100, thus realizing the passthrough.

You also attach a vlan interface, id 200, to the bridge. This vlan interface will be your WAN port, and you attach the dhcp client, etc. to this.

Perhaps this is the most proper way.

One thing to pay attention to, in all three variations, is to set the stp protocol mode of the bridges involved to none. We don't generally speak stp with the ISP.

[Stahab]

I didn't know that, I've seen similar feature requests posted on the forum in the past, looking for more users that needed the same feature or comments with suggestions from other users.

In my case, I thought I might have missed something and another user could suggest an alternative solution that I haven't thought of.
I have already posted this request to the support. If you think I should delete this post, I can do it, no problem.

[Stahab]

The point is that if I would like to keep hardware offloading, I need to avoid creating a second bridge.

The second solution you provide, enrolling ether1 into the bridge, defeats my main goal:

@Stahab

• IPv6 SLAAC to remain bound to the physical WAN interface.

I need to keep ipv6 bound to WAN port. My isp provides CGNAT ipv4 and the only public ip I can use to be seen from the internet is the SLAAC ipv6 my isp provides. The prefix is /64 and DHCP is not supported. So I can't forward ipv6, ony bind it to my WAN port and work from there.

It's 2am here in Greece and my mind is tired, so I may have misunderstood what you have proposed, but maybe not. What do you think? Can I bind my ipv6 ONLY to WAN (ether1) port while it's enrolled as a bridge port? I have tried but it doesn't work. In my initial post I describe better why it doesn't work.

[lurker888]

No problem. I'll write out my response and you can read it tomorrow.

First of all, l2 hw offloading has very minimal impact with offloading only voip/iptv bridging.

You might have misunderstood the ether1-fully-in-bridge setup. In this case you use only the vlan200 interface as your wan port. You do everything you would normally do on ether1, including slaac on it. It will work exactly the same as it did when you used ether1.

You have to conceptualize it something like this: the untagged packets were simply temporarily tagged 200 while transiting the switch chip, and reappear again, untagged, but now they're named differently, as the vlan200 interface. This is exactly what the Cisco "native vlan" concept describes. (And anyway, even when this traffic is received as ether1, it still transits the switch, and something very similar is done in the background, it's just hidden from you for simplicity.)

[Stahab]

I have slightly edited my previous responses to corect / clear some points. I will carefully reexamine your suggestions tomorrow, having a working mind. I tried to do it now, but my mind refuses to obey my commands and can't create the logic diagram of the concept you are describing... it throws an error message somewhere in the middle

Thank you very much for your time! I will take a carefull look again in the morning while drinking my coffee!
Have a nice day / night (depends on where you are)!

[CGGXANNX]

Putting all ports, including the WAN port in a single VLAN-filtered bridge as @lurker888 said, is the easy and working way to achieve your configuration. You make that port a hybrid port, the untagged VLAN interface associated with that port will take the role of your current WAN interface (where DHCP, SLAAC, etc... are attached to). The other tagged VLANs on that port (can be multiple, not only for VoIP but IPTV too, for example) can be shared with other ports normally because you have a full VLAN filtered bridge.

This configuration has been done many time. In fact my main home router is doing this. And here is a recent thread with the same idea implemented: Raw VLAN forwarding between WAN and LAN - RouterOS - MikroTik community forum.

In case your ISP needs a specific MAC address and you don't want to put that MAC address on the bridge (or you have multiple WANs, each requiring a different MAC address) then you can workaround the limitation of "all VLAN interfaces sharing the same MAC address" by simply adding MACVLAN interfaces on top of the VLAN interfaces and use the MACVLAN interface as WAN interface. But normally if you only use one WAN then it's not needed, just set the bridge to the required MAC address. As for keeping STP, in RouterOS if you set edge=yes on the port, it will no longer send BPDU and will also ignore any received BPDU, so there should be no problem with the ISP device.

There is no need to implement the feature you proposed, because it's already solvable, while retaining all the benefits of L2 hardware offload.

[jaclaz]

Of course not, the post here is fine, and it is a good thing to discuss possible alternatives, I was only telling you how a "feature request" on the forum not necessarily is read/taken into account by the good Mikrotik guys.

[Stahab]

Don't worry, forgive me if I sounded like I was offended, I was not. English is just not my native laguage...

[Stahab]

@lurker888 @CGGXANNX
Guys, thank you so much for the suggestions but I have already red these posts. I have been searching this forum for this specific matter more than a couple of months before posting.

I now realise that I may have started backwards:
My actual setup is much more complicated. I have oversimplified and lost context. Enrolling all ports in the bridge and using a separate hybrid WAN-vlan carrying both tagged and untagged traffic (I had already done that) solves the problem in the surface but creates other implications further in my more complicated setup, mainly with VPN (wireguard and/or L2TP) through my dynamic SLAAC ipv6 and other details having to do with my locked CPE which I should have mentioned.
Also, I am trying to setup two devices to connect two different locations over VPN, a hEX-S and a hAP-AX2, which behave very differently in bridging (the later has no hardware offload).
I falsely thought I should have started from my main problem, but as I have it posted seems easily solvable because I have omitted many details.

Another mistake I may have done is that I picked the wrong timing to post, because this week has been crazy for me and so will be the beginning of next week. My head is hurting and I'm slower than usual.
The main device is actually routing my current internet connection so It's not easy to experiment with it while posting here.

I think I'd better try to regroup everything this weekend.
Maybe try to put everything in a new post, with my full topology, requirements, devices with current configs and detailed problem description, presented cleanly.

It's a lot of things to do at once for a 55 y.o. non native english speaker hobbyist, that was never a network engeener, that tries to put his thoughs on a specialized forum using the right words.
Unfortunately, I like to suffer with hardware experimenting!
That of course doesn't mean you have to suffer as well. I just hope you can bear with me while I try to do this and learn from you. I won't judje if you can't

I am open for suggestions on how to proceed for this post and how to place my next post when I get things ready.
Again, thank you for your patience!

P.S. Thank you again! Caught a greatly important tip that I didn't know: edge=yes

[lurker888]

The rest of the difficulties you write about have no relation to the bridge/non-bridge setup. Maybe you are just not familiar with this method of configuration, i.e. viewing the device as a switch+router arrangement? You are probably falling into some pitfalls, but the actual issues are unrelated.

On the ax2 not having proper offload: this is the nice thing about the kernel features used by Mikrotik's implementation - there's always a full software implementation to fall back on, so even if there is no hw offload, the configuration is the same. (It's usually referred to as the offloading being opportunistic.)

Anyway, wish you well for what you are busy with in real life, and return to this when you're ready.

[Stahab]

You are probably right. ipv4 works normaly as is (unfortunately it's CGNATed), I only get problems with ipv6. when trying not only to be remotely accessible from the (only) public dynamic ipv6 i get, but also to have remote access to my only ipv4 LAN devices. Theoreticaly it can be done, but I may be unaware of existing ROS ipv6 limitations.
We'll see...

[jaclaz]

No prob , very few people on the board are native English speakers, and you are not the first Greek with some difficulties with English, JFYI:
https://www.texasbar.com/AM/Template.cfm?Section=Say_What_&Template=/CM/ContentDisplay.cfm&ContentID=35605

From John Phillip Mustachio of Houston, this excerpt from the trial testimony of the plaintiff, whose first language is Greek.

Q. What I'm trying to do, Mr. Emmanonil, is to show that you have quite a bit of experience in owning and operating real estate, do you not?

A. No. The only one experience I have is just to - to know how is the valuable of the land is going to go up or down. That's I'm good only. But legal phrase like this one, I'm zero. Like I say earlier, I have gift know when is good piece of land or not. The rest of this stuff it's English to me.

[Buckeye]

@Stahab

Currently, the only practical workaround is to use an external managed switch to split the services before they reach the MikroTik router.

That's essentially what configuring all ports of the router in the same bridge and then using the vlan-aware mode (vlan-filtering=yes) does. What's different is that instead of being external, it is a virtual vlan-aware switch, and with some devices (like the RB750Gr3 or RB5009) there is hw switching built in, either within the Soc (as with the RB750Gr3's MT7621A) or in a deditcated switch chip (like the RB5009's Marvell 88E6393).

Here's a relevant thread to read (first post has most of the meat) RouterOS bridge mysteries explained and this that goes into a bit more concerning the vlan-aware bridge Vlan-aware bridge mysteries

Here's a thread that discusses something similar to what you want to do:
VLAN Passthrough from WAN port to LAN bridge (specific port)

[CGGXANNX]

Yeah, but you are losing L2 hardware offload in that configuration, and you've implemented one of the Layer 2 misconfiguration cases, this one:

Layer2 misconfiguration | RouterOS Manual

Again, the correct solution (also stated by the article above) is to use bridge VLAN filtering with all the WAN port also in the bridge. I don't know why you keep mentioning issue with SLAAC and IPv6 where there should be none of that issue at all if you configure everything correctly.

EDIT: This is a response to a post from OP but it has been deleted in the meantime.

[Stahab]

(Reposted because I accidentally deleted original post)

Yesterday a new day dawned, much nicer than the previous 5-day torture for my ADHD brain (reason: preparing my annual tax statement).
While recovering, I received an important email from the support, which stated the following solution:

“Keep ether1 out of the bridge, create a VLAN interface on it (ether1.100), and add that VLAN interface as a bridge port. Untagged traffic stays on ether1 for DHCP and SLAAC, while VLAN 100 frames enter the bridge through the VLAN interface. Configure bridge VLAN filtering to carry VLAN 100 tagged to the VoIP gateway port.”

I had not realized until that moment that I could enroll a vlan interface as a port on the bridge!
The simple wording of that email came at the right time to unlock my mind.
Upon re-reading the previous answers here, I also realized that @lurker888 was first to mention this, but I just missed it at that time. Better late than never, so thank you @lurker888 for providing the solution!

I immediately modified my configuration by applying this technique and finally everything worked as intended. By removing WAN port (ether1) from the bridge and keeping it isolated, it seems that it solved some weird problems I had with my ISP’s SLAAC IPv6, probably because now ether1 MAC address is different from the bridge’s MAC address. My VoIP gateway works normally when connected to any trunk port of my downstream managed switch, connected to Mikrotik’s ether5 trunk port. I also noticed that now websites open slightly faster than before. Placebo effect maybe?

In a nutshell, I started by removing ether1 from the bridge (and relative bridge vlans to it). Then:

Step 1 - created a vlan interface on ether1 named VoIP-WAN configured with vlanID=100
/interface vlan
add comment="VoIP WAN" interface=ether1 name=VoIP-WAN vlan-id=100

Step 2 – enrolled above vlan interface as bridge port with same vlanID=100 and configured it to accept only untagged and priority tagged frames.
/interface bridge port
add bridge=bridge1 edge=yes frame-types=admit-only-untagged-and-priority-tagged interface=VoIP-WAN pvid=100

Step 3 - created a bridge VLAN named VoIP-VLAN (vlanID=100), tagged to the bridge and my trunk port ether5 (this port connects to my managed switch) and untagged to the enrolled bridge port of step 2.
/interface bridge vlan
add bridge=bridge1 comment=”VoIP VLAN” tagged=bridge1,ether5 untagged=VoIP-WAN vlan-ids=100

Please note that I had already bridge vlan filtering enabled, because I have already been using vlans in my network.

Again, thank you all for your support and advice!
I'll see you again in the next one. Take care!

Stavros