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?