Solved Guest network isolation changes 384 v 386 / AC68U v AX86U

[pjv]

For the last couple years, I've been running an AC68U with 384.14_2. I just bought a new AX86U and have installed 386.3_2 on it.

I configured everything from scratch / manually on the new AX so as not to push anything wonky from an old backup. Everything worked great except for one thing.

I run an intranet-isolated guest wifi for all of the IOT devices on my network. There is a single host on the main network (running home assistant) that needs to have 2-way access to / from those IOT devices. On the AC68U under 384.14_2, I have a nat-start script that creates two simple ebtables rules that allow this hole to be punched in the isolation to and from the home assistant box:

ebtables -I FORWARD -i wl0.1 -d $MAC1 -j ACCEPT
ebtables -I FORWARD -o wl0.1 -s $MAC1 -j ACCEPT

($MAC1 is the mac address of the home assistant host)

The one thing that didn't work when I set up the AX86U, was that my home assistant box could no longer see the IOT devices. Trying to figure out why, I noticed that all my IOT devices were on a separately numbered network. Some searching here revealed that the first guest network now has a separate subnet for AiMesh reasons, so I moved my IOT guest network to the second guest network and after verifying the interface for the second guest network was wl0.2 and that my IOT devices were now back on the same network numbers as my main network, re-wrote my ebtables script like so:

ebtables -I FORWARD -i wl0.2 -d $MAC1 -j ACCEPT
ebtables -I FORWARD -o wl0.2 -s $MAC1 -j ACCEPT

But that still does not work - i.e. the home assistant box still cannot see or ping the IOT devices on the AX86U like it can on the AC68U.

I don't know whether the issue is the new hardware or the new firmware, but does anyone have any idea why the above ebtables rules would work on the AC68U under 384x but not on the AX86U under 386x?

 

[Jack Yaz]

on 386.x when you disable intranet access Asus use VLANs and a different subnet for the guest interfaces, so you'll need to update your scripts to amend the VLANs.
EDIT: I've just seen you're opting to use GN2 which shouldn't encounter this problem

alternatively, use YazFi which maintains the isolation and put your script as a userscript for YazFi to call after it's done it's bit

EDIT2: are you able to flash 386 on the 68U to verify if this is specific to your AX86U, rather than a f/w issue? there's been a few oddities with the AX86U. you could also try GN3

 

[pjv]

Thank you, Jack.

I installed YazFi on the AX yesterday while I was looking for a quick fix. I seemed to run into a wall there with trying to keep my IOT devices on the same network numbers as my other stuff and be able to use static DHCP assignments for them (which I need to do).

When I tried to specify the same network numbers for the YazFi guest network as my main network, it didn't seem to want to allow that. Is there a way with YazFi to keep a guest network on the same subnet as the main network? And is there a way to let guest network hosts get static DHCP assignments?

I could try flashing the 68U with 386, but I'm a little reluctant to nuke what is my currently working default router. I have a whole household's worth of smart gizmos that has become pretty dependent on everything working correctly. While I was monkeying around with trying to get this working yesterday with Internet access going up and down, lights and thermostats working and not working, etc. over hours, I had some sad family members vocally wondering why I need to fix what wasn't broken and if the new router is an upgrade, why can't I turn on the damn lights?

 

[Jack Yaz]

Thank you, Jack.

I installed YazFi on the AX yesterday while I was looking for a quick fix. I seemed to run into a wall there with trying to keep my IOT devices on the same network numbers as my other stuff and be able to use static DHCP assignments for them (which I need to do).

When I tried to specify the same network numbers for the YazFi guest network as my main network, it didn't seem to want to allow that. Is there a way with YazFi to keep a guest network on the same subnet as the main network? And is there a way to let guest network hosts get static DHCP assignments?

I could try flashing the 68U with 386, but I'm a little reluctant to nuke what is my currently working default router. I have a whole household's worth of smart gizmos that has become pretty dependent on everything working correctly. While I was monkeying around with trying to get this working yesterday with Internet access going up and down, lights and thermostats working and not working, etc. over hours, I had some sad family members vocally wondering why I need to fix what wasn't broken and if the new router is an upgrade, why can't I turn on the damn lights?

YazFi will enforce the use of separate subnets as they provide isolation benefits as well as a "hands-off" approach for an SSID to be redirected to a VPN, for example.
Re. DHCP assignments this is possible as outlined here: https://github.com/jackyaz/YazFi/wi...e-and-ARP-records#a-note-on-dhcp-reservations

Other than DHCP assignment, what other reason(s) do you have for needing the same subnet please? (I may be able to help)

 

[pjv]

Other than DHCP assignment, what other reason(s) do you have for needing the same subnet please? (I may be able to help)

Off the top of my head, I think the DHCP assignment of reserved IPs is the only good reason. (One bad reason is lazily not wanting to have to scan through my entire lengthy set of home assistant config files and re-write all the device IP addresses in them, but I can suck that up).

