Looking for testers for MerVLAN

[r80xcore]

I am looking for more testers for the MerVLAN addon beta.

What is MerVLAN?
The addon aims for easy
VLAN tagging on both single and multi AP setups. Configure up to 5 nodes and apply VLAN tags via SSIDs or on LAN ports. The VLANs will survive reboots, power failures and event resets.
MerVLAN is easily accessible from within the Asuswrt-Merlin GUI under the Tools section.

Click on the link to the tread, to visit it and read more.

 

[penguin22]

Read through this and, as someone with VLANs assigned to each separate SSID for IoT and Guest networks, what does this do differently than assigning the VLAN at the time of Network creation?

Further, is there intention for having this manage IPTables for access from VLAN(s) to individual clients in another VLAN either fully or per designated ports? E.g., my printer is in my IoT VLAN (52 - br54), I have IPTables in firewall-start to allow clients from my main network and two guest networks to access the printer. Would be great to wrap this capability within MerVLAN.

 

[r80xcore]

Read through this and, as someone with VLANs assigned to each separate SSID for IoT and Guest networks, what does this do differently than assigning the VLAN at the time of Network creation?

Further, is there intention for having this manage IPTables for access from VLAN(s) to individual clients in another VLAN either fully or per designated ports? E.g., my printer is in my IoT VLAN (52 - br54), I have IPTables in firewall-start to allow clients from my main network and two guest networks to access the printer. Would be great to wrap this capability within MerVLAN.

Do you mean with a Pro model or through scripting? MerVLAN lets you assign or change VLANs anytime for both Wi-Fi and Ethernet using a single config file and through the GUI.
It also gives you control over AP isolation on all SSIDs (even the main ones), not just guest slots.
You can tag regular SSIDs with VLANs, so you're not forced to use only guest networks for segmentation.
I'm focusing on solid Layer 2 features — tagging, bridging, AP isolation — and intentionally leaving routing/firewalling to your main router or firewall. But who knows, I just began this project and it already expanded from script --> external UI --> addon, so if I find features that are solid and makes sense they might be implemented.

 

[Seth Harman]

Is this intended to run concurrently with Guest Network Pro/Smart Home Master? If so, the ability to tag Ethernet traffic is going to make some people happy as that's missing from non-Pro hardware and has forced people (myself included) to use cheap managed switches to accomplish this at the AiMesh nodes when using Guest Network Pro to create VLANs.

 

[r80xcore]

Is this intended to run concurrently with Guest Network Pro/Smart Home Master? If so, the ability to tag Ethernet traffic is going to make some people happy as that's missing from non-Pro hardware and has forced people (myself included) to use cheap managed switches to accomplish this at the AiMesh nodes when using Guest Network Pro to create VLANs.

As this is working now all SSIDs and Ports can be tagged and then handled by another box (VLAN capable router, OPNsense, Pfsense etc).

All work is being made on a XT8 with node so no work on Pro models are planned as I simply don't have access to one. If specific features are wanted for the Pro models these will have to be made from a user with a Pro model and with the knowledge to provide specifics and and collaborate in bug'n'log-hunting or help with the actual implementation. I have no problem with doing the work, i just need to know what to do.

 

[penguin22]

Do you mean with a Pro model or through scripting? MerVLAN lets you assign or change VLANs anytime for both Wi-Fi and Ethernet using a single config file and through the GUI.
It also gives you control over AP isolation on all SSIDs (even the main ones), not just guest slots.
You can tag regular SSIDs with VLANs, so you're not forced to use only guest networks for segmentation.
I'm focusing on solid Layer 2 features — tagging, bridging, AP isolation — and intentionally leaving routing/firewalling to your main router or firewall. But who knows, I just began this project and it already expanded from script --> external UI --> addon, so if I find features that are solid and makes sense they might be implemented.

I only have Pro devices for now, so also agree with Seth's question on whether this is kept in sync with what is already there. Meaning if I add this, will it pull in existing VLAN configurations?

