LAN port isolation

[Deleted member 62525]

I used this very good article (full credit goes to the author) to isolate my LAN port 4 (eth1) on RT-AC86U with some success. I wanted to have main computer on separate segment and the rest of the devices on main router segment. It is working fairly well allowing access to internet, my Synology , router etc, except for the fact that when I let the computer sleep for a while the connection to internet or the network for that matter is lost. Ping or dig does not work. It takes about 10 seconds to regain the connection.

Here are my iptables rules for new bridge br100.

# Allow new incoming connections from br100 to router
iptables -I INPUT -i br100 -m state --state NEW -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 access to Synology between VLAN's - PMS
iptables -I FORWARD -i br100 -p tcp --match multiport -d 192.168.50.10 --dports 31200 -j ACCEPT
# Allow packet forwarding between br100 and eth0 (WAN)
iptables -I FORWARD -i br100 -o eth0 -j ACCEPT
# Allow one-way traffic from br0 to br100
iptables -I FORWARD -i br0 -o br100 -j ACCEPT
iptables -I FORWARD -i br100 -o br0 -m state --state RELATED,ESTABLISHED -j ACCEPT

# NAT inside 192.168.150.0/24 on br100
iptables -t nat -A POSTROUTING -s 192.168.150.0/24 -d 192.168.150.0/24 -o br100 -j MASQUERADE

Am I missing any rules that would resolve this connection issues?
Once all is working I can be using internet and access Synology apps without issues. When I lock the computer, and come back in few minutes the connection is lost and it take a while to re-establish.

 

[eibgrad]

On the face of it, I suspect the issue of this new bridge and its configuration is a red herring. The problem as described just feels like something unrelated, but it's always difficult to know for sure. I just don't see how the suggested rules could somehow play a role, but I find it's best to minimize the number of rules when possible. It just lessens the chances for errors.

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

I suppose that rule would make sense if that bridge (br100) was bound to *multiple* IP networks. But presumably that's not the case. So while it does no harm, it seems unnecessary. Not unless you're expecting NAT loopback to work within this bridge. That's the reason you typically see the same rule for the default private network (br0). When the user references the WAN ip inside of the local network to trigger the port forward, that's the rare instance that results in a br0<->br0 routing. But if you're not using multiple IP networks w/ br100, or expecting to port forward to it and use NAT loopback, it's just superfluous.

# NAT inside 192.168.150.0/24 on br100
iptables -t nat -A POSTROUTING -s 192.168.150.0/24 -d 192.168.150.0/24 -o br100 -j MASQUERADE

Here again, normally this would make no sense. These devices on the same IP network communicate directly, via ethernet. As such, no routing is involved, so NAT will never take place. NOT unless we're talking about NAT loopback again. This effectively creates a matching SNAT for the DNAT of the port forward.

Let's just say that for some users (perhaps most), some of these rules may be overkill. But I suppose the author was trying to be thorough.

I want to stress, it's not that I see an obvious connection between these rules and your present problems. However, as a rule (no pun intended), I'm NOT a fan of manipulating bridges from scripting, since it occurs outside the scope of the GUI. And that *might* lead to compatibility issues if somehow the GUI has expectations about the underlying infrastructure that are now incorrect. It just makes me uncomfortable.

So while I can't draw a direct correlation at this time, this kind of stuff always gives me concerns. It's one of the reasons I refuse to manipulate VLANs, bridges, etc., except when directly supported in the GUI, if only to keep the GUI and those changes coordinated. It's why I sometimes use FT (FreshTomato) rather than Merlin, given the former supports this stuff natively, in the GUI. But of course, you then lose access to the other great features of Merlin.

As I often say, every firmware has its pluses and minuses, and this issue of VLANs and additional bridges w/ Merlin is one of the few minuses. Of course, the developer rightfully doesn't see it this way, since by design, it was never his intent to support it. But once you start delving into this area in particular, I can imagine strange things perhaps happening.

 

[Deleted member 62525]

Thank you @eibgrad for the comment and analysis. Appreciate it.

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

My intention later is to have LAN1 and LAN2 in the same bridge br100 so my main laptop and Synology server reside in a separate network segment - 192.168.150.0/24. While the rest of IoT devices will be on the main 192.168.50.0/24 segment. Creating the new bridge with brctl command is actually very easy done.

Isolating these 2 LAN's is my goal and so far I was able to do that, except for that wait time mentioned in my first post. I cannot seem to nail it down and determine what the problem is, but I do have a strong feeling that it has do to with the rules.

Your second comment is valid. I have replaced it with the following.

# NAT inside 192.168.150.0/24 on br100
iptables -t nat -I POSTROUTING -o eth0 -s 192.168.150.0/24 -j MASQUERADE

 

[eibgrad]

Given how brief the hesitation is (10 secs?), I wonder if it's a DHCP server response issue. Seems to me that would be more likely the problem than the firewall rules (w/ those, they're either there and working, or NOT).

