What's new
  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Trying to understand Guest Network Pro limitations

Deetlemore

Occasional Visitor
Using an AX-86U Pro on FW 3006.102.4_beta1, I'm experimenting with Guest Network Pro and VLANs and I must be missing something.

I've created a VLAN (tagged as 3) and set ethernet port 3 as an access port tagged with that VLAN. I've then created a new guest network with that same VLAN, turned on Intranet access to my main network, and activated the DHCP server to manually assign the printer on port 3 a static IP address.

I can confirm through both the printer's UI and the router's DHCP reservations that it has received the expected IP address, but I cannot ping the printer from any device on my main network. Am I misunderstanding something about ASUS's VLAN implementation? My end goal was to allow both my guest network and main network to access the printer, but I'm at a loss.
 
How have you configured the Guest Network Pro Profile? Do you have the option "Use same subnet as main network" enabled or disabled?

When the Guest Network Pro "Use same subnet as main network" is disabled, it blocks all access to the main LAN and clients connected to that Guest Network Pro Profile (VLAN profile) receive their own IP address from a IP subnet range that is typically independent from the main LAN IP subnet range. The Guest Network Pro Profile may have the "Access Intranet" option that one can try enabling if "Use same subnet as main network" is disabled. For some on the stock Asus 3006 firmware, the Access Intranet option was broken and didn't apparently work.

Most people likely create the Guest Network Pro Profile first, then assign the LAN port to the created Guest Network Pro Profile created VLAN. Asus has some general information on VLAN and Guest Network Pro if you haven't seen it already. Unfortunately the information provided by Asus on Guest Network Pro and it's features are somewhat sparse and lacking in detail.
 
I have the printer's guest network using it's own subnet separate from the main network, but I also have "access intranet" option enabled. I thought that option would enable communication between the main LAN's subnet and the VLAN's subnet. It does seem like that option isn't working correctly, but I don't want to point fingers in case I'm just configuring things wrong.
 
What's the idea behind printer on a Guest Network with access to the Main Network? Not sure if there is inter-VLAN routing in GUI for specific device in 3006 firmware (needed for what you want), but I personally never had a guest with need to use my printers. Seems like extra complication to me for no good reason.
 
I have the printer's guest network using it's own subnet separate from the main network, but I also have "access intranet" option enabled. I thought that option would enable communication between the main LAN's subnet and the VLAN's subnet. It does seem like that option isn't working correctly, but I don't want to point fingers in case I'm just configuring things wrong.
VLANs are by design segregated from other VLANs and main network. Under Access Intranet within General, you can override access between subnets.
 
I have the printer's guest network using it's own subnet separate from the main network, but I also have "access intranet" option enabled. I thought that option would enable communication between the main LAN's subnet and the VLAN's subnet. It does seem like that option isn't working correctly, but I don't want to point fingers in case I'm just configuring things wrong.
What is your use case that you put the printer on it's own guest network and not the main LAN?
Not sure how wired VLAN clients will operate with Guest Network Pro Presets when you enable the Access Intranet option.

Did a quick test on my RT-AX86U Pro running 3006.102.4_beta1 with the IoT Guest Network Profile with only WiFi clients connected (no wired VLAN assigned), Use same subnet as main network set to disable and Access Intranet enabled and it appeared to work. The IoT Guest Network client(s) could access a NAS on the main LAN.

Maybe delete VLAN and Guest Network Pro and have the printer assigned to the main LAN. Then create the Guest Network Pro Profile including enabling Access Intranet, then proceed to add the wired printer port to the VLAN created by the Guest Network Pro Profile.

Edit to add: Attached image shows Guest Network Pro (IoT) Profile's Access Intranet option enabled allowing access to Main LAN clients. Main LAN clients were able to ping Guest Network Pro (IoT) clients.
 

Attachments

  • AccessIntranet.jpg
    AccessIntranet.jpg
    9.9 KB · Views: 84
