What's new

ASUSWRT 386 new guest network IP space and DHCP static IPs

  • 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!

brentil

Occasional Visitor
We were talking about this in the RT-AC86U 386 firmware but saw people with RT-AC68U devices starting to have the same issue and wanted to pop it out into it's own thread.

There is a new behavior with the 386 firmware that Guest Network 1 uses a different IP space from what you have defined on your main network.

Main Network = 192.168.1.xyz
Guest Network 1 = 192.168.101.xyz (2.4 GHz) and 192.168.102.xyz (5 GHz)

The problem is you can no longer define DHCP static leases for any device on Guest Network 1 in these new IP spaces because the UI says these 192.168.101.xyz and 192.168.102.xyz IP ranges are invalid. If you have DHCP static leases defined they will be ignored in favor of these new IP ranges. If you run an IoT network on Guest Network or have firewall rules based on IP addresses you'll start to have issues.

We did find a workaround though. Guest Network 2 & 3 do not assign new IP spaces to devices and continue to use the main IP space so if you move a guest network to one of those you need DHCP static leases on they'll work again. So for example I moved my IoT network from GN1 to GN2 and the moved my actual guests on my network to GN1 so those exist in the new IP space which actually makes things easier since being in a different class C my firewall rules block them automatically.
 
I believe I have been a 'victim' of this new behavior on my AC68U. I am running my Asus router in AP mode. After the update, clients connecting to guest network 1 weren't able to be assigned an IP address by my main router (an OPNsense box) anymore. Switching from guest network 1 to 2 solved that issue for me.

In my mind this is a bug. If you run the Asus router in AP mode, guest network clients should be served an IP address by the authoritative DHCP server on the network, not by the Asus access point.
 
In my mind this is a bug. If you run the Asus router in AP mode, guest network clients should be served an IP address by the authoritative DHCP server on the network, not by the Asus access point.
The last time I used a guest network (4 years ago) this was already the case. The guest network isolates its client from your local network so they cannot reach your DHCP server. Though I agree that in AP mode there is an issue : the AP must allow clients to use the gateway (on the local network) to go to the Internet, so why not at least the DHCP, I guess this is because the AP cannot route and would not be able to prevent client to access local network unless using different IP (than the main router)
 
We were talking about this in the RT-AC86U 386 firmware but saw people with RT-AC68U devices starting to have the same issue and wanted to pop it out into it's own thread.

There is a new behavior with the 386 firmware that Guest Network 1 uses a different IP space from what you have defined on your main network.

Main Network = 192.168.1.xyz
Guest Network 1 = 192.168.101.xyz (2.4 GHz) and 192.168.102.xyz (5 GHz)

The problem is you can no longer define DHCP static leases for any device on Guest Network 1 in these new IP spaces because the UI says these 192.168.101.xyz and 192.168.102.xyz IP ranges are invalid. If you have DHCP static leases defined they will be ignored in favor of these new IP ranges. If you run an IoT network on Guest Network or have firewall rules based on IP addresses you'll start to have issues.

We did find a workaround though. Guest Network 2 & 3 do not assign new IP spaces to devices and continue to use the main IP space so if you move a guest network to one of those you need DHCP static leases on they'll work again. So for example I moved my IoT network from GN1 to GN2 and the moved my actual guests on my network to GN1 so those exist in the new IP space which actually makes things easier since being in a different class C my firewall rules block them automatically.

I found this also. I could access a client on Guest network 1 from the main network--which I want. However, if I connect the same client to Guest network 2, I cannot access it from the main newtwork.

I wonder what is the intended behavior.
 
I’ve been trying to follow along with this here and in the .386 beta thread and I’m confused a bit. So the guest network #1 is no longer isolated from the rest of the network regardless of whether you’ve allowed that behavior or not via the tickbox setting, yes no. Also, is this behavior only for those using aiMesh or is it behavior for all guest #1 on .386

I experienced some strange behavior on .386 guest network not using aiMesh, but this is really messed up if the guest network is not isolated And you’ve not allowed it specifically in the settings. I mean wtf is the setting there for if it’s gonna be ignored for anyway
 
I wonder who thought this behavior was preferred?
 
I believe I have been a 'victim' of this new behavior on my AC68U. I am running my Asus router in AP mode. After the update, clients connecting to guest network 1 weren't able to be assigned an IP address by my main router (an OPNsense box) anymore. Switching from guest network 1 to 2 solved that issue for me.

In my mind this is a bug. If you run the Asus router in AP mode, guest network clients should be served an IP address by the authoritative DHCP server on the network, not by the Asus access point.
There is no advantage in running a guest wifi in AP mode. Guest networks are to block access to the LAN. Thus using a different subnet for the guest wifi is a good thing not a bug.
 
There is no advantage in running a guest wifi in AP mode. Guest networks are to block access to the LAN. Thus using a different subnet for the guest wifi is a good thing not a bug.

You are correct, hence the reason I setup my ISP cable modem’s 2.4g wifi in isolation mode as my “guest” wifi. It allows internet access but keeps them off my network.
 
I’ve been trying to follow along with this here and in the .386 beta thread and I’m confused a bit. So the guest network #1 is no longer isolated from the rest of the network regardless of whether you’ve allowed that behavior or not via the tickbox setting, yes no. Also, is this behavior only for those using aiMesh or is it behavior for all guest #1 on .386

