Tutorial LAN port isolation on Asus Merlin example

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

Markster

Senior Member
It would be great if Asus supported VLAN on their routers for all of us that want a quick way to configure LAN ports isolation.
Until that time this is a quick way to use LAN bridge concepts to provide this functionality. I am using Asus RT-AC86U.
I am sharing here my own setup where I have a primary LAN (192.168.50.0/24) and a separate LAN segment (192.168.150.0/24). This separate and isolated segment is for my home Synology NAS with Plex server and main computer. All other devices, smart phones, printer, smart TV's are on main LAN. My NAS runs PLEX as well and Calendar and Contacts data. These NAS services can be accessed externally. I use duckdns.org as my provider. I am going to focus only on configuring LAN bridge here and provide the code. Modify to your own liking and purpose. The example here is based on this article.

In this example I am creating new LAN bridge (br100) with LAN segment 192.168.150.0/24. Default bridge that comes with the router is br0. You can run the command "brctl show" to have a look. Keep in mind that every Asus router may have different designations for LAN ports, so do your own research before modifying the scripts.

The first script you need is to create new bridge with interfaces and new IP segment. In my case I wanted LAN ports 3 and 4 to be part of the new LAN segment 192.168.150.0/24.
You need to add this script in /jffs/scripts/services-start to create the bridge on each startup. In may case both devices (my PC and NAS ) have static IP's so I do not need or want setup DHCP on the new LAN segment.

Code:
#!/bin/sh

# Physical port to interface map for RT-AC86U:
# eth0   WAN
# eth1   LAN 4
# eth2   LAN 3
# eth3   LAN 2
# eth4   LAN 1
# eth5   2.4 GHz Radio
# eth6   5 GHz Radio

# Delete those interfaces that we want to isolate from br0
brctl delif br0 eth1
brctl delif br0 eth2

# Create a new bridge br1 for isolated interfaces
logger -t "br100" "services-start: creating br100 with LAN PORTS 3 & 4 (eth1-2)"
brctl addbr br100
brctl stp br100 on # STP to prevent bridge loops
brctl addif br100 eth1
brctl addif br100 eth2
brctl setfd br100 2 # STP Forward Delay 2 sec (Default: 15 sec)

# Set up the IPv4 address for br100
# Here we set the subnet to be 192.168.150.0/24
logger -t "br100" "services-start: setting up IPv4 address for br100"
ifconfig br100 192.168.150.1 netmask 255.255.255.0
ifconfig br100 up


Next script is to configure the firewall. In my example you can tell that I am allowing traffic to new LAN segment for Synology NAS and Plex.
Here you can add your own rules as required. You need to call this script from /jffs/scripts/firewall-start so it takes effect on every boot.

Code:
#!/bin/sh

# Make sure the script is indeed invoked
logger -t "br100" "firewall-start: applying fw rules for br100"

# Allow new incoming connections from br100
iptables -I INPUT -i br100 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

# Allow br100 access the web UI and SSH of the main router
iptables -I INPUT -i br100 -p tcp --dport 80 -j ACCEPT
iptables -I INPUT -i br100 -p tcp --dport 443 -j ACCEPT
iptables -I INPUT -i br100 -p tcp --dport [YOUR SSH PORT] -j ACCEPT

# Forbid packets from br100 to be forwarded to other interfaces
iptables -I FORWARD -i br100 -j DROP

# But allow packet forwarding inside br100
iptables -I FORWARD -i br100 -o br100 -j ACCEPT

# Allow packet forwarding between br100 and eth0 (WAN)
iptables -I FORWARD -i br100 -o eth0 -j ACCEPT

# Forbid packets from br0 to be forwarded to br100, isolating new br100 from default br0
iptables -I FORWARD -i br0 -o br100 -j DROP

# But allow one-way traffic from br0 to br100 only for restricted ports - Synology NAS and PLEX
iptables -I FORWARD -i br0 -o br100 -p tcp --match multiport --dports 32400,5001 -j ACCEPT
iptables -I FORWARD -i br100 -o br0 -m state --state RELATED,ESTABLISHED -j ACCEPT

