LAN port isolation

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

Very Senior Member
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.

Code:
# 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.

Code:
# 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.
 

Markster

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

Code:
# 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.
Code:
# 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

Very Senior Member
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.
 

Markster

Senior Member
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

Very Senior Member
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?
 

Markster

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

Code:
#!/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

Very Senior Member
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.
 

Markster

Senior Member
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:
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"
 

Markster

Senior Member
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
Code:
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.
 
Last edited:

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