Not possible to set static IPs in VLAN (network with different subnet)?

[vmachiel]

Hi,

So: when I setup a GNP, and have it on a different VLAN (52), can I not set static IPs for certain clients? When I go to the LAN setings and DHCP, I see my device in the client list. When I select it, I see its IP (192.168.52.101). But when I try to set it as static, it says it’s not valid…

Is it not possible? Or do I need a plugin or something?

 

[bennor]

See YazDHCP which now supports Guest Network Pro manual IP addresses when one has set Guest Network Pro's Use same subnet as main network to off:

YazDHCP - YazDHCP v1.2.0 [2025-Oct-12] - Feature expansion of DHCP assignments (increasing limit on the number of DHCP reservations)

You could try running the same test scenario under the same or similar conditions using the native WebUI page (i.e. after uninstalling YazDHCP). If you experience the same problem, you could submit a bug report to ASUS, or perhaps @RMerlin might want to take a look. Hi @Martinski, OK, so I...

www.snbforums.com

If not using YazDHCP, one could use the Guest Network Pro Profile's Advanced Setting section Manually assign IP address around the DHCP list option to set manual reservations.

Otherwise, use the forum search feature to find the various past discussions on using the dnsmasq-INDEX.conf.add or dnsmasq-sdn.postconf to set a Guest Network Pro's manual IP reservation. For example, one such past post on using dnsmasq-INDEX.conf.add to set Guest Network Pro reservations:
https://www.snbforums.com/threads/a...-4-is-now-available.94651/page-26#post-958305

It is expected behavior that when Guest Network Pro's Use same subnet as main network is disabled (set to off) one cannot normally (without using YazDHCP) set Guest Network Pro client reservations through the LAN > DHCP Server section.

 

[CaptainSTX]

Hi,

So: when I setup a GNP, and have it on a different VLAN (52), can I not set static IPs for certain clients? When I go to the LAN setings and DHCP, I see my device in the client list. When I select it, I see its IP (192.168.52.101). But when I try to set it as static, it says it’s not valid…

Is it not possible? Or do I need a plugin or something?

If you are running a router with Guest Network Pro you can assign static IPs within a subnet under advanced settings directly using the GUI.

 

[bbunge]

You do not set client static IP's at the router. You set reserved IP's. Static IP addresses are set at the client and the client disregards DHCP.
There is a difference!

 

[CaptainSTX]

You do not set client static IP's at the router. You set reserved IP's. Static IP addresses are set at the client and the client disregards DHCP.
There is a difference!

You are correct however to answer the OPs question succinctly it was simpler to answer their question as written and not provide an explanation and also correct their technical semantics.

 

[jksmurf]

See YazDHCP…

… Guest Network Pro Profile's Advanced Setting section Manually assign IP address around the DHCP list …

… using the dnsmasq-INDEX.conf.add or dnsmasq-sdn.postconf to set a Guest Network Pro's manual IP reservation. …

It is expected behavior that when Guest Network Pro's Use same subnet as main network is disabled (set to off) one cannot normally (without using YazDHCP) set Guest Network Pro client reservations through the LAN > DHCP Server section.

As usual @bennor has nailed all the options for manual assignments (as they are called in the Router’s DHCP menu), although I’d suggest the order (in terms of simplicity) would be:

1. GNP native Manual Assignments (input via GNP, Advanced Settings), noting these are limited to 32 and 32 is not guaranteed) OR
2. Install and configure YazDHCP OR
3. WinSCP (or SSH) into your router and create the files mentioned in the format referred to by @bennor.

Whilst I was using method (3) for a while after coming up short with (1), my personal preference is now (2) YazDHCP due to numbers but also the ability to export, amend and import the manual assignments. Very neat.

On @bennor’s last point I am not sure this is absolutely correct [EDIT; @bennor is indeed correct, see below] as on one of my two independent systems I have reservations for the Main (Primary) Wi-Fi and a GNP Wi-Fi profile (same subnet as Primary) in the native LAN, DHCP, Manually Assigned IP list and I believe that the assignments work across both profiles. In my other network I use YazDHCP but there, the GNP Wi-Fi is on a different subnet.