# Drop icmp ping requests to br100
iptables -A OUTPUT -d 192.168.150.1/24 -p icmp --icmp-type echo-request -j DROP

Final code is to setup new LAN segment access to internet. Call this script from /jffs/scripts/nat-start

Code:
#!/bin/sh

# Make sure the script is indeed invoked
logger -t "br100" "nat-start: applying POSTROUTING rules for br100"

iptables -t nat -A POSTROUTING -o eth0 -s 192.168.150.0/24 -j MASQUERADE

Hope this will help you get started - happy coding!

As a final note about NAS - this configuration combined with duckdns allows me to use Synology NAS as my personal and private cloud to store Calendar, Contacts, Notes, Photos and Music.
 
Last edited:

Jack Yaz

Part of the Furniture
You mean RT-AC86U, the RT-AX86U has slightly different interfaces.
Its for this reason I've been reluctant to add LAN port isolation into YazFi, I'd need to gather port mappings on all current and update it as future routers come along.

That, and messing with EAP to recognise the additional bridges in nvram might have limitations.
 

Jack Yaz

Part of the Furniture
It would be great if Asus supported VLAN on their routers for all of us that want a quick way to configure LAN ports isolation.
Until that time this is a quick way to use LAN bridge concepts to provide this functionality. I am using Asus RT-86U.
I am sharing here my own setup where I have a primary LAN (192.168.50.0/24) and a separate LAN segment (192.168.150.0/24). This separate and isolated segment is for my home Synology NAS with Plex server and main computer. All other devices, smart phones, printer, smart TV's are on main LAN. My NAS runs PLEX as well and Calendar and Contacts data. These NAS services can be accessed externally. I use duckdns.org as my provider. I am going to focus only on configuring LAN bridge here and provide the code. Modify to your own liking and purpose. The example here is based on this article.

In this example I am creating new LAN bridge (br100) with LAN segment 192.168.150.0/24. Default bridge that comes with the router is br0. You can run the command "brctl show" to have a look.

The first script you need is to create new bridge with interfaces and new IP segment. In my case I wanted LAN ports 3 and 4 to be part of the new LAN segment 192.168.150.0/24.
You need to add this script in /jffs/scripts/services-start to create the bridge on each startup. In may case both devices (my PC and NAS ) have static IP's so I do not need or want setup DHCP on the new LAN segment.

Code:
#!/bin/sh

# Physical port to interface map:
# eth0   WAN
# eth1   LAN 4
# eth2   LAN 3
# eth3   LAN 2
# eth4   LAN 1
# eth5   2.4 GHz Radio
# eth6   5 GHz Radio

# Delete those interfaces that we want to isolate from br0
brctl delif br0 eth1
brctl delif br0 eth2

# Create a new bridge br1 for isolated interfaces
logger -t "br100" "services-start: creating br100 with LAN PORTS 3 & 4 (eth1-2)"
brctl addbr br100
brctl stp br100 on # STP to prevent bridge loops
brctl addif br100 eth1
brctl addif br100 eth2
brctl setfd br100 2 # STP Forward Delay 2 sec (Default: 15 sec)

# Set up the IPv4 address for br100
# Here we set the subnet to be 192.168.150.0/24
logger -t "br100" "services-start: setting up IPv4 address for br100"
ifconfig br100 192.168.150.1 netmask 255.255.255.0
ifconfig br100 up


Next script is to configure the firewall. In my example you can tell that I am allowing traffic to new LAN segment for Synology NAS and Plex.
Here you can add your own rules as required. You need to call this script from /jffs/scripts/firewall-start so it takes effect on every boot.

Code:
#!/bin/sh

# Make sure the script is indeed invoked
logger -t "br100" "firewall-start: applying fw rules for br100"

# Allow new incoming connections from br100
iptables -I INPUT -i br100 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

# Allow br100 access the web UI and SSH of the main router
iptables -I INPUT -i br100 -p tcp --dport 80 -j ACCEPT
iptables -I INPUT -i br100 -p tcp --dport 443 -j ACCEPT
iptables -I INPUT -i br100 -p tcp --dport [YOUR SSH PORT] -j ACCEPT

