Tutorial Adding IP Networks to the ASUS RT-AC68U (et al.)


Part of the Furniture

The following script adds support for the creation of additional IP networks for the ASUS RT-AC68U running Asuswrt-Merlin firmware.

The impetus for the script came from another forum member. The original intent was to simply add a single VLAN to the router. However, it became apparent it was just as easy to add multiple VLANs. Then I realized I could probably use the physical APs and guest VAPs and bridge them to the new VLANs without much additional effort.

As with anything involving low-level networking, it can get rather complicated. And I've made a concerted effort to make it as simple as possible to create additional IP networks (wired and/or wireless) as needed.

Being hardware dependent, and only having access to the RT-AC68U at the moment, I can only guarantee the script works w/ that router. But I suspect other AC routers w/ similar specs would probably work as well. I just have no way of confirming it.

How It Works

The key variables are VLANS_PORTS and VLANS_WL. The former configures ports for both existing VLANs (typically only the LAN (vlan1)) and new VLANs w/ zero or more ports. Optionally, using the latter, you can bridge one or more existing wireless network interfaces to those same VLANS.

In short, you can reconfigure existing ports and wireless APs/VAPs w/ existing or new VLANs in any way you see fit.

I provide several examples, w/ the default being the simplest (and only as a demonstration, not because it's necessarily practical); one new VLAN (3) w/ one port (4), bridged to the 5GHz radio.

Each new VLAN and its associated APs/VAPs (if any) defines a new and unique IP network. By default, that IP network is based on the private network, w/ the third octet replaced by the VID (VLAN ID) (e.g., assuming for the private network, and the creation of VLAN 3, the new IP network becomes

By default, a DHCP server and appropriate firewall are created for each new IP network. By default, *total* isolation is enforced among all local networks. The only available network interface for routing is the WAN. Access from the private network, or to/from any of the OpenVPN clients/servers is denied by default (although those capabilities can be easily enabled). Clients are restricted to DHCP, DNS, and ICMP (ping) from the router. Even DNS access from the router is denied if you choose to configure only public DNS servers (the default).

Of course, any script that automates the generation of many network configurations makes customization difficult. I struggled w/ how to allow *reasonable* customization w/o making the script overly complicated. My primary goal was to tighten down access between IP networks as much as possible, but offering various means to open it up. That comes in the form of program switches, direct customization of DNSMasq (e.g., static leases), and the firewall, both globally and on a per-network basis. In all these areas, I provide numerous examples of what is possible. If you so prefer, you can choose NOT to have a DHCP server and/or firewall pre-configured, but build your own solution instead.


As w/ any script of this complexity, I strongly recommend you first make a backup of your current config! And should you need to restore it for any reason, I recommend you first set the router to factory defaults.

For immediate execution (accepting all defaults) ...

curl -kLs pastebin.com/raw/hvHHic1V | tr -d '\r' | sh

Alternatively, to download the script and make changes ...

curl -kLs pastebin.com/raw/hvHHic1V | tr -d '\r' > $installer
chmod +x $installer
nano $installer

Then execute the script for installation.


Finally, reboot.

If you chose the default configuration, you'll find that LAN port 4 and the 5GHz AP are now bound to the network. And you will only have internet access via the WAN (if you have an active OpenVPN client, it will NOT be accessible from the new IP network).

As you might expect, some things within the GUI are NOT compatible w/ these changes. A good example is static leases. I can imagine other things won't work either (Parental Controls, QoS, bandwidth limiting, etc.). Many times these features are bound to the private network's interface (br0). Other times, the system is non-specific and things work just fine (e.g., port forwarding, the OpenVPN clients (including the VPN Director) and servers). And other third party scripts? I haven't a clue. I don't use all the features/AddOns the router has to offer, so you'll just have to experiment. If adjustments can be made to produce better integration, I'm certainly willing to consider it. But the goal was to solve the problem of adding something modest like an IOT network, NOT to make a wholesale replacement in how the router functions.

To remove the script and return the router to normal operations (or if you need to reinstall; the script will NOT overwrite existing files, even its own) ...

rm -f /jffs/configs/dnsmasq.conf.add
rm -f /jffs/scripts/firewall-start
rm -f /jffs/scripts/service-event-end
rm -f /jffs/scripts/services-start

Guest Networks

As I always say when it comes to guest #1, I recommend you avoid it, even though it does work w/ the script. If anything is going to cause issues, that's it, due to the changes ASUS made for the sake of AiMesh. And that's even under normal circumstances. For example, unless I enable intranet access for guest #1, I normally can't gain access. The router reports an "incorrect password" (at least on my iPhone) because it creates the and networks on guest #1 for the benefit of AiMesh, and blocks access on that basis alone. Knowing it can't/won't protect the private network, it denies me access.

All these guest #1 issues aside, you can assign the physical APs (2.4GHz or 5GHz) or any of the guest networks (VAPs, 2.4GHz or 5GHz) to any networks (including the private network via vlan1).

  • It's likely the script will work w/ other routers (esp. AC, but probably NOT AX), but I have no means to test anything other than my ASUS RT-AC68U, so currently it's the only "officially" supported router. Of course, I'm willing to make reasonable modifications to support other routers, and maintain a compatibility list for anyone reporting success w/ same.
  • Both routed and bridged configurations are supported (e.g., AP mode). But realize that bridged configurations are necessarily problematic. There's no way to control/block the switch on a reboot, so clients will temporarily have access to the private network until the new IP networks can be established.
  • There is only minimal validation within the script. If you attempt to do something patently wrong (e.g., create the same VLAN more than once, assign a non-existent AP/VAP to a non-existent VLAN), it will be caught. But it's NOT as if the script tries to determine whether your changes are rational or will produce the desired effect.
  • I recommend you keep intranet access enabled on any guest networks you assign to these new IP networks, esp. guest #1. If you don't, then the ethernet firewall rules (ebtables) will still be in effect, complicating access control. Everything is manageable via the IP firewall anyway, making the ethernet firewall superfluous. You're also more likely to avoid issues w/ "incorrect password" as I described above.
  • vlan1 (LAN) and vlan2 (WAN) already exist, so obviously you can only create new VLANs starting w/ VID=3, and up to VID=255. vlan1 can be modified, but any attempt to modify vlan2 will report a warning message and otherwise be ignored.
  • BE CAREFUL: It's possible to lock yourself out of the router for administrative purposes w/ certain configurations!


I can't possibly be comprehensive in my testing. At least not in the short term. I'd be interested in knowing what other routers work with it. I could then update the compatibility list. I know I've only provided scant information. But this forum limits what I can offer in a single post. I'll follow up w/ more details. And if I get enough recurring questions, I'll probably post a separate FAQ.

Final Thoughts

Despite this script, it always been (and always will be) my recommendation that you use additional hardware to work around the lack of networking features made available by these types of scripts, as I detail in the following link.

Yes, I'm advocating that most ppl do NOT use this script! I'm only providing it because a) I had written it for someone else anyway, and b) despite my recommendation to do otherwise, there will always be individuals for whom anything less than having their one router solves all problems is unthinkable (and you know who you are ;) ). So this is my contribution to those w/ that mindset.


Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

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