Last edited:
What's the idea behind printer on a Guest Network with access to the Main Network? Not sure if there is inter-VLAN routing in GUI for specific device in 3006 firmware (needed for what you want), but I personally never had a guest with need to use my printers. Seems like extra complication to me for no good reason.
I have guests over occasionally to play tabletop games and they sometimes need to use my printer to print things like character sheets. I won't lie, it's not strictly necessary, just very slightly more convenient than having to print them myself. I won't lose any sleep if I can't get this to work.
VLANs are by design segregated from other VLANs and main network. Under Access Intranet within General, you can override access between subnets.
I believe I've done that by checking "Main Network" under "Access Intranet," that's where my confusion comes from.
What is your use case that you put the printer on it's own guest network and not the main LAN?
Not sure how wired VLAN clients will operate with Guest Network Pro Presets when you enable the Access Intranet option.

Did a quick test on my RT-AX86U Pro running 3006.102.4_beta1 with the IoT Guest Network Profile with only WiFi clients connected (no wired VLAN assigned), Use same subnet as main network set to disable and Access Intranet enabled and it appeared to work. The IoT Guest Network client(s) could access a NAS on the main LAN.

Maybe delete VLAN and Guest Network Pro and have the printer assigned to the main LAN. Then create the Guest Network Pro Profile including enabling Access Intranet, then proceed to add the wired printer port to the VLAN created by the Guest Network Pro Profile.

Edit to add: Attached image shows Guest Network Pro (IoT) Profile's Access Intranet option enabled allowing access to Main LAN clients. Main LAN clients were able to ping Guest Network Pro (IoT) clients.
I have my wholly unnecessary use case in my reply to Tech9, I can manage without if this isn't possible. You bring up a good point, this seems related to the fact that the printer is wired as the "Access Intranet" option works as expected with wireless clients.

I attached some screenshots of my settings in case that helps.
 

Attachments

  • 1.png
    1.png
    44.2 KB · Views: 82
  • 2.png
    2.png
    50.4 KB · Views: 77
  • 3.png
    3.png
    107.2 KB · Views: 77
  • 4.png
    4.png
    86.9 KB · Views: 75
  • 5.png
    5.png
    47.3 KB · Views: 79
I have guests over occasionally to play tabletop games and they sometimes need to use my printer to print things like character sheets. I won't lie, it's not strictly necessary, just very slightly more convenient than having to print them myself. I won't lose any sleep if I can't get this to work.

You are giving your guests access to the entire main network though. What you need is inter-VLAN routing for a specific device. I don't know if this option is available in GUI. You may have to create the rules manually. Someone else may help you with this.
 
@Deetlemore, a suggestion. Remove the existing Printer VLAN. Try creating a new Guest Network Pro Profile for only the printer, then assign that printer to the new Guest Network Profile VLAN. From there enable Access Intrant for that new Guest Network Profile to all listed VLAN's and main LAN. Then on the two other Guest Network Profiles (Asus_Guest and Asus_IoT), enable Access Internet to the Printer Guest Network Pro VLAN. Then test if that accomplishes what you are trying to do.
 
You are giving your guests access to the entire main network though. What you need is inter-VLAN routing for a specific device. I don't know if this option is available in GUI. You may have to create the rules manually. Someone else may help you with this.
The guest network and main network both have access to the printer's VLAN, but they don't have access to each other as all 3 are separate subnets. I double-checked by pinging devices from the guest subnet to main and vice-versa. It's looking like I'll need to take the manual route as you suggest, I'm suspecting this is either a limitation or oversight in Asuswrt's VLAN implementation.
@Deetlemore, a suggestion. Remove the existing Printer VLAN. Try creating a new Guest Network Pro Profile for only the printer, then assign that printer to the new Guest Network Profile VLAN. From there enable Access Intrant for that new Guest Network Profile to all listed VLAN's and main LAN. Then on the two other Guest Network Profiles (Asus_Guest and Asus_IoT), enable Access Internet to the Printer Guest Network Pro VLAN. Then test if that accomplishes what you are trying to do.
I gave that a shot, but unfortunately it's the same end-result. I'm probably going to need to do this through a startup script or something similar.
 