# Forbid packets from br100 to be forwarded to other interfaces
iptables -I FORWARD -i br100 -j DROP

# But allow packet forwarding inside br100
iptables -I FORWARD -i br100 -o br100 -j ACCEPT

# Allow packet forwarding between br100 and eth0 (WAN)
iptables -I FORWARD -i br100 -o eth0 -j ACCEPT

# Forbid packets from br0 to be forwarded to br100, isolating new br100 from default br0
iptables -I FORWARD -i br0 -o br100 -j DROP

# But allow one-way traffic from br0 to br100 only for restricted ports - Synology NAS and PLEX
iptables -I FORWARD -i br0 -o br100 -p tcp --match multiport --dports 32400,5001 -j ACCEPT
iptables -I FORWARD -i br100 -o br0 -m state --state RELATED,ESTABLISHED -j ACCEPT

# Drop icmp ping requests to br100
iptables -A OUTPUT -d 192.168.150.1/24 -p icmp --icmp-type echo-request -j DROP

Final code is to setup new LAN segment access to internet. Call this script from /jffs/scripts/nat-start

Code:
#!/bin/sh

# Make sure the script is indeed invoked
logger -t "br100" "nat-start: applying POSTROUTING rules for br100"

iptables -t nat -A POSTROUTING -o eth0 -s 192.168.150.0/24 -j MASQUERADE

Hope this will help you get started - happy coding!
Great stuff!
 

Markster

Senior Member
Its for this reason I've been reluctant to add LAN port isolation into YazFi, I'd need to gather port mappings on all current and update it as future routers come along.

That, and messing with EAP to recognise the additional bridges in nvram might have limitations.
This setup does require some knowledge of networking basic and firewall rules. Hence it is not for a beginner.
I understand what you are saying and in honesty anyone with some basic know-how or willingness to learn can configure this functionity on their own. Trying to bundle this into some sort of universal script would be too much.
Just my opinion. This is why I have posted this tutorial so people that want to learn have a good start.
 

maxbraketorque

Very Senior Member
I have a home network setup using two ASUS routers operating as a main-AP combo, and I'm still trying to find a way to isolate the guest networks on the ASUS AP (not in AiMesh mode) from the remainder of my LAN while still having WAN access. If you are not aware, guest networks created on an AP cannot be configured in the factory firmware options to be isolated from the LAN. The AP plugs into one of the ethernet ports on the main router. Is there away that I can use this kind of scripting to isolate the AP guest networks from the LAN while still providing WAN access? Ideally, I'd like to do it without creating a separate subnet.
 

jasonlee

New Around Here
I have managed to created the separated lan , may i ask how to config the DHCP static ip lease on the new subnet ? thanks
 

Markster

Senior Member
If you will have only static IP's on the new LAN you dont need to do anything else. Just assign each client static IP in the new LAN subnet range. For example, if you have configured new segment with "
ifconfig br100 192.168.150.1 netmask 255.255.255.0", just assign clients IP within this IP range. This is all you need.

On the other hand, if you need DHCP for thie new LAN segment add the following code to /jffs/configs/dnsmasq.conf.add and restart dnsmasq.

interface=br100
# DHCPv4 range: 192.168.150.2 - 192.168.150.254, netmask: 255.255.255.0
# DHCPv4 lease time: 86400s (1 day)
dhcp-range=br100,192.168.150.2,192.168.150.254,255.255.255.0,86400s
# DHCPv4 router (option 3): 192.168.150.1
dhcp-option=br100,3,192.168.150.1
 

sbsnb

Very Senior Member
dhcp-option=br100,3,192.168.150.1
Interesting. The router is multi-homed with this arrangement (answering packets to 192.168.50.1 and 192.168.150.1)?
 

Markster

Senior Member
I don't know if you can call it multi-homed, but the two LAN segments share default gateway to WAN.
 

jasonlee