I do fully think this could become an incredibly powerful add-in if you consider adding some firewall-start logic and sh refresh or restart to apply IPTable configurations. I have found this could be accomplished fairly programmatic (even though I am not a programmer/coder). Sharing my current config as reference, which includes a cleanup to prevent duplication when applying without firewall restart. Using Avahai reflector, which is also included as mDNS portion for reference, which supports casting to smart devices accessible cross-VLAN.

#!/bin/sh

# ===== Variables =====
PRINTER_IP="192.168.52.20"
VALERION_IP="192.168.52.254"
LAN_NET="192.168.50.0/24"
GUEST_NET="192.168.55.0/24"
SOMVE_NET="192.168.56.0/24"

# ===== Cleanup old printer rules =====
# This removes any existing rules that reference the printer IP
iptables -S FORWARD | grep "$PRINTER_IP" | while read -r rule; do
  # Convert the -A rule line into -D so it deletes cleanly
  iptables -D FORWARD ${rule#-A FORWARD }
done

# ===== Allow LAN + Guests to reach printer =====
# Insert at the top so they^rre evaluated before logdrop
for NET in "$LAN_NET" "$GUEST_NET" "$SOMVE_NET"; do
  iptables -I FORWARD 1 -s "$NET" -d "$PRINTER_IP" -j ACCEPT
done

# ===== Cleanup old Valerion rules =====
iptables -S FORWARD | grep "$VALERION_IP" | while read -r rule; do
  iptables -D FORWARD ${rule#-A FORWARD }
done

# ===== Allow LAN to reach Valerion =====
iptables -I FORWARD 1 -s "$LAN_NET" -d "$VALERION_IP" -j ACCEPT

# ===== Cleanup all existing mDNS rules =====
for CHAIN in INPUT FORWARD; do
  while iptables -L $CHAIN --line-numbers -n | grep "udp dpt:5353" >/dev/null; do
    LINENO=$(iptables -L $CHAIN --line-numbers -n | grep "udp dpt:5353" | head -n1 | awk '{print $1}')
    iptables -D $CHAIN $LINENO
  done
done

# ===== Re-add reflection rules =====
iptables -A INPUT   -i br0  -p udp --dport 5353 -j ACCEPT
iptables -A INPUT   -i br54 -p udp --dport 5353 -j ACCEPT
iptables -A FORWARD -i br0  -o br54 -p udp --dport 5353 -j ACCEPT
iptables -A FORWARD -i br54 -o br0 -p udp --dport 5353 -j ACCEPT

 

[r80xcore]

I only have Pro devices for now, so also agree with Seth's question on whether this is kept in sync with what is already there. Meaning if I add this, will it pull in existing VLAN configurations?

I do fully think this could become an incredibly powerful add-in if you consider adding some firewall-start logic and sh refresh or restart to apply IPTable configurations. I have found this could be accomplished fairly programmatic (even though I am not a programmer/coder). Sharing my current config as reference, which includes a cleanup to prevent duplication when applying without firewall restart. Using Avahai reflector, which is also included as mDNS portion for reference, which supports casting to smart devices accessible cross-VLAN.

#!/bin/sh

# ===== Variables =====
PRINTER_IP="192.168.52.20"
VALERION_IP="192.168.52.254"
LAN_NET="192.168.50.0/24"
GUEST_NET="192.168.55.0/24"
SOMVE_NET="192.168.56.0/24"

# ===== Cleanup old printer rules =====
# This removes any existing rules that reference the printer IP
iptables -S FORWARD | grep "$PRINTER_IP" | while read -r rule; do
  # Convert the -A rule line into -D so it deletes cleanly
  iptables -D FORWARD ${rule#-A FORWARD }
done

# ===== Allow LAN + Guests to reach printer =====
# Insert at the top so they^rre evaluated before logdrop
for NET in "$LAN_NET" "$GUEST_NET" "$SOMVE_NET"; do
  iptables -I FORWARD 1 -s "$NET" -d "$PRINTER_IP" -j ACCEPT
done

# ===== Cleanup old Valerion rules =====
iptables -S FORWARD | grep "$VALERION_IP" | while read -r rule; do
  iptables -D FORWARD ${rule#-A FORWARD }
done

# ===== Allow LAN to reach Valerion =====
iptables -I FORWARD 1 -s "$LAN_NET" -d "$VALERION_IP" -j ACCEPT

# ===== Cleanup all existing mDNS rules =====
for CHAIN in INPUT FORWARD; do
  while iptables -L $CHAIN --line-numbers -n | grep "udp dpt:5353" >/dev/null; do
    LINENO=$(iptables -L $CHAIN --line-numbers -n | grep "udp dpt:5353" | head -n1 | awk '{print $1}')
    iptables -D $CHAIN $LINENO
  done
done

# ===== Re-add reflection rules =====
iptables -A INPUT   -i br0  -p udp --dport 5353 -j ACCEPT
iptables -A INPUT   -i br54 -p udp --dport 5353 -j ACCEPT
iptables -A FORWARD -i br0  -o br54 -p udp --dport 5353 -j ACCEPT
iptables -A FORWARD -i br54 -o br0 -p udp --dport 5353 -j ACCEPT

Sorry but could you explain the network path here for me so I know what we are dealing with.

Do you run the Pro models in router mode or AP mode to an firewall/router like Opnsense etc? Can you explain the problem you are having and why MervLAN would fix that? I read something about the VLANS not applying to internet?

 

[penguin22]

I run the BE88U in router mode, with two AiMesh nodes, a BE86U (supports LAN VLAN tagging in addition to Pro Network VLAN tagging for individual SSIDs) and a BE82U. Pictures should help show this better:

 

[penguin22]

Sorry but could you explain the network path here for me so I know what we are dealing with.

Do you run the Pro models in router mode or AP mode to an firewall/router like Opnsense etc? Can you explain the problem you are having and why MervLAN would fix that? I read something about the VLANS not applying to internet?

MerVLAN could be a nice path to manage all VLANs in one place, along with assigning access (by IP or ports) across VLANs. If this is not the desired outcome, that's fine. As of now, it was just a suggestion. This setup with Pro devices is working, although the one item I have seen at times is where the timing of VLANs applying on restart can sometimes mean devices connect before the VLANs apply and they temporarily may receive a DHCP address from the main network vs their own pool. I don't know that MerVLAN would help in this case regardless.

 

[Seth Harman]

I run the BE88U in router mode, with two AiMesh nodes, a BE86U (supports LAN VLAN tagging in addition to Pro Network VLAN tagging for individual SSIDs) and a BE82U.

This is the kind of scenario that I was referring to. This can be a bit messy so let me be as clear as I can...

1. Guest Network Pro/Smart Home Master deal specifically with the creation of wireless VLANs
2. Pro models have the above, but can also manage Ethernet port VLAN tagging/wired VLANs
3. AiMesh under the 3006.xx firmware branch supports both wireless VLANs and Ethernet port VLAN tagging if the node supports LAN VLANs (which I believe is limited to Pro hardware at this point), otherwise it only supports wireless VLANs

My question really revolves around granting the ability for people using both Guest Network Pro/Smart Home Master and AiMesh where the hardware being used as nodes doesn't support LAN VLAN tagging. Right now I get around this by using managed switches, but if this add-on can provide this feature without having to used a managed switch it would very valuable to a lot of people.

 

[r80xcore]

MerVLAN could be a nice path to manage all VLANs in one place, along with assigning access (by IP or ports) across VLANs. If this is not the desired outcome, that's fine. As of now, it was just a suggestion. This setup with Pro devices is working, although the one item I have seen at times is where the timing of VLANs applying on restart can sometimes mean devices connect before the VLANs apply and they temporarily may receive a DHCP address from the main network vs their own pool. I don't know that MerVLAN would help in this case regardless.

Yes I agree, it would be really nice. I was under the impression that the Pro user wouldn't be interested in this at all. I've actually blocked most Pro units just so I don't screw with it, don't fix what isn't broken, ey?

If you would use my script as is right now it would most likely spawn SSIDs without a DHCP range.

An implementation of this could also mean that the interfaces gets decoupled from the regular interface. I canr guarantee this, as the vlan would actually point to br0 after they are created. But that would need to be tested.

A configure page could be made to save FW/IP-tables settings that the script is feeding on.

Is would probably be possible to fix the lingering units with a general block on the configured interfaces that is pushed on start and then removed when the dhcp is up. Actually something that I probably will start looking into on the one I have now, would be a neat feature to make sure no clients gets a range until everything is ready.

I will absolutely consider this. But it will have to wait until the current build is stable and all those functions are working as they should.

 

[r80xcore]

This is the kind of scenario that I was referring to. This can be a bit messy so let me be as clear as I can...

1. Guest Network Pro/Smart Home Master deal specifically with the creation of wireless VLANs
2. Pro models have the above, but can also manage Ethernet port VLAN tagging/wired VLANs
3. AiMesh under the 3006.xx firmware branch supports both wireless VLANs and Ethernet port VLAN tagging if the node supports LAN VLANs (which I believe is limited to Pro hardware at this point), otherwise it only supports wireless VLANs

My question really revolves around granting the ability for people using both Guest Network Pro/Smart Home Master and AiMesh where the hardware being used as nodes doesn't support LAN VLAN tagging. Right now I get around this by using managed switches, but if this add-on can provide this feature without having to used a managed switch it would very valuable to a lot of people.

If the Main unit discovers VLANs then we should be able to configure the nodes with MerVLAN and keep the main out of it. It depends on how the discovery there is. Do you configure it like a normal vlan like on Opnsense/Pfsense?

 

[Seth Harman]

If the Main unit discovers VLANs then we should be able to configure the nodes with MerVLAN and keep the main out of it. It depends on how the discovery there is. Do you configure it like a normal vlan like on Opnsense/Pfsense?

On my main router which is a Pro-series I'm using Guest Network Pro to create the wireless VLANs. Because the main router is Pro-series there's also a VLAN tab in the router interface that allows me to configure the LAN ports on it for both tagging and restricting the VLANs allowed across those ports. If my AiMesh nodes were also Pro-series the ability to control the tagging/etc... on the LAN ports of those nodes would also show up in the VLAN tab on the main router, but because my nodes are not Pro-series there is no ability to configure the LAN ports on the nodes to do anything with VLANs. I got around this by plugging cheap managed switches into a LAN port on each node and then plugged wired devices into those so I can tag the traffic. The key here is non Pro-series ASUS hardware doesn't have the ability to configure the LAN ports to tag traffic, and this is true regardless if you're using them as the main router or AiMesh nodes.

 

[r80xcore]

On my main router which is a Pro-series I'm using Guest Network Pro to create the wireless VLANs. Because the main router is Pro-series there's also a VLAN tab in the router interface that allows me to configure the LAN ports on it for both tagging and restricting the VLANs allowed across those ports. If my AiMesh nodes were also Pro-series the ability to control the tagging/etc... on the LAN ports of those nodes would also show up in the VLAN tab on the main router, but because my nodes are not Pro-series there is no ability to configure the LAN ports on the nodes to do anything with VLANs. I got around this by plugging cheap managed switches into a LAN port on each node and then plugged wired devices into those so I can tag the traffic. The key here is non Pro-series ASUS hardware doesn't have the ability to configure the LAN ports to tag traffic, and this is true regardless if you're using them as the main router or AiMesh nodes.

Okay so you connect a cheap managed switch to the node on U51 (example) and the uplink to the main to allow T51?

Right now this script acts like a manged witch in that sense. It tags the SSID as T51 the sets the uplink to allow T51 towards the Main etc.

It does not run any tagged (U51 etc) right now on the remaining traffic so that will run straight on br0, don't know if it will be assigned DHCP there or not, that would need to be tested. Depends on how your Asus assigns untagged traffic from the node.

But this implementation should probably be possible. In that case I could make a single configurable "Assign untagged br0 (VLAN number)"

Will check that out. If your router picks up the untagged traffic, then if would probably work as it is now.

 

[Seth Harman]

Okay so you connect a cheap managed switch to the node on U51 (example) and the uplink to the main to allow T51?

Right now this script acts like a manged witch in that sense. It tags the SSID as T51 the sets the uplink to allow T51 towards the Main etc.

It does not run any tagged (U51 etc) right now on the remaining traffic so that will run straight on br0, don't know if it will be assigned DHCP there or not, that would need to be tested. Depends on how your Asus assigns untagged traffic from the node.

But this implementation should probably be possible. In that case I could make a single configurable "Assign untagged br0 (VLAN number)"

Will check that out. If your router picks up the untagged traffic, then if would probably work as it is now.

Right now ASUS hardware operates as it should as any tagged traffic (whether tagged by ASUS hardware or a managed switch) gets passed through without any further alteration. In my case, for example, I created a VLAN using Guest Network Pro on the main router for my IoT devices. Because my AiMesh nodes are not Pro I can't add any wired devices to that VLAN if I connect them directly to a LAN port on a node so by connecting it to a managed switch and then running that into the node I can tag the wired traffic at the managed switch before it gets to the node and then it plays nice with the ASUS-created VLAN. So the real trick here is creating a method for an AiMesh node to tag LAN traffic. I'm out of my depth here in what exactly you're doing, but are you saying you can run something on the main router that will cause an AiMesh node to tag traffic coming across one of its LAN ports (not the backhaul), or is this something all being done after the traffic eventually gets to the main router as the script will recognize that a packet originally came from a node across a specific-LAN port?

 

[jksmurf]

I'm out of my depth here in what exactly you're doing

I’m in the same boat as @Seth Harman but curious whether this has legs as far as replicating (and obviating the need for) the managed switches to tell the main router which VLAN a device on the node should be on. That solution always seemed a bit messy as you’re adding more hardware, although not as costly as VLAN capable nodes. One advantage though (of either of these two solutions), is that the uplink can be wireless, whereas my understanding is your proposed implementation is wired only.

There is (quite a long) thread here which explains and give background and context to how we got to the point of what 3006/3004 and non VLAN capable nodes can and can not do, so your project has really piqued my and presumably Seth’s interest in that regard. You’ve certainly taken on a big project and thank you for rustling around in the innards of this thing. Way beyond my capabilities.

Switch capabilities of AiMesh Nodes?

A recent thread (a very interesting one) started me off thinking about how under-utilized nodes appear to be, for 3006 FW based nodes in particular. I am reasonably sure I know what the answer is, but bear with me while I muse and ramble and throw my toys out of the pram. I’m starting to look...

www.snbforums.com

 

[r80xcore]

Right now ASUS hardware operates as it should as any tagged traffic (whether tagged by ASUS hardware or a managed switch) gets passed through without any further alteration. In my case, for example, I created a VLAN using Guest Network Pro on the main router for my IoT devices. Because my AiMesh nodes are not Pro I can't add any wired devices to that VLAN if I connect them directly to a LAN port on a node so by connecting it to a managed switch and then running that into the node I can tag the wired traffic at the managed switch before it gets to the node and then it plays nice with the ASUS-created VLAN. So the real trick here is creating a method for an AiMesh node to tag LAN traffic. I'm out of my depth here in what exactly you're doing, but are you saying you can run something on the main router that will cause an AiMesh node to tag traffic coming across one of its LAN ports (not the backhaul), or is this something all being done after the traffic eventually gets to the main router as the script will recognize that a packet originally came from a node across a specific-LAN port?

In that case should be able to use a "node sync" -version only. This is when we copy only the needed files for configuring the accesspoint.

Right now i dont have any GUI version for that, but making a custom installer for that wouldn't be too hard. This way you would need to put in the vlans manually via ssh but that isnt hard.
This way your LAN ports would be tagged and then passed through the ethernet backhaul (wan port) to your main router that traffics the VLANs.

If you dont touch the SSIDs they wont be altered and still be on br0. So you should be able to just VLAN your LAN ports if thats what you want. This is a should, as i havent tested that yet.

But to clarify, is this the setup you are aiming for?

 

[r80xcore]

I’m in the same boat as @Seth Harman but curious whether this has legs as far as replicating (and obviating the need for) the managed switches to tell the main router which VLAN a device on the node should be on. That solution always seemed a bit messy as you’re adding more hardware, although not as costly as VLAN capable nodes. One advantage though (of either of these two solutions), is that the uplink can be wireless, whereas my understanding is your proposed implementation is wired only.

There is (quite a long) thread here which explains and give background and context to how we got to the point of what 3006/3004 and non VLAN capable nodes can and can not do, so your project has really piqued my and presumably Seth’s interest in that regard. You’ve certainly taken on a big project and thank you for rustling around in the innards of this thing. Way beyond my capabilities.

Switch capabilities of AiMesh Nodes?

A recent thread (a very interesting one) started me off thinking about how under-utilized nodes appear to be, for 3006 FW based nodes in particular. I am reasonably sure I know what the answer is, but bear with me while I muse and ramble and throw my toys out of the pram. I’m starting to look...

www.snbforums.com

As far as this project is now, setting VLAN per device (end client) is not possible. What we can do is set VLAN per interface or VAP. This means that we can bind SSIDS and LAN ports to individual VLANs and then trunk (send them) through a wired backhaul. Wireless backhaul is not possible here as the chips in these devices don't support it and strips the tags from the traffic.*

But as far as I understand you this is probably what you want. A MerVLAN manager that has support for editing only nodes and then let the default Asus VLAN manager pick that up and route it.

This would be possible. In that case we would use a toggle between standard mode and node-only mode. This would use SSH to push the needed files and you could even edit and save them in the GUI the remote execute it. After that the event handler and scripts would make sure it comes back up after a reboot/power failure/event.

If this is something people want i would be willing to add it on my to-do list.

 

[Seth Harman]

In that case should be able to use a "node sync" -version only. This is when we copy only the needed files for configuring the accesspoint.

Right now i dont have any GUI version for that, but making a custom installer for that wouldn't be too hard. This way you would need to put in the vlans manually via ssh but that isnt hard.
This way your LAN ports would be tagged and then passed through the ethernet backhaul (wan port) to your main router that traffics the VLANs.

If you dont touch the SSIDs they wont be altered and still be on br0. So you should be able to just VLAN your LAN ports if thats what you want. This is a should, as i havent tested that yet.

But to clarify, is this the setup you are aiming for?

I think what I'm looking for is fairly straightforward (assuming it's possible): I would like my non-Pro AiMesh nodes to be able to VLAN tag wired clients connected to the LAN ports on the nodes when VLANs are being created using Guest Network Pro on the main router. Right now this is limited to Pro-series AiMesh nodes but I've always suspected ASUS may use the same LAN hardware in them and just enables/disables features to differentiate between Pro and non-Pro.

 

[Seth Harman]

Wireless backhaul is not possible here as the chips in these devices don't support it and strips the tags from the traffic.*

I believe that runs contrary to how Guest Network Pro runs in conjunction with AiMesh under the 3006.xx firmware: if both your main router and nodes are on 3006.xx, when you create a VLAN using Guest Network Pro on the main router those VLAN ID tags can be assigned to wireless clients connecting to an AiMesh node and will survive all the way to the main router if you're using the wireless backhaul option. I run wired backhauls so I cannot confirm this personally but I believe we've got people on this forum doing this.