So try configuring TCP/IP on the client *statically* rather than using DHCP and see if that hesitation now disappears.

 

[Deleted member 62525]

Yes. That is exactly what I have tried doing. Even with static IP on the client it still is the same. This is why I was thinking that maybe my rules have something to do with it. Post wake up on the client I have to wait around 10 sec to get the connection. Then all is good and working.

 

[eibgrad]

And if you are NOT using that bridge, but just the normal private network, that same client shows no such problems? It just (re)connects instantly?

 

[Deleted member 62525]

Yes

And if you are NOT using that bridge, but just the normal private network, that same client shows no such problems? It just (re)connects instantly?

that’s true.

 

[Deleted member 62525]

Here is the code I use to create the bridge br100.

#!/bin/sh

brctl delif br0 eth1
brctl addbr br100
brctl stp br100 on # STP to prevent bridge loops
brctl addif br100 eth1

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

 

[eibgrad]

Quite honestly, I'm at loss at this point. Everything *looks* correct. But as I said, I've never been comfortable w/ managing VLANs and bridges behind the GUI's back, regardless which third-party firmware. You just never know what kind of funky behavior may result.

The good news is at least it works, and while an annoyance, I can't say 10 secs of hesitation from a just woken PC is intolerable (many times other things on the PC are slow to recover as well). In fact, sleep is often problematic, esp. on Linux (my daily driver). I just don't bother anymore.

 

[Deleted member 62525]

Just now I was able to find the FIX!! It was STP related.

When I compared br0 to br100 using command brctl showstp br0 | br100 I have noticed that br0 "forward delay" was set to 2 seconds and on br100 it was 15 seconds. That was my delay. Issue "brctl setfd br100 2" and problem is fixed.

Final 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
logger -t "isolate_port" "services-start: deleting LAN 4 (eth1) from br0"
brctl delif br0 eth1

# Create a new bridge br1 for isolated interfaces
logger -t "isolate_port" "services-start: creating br1 with LAN 4 (eth1)"
brctl addbr br100
brctl stp br100 on # STP to prevent bridge loops
brctl addif br100 eth1
# Set Forward Delay STP to 2 seconds
brctl setfd br100 2

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

logger -t "isolate_port" "services-start: all done"

 

[eibgrad]

Awesome job, makes sense now!

 

[Deleted member 62525]

In order to continue this network isolation I moved my main Mac and Synology to new segment -> 192.168.150.0/24. Communication between these two is working as intended. Synology runs my Plex, WebDAV and CardDev services. Internet access from this segment is working as designed and Plex remote access is fine.
I can access all Synology services from my local Mac since it is located on the same network segment.

I configured the router (RT-AC86U) WAN -> Virtual Ports/Forwarding to include ports for Plex,WebDAV and CardDEV to forward to Synology IP on the new segment. When creating these entries I left source address blank since I am assuming this means any IP address (remote or local). This allows me to access these services remotely, when I am no on the local home WiFi.

However, one problem I have with this config and nat filter rules is that when using my iOS device on local WiFi, I am unable to access Synology services from iOS devices. Synology server has a static IP of 192.168.150.10.

I tried the following code without a success

iptables -t nat -A PREROUTING -i br0 -p tcp --dport 5006 -j DNAT --to-destination 192.168.150.10
iptables -A FORWARD -i br0 -p tcp -d 192.168.150.10 --dport 5006 -j ACCEPT

It seems that br0 is not forwarding the traffic to br100.

br0 -> 192.168.50.0/24
br100 -> 192.168.150.0/24

I am not an expert on net filter and if somebody has any suggestions I would appreciate it.

Long story short I found that Synology interface configuration was wrongly setup and gateway was set to br0 instead of br100 interface. Once corrected everything works like a charm!!
Nothing wrong with current nat config and iptables rules.

 

[gavcol]

Just now I was able to find the FIX!! It was STP related.

When I compared br0 to br100 using command brctl showstp br0 | br100 I have noticed that br0 "forward delay" was set to 2 seconds and on br100 it was 15 seconds. That was my delay. Issue "brctl setfd br100 2" and problem is fixed.

Final 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
logger -t "isolate_port" "services-start: deleting LAN 4 (eth1) from br0"
brctl delif br0 eth1

# Create a new bridge br1 for isolated interfaces
logger -t "isolate_port" "services-start: creating br1 with LAN 4 (eth1)"
brctl addbr br100
brctl stp br100 on # STP to prevent bridge loops
brctl addif br100 eth1
# Set Forward Delay STP to 2 seconds
brctl setfd br100 2

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

logger -t "isolate_port" "services-start: all done"