New Around Here
If you will have only static IP's on the new LAN you dont need to do anything else. Just assign each client static IP in the new LAN subnet range. For example, if you have configured new segment with "
ifconfig br100 192.168.150.1 netmask 255.255.255.0", just assign clients IP within this IP range. This is all you need.

On the other hand, if you need DHCP for thie new LAN segment add the following code to /jffs/configs/dnsmasq.conf.add and restart dnsmasq.

interface=br100
# DHCPv4 range: 192.168.150.2 - 192.168.150.254, netmask: 255.255.255.0
# DHCPv4 lease time: 86400s (1 day)
dhcp-range=br100,192.168.150.2,192.168.150.254,255.255.255.0,86400s
# DHCPv4 router (option 3): 192.168.150.1
dhcp-option=br100,3,192.168.150.1
Thanks Markster, maybe I didn't phrase the question properly.
I have the subnet set up, and connected an old AC87U in AP mode, the clients connect to the AP could obtain the 192.168.150.* IP through the dnsmasq.

What I am trying to achieve is manually assign DHCP IP based on the client MAC address inside the 192.168.150.* subnet
like we could do on the router LAN config for the br0 192.168.50.*

Your advice will be highly appreciated.



Update:
appending /jffs/configs/dnsmasq.conf.add

add the following line seems work for me
dhcp-host= macaddress,set:macaddress,192.168.150.* ( * any number in the range)
 
Last edited:

sbsnb

Very Senior Member
I don't know if you can call it multi-homed, but the two LAN segments share default gateway to WAN.
I figured, but that DHCP rule will have one vlan pointing to 192.168.150.1 as the default gateway and I assume br0 will be pointing to 192.168.50.1 as the default gateway. The Asus would have to answer packets addressed to both IPs.
 

Markster

Senior Member
I figured, but that DHCP rule will have one vlan pointing to 192.168.150.1 as the default gateway and I assume br0 will be pointing to 192.168.50.1 as the default gateway. The Asus would have to answer packets addressed to both IPs.

yes and the IP rules must be set up accordingly to route the traffic between these two LAN segments and WAN
 

sbsnb

Very Senior Member
That's unexpected to me. I wouldn't expect the router to be able handle having separate IP addresses depending on the interface like that.
 

dcballers

Occasional Visitor
Hi @Markster , I am trying to isolate a LAN port on my AC86-U (merlin 386.3_2) and after spending a couple hours surfing these forums and the web at-large, I came across this excellent post of yours.

My use case is simpler than yours or others I have seen on these forums. I wish to isolate a single LAN port that will be used by a single device. I'd like that device to use the internet at-will without restrictions, but just not have access to the other devices on my internal network.

I understand your first script and how to modify it to isolate just one port rather than the two in your example. However, given that I don't have any of the other complexities of your use-case, such as remote access or multiple devices in my isolated section, do I need the second and third scripts?

If so, how might I modify those? I am able to SSH into my router and can load scripts there (I did one for iptables) but am not confident enough to modify scripts on my own without fear of bricking something.

Any guidance is much appreciated. Thanks!
 

Markster

Senior Member
"I'd like that device to use the internet at-will without restrictions, but just not have access to the other devices on my internal network."

For the internet access you would need to add this to nat-start script

Code:
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.150.0/24 -j MASQUERADE

In order to block new LAN segment br100 accessing br0 LAN segment you would need set of iptables rules in the firewall-start script.

Code:
# Forbid packets from br100 to be forwarded to other interfaces
iptables -I FORWARD -i br100 -j DROP
# Allow packet forwarding between br100 and eth0 (WAN)
iptables -I FORWARD -i br100 -o eth0 -j ACCEPT
 

eibgrad

Very Senior Member
Might I make a few suggestions.

While using the logger to ensure the script is invoked is good, I think it would be better if the syslog was used to detect any errors too. As currently written, you wouldn't know anything had possibly failed until things just didn't work right.

What would be better is to place the script in a block, and have all the output from the block sent to the syslog.

