MerVLAN v0.52.91 Simple and Powerful VLAN Management **BETA**

[r80xcore]

@r80xcore I am trying to configure Mervlan, but need some extra help. You mentioned before that you use Opnsense also, so that's why I am asking you.

My setup:
ONT --> Opnsense --> Asus RT-AC5300

Opnsense has two VLAN's at the WAN side, vlan 4 needed for multicast IPTV and vlan 6 needed for internet access. ( this is required from ISP)
At the LAN side I have setup 4 vlan's; main, IoT, guest and IPTV
I am using Kea DHCP and added all interfaces, subnets and ip pools for each internal vlan.

Asus RT-AC5300 is my old/spare router I am using to test mervlan and Opnsense setup. When I get everything working I am replacing with two RT-AX88U Pro routers.
To test, I unplug my main AX88U pro router from ONT and connect my Opnsense router to it.

My question is, how do I setup mervlan in combination with vlans of Opnsense?
My main network uses vlan 10 on Opnsense. When I add vlan 10 to my main ssid using mervlan, I am no longer able to connect to my main wifi network, as if my laptop does not recieve an ip. ( I think).

What am I missing?

Thanks in advance,
RaccoonNL

Hi!
First you should do is to make sure that MerVLAN is mapping correctly. I don't currently have a profile for your model yet. But that is easy to do by using the script I've made to map the unit and also send the map to github for proper support. Click here for that thread.

Secondly, when adding a VLAN it's important that the managed switch is properly trunking the traffic. This means that the port connected to your AP should be set to T(ID) and also U(ID) if you want to pass the remaining traffic. The port towards the OPNsense firewall also needs to be set up properly.

In MerVLAN it's often best to use a Guest SSID when adding a VLAN ID. That is thoroughly tested.

Whai I myself do is that my AP is set to
Main SSID1
Main SSID2
Main SSID3
GUEST SSID1 VLAN 187
GUEST SSID2 VLAN 188
GUEST SSID3 VLAN 189

I then set the port for the AP to T187 T188 T188 U186.
This makes the port pass the VLANs and then tag the remaining traffic with 186. Leaving all traffic properly tagged when entering opnsense from the switch that is tagged with T186 T187 T188 T189.

Important note.
For MerVLAN to function properly right now, you need to trunk via the WAN port. This will be modular is a future release but right now, WAN is used to forward to the next unit.

 

[heysoundude]

@r80xcore - I’ve been following along for a little while, and I’m going to ask if you’ve had a chance to look at the scripts here, with particular attention paid to the Tunnel Director section, where I suspect certain synergies may be found?

 

[ColinTaylor]

with particular attention paid to the Tunnel Director section, where I suspect certain synergies may be found?

I don't see the "synergies". What am I missing?

 

[r80xcore]

@r80xcore - I’ve been following along for a little while, and I’m going to ask if you’ve had a chance to look at the scripts here, with particular attention paid to the Tunnel Director section, where I suspect certain synergies may be found?

I suspect you are referring to VLAN over WiFi backhaul? If so, yes I have and it is something that I will look into in the future but as of now, stability and device compatibility over Eth is my main goal. After that I will continue on my WiFi backhaul tunnel script.

 

[heysoundude]

The two terms share Virtual and Network and are methods of segmenting traffic; would making a Private Local Area the default be more efficient and/or elegant within SDN definitions? I realize this question likely upsets Colin as my musings usually do, but I’m suggesting perspective change might lead to enlightenment- change can be good.

 

[r80xcore]

The two terms share Virtual and Network and are methods of segmenting traffic; would making a Private Local Area the default be more efficient and/or elegant within SDN definitions? I realize this question likely upsets Colin as my musings usually do, but I’m suggesting perspective change might lead to enlightenment- change can be good.

Those tunnelling scripts are really interesting and would be a great complement to MerVLAN. Especially in passing VLANs over WiFi.

The tunnelling will probably affect speeds over 1gbps, but would still enable broader use.

Other than that it would be interesting to look for more uses and gradually expand MerVLAN.

But first I need to work on stability and device integration. I need to get more maps and get a better view on which units will be limited in LAN VLANs and not.

 

[Stpa67]

I tried MerVLAN today with ssid's mapped to vlans and it works very well on my RT-AX58U v1 in AP mode. This addon is very useful - thanks

 

[r80xcore]

I tried MerVLAN today with ssid's mapped to vlans and it works very well on my RT-AX58U v1 in AP mode. This addon is very useful - thanks

It's great to hear that it works for you. Thank you for the profile contribution too! If you happen to stumble onto any bugs or issues, please open a issue ticket on the github page.

 

[wild_tree]

@r80xcore I am testing v0.52.91 on a ZenWiFi XT8 AiMesh setup (1 Main AP, 1 Node, Ethernet backhaul) running Gnuton firmware 3004.388.10_2-gnuton1 in AP Mode.

I have run into two bugs regarding SSID resolution and node trunking that I wanted to report.

Bug 1: SSID Resolution Fails for Dual-Band Identical SSIDs: When a 2.4GHz Guest Network and a 5GHz Guest Network share the exact same SSID name, mervlan_manager.sh only maps the 2.4GHz interface to the VLAN bridge and skips the 5GHz interface.

The NVRAM strings are identical, but the script matches wl0.1 and exits before evaluating wl1.1. The 5GHz clients end up leaking onto the default br0 bridge.

From the Main AP's NVRAM:

# nvram show 2>/dev/null | grep -E "^wl[0-9]+(\.[0-9]+)?_ssid=" | grep blueberry
wl0.1_ssid=blueberry
wl1.1_ssid=blueberry

From the Main AP's Execution Log:

[INFO] Resolved SSID 'blueberry' -> wl0.1
[INFO] Created bridge br20
[INFO] SSID_01 -> br20 (VLAN 20)
...
[INFO] Unconfigured IF wl1.1 -> br0 (untagged)

Bug 2: Node Trunk Identification Fails on Empty wan_ifnames: The script successfully syncs files to the AiMesh node but completely aborts building the br20 bridge and the eth0.20 trunk on the node itself.

I believe the script relies on the wan_ifnames variable to determine the physical backhaul port for trunking. However, on XT8 AiMesh nodes connected via Ethernet backhaul, Asus leaves wan_ifnames empty and lists the physical backhaul port (eth0) under lan_ifnames instead. Because the variable is empty, the node fails to identify the uplink.

From the AiMesh Node:

# nvram show 2>/dev/null | grep -E '^(wan|lan)_ifnames='
lan_ifnames=eth0 eth1 eth2 eth3 eth4 eth5 eth6 wl0.1 wl0.2 wl1.1 wl1.2 wl2.1 wl2.6
wan_ifnames=

From the AiMesh Node's Execution Log:

[INFO] No trunk configuration enabled. Skipping.

Let me know if you need any additional logs, hardware mapping tests, or testing from the XT8!