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.

eibgrad

Very Senior Member
Thanks, I crossed posts with you here. Didn't see this until I already posted my reply. I'm not sure that I want all of the same traffic rules as him with the remote access and some interactions allowed between the bridges that he describes. I suppose I could try this verbatim as proof of concept, but I would like to limit this to just keeping the br100 without any intranet access.

I understand. But when the OP claims it works as-is, then you decide to change it before proving it to yourself, there's no way to know if it's YOU that broke it w/ your changes. Let's just make sure your client gets an IP assignment w/ DHCP and can access the internet, minimally. THEN worry about tightening it down w/ changes.
 

dcballers

Occasional Visitor
I understand. But when the OP claims it works as-is, then you decide to change it before proving it to yourself, there's no way to know if it's YOU that broke it w/ your changes. Let's just make sure your client gets an IP assignment w/ DHCP and can access the internet, minimally. THEN worry about tightening it down w/ changes.
Excellent point. And correct because I did the firewall script as you posted, unmodified, and now it works! Thank you!!

The device doesn't show up in the Client List of the Network Map tab in the WebUI. Not a big deal, and maybe that's expected, but I find it interesting.

I guess the only parts of the firewall script that concerns me are these. Will try to comment out one at a time and see if it makes any difference.

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
 

dcballers

Occasional Visitor
Follow-up. I tried removing these individually and it broke. Either the isolated LAN lost internet connectivity or non-tunneled devices on the main LAN lost internet connectivity. Anyone know why that would be?

I'm trying to decipher what all these do and the consequences of keeping them https://linux.die.net/man/8/iptables but not making much headway. Can anyone shed some light on these?

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

Thank you!
 

Markster

Senior Member
Follow-up. I tried removing these individually and it broke. Either the isolated LAN lost internet connectivity or non-tunneled devices on the main LAN lost internet connectivity. Anyone know why that would be?

I'm trying to decipher what all these do and the consequences of keeping them https://linux.die.net/man/8/iptables but not making much headway. Can anyone shed some light on these?

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

Thank you!
The last 2 lines allow br100 lan access to router http and https ports. Based on your requirements you don’t need that. The first rule you quoted is to allow new connections from br100 lan segment. You will need that.

I don't know what device you have on new br100 lan, but make sure this device gateway is properly - in example case it is 192.168.150.1, and DNS is set to router IP address (if your router DNS Filter is set to "router").
 
Last edited:

eibgrad

Very Senior Member
@dcballers

Glad you got it working.

What I've posted below is a firewall-start script (which can be pasted into an ssh window) that's probably more appropriate to most users. All it does it allow dhcp, dns, and icmp (ping) to the router. And if you use the public DNS servers I provided in the dnsmasq file (8.8.8.8 and 8.8.4.4), you don't even need to allow dns. I allow ping simply for diagnostic purpose, but that could be eliminated too.

Any device on br100 can configure itself w/ DHCP, access the router's DNS server, ping the router, and access the internet. br100 can't initiate communications w/ other bridges (e.g., br0), but br0 can initiate communications w/ br100, and br100 can reply.

Code:
cat << "EOF" > /jffs/scripts/firewall-start
#!/bin/sh

WAN_IF="$([ $1 ] && echo $1 || echo $(nvram get wan0_ifname))"

# limit br100 to essential router services (dhcp, dns, ping)
iptables -I INPUT -i br100 -j REJECT
iptables -I INPUT -i br100 -p icmp -j ACCEPT
iptables -I INPUT -i br100 -p tcp --dport 53 -j ACCEPT
iptables -I INPUT -i br100 -p udp --dport 53 -j ACCEPT
iptables -I INPUT -i br100 -p udp --dport 67 -j ACCEPT

# limit br100 to wan access
iptables -I FORWARD -i br100 -j REJECT
iptables -I FORWARD -i br100 -o $WAN_IF -j ACCEPT
iptables -I FORWARD -i br100 -m state --state RELATED,ESTABLISHED -j ACCEPT
EOF
chmod +x /jffs/scripts/firewall-start
:

Beware, I had no way to test it. I don't own an RT-AC86U. But at least w/ my RT-AC68U, it didn't generate any syntax errors.

P.S. Sorry. I had to change the script. I just realized the prior one would interfere w/ AiProtection on br0.
 
Last edited:

dcballers

Occasional Visitor
The last 2 lines allow br100 lan access to router http and https ports. Based on your requirements you don’t need that. The first rule you quoted is to allow new connections from br100 lan segment. You will need that.

I don't know what device you have on new br100 lan, but make sure this device gateway is properly - in example case it is 192.168.150.1, and DNS is set to router IP address (if your router DNS Filter is set to "router").
Thanks for your reply here. Maybe this is a term of art I do not understand, but what throws me off is that, "# Allow new incoming connections from br100" sounds to me like, "allow br100 to initiate connections with other things, such as br0". However, I sense that isn't correct?