Code:
#!/bin/sh
{
set -x # uncomment/comment to enable/disable debug mode

# Physical port to interface map for RT-AC86U:
# eth0   WAN
# eth1   LAN 4
# eth2   LAN 3
# eth3   LAN 2
# eth4   LAN 1
# eth5   2.4 GHz Radio
# eth6   5 GHz Radio

# Delete those interfaces that we want to isolate from br0
brctl delif br0 eth1
brctl delif br0 eth2

# Create a new bridge br1 for isolated interfaces
echo "creating br100 with LAN PORTS 3 & 4 (eth1-2)"
brctl addbr br100
brctl stp br100 on # STP to prevent bridge loops
brctl addif br100 eth1
brctl addif br100 eth2
brctl setfd br100 2 # STP Forward Delay 2 sec (Default: 15 sec)

# Set up the IPv4 address for br100
# Here we set the subnet to be 192.168.150.0/24
echo "setting up IPv4 address for br100"
ifconfig br100 192.168.150.1 netmask 255.255.255.0
ifconfig br100 up

} 2>&1 | logger -t $(echo $(basename $0) | grep -Eo '^.{0,23}')[$$]

Now should anything fail w/ an error message, it will appear in the syslog! And if you use the 'set -x' option, it will help you debug it as well.

One of the hardest things to deal w/ when writing/using scripts is not just knowing whether they were executed, but whether they worked correctly or produced errors, particularly during development. Once working, it's still a good idea to have any unexpected errors reported.

To be fair, this isn't unique to your script. I'm just taking this opportunity to point it out as a general recommendation to *all* script developers. It's something I've noticed about many scripts that make use of the logger. It's just a lot more efficient and beneficial to bind the entire block to the logger than individual lines. It also means that you can easily send the entire script to the background and have it run asynchronously using the ampersand (&), if that was appropriate of course.

Code:
...
} 2>&1 | logger -t $(echo $(basename $0) | grep -Eo '^.{0,23}')[$$] &

One other point about the firewall script. The following rules don't make sense.

Code:
# Allow new incoming connections from br100
iptables -I INPUT -i br100 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

# Allow br100 access the web UI and SSH of the main router
iptables -I INPUT -i br100 -p tcp --dport 80 -j ACCEPT
iptables -I INPUT -i br100 -p tcp --dport 443 -j ACCEPT
iptables -I INPUT -i br100 -p tcp --dport [YOUR SSH PORT] -j ACCEPT

What this is saying is that *any* port is accessible on the router's INPUT chain via the br100 network interface due to the NEW,RELATED,ESTABLISHED rule. The other INPUT rules are superfluous.

What makes more sense is the following.

Code:
# Only allow br100 access to the web UI and SSH of the main router
iptables -I INPUT -i br100 -j DROP
iptables -I INPUT -i br100 -p tcp --dport 80 -j ACCEPT
iptables -I INPUT -i br100 -p tcp --dport 443 -j ACCEPT
iptables -I INPUT -i br100 -p tcp --dport [YOUR SSH PORT] -j ACCEPT

# Allow established,related incoming connections from br100
iptables -I INPUT -i br100 -m state --state RELATED,ESTABLISHED -j ACCEPT

Strictly speaking, the RELATED,ESTABLISHED rule could be eliminated, but using it does make things slightly more efficient since established connections don't have to traverse the rest of the INPUT chain.

P.S. I don't think the POSTROUTING rule is necessary either. At least on my RT-AC68U, the router NAT's *anything* over the WAN (vlan2), regardless of the incoming network interface (second rule below).

Code:
Chain POSTROUTING (policy ACCEPT 112 packets, 60268 bytes)
pkts bytes target     prot opt in     out     source               destination       
    4  1528 PUPNP      all  --  *      vlan2   0.0.0.0/0            0.0.0.0/0         
    0     0 MASQUERADE  all  --  *      vlan2  !192.168.63.102       0.0.0.0/0         
1778  156K MASQUERADE  all  --  *      br0     192.168.1.0/24       192.168.1.0/24
 
Last edited:

Similar threads

Sign Up For SNBForums Daily Digest

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