I experienced some strange behavior on .386 guest network not using aiMesh, but this is really messed up if the guest network is not isolated And you’ve not allowed it specifically in the settings. I mean wtf is the setting there for if it’s gonna be ignored for anyway
My experience is that I cannot access the main network from Guest network 1, but I could acess Guest network 1 from the main network. I could not acces Guest network 2 from the main network.
 
My experience is that I cannot access the main network from Guest network 1, but I could acess Guest network 1 from the main network. I could not acces Guest network 2 from the main network.
I thought that sounded proper, but on 2nd thought, shouldn't main always be able to access guest but not the other way around.

The way I thought guest worked was Guest cannot access intranet unless specifically told yes with the tickbox setting. Asus faq confirms this.
Seems like main should always be allowed to access guest though.

this faq from Sep 2020 clearly needs some work, especially 2 at the bottom where it says devices won’t show in network map GUI if they are on guest. They do and have done so for awhile.
 
Last edited:
...There is a new behavior with the 386 firmware that Guest Network 1 uses a different IP space from what you have defined on your main network.

Main Network = 192.168.1.xyz
Guest Network 1 = 192.168.101.xyz (2.4 GHz) and 192.168.102.xyz (5 GHz)...

Ok, so I upgraded back to:
Version 3.0.0.4.386.40451
2020/10/22 60.01 MBytes

I do not use aiMesh or have any other routers on my single ac86u network.

I then enabled guest #1 on my ac86u.
It does NOT behave as you've stated.
My main network = 192.168.50.xyz
My Guest network 1 = 192.168.50.xyz

No different ip space showing for me.
 
Ok, so I upgraded back to:
Version 3.0.0.4.386.40451
2020/10/22 60.01 MBytes

I do not use aiMesh or have any other routers on my single ac86u network.

I then enabled guest #1 on my ac86u.
It does NOT behave as you've stated.
My main network = 192.168.50.xyz
My Guest network 1 = 192.168.50.xyz

No different ip space showing for me.

Then it will when the next RC2 beta gets released.

OE
 
Ok, so I upgraded back to:
Version 3.0.0.4.386.40451
2020/10/22 60.01 MBytes

I do not use aiMesh or have any other routers on my single ac86u network.

I then enabled guest #1 on my ac86u.
It does NOT behave as you've stated.
My main network = 192.168.50.xyz
My Guest network 1 = 192.168.50.xyz

No different ip space showing for me.
Do you have Access Intranet enabled in your Guest 1 WIFI? If so you will not have the 192.168.101.0/24 or 192.168.102.0/24 subnet.

And yes, the new Guest WIFI subnetting has been implemented and for some of us it is a good thing.
 
Do you have Access Intranet enabled in your Guest 1 WIFI? If so you will not have the 192.168.101.0/24 or 192.168.102.0/24 subnet.

And yes, the new Guest WIFI subnetting has been implemented and for some of us it is a good thing.
Nope, I don't have the access intranet turned on in Guest. It's exactly as I said above and the guest is the same as the main.
 
Interesting thread - I have put my AC88U to AP-mode, and the guest networks are compeltely useless now. I have 2,4 1&2 activated. Not only that bandwith limitations do not work anylonger, no, you can easily access devices in the other networks. From guest and to guest. So for me AP mode and guest networks do not work together at all. The checkbox for "allow intranet access" doesnt even exist ... a warnign at least would be nice. So looking at the development described above I hope they have their own mini dhcp for guest in ap mode with future fw releases, otherwise it is pointless, or they could finally enable VLAN tagging....
 
Interesting thread - I have put my AC88U to AP-mode, and the guest networks are compeltely useless now. I have 2,4 1&2 activated. Not only that bandwith limitations do not work anylonger, no, you can easily access devices in the other networks. From guest and to guest. So for me AP mode and guest networks do not work together at all. The checkbox for "allow intranet access" doesnt even exist ... a warnign at least would be nice. So looking at the development described above I hope they have their own mini dhcp for guest in ap mode with future fw releases, otherwise it is pointless, or they could finally enable VLAN tagging....

Guest WLAN clients in AP Mode never were isolated from LAN/WLAN clients, yes?

OE
 
Guest WLAN clients in AP Mode never were isolated from LAN/WLAN clients, yes?

I dont know, however then it has been a design flaw in my view... I mean I understand the reasoning, however a quick warnign would no tharm.

Anybody ideas how to build this manually in router mode? Like deactivating firewall, dhcp, enable acces from WAN... ?
 
I thought that sounded proper, but on 2nd thought, shouldn't main always be able to access guest but not the other way around.

The way I thought guest worked was Guest cannot access intranet unless specifically told yes with the tickbox setting. Asus faq confirms this.
Seems like main should always be allowed to access guest though.

this faq from Sep 2020 clearly needs some work, especially 2 at the bottom where it says devices won’t show in network map GUI if they are on guest. They do and have done so for awhile.

Interesting. I have 2 nodes with AIMesh enabled. The Guest network is emited from both nodes. I suspect that with multiple nodes, they use a different subnet for Guest LAN #1 and use a VLAN tag on the Guest packets so the non-router node knows the packets are Guest packets. I should also piont out that I have an ethernet backhaul between the nodes, so--in the general case--the router node does not know what happens to the packets before they reach the other node (they could go through switches for eaxample, but do not in my case).
 

Latest threads

Sign Up For SNBForums Daily Digest

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