We actually had this available in 3004 firmware with no VLANs and custom script from AMTM. 🤔
 
We actually had this available in 3004 firmware with no VLANs and custom script from AMTM. 🤔
Yep, that's one option for the OP. Downside though is RMerlin has indicated the RT-AX86U Pro was not part of the 3004.388.9 release firmware. They'd be stuck using firmware 3004_388.8_4 firmware from last November.
 
I would stay there until 3006 pond clears up.
 
I appreciate you guys taking a peek at this, I just wanted to make sure I wasn't missing something obvious in the GUI. Not a deal-breaker at the end of the day, I'll just have to set aside some time to do things through SSH and leave the printer in the main network for the time being. At least 3006 has an option for client isolation now rather than needing to set it through services-start like I used to.
 
Here is another suggestion using scripting in the Asus-Merlin 3006.102.4 Beta firmware. Did a quick and dirty test and it appears to work on a RT-AX86U Pro running 3006.102.4_beta2. It allows a Guest Network Pro client(s) to access a single IP address on the main LAN.

Using SSH (Putty, WinSCP, etc), access the router and create a file called firewall-start in the /jffs/scripts/ directory (/jffs/scripts/firewall-start).
In that firewall-start file, put in the following code example. Adjust the IP addresses to match your Guest Network Pro VLAN (example uses VLAN 52 and 53) and main LAN client IP address you are trying to target (i.e. your printer connected to main LAN).
Code:
#!/bin/sh
iptables -I FORWARD -i br52 -s 192.168.52.0/24 -d 192.168.1.10 -j ACCEPT
iptables -I FORWARD -i br53 -s 192.168.53.0/24 -d 192.168.1.10 -j ACCEPT
Save the changes to the firewall-start file and set it's permissions to 0755 (chmod a+rx /jffs/scripts/firewall-start)
Restart the router firewall so it loads the firewall-start script by issuing the service restart_firewall command.

The above method in effect creates a one-way opening from Guest Network Pro VLAN to a single main LAN IP address. If you need two-way to/from Guest Network Pro VLAN and a specific main LAN IP address try the following:
Code:
#!/bin/sh
iptables -I FORWARD -i br52 -s 192.168.52.0/24 -d 192.168.1.10 -j ACCEPT
iptables -I FORWARD -i br53 -s 192.168.53.0/24 -d 192.168.1.10 -j ACCEPT
iptables -I FORWARD -i br0 -s 192.168.1.10 -d 192.168.52.0/24 -j ACCEPT
iptables -I FORWARD -i br0 -s 192.168.1.10 -d 192.168.53.0/24 -j ACCEPT

If the Access Intranet option isn't working correctly when enabled in Guest Network Pro Profile perhaps the following would work in the firewall-start script file.
Code:
#!/bin/sh
iptables -I FORWARD -i br52 -s 192.168.52.0/24 -d 192.168.1.0/24 -j ACCEPT
iptables -I FORWARD -i br53 -s 192.168.53.0/24 -d 192.168.1.0/24 -j ACCEPT
iptables -I FORWARD -i br0 -s 192.168.1.0/24 -d 192.168.52.0/24 -j ACCEPT
iptables -I FORWARD -i br0 -s 192.168.1.0/24 -d 192.168.53.0/24 -j ACCEPT

One uses such scripting at their own risk. There may be better way's to script such actions but in quick testing the one-way and two-way method detailed above appeared to work to facilitate a Guest Network Pro client(s) to access a specific main LAN client and for a main LAN client to access a Guest Network Pro client(s).

By using such methods one should be able to have their printer on the main LAN subnet and have Guest Network clients access and print from that main LAN printer while keeping the rest of the main LAN clients isolated from the Guest Network Pro client(s). As always it helps to assign a manual (or static) IP address to the printer so it's IP address doesn't change.
 
Here is another suggestion using scripting in the Asus-Merlin 3006.102.4 Beta firmware. Did a quick and dirty test and it appears to work on a RT-AX86U Pro running 3006.102.4_beta2. It allows a Guest Network Pro client(s) to access a single IP address on the main LAN.