Not sure I 100% follow the suggestion in your second part because there may be a word missing after "properly", but the device I have on the new br100 lan is a secure gateway with a wifi router on the back of it. I didn't define a static IP for it if that's what you're asking because I did not know the MAC address as the gateway device is new and it's not listed anywhere on it. Instead I enabled DHCP using some code from @eibgrad. What might be the consequences of doing it this way given the explicit call out in /services-start to 192.168.150.1?

The wifi router behind my br100 lan gateway is accessible by 192.168.1.1 in a browser when I am connected to its wifi. When I am on that br100 wifi I can still connect to my main ASUS via 192.168.50.1 in the browser -- perhaps this is because of the http and https port access that your original script provides?

Back on the main br0 wifi, neither 192.168.150.1 nor 192.168.1.1 take me anywhere in the browser, nor a few other random 192.168.150.x. If I understand correctly, I think this is by design in your original script, the exception being a couple of specific ports that you allowed.

I really appreciate this tutorial you started!
 

dcballers

Occasional Visitor
@dcballers

Glad you got it working.

What I've posted below is a firewall-start script (which can be pasted into an ssh window) that's probably more appropriate to most users. All it does it allow dhcp, dns, and icmp (ping) to the router. And if you use the public DNS servers I provided in the dnsmasq file (8.8.8.8 and 8.8.4.4), you don't even need to allow dns. I allow ping simply for diagnostic purpose, but that could be eliminated too.

Any device on br100 can configure itself w/ DHCP, access the router's DNS server, ping the router, and access the internet. br100 can't initiate communications w/ other bridges (e.g., br0), but br0 can initiate communications w/ br100, and br100 can reply.

Code:
cat << "EOF" > /jffs/scripts/firewall-start
#!/bin/sh

WAN_IP="$([ $1 ] && echo $1 || echo $(nvram get wan0_ifname))"

# limit br100 to essential router services (dhcp, dns, ping)
iptables -I INPUT -i br100 -j REJECT
iptables -I INPUT -i br100 -p icmp -j ACCEPT
iptables -I INPUT -i br100 -p tcp --dport 53 -j ACCEPT
iptables -I INPUT -i br100 -p udp --dport 53 -j ACCEPT
iptables -I INPUT -i br100 -p tcp --dport 67 -j ACCEPT

# limit br100 to wan access
iptables -I FORWARD -i br100 -j REJECT
iptables -I FORWARD -i br100 -o $WAN_IP -j ACCEPT
iptables -I FORWARD -i br100 -m state --state RELATED,ESTABLISHED -j ACCEPT
EOF
chmod +x /jffs/scripts/firewall-start
:

Beware, I had no way to test it. I don't own an RT-AC86U. But at least w/ my RT-AC68U, it didn't generate any syntax errors.

P.S. Sorry. I had to change the script. I just realized the prior one would interfere w/ AiProtection on br0.
Thanks for this! I like those access rules that you described - sounds like just what I'm looking for. I will give it a try over the weekend.
 

Markster

Senior Member
Thanks for your reply here. Maybe this is a term of art I do not understand, but what throws me off is that, "# Allow new incoming connections from br100" sounds to me like, "allow br100 to initiate connections with other things, such as br0". However, I sense that isn't correct?

Not sure I 100% follow the suggestion in your second part because there may be a word missing after "properly", but the device I have on the new br100 lan is a secure gateway with a wifi router on the back of it. I didn't define a static IP for it if that's what you're asking because I did not know the MAC address as the gateway device is new and it's not listed anywhere on it. Instead I enabled DHCP using some code from @eibgrad. What might be the consequences of doing it this way given the explicit call out in /services-start to 192.168.150.1?

The wifi router behind my br100 lan gateway is accessible by 192.168.1.1 in a browser when I am connected to its wifi. When I am on that br100 wifi I can still connect to my main ASUS via 192.168.50.1 in the browser -- perhaps this is because of the http and https port access that your original script provides?

Back on the main br0 wifi, neither 192.168.150.1 nor 192.168.1.1 take me anywhere in the browser, nor a few other random 192.168.150.x. If I understand correctly, I think this is by design in your original script, the exception being a couple of specific ports that you allowed.

I really appreciate this tutorial you started!
I am glad you have it working.
 

ColinTaylor

Part of the Furniture
Colin, could you say how the AX86U differs, please? I’ve searched but can see how to get this info.
The radio interfaces on the AX86U are eth6 and eth7 rather than the AC86U's eth5 and eth6. There may be other differences, I haven't paid much attention to the VLAN discussions.
 

Spud

Occasional Visitor
The radio interfaces on the AX86U are eth6 and eth7 rather than the AC86U's eth5 and eth6. There may be other differences, I haven't paid much attention to the VLAN discussions.
Thanks, sounds as if the wireless interfaces have been bumped up a number due to the extra 2.5g LAN port.
 

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