I do have a specific local domain configured and in addition to referring to some devices by static IP's, the home assistant box does also connect to some of them using hostname.localdomain. If I use the scripted dnsmasq.postconf technique you linked to, will dnsmasq correctly resolve those IOT devices I specify in there?

EDIT: I guess one other reason for using the same subnet is that I really do like how simple and elegant my pair of ebtables rules are that are working on the 68U / 384x. Somehow it seems like dealing with the guest network isolation at the Ethernet frame level is simple and robust. So if nothing else, as a matter of curiosity, I would really like to know why that works on the old router + firmware but not on the new stuff.

 

[john9527]

Just as a double check, are you sure your added ebtables rules aren't getting wiped out by other code changes?
ebtables -L

also, maybe check that they aren't doing something new in the broute table
ebtables -t broute -L

 

[pjv]

Thank you John.

I did verify the ebtables rules were there and I also checked the broute table and it is identical on the AX and the AC.

I also tried inserting an additional BROUTE rule using the IP address of the home assistant box:

ebtables -t broute -I BROUTING -p IPv4 -i wl0.2 --ip-dst 10.111.5.120 -j ACCEPT

...but this is un-needed on the AC and doesn't help on the AX.

[I also made sure that the wireless professional "Set AP Isolated" setting was set to No].

While I was at it, I also diffed all the iptables rules between the AC and the AX and though there were a few differences between them, as far as I could make out, none of those differences seem to have anything at all to do with the guest network isolation.

As far as I can tell, all guest network intranet isolation on the AC+384 and on guest networks 2 and 3 on the AX+386 is accomplished at the frame level by these ebtables BROUTE rules:

Bridge chain: BROUTING, entries: 3, policy: ACCEPT
-p IPv4 -i wl0.2 --ip-dst 10.111.5.1 --ip-proto icmp -j ACCEPT
-p IPv4 -i wl0.2 --ip-dst 10.111.5.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl0.2 --ip-dst 10.111.5.0/24 --ip-proto tcp -j DROP

I can't see anything in the iptables rules that seem to have anything to do with guest network isolation.

Does anyone know if there is anything else going on that has something to do with the guest isolation?

 

[GSpock]

on 386.x when you disable intranet access Asus use VLANs and a different subnet for the guest interfaces, so you'll need to update your scripts to amend the VLANs.
EDIT: I've just seen you're opting to use GN2 which shouldn't encounter this problem

alternatively, use YazFi which maintains the isolation and put your script as a userscript for YazFi to call after it's done it's bit

EDIT2: are you able to flash 386 on the 68U to verify if this is specific to your AX86U, rather than a f/w issue? there's been a few oddities with the AX86U. you could also try GN3

I am trying to achieve the same as OP ; I did a test with those ebtables on GN3 and same thing ... it does not work on my AX86U.

 

[pjv]

I've now tried a lot of variations on the ebtables rules posted above, moving them to various tables and chains and had no good results.

I've also tried inserting various iptables rules on the guess that maybe the ebtables ACCEPT targets might be dumping packets into the iptables tables and there might be something in iptables that is blocking them without it being obvious to my not-super-experienced IP network eyes. Also no luck there.

Does anyone know of any tools that are on the router or can be entware installed on the router that would give me visibility into what might be blocking either ethernet frames or IP packets moving between hosts on the same subnet?

 

[pjv]

I am trying to achieve the same as OP ; I did a test with those ebtables on GN3 and same thing ... it does not work on my AX86U.

GSpock, I'm not sure when my next opportunity will be to monkey with the AX86U, but based on some researching, my next wild flail will be inserting this iptables rule:

iptables -t filter -I PControls -i br0 -o br0 -j ACCEPT

That rule exists on the AC68U but the corresponding rule on the AX86U has a DROP target. Inserting the one above should make the AX the same as the AC with respect to this chain. I have no idea whether that matters or not and also no idea what the potential security implications of changing that rule from ACCEPT to DROP are, but that's what I'll try next.

If that doesn't work, then I will probably re-install YazFi, set up the DHCP reservations per the link that Jack Yaz posted above, and begin the arduous process of editing all the home assistant configs that have hard-coded IP addresses for IOT doodads.

 

[pjv]

The iptables rule in the post above had no effect.

So I went the YazFi route using DHCP reservations with dnsmasq.postconf per the link in Jack’s post above (#4). After re-writing all the home assistant configs that were addressing IOT devices with hard-coded IP addresses to use their new address on the new YazFi guest network subnet, and after configuring a userscript with the custom iptables rules illustrated on the bottom of the YazFi github to make the guest hosts accessible to / from the home assistant box, all is working again (with no more need for custom ebtables rules).

I’m still really curious what changed in the guest network isolation between my old router and new router and what the AX86U / 386.x is doing altogether to maintain the guest network isolation. I tried so many different ebtables rules and iptables rules and none of it worked. When I was trying to ping hosts on the guest network from the home assistant box, I was getting a Destination Host Unreachable error, which makes me think that somehow the router might be blocking arp requests for the guest network. If it is, I couldn’t figure out how it is.

EDIT: Thanks Jack Yaz both for YazFi and also for your assistance above.