Allowing main network to access guest networks

[Christian_Haitian]

This has been dug into in-depth in other threads, but here's the gist:

Guest Network Pro/Smart Home Master are for creating wireless VLANs (meaning you can only add wireless clients to a VLAN). Pro-series routers generally also support wired VLANs (meaning you can also add wired clients to a VLAN). Depending on your setup you may have AiMesh nodes that support wireless VLANs but not wired VLANs (my setup is like this), but the lack of wired VLAN support on an AiMesh node has nothing to do with wired clients being able to talk to wireless VLAN clients via a firewall rule: if there is a firewall rule that allows traffic from the main network into a VLAN it shouldn't matter if a given main network client is connected to the main router or a node.

iptables -I FORWARD -i br0 -s 192.168.1.0/24 -d 192.168.53.0/24 -j ACCEPT

Above is the rule I use in the firewall-start script to allow anything on the main network to initiate a connection to anything on the IoT VLAN I created in Guest Network Pro. Try something simple like that and see if it solves the problem.

Thank you for the recommendation. I tried adding this firewall rule but it made no difference for my issue. Should I remove the previous rules first to ensure that those are not possibly interfering with this rule?

The previous rules are as follows


iptables -I FORWARD -i br0 -o br1 -j ACCEPT
iptables -I FORWARD -i br1 -o br0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -I FORWARD -i br0 -o br2 -j ACCEPT
iptables -I FORWARD -i br2 -o br0 -m state --state ESTABLISHED,RELATED -j ACCEPT

 

[Seth Harman]

The following allows access to/from my printer (222.10) on primary network (.222) for devices on guest (.54):

iptables -I FORWARD -i br0  -s 192.168.222.0/24 -d 192.168.54.0/24   -j ACCEPT # Access to guest from primary network
iptables -I FORWARD -i br52 -s 192.168.54.0/24  -d 192.168.222.10/32 -j ACCEPT # Reverse for guest devices to printer

You know I've never understood the point of using /32 when you're specifying a single IP address.

Thank you for the recommendation. I tried adding this firewall rule but it made no difference for my issue. Should I remove the previous rules first to ensure that those are not possibly interfering with this rule?

The previous rules are as follows


iptables -I FORWARD -i br0 -o br1 -j ACCEPT
iptables -I FORWARD -i br1 -o br0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -I FORWARD -i br0 -o br2 -j ACCEPT
iptables -I FORWARD -i br2 -o br0 -m state --state ESTABLISHED,RELATED -j ACCEPT

Yes, take those out as they're redundant to the rule I provided and may actually be the source of the problem. Someone with more expertise can possibly chime in here but it seems to me if you specify a bridge with no IP block maybe it's only routing traffic directly on the main router and not anything connected directly to a node? Also, I've never seen a need to specify traffic is ok if it's ESTABLISHED,RELATED as everything on my network just works (including security cameras and all kinds of IoT devices on the 53 VLAN) so start with that rule structure I gave you and see if you're good.

Edit: Just for completeness-sake, make sure you're editing that rule I pasted to reflect whatever you main and VLAN IP blocks actually are if they're different than mine. In your case it would appear you're going to need to input that rule twice: once for the VLAN on br52 and once for the VLAN on br53. In the case of my network it'd look like this:

iptables -I FORWARD -i br0 -s 192.168.1.0/24 -d 192.168.53.0/24 -j ACCEPT
iptables -I FORWARD -i br0 -s 192.168.1.0/24 -d 192.168.52.0/24 -j ACCEPT

 

[visortgw]

You know I've never understood the point of using /32 when you're specifying a single IP address.

Yes, you are correct — it is unnecessary. I was just copying/pasting/editing existing rules, and it didn't occur to me at the time.

 

[Seth Harman]

Yes, you are correct — it is unnecessary. I was just copying/pasting/editing existing rules, and it didn't occur to me at the time.

If you do a Google search on whether it's required or not its AI will give you this:

"If a /32 is not used, firewalls may interpret a single IP (e.g., 192.168.1.5) incorrectly, sometimes defaulting to a /24 or the interface's broader subnet, leading to overly permissive rules."

Really? A firewall can potentially interpret a single IP as a /24? Stuff like this bothers me, if that's true the subnet mask should be required in firewall rules and shouldn't work without it. That being said, in my limited experience with firewall rules I've never seen anything go haywire when you specify a single IP with no subnet mask.

 

[visortgw]

If you do a Google search on whether it's required or not its AI will give you this:

"If a /32 is not used, firewalls may interpret a single IP (e.g., 192.168.1.5) incorrectly, sometimes defaulting to a /24 or the interface's broader subnet, leading to overly permissive rules."

