RT-AC86U VLAN-like modifications to guest network

[georgev]

Hello all!

I'm using an RT-AC86U with Merlin and I would like to have three different wireless networks (all with different SSIDs and passwords): one for trusted devices, one for guests, and one for IoT devices. On the guest and IoT networks, I want all devices to be isolated.

At this point, using the "Guest Network" feature in the GUI has me all set! However, I have a few additional requirements...

1. I would like devices on the trusted subnet to be able to connect to devices on the IoT subnet.
2. I would like devices on the guest subnet to connect to a server I'm hosting on the trusted subnet. (Port forward?)

And a few strech-goal requirements:

3. I would like to have guest devices be able to connect to a single device on the IoT subnet. (a chromecast with a static ip)
4. I would like to be able to enforce firewall rules on the IoT subnet to prevent them from connecting to there respective services when possible. (I know I have to be careful with this as some IoT devices will throw a fit if they can't phone home)
5. I would like to utilize any bonus security features to strictly lock down the guest and IoT subnet (IDS, etc.).

I tried to figure this out myself by trying to figure out what exactly is getting set up by the "guest network" gui feature. I see that it creates a new br interface, as well as a bunch of ethX.0 and ethX.501 interfaces that connect to the trusted bridge and the guest bridge respectively. I don't see via "brctl", "ip", "iptables", "ebtables" commands how it is enforcing isolation between clients on that interface, so now I'm stuck reverse engineering how the guest networks are set up. I also don't understand why there is still just one wl interface (wl0.1). I would expect there to be two wl interfaces for the two different SSIDs?

Also, based on the "ethX.501" naming convention, am I understanding correctly that this is a "Tagged VLAN" sort of network setup? I'm a total rookie with this sort of stuff, so I'd appreciate any lessons/info/reading anyone can give or point me to!

Lastly, in absence of any other suggestions, I was going to somewhat follow this dude's procedure (https://wu.renjie.im/blog/network/ax88u-vlan/) to set up VLANs via iptables. I am somewhat comfortable with iptables, so that seemed like an accessible type of solution.

 

[drinkingbird]

Hello all!

I'm using an RT-AC86U with Merlin and I would like to have three different wireless networks (all with different SSIDs and passwords): one for trusted devices, one for guests, and one for IoT devices. On the guest and IoT networks, I want all devices to be isolated.

At this point, using the "Guest Network" feature in the GUI has me all set! However, I have a few additional requirements...

1. I would like devices on the trusted subnet to be able to connect to devices on the IoT subnet.
2. I would like devices on the guest subnet to connect to a server I'm hosting on the trusted subnet. (Port forward?)

And a few strech-goal requirements:

3. I would like to have guest devices be able to connect to a single device on the IoT subnet. (a chromecast with a static ip)
4. I would like to be able to enforce firewall rules on the IoT subnet to prevent them from connecting to there respective services when possible. (I know I have to be careful with this as some IoT devices will throw a fit if they can't phone home)
5. I would like to utilize any bonus security features to strictly lock down the guest and IoT subnet (IDS, etc.).

I tried to figure this out myself by trying to figure out what exactly is getting set up by the "guest network" gui feature. I see that it creates a new br interface, as well as a bunch of ethX.0 and ethX.501 interfaces that connect to the trusted bridge and the guest bridge respectively. I don't see via "brctl", "ip", "iptables", "ebtables" commands how it is enforcing isolation between clients on that interface, so now I'm stuck reverse engineering how the guest networks are set up. I also don't understand why there is still just one wl interface (wl0.1). I would expect there to be two wl interfaces for the two different SSIDs?

Also, based on the "ethX.501" naming convention, am I understanding correctly that this is a "Tagged VLAN" sort of network setup? I'm a total rookie with this sort of stuff, so I'd appreciate any lessons/info/reading anyone can give or point me to!

Lastly, in absence of any other suggestions, I was going to somewhat follow this dude's procedure (https://wu.renjie.im/blog/network/ax88u-vlan/) to set up VLANs via iptables. I am somewhat comfortable with iptables, so that seemed like an accessible type of solution.

For all the stuff you want to do, Yazfi will get you started and a script to go with it (has scripting support built in) will get you most of the way there. It eliminates the VLANs Asus uses so be aware that your wifi and isolation will not propagate to AiMesh nodes if you have any (or add any in the future).

 

[georgev]

Thanks for pointing me towards that repo! That's great to hear someone has already put together a nice solution for this. Although I'm a bit daunted at the possibility that there are many like plugins/extensions out there that I also don't know about! Does Yazfi exist on some sort of "Merlin GUI extensions" list somewhere? Is there a thread somewhere on this website where people highlight awesome repos like this? Or do I just need to be a more active reader on this website to hear about stuff like this?

I currently do some funny things with VPN routing and custom DNS that I'm a bit concerned this will clobber. These are things I set up many years ago and don't exactly remember what things I changed and why... but I guess that's part of the game. I'm still interested in discussing how I'd go about setting this up myself; specifically gaining an understanding of what is happening behind the scenes when the router (without the Yazfi extension) does when it sets up a guest network. It feels like I'm just a few iptables lines away from what I want now without the extension. However, I might also be able to figure this out by digging through the source of Yazfi.

 

[ColinTaylor]

Thanks for pointing me towards that repo! That's great to hear someone has already put together a nice solution for this. Although I'm a bit daunted at the possibility that there are many like plugins/extensions out there that I also don't know about! Does Yazfi exist on some sort of "Merlin GUI extensions" list somewhere? Is there a thread somewhere on this website where people highlight awesome repos like this? Or do I just need to be a more active reader on this website to hear about stuff like this?

Asuswrt-Merlin Addon Software Catalog

Asus-Merlin Addon Software Catalog This sticky post functions as a software catalog (with links to threads, scripts, and author names), grouped by functionality, to make it easier for Asus-Merlin users to find and install addons for their Asus routers without having to search through massive...

www.snbforums.com

Asuswrt-Merlin AddOns

This forums is for discussions about AddOns for Asuswrt-Merlin, i.e. Diversion, Skynet, etc.

www.snbforums.com

 

[georgev]

Thanks @ColinTaylor! That's super helpful!

 

[drinkingbird]

Thanks for pointing me towards that repo! That's great to hear someone has already put together a nice solution for this. Although I'm a bit daunted at the possibility that there are many like plugins/extensions out there that I also don't know about! Does Yazfi exist on some sort of "Merlin GUI extensions" list somewhere? Is there a thread somewhere on this website where people highlight awesome repos like this? Or do I just need to be a more active reader on this website to hear about stuff like this?

I currently do some funny things with VPN routing and custom DNS that I'm a bit concerned this will clobber. These are things I set up many years ago and don't exactly remember what things I changed and why... but I guess that's part of the game. I'm still interested in discussing how I'd go about setting this up myself; specifically gaining an understanding of what is happening behind the scenes when the router (without the Yazfi extension) does when it sets up a guest network. It feels like I'm just a few iptables lines away from what I want now without the extension. However, I might also be able to figure this out by digging through the source of Yazfi.

You're a lot more than a few iptables rules away
Iptables
Ebtables
Disabling AP isolation
If you want to modify the stock VLANs you'll need IP link, vconfig, ifconfig, brctl, various nvram variables, probably a few others I'm not remembering.

Note Yazfi does things differently, it doesn't use VLANs like Asus stock does, it uses routed interfaces. Similar, but can't be extended to other devices or nodes.

 

[bennor]

Does Yazfi exist on some sort of "Merlin GUI extensions" list somewhere?

Direct link to the latest main YazFi discussion in the Add-Ons subforum:

YazFi - YazFi v4.x - continued

v4.4.4 Updated 2023-11-26 Feature expansion of guest WiFi networks on AsusWRT-Merlin, including, but not limited to: * Dedicated VPN WiFi networks * Separate subnets for organisation of devices * Restrict guests to only contact router for ICMP, DHCP, DNS, NTP and NetBIOS * Allow guest networks...

www.snbforums.com

The YazFi GitHub:

GitHub - jackyaz/YazFi: Feature expansion of guest WiFi networks on AsusWRT-Merlin, including SSID -> VPN, separate subnets per guest network, pinhole access to LAN resources (e.g. DNS) and more!

Feature expansion of guest WiFi networks on AsusWRT-Merlin, including SSID -> VPN, separate subnets per guest network, pinhole access to LAN resources (e.g. DNS) and more! - jackyaz/YazFi

github.com

Note: YazFi generally doesn't work on AiMesh nodes, AP nodes or Media Bridge nodes.

 

[georgev]

Alright, if you don't want to explain what it would take with "a lot more than a few iptables rules" to modify the stock guest network paradigm, I understand. To satisfy my curiosity, I'll attempt to pursue learning about how the router sets up its VLANs for guest networks without the help of the forum. But in order to get to the finish line of this project, I'll go with the YazFi route.

Pursuing the Yazfi route: I can see how I can easily achieve requirement #1, but I'm still not sure how I'd tackle the rest. Again, the requirements of the project are

1. I would like devices on the trusted subnet to be able to connect to devices on the IoT subnet.
2. I would like devices on the guest subnet to connect to a server I'm hosting on the trusted subnet. (LAN port mapping?)

(stretch goals)

3. I would like to have guest devices be able to connect to a single device on the IoT subnet. (a chromecast with a static ip)
4. I would like to be able to enforce firewall rules on the IoT subnet to prevent them from connecting to there respective services when possible. (I know I have to be careful with this as some IoT devices will throw a fit if they can't phone home)
5. I would like to utilize any bonus security features to strictly lock down the guest and IoT subnet (IDS, etc.).

I'm assuming I could set up a LAN port map for #2? Let's say the trusted network is 192.168.100.0/24, the guest network is 192.168.200.0/24, and my server is 192.168.100.100:80. Could I just set up a port forward of 192.168.200.100:80 -> 192.168.100.100:80, or will that mess with the isolation that YazFi tries to enforce? Also, is that kosher if 192.168.200.100 is not an actual ip on the network?

If that strategy works for #2, I could maybe do the same for #3? Create a fake ip within the trusted network as well as in the guest network? So when the devices search for a chromecast on the network, the router forwards those probes to the actual device, then the chromecast is able to respond via the established link?

#4 sounds like more iptables rules...

#5 was more just a query if any nice features are built into the router that I could take advantage of for more advanced security features.

 

[drinkingbird]

Alright, if you don't want to explain what it would take with "a lot more than a few iptables rules" to modify the stock guest network paradigm, I understand.

It would be pages and pages and I don't have an HND router to double check my spotty memory, but others here have done various changes to VLANs on HND routers so a search for "vconfig" or "ip link" should find many of those posts. But to warn again, doing VLAN stuff on an HND router is very involved (and requires disabling hardware acceleration), especially if you want to start using physical ports. That's why I recommend just using the stock asus VLANs and an external smart switch (since all LAN ports trunk those VLANs by default) and then you can disable client isolation and add iptables rules as needed for allowing traffic. But if you're going to use Yazfi, you don't need VLANs, (but you also can't put wired ports into the guest networks and can't have the guest span to other aimesh nodes). So depends on your needs.

To satisfy my curiosity, I'll attempt to pursue learning about how the router sets up its VLANs for guest networks without the help of the forum. But in order to get to the finish line of this project, I'll go with the YazFi route.

Pursuing the Yazfi route: I can see how I can easily achieve requirement #1, but I'm still not sure how I'd tackle the rest. Again, the requirements of the project are

1. I would like devices on the trusted subnet to be able to connect to devices on the IoT subnet.

Easy, "one way to guest" in Yazfi GUI

2. I would like devices on the guest subnet to connect to a server I'm hosting on the trusted subnet. (LAN port mapping?)

Fairly easy, yazfi supports a script to add iptables rules

(stretch goals)

3. I would like to have guest devices be able to connect to a single device on the IoT subnet. (a chromecast with a static ip)

I believe this can be done with the same script from above but both guest networks will likely need "client isolation" set to off.

4. I would like to be able to enforce firewall rules on the IoT subnet to prevent them from connecting to there respective services when possible. (I know I have to be careful with this as some IoT devices will throw a fit if they can't phone home)

Can probably do this via the firewall -> network services filter, or add them to the same script above.

5. I would like to utilize any bonus security features to strictly lock down the guest and IoT subnet (IDS, etc.).

Trend micro will still work with the guest subnets, at least to the internet (not in between them or between them and your main LAN). There are no other "bonus" security features that I know of, unless you start installing more addons which is certainly an option (DNS filters like pihole or using a filtering DNS server on your WAN settings, IP blacklists, etc).

I'm assuming I could set up a LAN port map for #2? Let's say the trusted network is 192.168.100.0/24, the guest network is 192.168.200.0/24, and my server is 192.168.100.100:80. Could I just set up a port forward of 192.168.200.100:80 -> 192.168.100.100:80, or will that mess with the isolation that YazFi tries to enforce? Also, is that kosher if 192.168.200.100 is not an actual ip on the network?

No, port forwarding is only from WAN to LAN, it might work using NAT loopback i.e. point the client to the WAN IP then have a port forwarding rule back in but that is messy and will slow you down. You'll just need an iptables rule in the yazfi script to accomplish this directly between the networks. Side note, I'm assuming those are just examples but don't use 192.168.100, 101, 102, or 103. 100 is used by many ISP devices for management, and 101-103 are used by the default Asus guest. You won't be using them but still best to avoid them. If you want nice round numbers you can use the 10.x range, lots of subnets available in there and it avoids the entire 192.168 which gets used by a lot of other stuff.

If that strategy works for #2, I could maybe do the same for #3? Create a fake ip within the trusted network as well as in the guest network? So when the devices search for a chromecast on the network, the router forwards those probes to the actual device, then the chromecast is able to respond via the established link?

When you enable "one way to guest" by default replies (established TCP connections) are allowed. You can do similar between guest networks by copying that rule and just changing the interfaces. So one guest can initiate connections to another, the other can reply, but not initiate its own connections back. This only applies to TCP, if you need UDP you need specific rules in both directions for that.

 

[georgev]

Well, I installed the YazFi software and ran into many issues. The order of operations went like this:

- I installed the software, enabled YazFi on my guest network. Isolation remained, but I did not have the one way communication that I set the radio button for (I had neither direction).
- I also noticed that "Access Intranet" on the guest network was suddenly turned on (bad). I disabled that again.
- I re-enabled the one way communication and it seemed to work.
- I enabled the YazFi on my second network. This caused internet access to end on my first guest network, and now neither IoT network or the Guest network could talk in either direction.
- I disabled both YazFi networks. When the wifi radio came back on, all of my devices (on trusted, guest, and IoT) had network connection, but none could touch the internet, each other, or my router! No ssh or web access anymore in my main network.
- I rebooted, nothing changed. No internet or access to router from any network.

I eventually had to power down my router, disconnect the external media I'm using for entware, reboot, disable guest networks, power down, plug the external drive back in, power up, then uninstall YazFi.

I know it's a community project, so I don't expect perfection, but that was a pretty serious way to screw up my whole home networking setup. Perhaps it's buggy with the RT-AC86U?

In either case, it really looks like the YazFi route is:

1. Set up the guest networks via the guest networks tab
2. Set up YazFi via that tab
3. Tweak with iptables

vs.

1. Set up the guest networks via the guest networks tab
2. Tweak with iptables

I see the bridge that gets set up when I start a guest network (br1), I see the other wifi SSID interface that gets created (wl0.1). I'm having a hard time understanding why I can't set up an iptables rule to go between br0 and br1... What am I failing to understand? I'd think I could set up a rule allowing connections from br0 to br1, and related/established connections from br1 back to br0. That seems like what Renjie did (https://wu.renjie.im/blog/network/ax88u-vlan/) and what @scrypt did (https://www.snbforums.com/threads/vlan-setup-for-iot-devices.84272/). Why would it be so much harder on my hardware?

As for the hardware acceleration, I've tried disabling "Runner" (`runner disable`) and "Flow Cache" (`fc disable` and `fc flush`), it doesn't seem to make any difference.

For the record, I went through Renjie's setup. It resulted in a guest network on a fresh bridge that I created that would not let devices connect to it. I tried doing a static ip from the device side to rule out dhcp issues, and it still doesn't connect. The only difference between what I see when I do mine vs his is that my mac of my new bridge is not the same as my main bridge (rather it is the same as the isolated bridge that the guest network creates, br1). Not sure if that's related.

Also, I can't do exactly whta @scrypt did, because I don't have robocfg available to me.

 

[drinkingbird]

Well, I installed the YazFi software and ran into many issues. The order of operations went like this:

- I installed the software, enabled YazFi on my guest network. Isolation remained, but I did not have the one way communication that I set the radio button for (I had neither direction).
- I also noticed that "Access Intranet" on the guest network was suddenly turned on (bad). I disabled that again.
- I re-enabled the one way communication and it seemed to work.
- I enabled the YazFi on my second network. This caused internet access to end on my first guest network, and now neither IoT network or the Guest network could talk in either direction.
- I disabled both YazFi networks. When the wifi radio came back on, all of my devices (on trusted, guest, and IoT) had network connection, but none could touch the internet, each other, or my router! No ssh or web access anymore in my main network.
- I rebooted, nothing changed. No internet or access to router from any network.

I eventually had to power down my router, disconnect the external media I'm using for entware, reboot, disable guest networks, power down, plug the external drive back in, power up, then uninstall YazFi.

I know it's a community project, so I don't expect perfection, but that was a pretty serious way to screw up my whole home networking setup. Perhaps it's buggy with the RT-AC86U?

In either case, it really looks like the YazFi route is:

1. Set up the guest networks via the guest networks tab
2. Set up YazFi via that tab
3. Tweak with iptables

vs.

1. Set up the guest networks via the guest networks tab
2. Tweak with iptables

I see the bridge that gets set up when I start a guest network (br1), I see the other wifi SSID interface that gets created (wl0.1). I'm having a hard time understanding why I can't set up an iptables rule to go between br0 and br1... What am I failing to understand? I'd think I could set up a rule allowing connections from br0 to br1, and related/established connections from br1 back to br0. That seems like what Renjie did (https://wu.renjie.im/blog/network/ax88u-vlan/) and what @scrypt did (https://www.snbforums.com/threads/vlan-setup-for-iot-devices.84272/). Why would it be so much harder on my hardware?

As for the hardware acceleration, I've tried disabling "Runner" (`runner disable`) and "Flow Cache" (`fc disable` and `fc flush`), it doesn't seem to make any difference.

For the record, I went through Renjie's setup. It resulted in a guest network on a fresh bridge that I created that would not let devices connect to it. I tried doing a static ip from the device side to rule out dhcp issues, and it still doesn't connect. The only difference between what I see when I do mine vs his is that my mac of my new bridge is not the same as my main bridge (rather it is the same as the isolated bridge that the guest network creates, br1). Not sure if that's related.

Also, I can't do exactly whta @scrypt did, because I don't have robocfg available to me.

Yazfi requires you to leave access intranet enabled on the main screen. It moves control of that to the Yazfi screen. Enabling it on the main screen especially for GW1 will totally hose everything.

Certain settings changes in Yazfi will require a reboot also.

Robocfg is not available on your router, totally different chipset. If you had robocfg, VLANs would be a lot easier.

I'd start over and let yazfi enable your main guest settings to access intranet, set the stuff you want, and reboot. Don't change anything on the normal guest tab once you install and enable Yazfi.

But you also have to keep in mind some stuff requires the same subnet (like mDNS and other discovery mechanisms) and other stuff uses UDP which won't work properly with the "one way to guest".

If you want to stick with the stock guest network, you'll need scripts to disable AP isolation, and update iptables and ebtables rules. However I've found this only seems to work with guest wireless 1. GW 2 and 3 on my router also have some additional broadcast blocking somewhere. It may be different on your router, so you'll just have to give it a try.

Honestly you may be at the point where it makes more sense to have a separate router (pfsense/opnsense, or a pre built one like edgerouter, mikrotik, TP-Link) and an access point.

 

[drinkingbird]

Well, I installed the YazFi software and ran into many issues. The order of operations went like this:

If you want to give YazFi another go, here is what I would do.

Hard factory reset the router, start with no Yazfi installed.
Configure GW1 but for each band, make sure access intranet is ENABLED before hitting apply.
Configure GW2 (and 3 if needed), not quite as important here but still best to enable it before applying.
Reboot
Install Yazfi
Never touch the "access intranet" option on the main wifi again
Configure your Yazfi options, most likely you're just going to want to disable client isolation on all of the guest networks for what you're looking to do. You can toy with the settings either way.
Reboot again

Now you can test the basics and start adding iptables rules via the yazfi script.

Not every change to Yazfi requires a reboot but to be safe after changing options it is a good idea.

As long as you don't touch the access intranet feature on the main wifi settings, you should be able to change other things but honestly it would be best to just pick your SSIDs and passwords before installing Yazfi and touch that main screen as rarely as possible. Changes there may result in overwriting some of the yazfi configs so better safe than sorry.

 

[bennor]

- I also noticed that "Access Intranet" on the guest network was suddenly turned on (bad). I disabled that again.

Access Internet being enabled is by design with YazFi. Do not disable it. The reason why has been explain a number of times in the past in other discussions about YazFi when this question comes up, for example here. The developer's response to why:

yes. asus makes some changes that conflict if access internet is disabled, YazFi installs its own rules that achieves the same

Some comments about using YazFi. If you run into issues using GW1 then try using GW2 and or GW3. Guest Network 1 is handled slightly differently than the other guest networks by the Asus firmware. Make sure each IP address is unique from both each other and from the main LAN IP address. For example if the main LAN is 192.168.1.1 set the YazFi guest network to 192.168.2.1. See this link for more on this specific issue with IP address naming with YazFi to avoid certain conflict issues with the main LAN IP address range.

 

[drinkingbird]

Access Internet being enabled is by design with YazFi. Do not disable it. The reason why has been explain a number of times in the past in other discussions about YazFi when this question comes up, for example here. The developer's response to why:

Some comments about using YazFi. If you run into issues using GW1 then try using GW2 and or GW3. Guest Network 1 is handled slightly differently than the other guest networks by the Asus firmware. Make sure each IP address is unique from both each other and from the main LAN IP address. For example if the main LAN is 192.168.1.1 set the YazFi guest network to 192.168.2.1. See this link for more on this specific issue with IP address naming with YazFi to avoid certain conflict issues with the main LAN IP address range.

As long as access intranet is enabled on the main guest properties, GW1, 2 and 3 are all treated identically.

 

[georgev]

Alright, everything seems stable and the way I want it! I am using YazFi as suggested. Thanks so much for your help and patience @drinkingbird!

I think the problem I was having was due to one of my guest networks being part of a subnet range that has changing VPN director rules? I also now see how disabling access to intranet could cause some bad/weird behavior.

I also had a weird case where my Google Nest (on the IoT subnet) would stay connected for a few hours, then disconnect, and repeatedly reconnect every half second. This seemed to be linked to taking down a security cam stream on my network. I was able to take down the IoT subnet and avoid the problem all together. Then I found a thread somewhere on this site that I can't seem to find again where someone was having a similar issue that someone else (I actually think it was you, @drinkingbird) mentioned there could be some weird issue with aimesh and a hidden SSID. It was recommended to turn off the Roaming Assistant setting (mine was already off) and add the offending device to the roaming blacklist. Doing the latter seemed to do the trick!

Note: I'm not doing the hidden SSID for any security reason. I just live in a dense environment and I felt bad for cluttering up everyone's SSID list with more than my fair share of SSIDs.

As for the iptables rules, I wanted to do something in /jffs/addons/YazFi.d/userscripts.d/custom_iptables_rules.sh like:

#!/bin/bash

# Enable guests to reach out to port 80 of the server on the trusted network
iptables -I YazFiFORWARD -i [guest interface] -d [trusted server ip] -p tcp --dport 80 -j ACCEPT

# Allow related traffic to go from the guest network to the server on the trusted network
iptables -I YazFiFORWARD -i [guest interface] -d [trusted server ip] -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

# Allow the server on the trusted network to talk to the guest interface (although this should be allowed by YazFi One Way traffic)
iptables -I YazFiFORWARD -o [guest interface] -s [trusted server ip] -j ACCEPT

---

This worked fine and dandy for desktops and Android devices talking to the server, but no dice for iPhones. It does work for iPhones if I open up iptables even more (iptables -I YazFiFORWARD -i [guest interface] -d [trusted server ip] -j ACCEPT). Not exactly sure why. I'd think the "RELATED,ESTABLISHED" rule would cover all related traffic, but I guess iPhones start traffic on an ephemeral port without marking that traffic as related or established?

Oh well. Serves 'em right for having an iPhone.

 

[drinkingbird]

This worked fine and dandy for desktops and Android devices talking to the server, but no dice for iPhones. It does work for iPhones if I open up iptables even more (iptables -I YazFiFORWARD -i [guest interface] -d [trusted server ip] -j ACCEPT). Not exactly sure why. I'd think the "RELATED,ESTABLISHED" rule would cover all related traffic, but I guess iPhones start traffic on an ephemeral port without marking that traffic as related or established?

Oh well. Serves 'em right for having an iPhone.

Related/established is not anything to do with the client "marking" anything, it is just the router saying any traffic replying with the ports reversed should be allowed (and in some cases like FTP where the port changes, the router should know that and allow the traffic). The firewall tracks TCP handshake to determine who is the "sender" and "receiver" and as long as the traffic is part of that session allows the replies.

Your first rule takes care of a guest initiating to the trusted server. The replies should be allowed through the "one way to guest" rule.
Your second rule takes care of replies from guest when your trusted server initiates a connection. The original traffic is handled by the "one way to guest" rule. As mentioned below, this rule may not even be needed.
Third rule as you say shouldn't be needed.

Just for hygiene reasons and also to potentially reduce the load on the router (the more specific the rule, in theory the less the router has to analyze) I'd specify both an interface and subnet/ip on both source and destination on all rules. In theory this is a bit more secure too. I guess your conntrack rule probably can just be a couple of interfaces, actually Asus has a default rule that says "all" established traffic is allowed (no interfaces or IPs specified) however I'm not sure where that falls in the heirarchy once you enable yazfi. You might not need that rule at all but you'd have to look at the yazfi rules and see.

My guess is the iphones are automatically converting port 80 to 443, so add 443 to your destination port in addition to 80 and that will probably work (a feature of many browsers these days). If not then might need to load up tcpdump and snoop to see what is going on.

As you say your 3rd rule shouldn't be needed but not hurting anything really.

 

[georgev]

Great point with the hygiene and the load on the router. I didn't know it worked that way, but that makes sense!

That was a no go on the port 443 being the problem, unfortunately. I'll do a tcpdump at some point and report back if I figure this out!

 

[georgev]

After tcpdump, it looks like 443 was involved, but not the entire problem. Even after I allow 443 traffic through, there is still some tcp traffic going to an ephemeral port on the server that I guess isn't considered "related" or "established". What a weird thing to happen only on iPhone... and it's not even browser specific (I've tried on DuckDuckGo, chrome, safari)

 

[drinkingbird]

After tcpdump, it looks like 443 was involved, but not the entire problem. Even after I allow 443 traffic through, there is still some tcp traffic going to an ephemeral port on the server that I guess isn't considered "related" or "established". What a weird thing to happen only on iPhone... and it's not even browser specific (I've tried on DuckDuckGo, chrome, safari)

Definitely odd, if 80 and 443 aren't enough for it to load a site then nothing on the internet would work from an iPhone. Some of the traffic you're seeing is probably just chatter, phone trying to do mDNS or other discovery.

If you're initiating from the iPhone, then there should be no "related" or "established" involved, it is hitting your rule to go from guest to main LAN, and the "one way to guest" (or possibly the router's default established rule) is permitting the return traffic.

Only things that come to mind are to use another device to make sure your server is listening on 443 and serving up the same site via https. Also I'm assuming you're using a self signed cert (get a cert warning on HTTPS) and apple may just outright block that. But neither would explain why it works when you open all ports.

When initiating from the phone, there should be no ephemeral port coming from the server back to the phone, server should always be 443 and phone should always be >1024. If you're seeing the server sourcing from a high port to the phone, then something on your site must be kicking off some other process (not sure what your site is hosting). But even then your one way to guest should allow it in, and your established rule should allow the phone to respond.

I guess at this point just double check the order of your iptables rules and make sure yours are at the very top so there is no risk of conflicting with another rule. Maybe even remove the established rule for now since that shouldn't be needed. Also double check ebtables (the brouting chain), I don't know if yazfi uses that but stock asus does and rules have to be added there too (but again that wouldn't seem to explain why it works when you permit any port).

If you do a verbose output of the iptables FORWARD chain you should be able to see counters increment and see what rules are getting hit (whether they be permit or deny). Sometimes a bit tough when other stuff is going on but if you can disconnect other devices that helps.

Are you accessing the server via hostname or IP? If hostname, it is possible the iphones are using secure DNS which obviously won't know about your server. So try IP in that case.

 

[pjd50]

@drinkingbird Do you know if the new ASUS PRO routers allow VLANs alongside older routers set as AiMesh nodes throughout the house? Would like to create a VLAN for IoT devices (but also have the IoT devices use a pi-hole or AdGuard Home DNS filter that sits on my NAS).

Edit/Update: Not trying to hijack this thread or spam my own thread, but I think it's relevant to the discussion here - I have more details on what I asked above here: https://www.snbforums.com/threads/custom-dns-for-guest-network-possible.88079/#post-881105