Awesome. Sounds like you've done almost exactly what I want to do although with the difference that I will keep all home devices, PC, laptops, Phones, Synology Nas etc on the main br0 -> 192.168.50.0/24 segment and would like to isolate port 4 for a number of IoT devices on br100 -> 192.168.150.0/24. (on an RT-AC5300)

I have manual assignments of IPs to every device on my network, so will this also work for the br100 segment if I manually specify the IP address for each device connecting to this new segment ?
or.... if I attach a spare old rt-n66u router to port 4 then let it handle dhcp on the new segment ?

and is the "final code" snippet above, still the final code or have you made some mods to it ?

Thx in advance
Gav

 

[Deleted member 62525]

Awesome. Sounds like you've done almost exactly what I want to do although with the difference that I will keep all home devices, PC, laptops, Phones, Synology Nas etc on the main br0 -> 192.168.50.0/24 segment and would like to isolate port 4 for a number of IoT devices on br100 -> 192.168.150.0/24. (on an RT-AC5300)

I have manual assignments of IPs to every device on my network, so will this also work for the br100 segment if I manually specify the IP address for each device connecting to this new segment ?
or.... if I attach a spare old rt-n66u router to port 4 then let it handle dhcp on the new segment ?

and is the "final code" snippet above, still the final code or have you made some mods to it ?

Thx in advance
Gav

In my case br100 (port 3 and 4) has 2 devices connected. NAS and my main laptop PC. Both have static IP's assigned. I don't use DHCP with br100 segment since only two devices are connected.

But, nothing is stopping you to use DHCP on br100 and still assign static IP's. That also would work.

 

[gavcol]

In my case br100 (port 3 and 4) has 2 devices connected. NAS and my main laptop PC. Both have static IP's assigned. I don't use DHCP with br100 segment since only two devices are connected.

But, nothing is stopping you to use DHCP on br100 and still assign static IP's. That also would work.

Thanks Markster. I've finished a whole heap of reading in the past day or so and I'm not sure I can use the same CLI commands you did due to differences between your RT-AC86U and the RT-AC5300 I'm using.
How did you get the following physical port interface map ?
# 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


When I do a 'brctl show' I get

bridge name bridge id STP enabled interfaces
br0 8000.3c96dc4e78d0 yes vlan1
wl0.1
wl1.1
wl2.1

and when I do a 'robocfg show vlan' I get (macs truncated)

Port 0: 1000FD enabled stp: none vlan: 2 jumbo: on mac: 00:
Port 1: 1000FD enabled stp: none vlan: 1 jumbo: on mac: 00:
Port 2: DOWN enabled stp: none vlan: 1 jumbo: on mac: dc:
Port 3: 1000FD enabled stp: none vlan: 1 jumbo: on mac: 00:
Port 4: 100FD enabled stp: none vlan: 1 jumbo: on mac: 00:
Port 5: 1000FD enabled stp: none vlan: 1 jumbo: on mac: dc:
Port 7: 1000FD enabled stp: none vlan: 1 jumbo: on mac: dc:
Port 8: 1000FD enabled stp: none vlan: 2 jumbo: on mac: 2d
VLANs: BCM5301x enabled mac_check mac_hash
1: vlan1: 1 2 3 4 5 7 8t
2: vlan2: 0 8u

I can't seem to find how to determine the port mappings to the physical ports and I'm not sure the commands you've used will work on the RT-AC5300

 

[Deleted member 62525]

I don't have RT-AC5300 to help you out here. Unfortunately asus routers have different mappings for various routers. You may have to email Asus tech support and ask that question or try searching for your router port mappings on this forum. The example I have written is for RT-AC86U.

 

[gavcol]

I don't have RT-AC5300 to help you out here. Unfortunately asus routers have different mappings for various routers. You may have to email Asus tech support and ask that question or try searching for your router port mappings on this forum. The example I have written is for RT-AC86U.

No prob. I've already learned a lot from your post, Thanks.
Although at this point I think I might go down the path of getting a cheap managed switch and setting up a few vlans that way.

 

[Jeffrey Young]

Echoing @eibgrad comments, you need to advise the rest of the router's "Asus" stuff that you have made changes to the br0 bridge. You need to modify the nvram variable "br0_ifnames" at the very least. You may need to add a couple new nvram variables to advise the rest of router about the new bridge's existence.

 

[Deleted member 62525]

Echoing @eibgrad comments, you need to advise the rest of the router's "Asus" stuff that you have made changes to the br0 bridge. You need to modify the nvram variable "br0_ifnames" at the very least. You may need to add a couple new nvram variables to advise the rest of router about the new bridge's existence.

I get what you mean, but without any additional nvram params this configuration has been flawless on this router for many months without a problem. I know that with some VLAN configs people had to set nvram parameters. My current setup without any additional mods to nvram params is working as is.
I don't really know how these params are used in Asus code when using a bridge and as I being running it for so long without issues I would (in my case) say it is not necessary.

 

[Cleanev]

Deleted as requested