Whilst I do use static DHCPs on my Shelly IoT devices (apologies to use up all the terminologies in one post…) and noting my IoT network is on the same subnet as the Main (Primary), in the extract below the Samsung Dryer (which does not have a static IP and thus a good example) has a manually assigned IP in the “Primary” manual assignments list under LAN, DHCP and seems to happily show up in the client list as using 192.168.47.110., as assigned.

At the risk of veering away from the OPs query, I’d be curious to understand under what conditions this does not work.

 

[bennor]

At the risk of veering away from the OPs query, I’d be curious to understand under what conditions this does not work.

In my testing with a RT-AX86U Pro running the 3006.102.x firmware, it all boiled down to the Guest Network Pro Profile option Use same subnet as main network and how it is configured when one creates the Guest Network Pro Profile.

• If Use same subnet as main network is enabled (set to on) then a client can have their IP address reserved under the LAN > DHCP Server > Manually Assigned IP addresses in the DHCP scope.
• If Use same subnet as main network is disabled (set to off) then the Guest Network Pro Profile creates a VLAN/SDN and defaults to starting with BR52, ex: subnet 192.168.52.1. When using VLAN the Guest Network Pro client doesn't (at least in my experience) pull the manual IP reservation configured in the LAN > DHCP Server section. Which is logical when you think about it since the client is now using an IP address from the 192.158.52.x pool and not the IP address from the main LAN IP address pool.

Setting aside the new v1.2.0 YazDHCP for the moment. The Guest Network Pro Profile client will, depending on the Use same subnet as main network setting, pull it's reserved IP address from either the main LAN reservation list (DHCP Server page) OR from either the Guest Network Pro Profile Advanced Settings > Manually assign IP address around the DHCP list option (if assigned there), or it will pull it from the dnsmasq-INDEX.conf.add or dnsmasq-sdn.postconf, which ever one is being used and is configured with reservations. One can disconnect the client from the Guest Network Pro Profile and connect it to the main LAN and it should change it's reserved IP to the reserved IP address from the LAN > DHCP Server page. And it should switch back when the client is moved back to the Guest Network Pro Profile. At least in my quick and dirty testing that is what was happening.