Using SSH (Putty, WinSCP, etc), access the router and create a file called firewall-start in the /jffs/scripts/ directory (/jffs/scripts/firewall-start).
In that firewall-start file, put in the following code example. Adjust the IP addresses to match your Guest Network Pro VLAN (example uses VLAN 52 and 53) and main LAN client IP address you are trying to target (i.e. your printer connected to main LAN).
Code:
#!/bin/sh
iptables -I FORWARD -i br52 -s 192.168.52.0/24 -d 192.168.1.10 -j ACCEPT
iptables -I FORWARD -i br53 -s 192.168.53.0/24 -d 192.168.1.10 -j ACCEPT
Save the changes to the firewall-start file and set it's permissions to 0755 (chmod a+rx /jffs/scripts/firewall-start)
Restart the router firewall so it loads the firewall-start script by issuing the service restart_firewall command.

The above method in effect creates a one-way opening from Guest Network Pro VLAN to a single main LAN IP address. If you need two-way to/from Guest Network Pro VLAN and a specific main LAN IP address try the following:
Code:
#!/bin/sh
iptables -I FORWARD -i br52 -s 192.168.52.0/24 -d 192.168.1.10 -j ACCEPT
iptables -I FORWARD -i br53 -s 192.168.53.0/24 -d 192.168.1.10 -j ACCEPT
iptables -I FORWARD -i br0 -s 192.168.1.10 -d 192.168.52.0/24 -j ACCEPT
iptables -I FORWARD -i br0 -s 192.168.1.10 -d 192.168.53.0/24 -j ACCEPT

If the Access Intranet option isn't working correctly when enabled in Guest Network Pro Profile perhaps the following would work in the firewall-start script file.
Code:
#!/bin/sh
iptables -I FORWARD -i br52 -s 192.168.52.0/24 -d 192.168.1.0/24 -j ACCEPT
iptables -I FORWARD -i br53 -s 192.168.53.0/24 -d 192.168.1.0/24 -j ACCEPT
iptables -I FORWARD -i br0 -s 192.168.1.0/24 -d 192.168.52.0/24 -j ACCEPT
iptables -I FORWARD -i br0 -s 192.168.1.0/24 -d 192.168.53.0/24 -j ACCEPT

One uses such scripting at their own risk. There may be better way's to script such actions but in quick testing the one-way and two-way method detailed above appeared to work to facilitate a Guest Network Pro client(s) to access a specific main LAN client and for a main LAN client to access a Guest Network Pro client(s).

By using such methods one should be able to have their printer on the main LAN subnet and have Guest Network clients access and print from that main LAN printer while keeping the rest of the main LAN clients isolated from the Guest Network Pro client(s). As always it helps to assign a manual (or static) IP address to the printer so it's IP address doesn't change.
I tried configuring rules to also printer access from both my IoT and guest networks (both with custom configuration as opposed to templates). My primary network (br0) is 192.168.222.0/24, my IoT network (br53) is 192.168.52.0/24, and my guest network (br52) is 192.168.54.0/24) — my printer is 192.168.222.10.

NOTE: For whatever reason, the bridge names do not match the VLAN subnets.

The rules in /jffs/scripts/firewall-start are as follows.:
Code:
#!/bin/sh

iptables -I FORWARD -i br53 -s 192.168.52.0/24 -d 192.168.222.10 -j ACCEPT
iptables -I FORWARD -i br52 -s 192.168.54.0/24 -d 192.168.222.10 -j ACCEPT

iptables -I FORWARD -i br0 -s 192.168.222.10 -d 192.168.52.0/24 -j ACCEPT
iptables -I FORWARD -i br0 -s 192.168.222.10 -d 192.168.54.0/24 -j ACCEPT
Unfortunately, I am still unable to access the printer (HP OfficeJet Pro 8720) from either IoT or guest VLAN. Any suggestions as to what I might be missing, or information that might help to diagnose the issue?
 
Last edited:
NOTE: For whatever reason, the bridge names do not match the VLAN subnets.
I don't have any insight except I've heard other say they fixed vlan problems by deleting and recreating them. The fact that your vlan tags/bridge names don't match your subnets is odd. Worth fixing that by deleting and recreating?
 