Really? A firewall can potentially interpret a single IP as a /24? Stuff like this bothers me, if that's true the subnet mask should be required in firewall rules and shouldn't work without it. That being said, in my limited experience with firewall rules I've never seen anything go haywire when you specify a single IP with no subnet mask.

Do we trust AI?!

I guess that I'll leave my single IP rules with the /32 to guarantee that there are no misinterpretations.

 

[diyguy]

You know I've never understood the point of using /32 when you're specifying a single IP address.

Yes, take those out as they're redundant to the rule I provided and may actually be the source of the problem. Someone with more expertise can possibly chime in here but it seems to me if you specify a bridge with no IP block maybe it's only routing traffic directly on the main router and not anything connected directly to a node? Also, I've never seen a need to specify traffic is ok if it's ESTABLISHED,RELATED as everything on my network just works (including security cameras and all kinds of IoT devices on the 53 VLAN) so start with that rule structure I gave you and see if you're good.

Edit: Just for completeness-sake, make sure you're editing that rule I pasted to reflect whatever you main and VLAN IP blocks actually are if they're different than mine. In your case it would appear you're going to need to input that rule twice: once for the VLAN on br52 and once for the VLAN on br53. In the case of my network it'd look like this:

iptables -I FORWARD -i br0 -s 192.168.1.0/24 -d 192.168.53.0/24 -j ACCEPT
iptables -I FORWARD -i br0 -s 192.168.1.0/24 -d 192.168.52.0/24 -j ACCEPT

The "ESTABLISHED,RELATED" is for my use case, I don't want any guest devices communicating to my main network devices unless they have had a connect initiated to them from the main lan side.

 

[Seth Harman]

Do we trust AI?!

I guess that I'll leave my single IP rules with the /32 to guarantee that there are no misinterpretations.

I don't trust AI at all, but if there's a chance any firewall could misinterpret that rule you'd think the /netmask should be mandatory.

 

[Seth Harman]

The "ESTABLISHED,RELATED" is for my use case, I don't want any guest devices communicating to my main network devices unless they have had a connect initiated to them from the main lan side.

Sure, but unless you set the VLAN to operate on the same IP block as the main network and disabled AP isolation they already can't do that unless you've setup a firewall rule to allow such communication. By creating a rule to allow the main network devices to establish communications with devices on the VLAN those VLAN devices are only communicating back after that connection is established. Am I missing something?

 

[diyguy]

Sure, but unless you set the VLAN to operate on the same IP block as the main network and disabled AP isolation they already can't do that unless you've setup a firewall rule to allow such communication. By creating a rule to allow the main network devices to establish communications with devices on the VLAN those VLAN devices are only communicating back after that connection is established. Am I missing something?

yep thats it, I keep some devices separated that I use specific applications that connect to those devices.

 

[Seth Harman]

yep thats it, I keep some devices separated that I use specific applications that connect to those devices.

Ok, but again... the SPI firewall in use on your Asus router isn't going to allow a connection from a VLAN device back to a main LAN device unless there's a firewall rule in place that allows it and the firewall rule that allows main LAN -> VLAN is going to allow reciprocal communication from the VLAN device back to the main LAN device only after the main LAN device initiates the communication. I'm trying to wrap my head around what the ESTABLISHED, RELATED rule is accomplishing that the SPI firewall+firewall rule already isn't; this isn't a dig on your rule, but from what I understand about the Asus firewall I'm just trying to figure out how it isn't redundant.

 

[diyguy]

Ok, but again... the SPI firewall in use on your Asus router isn't going to allow a connection from a VLAN device back to a main LAN device unless there's a firewall rule in place that allows it and the firewall rule that allows main LAN -> VLAN is going to allow reciprocal communication from the VLAN device back to the main LAN device only after the main LAN device initiates the communication. I'm trying to wrap my head around what the ESTABLISHED, RELATED rule is accomplishing that the SPI firewall+firewall rule already isn't; this isn't a dig on your rule, but from what I understand about the Asus firewall I'm just trying to figure out how it isn't redundant.

You're right — I checked and my FORWARD policy is ACCEPT, so the ESTABLISHED/RELATED rule is redundant in my setup with SPI enabled. I added it during a troubleshooting session and thought it was the fix, but the actual issue turned out to be mDNS not crossing subnet boundaries, which iptables rules can't solve anyway. The rule is harmless but you're correct it isn't doing anything SPI isn't already handling.

 

[Seth Harman]

You're right — I checked and my FORWARD policy is ACCEPT, so the ESTABLISHED/RELATED rule is redundant in my setup with SPI enabled. I added it during a troubleshooting session and thought it was the fix, but the actual issue turned out to be mDNS not crossing subnet boundaries, which iptables rules can't solve anyway. The rule is harmless but you're correct it isn't doing anything SPI isn't already handling.

Ok, thanks for clarifying, I wasn't sure if I was missing some odd case where that'd be necessary for your setup.