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

eibgrad

Part of the Furniture
Overview

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 192.168.1.0/24 for the private network, and the creation of VLAN 3, the new IP network becomes 192.168.3.0/24).

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.

Installation

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) ...

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

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

Bash:
installer=/tmp/tmpfile.$$.sh
curl -kLs pastebin.com/raw/hvHHic1V | tr -d '\r' > $installer
chmod +x $installer
nano $installer

Then execute the script for installation.

Bash:
$installer

Finally, reboot.

If you chose the default configuration, you'll find that LAN port 4 and the 5GHz AP are now bound to the 192.168.3.0/24 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) ...

Bash:
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 192.168.101.0/24 and 192.168.102.0/24 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).

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

Feedback

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.

Enjoy!
 

eibgrad

Part of the Furniture
UPDATE: v2.0.0 is now available.

In my continuing quest to revamp my scripts for the purposes of better file management, I've updated the script in several ways.


You can use the following command to download and install it using my new installer.

Code:
curl -kLs bit.ly/merlin-installer|tr -d '\r'|sh -s hvHHic1V

It will create nine (9) files (yeah, count 'em, nine)

Code:
/jffs/configs/merlin-ac68u-add-networks.options
/jffs/scripts/merlin-ac68u-add-networks.dnsmasq
/jffs/scripts/merlin-ac68u-add-networks.firewall
/jffs/scripts/merlin-ac68u-add-networks.service-event-end
/jffs/scripts/merlin-ac68u-add-networks.services-start
/jffs/scripts/dnsmasq.postconf
/jffs/scripts/firewall-start
/jffs/scripts/service-event-end
/jffs/scripts/services-start

As an aside, two (2) of those files (*.services-start) wouldn't even be necessary but for the sake of a bug (?) in the event handler that refuses to send a notification on bootup for the "wireless start" event. Really annoying. I had to trigger it myself using the services-start script. It has to be bug since any subsequent restart of wireless *does* produce a corresponding event notification. Other script developers, beware!

I've been updating all my scripts to make it easier to resolve conflicts when other scripts (whether from me or others) need to use the same event scripts. I was previously burying the meat and potatoes of my scripts in the event scripts, making that process too difficult. Now the meat and potatoes are kept in my own files, and the Merlin user scripts are just shells that call my scripts. So even though there are more files (sometimes a lot more), it's a good thing in the long run.

For the purposes of changing options, you just need to concern yourself w/ the *.options file.

If you need to uninstall it, just delete those same files.

Code:
rm -f /jffs/configs/merlin-ac68u-add-networks.options
rm -f /jffs/scripts/merlin-ac68u-add-networks.dnsmasq
rm -f /jffs/scripts/merlin-ac68u-add-networks.firewall
rm -f /jffs/scripts/merlin-ac68u-add-networks.service-event-end
rm -f /jffs/scripts/merlin-ac68u-add-networks.services-start
rm -f /jffs/scripts/dnsmasq.postconf
rm -f /jffs/scripts/firewall-start
rm -f /jffs/scripts/service-event-end
rm -f /jffs/scripts/services-start
:

So what's changed beyond that?

- I removed support for bridged configurations (e.g., AP mode). ONLY a routed configuration is now supported. The former proved impractical for several reasons. First, I had no access to the primary router for configuring DHCP for the new IP network(s). And second, dealing w/ the firewall was problematic since the router disables it, leaving those IP networks vulnerable for a brief period on reboot. Even if I managed the firewall entirely by myself, I could never completely eliminate that period of vulnerability. Given those issues, it just made sense to eliminate bridged configurations.

Note: The prior version actually had a bug that would, given specific conditions, mistakenly believe the router was in a bridged configuration, when in fact it was NOT. Had I continued to support bridged configurations, I would have obviously fixed it. But that became irrelevant w/ the removal of support for bridged configurations. But just in case anyone was affected by that bug, know this latest version obviously corrects it.

- Debugging mode is now OFF in all my scripts (it used to be a mix of ON and OFF). I tended to leave it ON assuming more ppl would have problems, but that's proven a rarity. And unless you're having problems, leaving it ON just fouls the syslog. If you ever need/or want to enable debugging mode, the easiest way is to pass the --debug option w/ the installer.

Code:
curl -kLs bit.ly/merlin-installer|tr -d '\r'|sh -s -- --debug hvHHic1V

The other option is to download the file w/ the --noexec option, and use the nano editor to uncomment the DEBUG variable at the top of the script.

Code:
script=/tmp/tmpfile.$$.sh
curl -kLs bit.ly/merlin-installer|tr -d '\r'|sh -s hvHHic1V > $script
chmod +x $script
nano $script
:

Finally, execute it.

Code:
$script

Note as well that in debugging mode, besides the normal writing to the syslog, the script also writes *many* log files to the /tmp directory, for diagnostic purposes. Those (along w/ the syslog) may prove useful to you or me, should problems arise. I may ask you to tar them up and PM them to me.

Code:
ssh [email protected] << 'EOF'
cd /tmp
tar cvzf /tmp/logfiles.tgz merlin-ac68u-add-networks.*.log syslog.log*
EOF
scp [email protected]:/tmp/logfiles.tgz .

The following are not so much changes, but clarification on several issues (I may have mentioned some of them previously, but still worth repeating).

- Although written specifically for the RT-AC68U, the script is likely compatible w/ similar AC routers. If you determine that to be the case, and let me know, I'll add that information to the script.

- Technically, the dnsmasq and firewall scripts are optional (see the *.options file). So if you prefer to manage your own DHCP/DNS and firewall changes for some reason, you can do so. For reasons of practicality, I had to make many assumptions about what would be the best defaults for these services, if only to minimize the complexity and need for changes. But you may disagree w/ those defaults and have your own preferences.

- Speaking of which, the default firewall rules always deny access between bridges and limit access by the bridge to essential router services, specifically dhcp, dns, and icmp/ping (for diagnostic purposes). IOW, by default, I lock down access as much as possible and practical. YOU have to choose to open things up.

- It is possible to customize DNSMasq and the firewall using the *.option file. I provide numerous examples. To be honest, I found this one of the more challenging features to offer w/o creating more confusion (I had considered removing it as well). Let's face it, none of this is easy. But I wanted to at least make the attempt.

- The default installation creates a new bridge (br3) w/ lan port 4 and the 5GHz radio. It's only meant to demonstrate how you might use it, and more importantly, should work immediately upon installation.

- Any changes by the script are normally NOT persistent across a reboot. To return the router to normal, simply delete the installation files and reboot. However, it's always possible something *else* in the system has unexpectedly issued an nvram commit. In that rare event, you can uncomment the line "for cleanup purposes only" in the *.options file, then save and reboot. The script understands that to be a signal to clean up its own changes and return things to normal (and w/ its own nvram commit).

Enjoy!
 

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