Now for YazDHCP v1.2.0 (and later versions). Now that YazDHCP supports Guest Network Pro Profile client reservations (YazDHCP Allow Guest Network Client Assignments enabled, set to Yes), it simplifies making reservations and combines the reservations (main LAN and Guest Network Pro Profile SDN's) to one location, the LAN > DHCP Server > Manually Assigned IP addresses in the DHCP scope section. One can then export and save those reservations and re-import them quickly if one ever resets the router. One can have two reservations configured, one for main LAN the other for Guest Network Pro Profile VLAN and the client will pull either reservation depending on where it's connected.

 

[jksmurf]

If Use same subnet as main network is enabled (set to on) then a client can have their IP address reserved under the LAN > DHCP Server > Manually Assigned IP addresses in the DHCP scope.

It is expected behavior that when Guest Network Pro's Use same subnet as main network is disabled (set to off) one cannot normally (without using YazDHCP) set Guest Network Pro client reservations through the LAN > DHCP Server section.

Ah, I see where I misread your original post (the second extract above), my apologies.

Thank you for clarifying, both posts effectively say the same thing.

 

[bennor]

both posts effectively say the same thing.

Essentially yes, both posts are saying the same thing. It all depends on the Guest Network Pro's Use same subnet as main network setting. At least with the latest version of YazDHCP it simplifies things a bit since you can do all the manual reservation programming for the main LAN clients and the Guest Network Pro Profile clients right on the LAN > DHCP Server > Manually Assigned IP addresses in the DHCP scope section.

 

[vmachiel]

Thanks again everyone. I'll try to get better at searching, but again: I learned a lot from this small discussion

 

[CaptainSTX]

Essentially yes, both posts are saying the same thing. It all depends on the Guest Network Pro's Use same subnet as main network setting. At least with the latest version of YazDHCP it simplifies things a bit since you can do all the manual reservation programming for the main LAN clients and the Guest Network Pro Profile clients right on the LAN > DHCP Server > Manually Assigned IP addresses in the DHCP scope section.

YazDHCP is helpful but it only picks up the first VLAN which by default is the 52. It doesn't pick up the second VLAN on the 53 and save assigned IPs. In my case I run both VLANs to further segregate my devices.

 

[jksmurf]

YazDHCP is helpful but it only picks up the first VLAN which by default is the 52. It doesn't pick up the second VLAN on the 53 and save assigned IPs. In my case I run both VLANs to further segregate my devices.

Hi, are you using the very recently updated v1.2.0? It does main plus multiple Guest Networks and has pretty pastel colours too…

 

[bennor]

It doesn't pick up the second VLAN on the 53 and save assigned IPs.

YazDHCP v1.2.0 release is working for me with two Guest Network Pro Profile VLAN's (52 and 53). Shrugs. From the LAN > DHCP Server page:

 

[CaptainSTX]

YazDHCP v1.2.0 release is working for me with two Guest Network Pro Profile VLAN's (52 and 53). Shrugs. From the LAN DHCP page:
View attachment 68373

I am running the latest version. What I checked is the exported CSV file and it only includes the main range and the 52 range. No 53 devices which means to me if I did a restore I would get main plus the 52s only. Same when I check the DHCP list for some reason the 53s aren't shown. When I check the wireless client list the 53s are there and connected. Both of the 53s are on a 5 Ghz radio. Not sure why I'm not getting the same results as you.

 

[jksmurf]

I am running the latest version. What I checked is the exported CSV file and it only includes the main range and the 52 range. No 53 devices which means to me if I did a restore I would get main plus the 52s only. Same when I check the DHCP list for some reason the 53s aren't shown. When I check the wireless client list the 53s are there and connected. Both of the 53s are on a 5 Ghz radio. Not sure why I'm not getting the same results as you.

Hmm. That’s odd. Two of us have similar (working as intended) experience with the new version.

Here is my DHCP export (corresponding to my example extract above). They match perfectly. I’m not sure what to suggest, apart from an uninstall / reinstall, check your csv file has all the 53 subnet entries and add them manually if needed, reimport.

Presumably you did add these to the DHCP list at some stage after you installed YazDHCP v1.2.0? The 53 subnet devices will appear in the System Log, Wireless Log (when attached to main Router only, not AiMesh nodes) when connected and may even have recognisable names from the devices themselves or from custom_clientlist in /jffs/nvram/ but my guess is the IP addresses are not assigned (unless you are using one of the other methods discussed above, if so then probably best to remove to avoid conflicts)?

 

[bennor]

I am running the latest version. What I checked is the exported CSV file and it only includes the main range and the 52 range. No 53 devices which means to me if I did a restore I would get main plus the 52s only. Same when I check the DHCP list for some reason the 53s aren't shown. When I check the wireless client list the 53s are there and connected. Both of the 53s are on a 5 Ghz radio. Not sure why I'm not getting the same results as you.

CSV export working on my end with YazDHCP v1.2.0. It exports main LAN (192.168.2.x), Guest Network Pro Profile IoT #1 (192.168.52.x) and Guest Network Pro PRofile IoT #2 (192.168.53.x). See example export CSV below.

Make sure to check you have removed any Guest Network Pro manual reservations from the dnsmasq-INDEX.conf.add file and or the dnsmasq-sdn.postconf file. And check that there are no manual reservations in the Guest Network Pro > Advanced Settings > Manually assign IP around the DHCP list.

You may want to check the YazDHCP .staticlist, .staticlist_br5x files to ensure they're properly formatted. Or try uninstalling YazDHCP and reinstall it, to see if that clears your issue. Could be somewhere along the way something got corrupted on your end.

Edit to add: If you are not seeing the BR53 VLAN manually reserved IP addresses on the LAN > DHCP Server > Manually Assigned IP addresses in the DHCP scope section, that likely means they were not entered properly into the correct YazDHCP file (or exported YazDHCP cvs file, then imported into YazDHCP) or were not correctly pulled from the NVRAM. Did you follow all the steps detailed in the YazDHCP v1.2.0 directions? See the following two links, particularly the "note" information in the second link:
https://www.snbforums.com/threads/y...of-dhcp-reservations.94827/page-4#post-971788
https://www.snbforums.com/threads/y...of-dhcp-reservations.94827/page-4#post-971789

 

[CaptainSTX]

CSV export working on my end with YazDHCP v1.2.0. It exports main LAN (192.168.2.x), Guest Network Pro Profile IoT #1 (192.168.52.x) and Guest Network Pro PRofile IoT #2 (192.168.53.x). See example export CSV below.

Make sure to check you have removed any Guest Network Pro manual reservations from the dnsmasq-INDEX.conf.add file and or the dnsmasq-sdn.postconf file. And check that there are no manual reservations in the Guest Network Pro > Advanced Settings > Manually assign IP around the DHCP list.

View attachment 68377

You may want to check the YazDHCP .staticlist, .staticlist_br5x files to ensure they're properly formatted. Or try uninstalling YazDHCP and reinstall it, to see if that clears your issue. Could be somewhere along the way something got corrupted on your end.

Edit to add: If you are not seeing the BR53 VLAN manually reserved IP addresses on the LAN > DHCP Server > Manually Assigned IP addresses in the DHCP scope section, that likely means they were not entered properly into the correct YazDHCP file (or exported YazDHCP cvs file, then imported into YazDHCP) or were not correctly pulled from the NVRAM. Did you follow all the steps detailed in the YazDHCP v1.2.0 directions? See the following two links, particularly the "note" information in the second link:
https://www.snbforums.com/threads/y...of-dhcp-reservations.94827/page-4#post-971788
https://www.snbforums.com/threads/y...of-dhcp-reservations.94827/page-4#post-971789

Both the 52 & 53 were set up using advanced settings. Both the 52 & 53 show up as connected devices and the 53s function as expected. I when I get a chance I will start by removing then reinstalling YazDHCP and see if it fixes the missing 53s. To me the missing 53s is a minor problem as I only have two of them while having over 30 in the main and 52. Thanks for your suggestions.

 

[bennor]

Both the 52 & 53 were set up using advanced settings. Both the 52 & 53 show up as connected devices and the 53s function as expected. I when I get a chance I will start by removing then reinstalling YazDHCP and see if it fixes the missing 53s. To me the missing 53s is a minor problem as I only have two of them while having over 30 in the main and 52. Thanks for your suggestions.

If you use the Guest Network Pro profile's Manually assign IP around the DHCP list option in Guest Network Pro, YazDHCP (v1.2.0) is supposed to pull the NVRAM entries from that Manually assign IP around the DHCP list option. As the directions indicate the user, if they had YazDHCP already installed and then updated it, is supposed to use the "x" option in the YazDHCP CLI to export the NVRAM to YazDHCP. Otherwise when installing YazDHCP for the first time the user should get asked if they want to import the NVRAM to YazDHCP.

One thing to do is check what the NVRAM is storing for the Guest Network Pro profiles if one has used Manually assign IP around the DHCP list option before exporting the NVRAM into YazDHCP. For example if you have two Guest Network Pro profiles you can see what is stored in the NVRAM by issuing the following two commands via SSH on the router.

nvram get dhcpres1_rl
nvram get dhcpres2_rl

 

[CaptainSTX]

If you use the Guest Network Pro profile's Manually assign IP around the DHCP list option in Guest Network Pro, YazDHCP (v1.2.0) is supposed to pull the NVRAM entries from that Manually assign IP around the DHCP list option. As the directions indicate the user, if they had YazDHCP already installed and then updated it, is supposed to use the "x" option in the YazDHCP CLI to export the NVRAM to YazDHCP. Otherwise when installing YazDHCP for the first time the user should get asked if they want to import the NVRAM to YazDHCP.

One thing to do is check what the NVRAM is storing for the Guest Network Pro profiles if one has used Manually assign IP around the DHCP list option before exporting the NVRAM into YazDHCP. For example if you have two Guest Network Pro profiles you can see what is stored in the NVRAM by issuing the following two commands via SSH on the router.

nvram get dhcpres1_rl
nvram get dhcpres2_rl

I will have to some more testing. Removing YazDHCP, rebooting router and then reinstalling YazDHCP didn't magically make the 53s appear. Good suggestions on your part so I will give them a try.

I installed it again and still no 53s. Also when I fun NVRAM get both dhcpress1_r1 and dhcpress2 nothing is returned yet all the assignments are in place and displayed under dhcp leases.

 

[jksmurf]

When I was experimenting with dnsmasq-x.conf.add (one of the approaches mentioned above) I did have a conflict whereby it didn’t work until I deleted the duplicate values in GNP manually assigned IPs first [see EDIT 3].

If this conflict logic applies equally to any pair of the three methods dnsmasq/GNP Manual/YazDHCP, wondering if there’s some legacy assignment entries anywhere (including in /jffs/nvram/dhcp-list which might be holding yours up? Just a thought.