My primary network (br0) is 192.168.222.0/24, my IoT network (br53) is 192.168.52.0/24, and my guest network (br52) is 192.168.52.0/24) — my printer is 192.168.222.10.
Double check that you are using the correct VLAN (br) numbers and IP addresses. What you have indicated is you have two guest networks using the same IP address subnet range 192.168.52.0/24. You indicate a br52 and br53 yet your scripting indicates 192.168.52.0/24 and 192.168.54.0/24 (was the br53 IP address subnet range changed to 192.168.54.0/24?). And make sure you have set the permissions on the firewall-start script file to 0755 (chmod a+rx /jffs/scripts/firewall-start) so it can be executed by the router firmware.

Maybe try starting with the following and see if the Guest Network clients and main LAN client can ping or see/access each other. If they can then you can change out the entire 192.168.222.0/24 subnet address with the IP address of the printer
Code:
#!/bin/sh
iptables -I FORWARD -i br52 -s 192.168.52.0/24 -d 192.168.222.0/24 -j ACCEPT
iptables -I FORWARD -i br53 -s 192.168.53.0/24 -d 192.168.222.0/24 -j ACCEPT
iptables -I FORWARD -i br0 -s 192.168.222.0/24 -d 192.168.52.0/24 -j ACCEPT
iptables -I FORWARD -i br0 -s 192.168.222.0/24 -d 192.168.53.0/24 -j ACCEPT
You may need to reboot the router if service restart_firewall command doesn't work after each time you modify and save the firewall-start file.
 
Double check that you are using the correct VLAN (br) numbers and IP addresses. What you have indicated is you have two guest networks using the same IP address subnet range 192.168.52.0/24. You indicate a br52 and br53 yet your scripting indicates 192.168.52.0/24 and 192.168.54.0/24 (was the br53 IP address subnet range changed to 192.168.54.0/24?). And make sure you have set the permissions on the firewall-start script file to 0755 (chmod a+rx /jffs/scripts/firewall-start) so it can be executed by the router firmware.

Maybe try starting with the following and see if the Guest Network clients and main LAN client can ping or see/access each other. If they can then you can change out the entire 192.168.222.0/24 subnet address with the IP address of the printer
Code:
#!/bin/sh
iptables -I FORWARD -i br52 -s 192.168.52.0/24 -d 192.168.222.0/24 -j ACCEPT
iptables -I FORWARD -i br53 -s 192.168.53.0/24 -d 192.168.222.0/24 -j ACCEPT
iptables -I FORWARD -i br0 -s 192.168.222.0/24 -d 192.168.52.0/24 -j ACCEPT
iptables -I FORWARD -i br0 -s 192.168.222.0/24 -d 192.168.53.0/24 -j ACCEPT
You may need to reboot the router if service restart_firewall command doesn't work after each time you modify and save the firewall-start file.
Typo above on the IP address of one of the VLANs (since corrected). My primary network (br0) is 192.168.222.0/24, my IoT network (br53) is 192.168.52.0/24, and my guest network (br52) is 192.168.54.0/24) — yes, there is a mismatch between br numbers and IP address of subnet. My printer is 192.168.222.10, so I believe that iptables commands were correct.
 
I think brX changes with network changes. My setup after a few adds and removes:
Code:
# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.60cf84003798       yes             bond0
                                                        eth3
                                                        eth4
                                                        eth5
                                                        eth6
                                                        eth7
                                                        eth8
                                                        eth9
                                                        wl0.0
                                                        wl0.1
                                                        wl0.4
                                                        wl1.0
                                                        wl1.1
br54            8000.72cf8400379a       yes             eth1.52
                                                        eth2.52
                                                        eth3.52
                                                        eth4.52
                                                        eth5.52
                                                        eth6.52
                                                        eth7.52
                                                        eth8.52
                                                        eth9.52
                                                        wl0.2
                                                        wl0.52
                                                        wl1.52
 

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Back
Top