YazFi YazFi - Combining guest networks/subnets

[adri]

Hi, so this came up in my other thread, but I wanted to start a new one since it's a separate issue and I like separation of concerns . I want to make it so that, for one of my guest networks, the 2.4GHz segment (.14 subnet) can talk to the 5GHz segment (.15 subnet) and vice-versa, without enabling 2-way to guest and opening up the entire network to them. I was advised to look at the info on the YazFi GitHub page, and I found the instructions there on creating custom firewall rules, but I haven't found any documentation on working solutions to do this specifically. I'm new to iptables, so I appreciate any guidance that can be offered. The communication I am trying to make happen between devices does work when 2-way to guest is enabled, so I know the issue not the devices or their software. And I would hammer away at this until it worked, but I'm trying to keep my roommate from strangling me for taking the network down every 5 minutes.

I have, in /jffs/addons/YazFi.d/userscripts.d/spider_garden.sh :

#!/bin/sh
iptables -I YazFiFORWARD -i wl0.3 -o wl1.3 -d 192.168.14.0/23 -j ACCEPT
iptables -I YazFiFORWARD -i wl0.3 -o wl1.3 -s 192.168.14.0/23 -j ACCEPT
iptables -I YazFiFORWARD -i wl1.3 -o wl0.3 -s 192.168.14.0/23 -j ACCEPT
iptables -I YazFiFORWARD -i wl1.3 -o wl0.3 -d 192.168.14.0/23 -j ACCEPT

From the instructions and the man page, it seems like this should work. I can see the rules are being picked up if I do iptables --list. But I'm not having any luck getting the devices to communicate. What am I doing wrong? Do I even need to specify the -s and -d arguments?

Bonus question: If I wanted to open up a specific port of a specific machine on my main network (let's say 192.168.0.15:43, which is on the wired LAN) to the .14 and .15 subnets, what syntax would I need? Something like:

iptables -l YazFiFORWARD -p tcp -i wl0.3 -o br0 --dport 443 -j ACCEPT

Is that enough? Do I need a rule going in the other direction?

And finally, how do I delete rules and refresh my iptables within the whole Merlin/YazFi ecosystem so I can test another iteration? Preferably without knocking all the wifi devices off the network?

Thank you in advance!

 

[adri]

I'm betting this has been discussed before, but could someone please point me to the appropriate post(s)?

 

[SomeWhereOverTheRainBow]

Hi, so this came up in my other thread, but I wanted to start a new one since it's a separate issue and I like separation of concerns . I want to make it so that, for one of my guest networks, the 2.4GHz segment (.14 subnet) can talk to the 5GHz segment (.15 subnet) and vice-versa, without enabling 2-way to guest and opening up the entire network to them. I was advised to look at the info on the YazFi GitHub page, and I found the instructions there on creating custom firewall rules, but I haven't found any documentation on working solutions to do this specifically. I'm new to iptables, so I appreciate any guidance that can be offered. The communication I am trying to make happen between devices does work when 2-way to guest is enabled, so I know the issue not the devices or their software. And I would hammer away at this until it worked, but I'm trying to keep my roommate from strangling me for taking the network down every 5 minutes.

I have, in /jffs/addons/YazFi.d/userscripts.d/spider_garden.sh :

#!/bin/sh
iptables -I YazFiFORWARD -i wl0.3 -o wl1.3 -d 192.168.14.0/23 -j ACCEPT
iptables -I YazFiFORWARD -i wl0.3 -o wl1.3 -s 192.168.14.0/23 -j ACCEPT
iptables -I YazFiFORWARD -i wl1.3 -o wl0.3 -s 192.168.14.0/23 -j ACCEPT
iptables -I YazFiFORWARD -i wl1.3 -o wl0.3 -d 192.168.14.0/23 -j ACCEPT

From the instructions and the man page, it seems like this should work. I can see the rules are being picked up if I do iptables --list. But I'm not having any luck getting the devices to communicate. What am I doing wrong? Do I even need to specify the -s and -d arguments?

Bonus question: If I wanted to open up a specific port of a specific machine on my main network (let's say 192.168.0.15:43, which is on the wired LAN) to the .14 and .15 subnets, what syntax would I need? Something like:

iptables -l YazFiFORWARD -p tcp -i wl0.3 -o br0 --dport 443 -j ACCEPT

Is that enough? Do I need a rule going in the other direction?

And finally, how do I delete rules and refresh my iptables within the whole Merlin/YazFi ecosystem so I can test another iteration? Preferably without knocking all the wifi devices off the network?

Thank you in advance!

Isn't 192.168.14.0/23 a /24 network, whereas /23 would mean something completely different? (Basically, shouldn't all the subnets in the iptables be /24 and not /23?)

Also, if you were interested to expose port 43 on one of these networks to adjacent networks, wouldn't you use port 43 in the iptable rules instead of port 443?

As for deleting the chain, you just include a -D instead of -I in the command. Pasting it straight in the terminal should work if you are concerned about not losing devices connections.

For more information on iptables please refer to this guide:

iptables(8) - Linux man page

Iptables is used to set up, maintain, and inspect the tables of IP packet filter rules in the Linux kernel. Several different tables may be defined. Each ...

linux.die.net

Also here is the YazFi github if you need to refer back to it:

GitHub - jackyaz/YazFi: Feature expansion of guest WiFi networks on AsusWRT-Merlin, including SSID -> VPN, separate subnets per guest network, pinhole access to LAN resources (e.g. DNS) and more!

Feature expansion of guest WiFi networks on AsusWRT-Merlin, including SSID -> VPN, separate subnets per guest network, pinhole access to LAN resources (e.g. DNS) and more! - jackyaz/YazFi

github.com

 

[Martinski]

I have, in /jffs/addons/YazFi.d/userscripts.d/spider_garden.sh :

#!/bin/sh
iptables -I YazFiFORWARD -i wl0.3 -o wl1.3 -d 192.168.14.0/23 -j ACCEPT
iptables -I YazFiFORWARD -i wl0.3 -o wl1.3 -s 192.168.14.0/23 -j ACCEPT
iptables -I YazFiFORWARD -i wl1.3 -o wl0.3 -s 192.168.14.0/23 -j ACCEPT
iptables -I YazFiFORWARD -i wl1.3 -o wl0.3 -d 192.168.14.0/23 -j ACCEPT

It looks like you're trying to encapsulate both network segments when using the "192.168.14.0/23" notation since that includes the IP address ranges from "192.168.14.1 to 192.168.14.255" plus "192.168.15.1 to 192.168.15.254" (i.e. "wl0.3" + "wl1.3"). IOW, you're trying to apply the firewall rules to the "merged set" of IP ranges, but that may not be the correct solution.

Try with the following commands:

#!/bin/sh

# Delete Rules (if found) #
iptables -D YazFiFORWARD -i wl0.3 -o wl1.3 -j ACCEPT 2>/dev/null
iptables -D YazFiFORWARD -i wl1.3 -o wl0.3 -j ACCEPT 2>/dev/null

# Insert Rules #
iptables -I YazFiFORWARD -i wl0.3 -o wl1.3 -j ACCEPT
iptables -I YazFiFORWARD -i wl1.3 -o wl0.3 -j ACCEPT

Make sure to restart the firewall after making any changes you want to test/verify:
/sbin/service restart_firewall

 

[SomeWhereOverTheRainBow]

It looks like you're trying to encapsulate both network segments when using the "192.168.14.0/23" notation since that includes the IP address ranges from "192.168.14.1 to 192.168.14.255" plus "192.168.15.1 to 192.168.15.254" (i.e. "wl0.3" + "wl1.3"). IOW, you're trying to apply the firewall rules to the "merged set" of IP ranges, but that may not be the correct solution.

Try with the following commands:

#!/bin/sh

# Delete Rules (if found) #
iptables -D YazFiFORWARD -i wl0.3 -o wl1.3 -j ACCEPT 2>/dev/null
iptables -D YazFiFORWARD -i wl1.3 -o wl0.3 -j ACCEPT 2>/dev/null

# Insert Rules #
iptables -I YazFiFORWARD -i wl0.3 -o wl1.3 -j ACCEPT
iptables -I YazFiFORWARD -i wl1.3 -o wl0.3 -j ACCEPT

Make sure to restart the firewall after making any changes you want to test/verify:
/sbin/service restart_firewall

Nice touch, the path of least resistance is to accept all interactions between the two interfaces. Does that mean the interactions between the different subnets will be allowed though? Or does that even matter since you provided a somewhat catch all rule?

 

[Martinski]

Nice touch, the path of least resistance is to accept all interactions between the two interfaces. Does that mean the interactions between the different subnets will be allowed though? Or does that even matter since you provided a somewhat catch all rule?

Apologies for the delayed response. We got very busy at work toward the end of last week and even worked for a few hours over the weekend.

Anyway... Yeah, those 2 filter table rules essentially allow all network traffic between the 2 interfaces *without* setting any specific restrictions (e.g. no protocols, ports, or IP address constraints). Based on my understanding of the OP's description of what he wanted to do, I figured that they should try the simplest approach first, and then go from there if his setup gets more complicated. If desired, of course, you could very explicitly set the network IP address for each interface over which the traffic will be allowed.

Here is an equivalent example script that explicitly sets the IP addresses (based on the OP's YazFi network setup):

#!/bin/sh

# For TESTING/DEBUG purposes, call with argument "-off" to only do deletion of the new rules #

# Delete Rules (if found) #
iptables -D YazFiFORWARD -s 192.168.14.0/24 -d 192.168.15.0/24 -i wl0.3 -o wl1.3 -j ACCEPT 2>/dev/null
iptables -D YazFiFORWARD -s 192.168.15.0/24 -d 192.168.14.0/24 -i wl1.3 -o wl0.3 -j ACCEPT 2>/dev/null

[ -n "$1" ] && [ "$1" = "-off" ] && exit 0

# Insert Rules #
iptables -I YazFiFORWARD -s 192.168.14.0/24 -d 192.168.15.0/24 -i wl0.3 -o wl1.3 -j ACCEPT
iptables -I YazFiFORWARD -s 192.168.15.0/24 -d 192.168.14.0/24 -i wl1.3 -o wl0.3 -j ACCEPT

One caveat of adding IP addresses here is that if sometime later the OP decides to change the current network IP addresses of the Guest WLANs using the YazFi GUI, they would have to remember to go back to this script and modify it as necessary based on the new network IPs. Perhaps that doesn't happen often, but it can happen.

 

[Martinski]

One caveat of adding IP addresses here is that if sometime later the OP decides to change the current network IP addresses of the Guest WLANs using the YazFi GUI, they would have to remember to go back to this script and modify it as necessary based on the new network IPs. Perhaps that doesn't happen often, but it can happen.

Well, thinking more about this caveat, I realized that one can programmatically get the network IP address for each of the target WLAN interfaces *once* the YazFi setup changes have been applied and the Guest Network is active.

Here is a modified version of the previous script with a few improvements:

#!/bin/sh

# For TESTING/DEBUG purposes, call with argument "-off" to only do deletion of the new rules #

# Set here valid WLAN Interface Name ID targets #
NET_IFname_24G="wl0.3"   #GUEST 2.4GHz Network#
NET_IFname_50G="wl1.3"   #GUEST 5.0GHz Network#

#--------------------------------------------------------------------#
_Get_GuestNet_IPAddr_CIDR_()
{
    if [ $# -eq 0 ] || [ -z "$1" ] || [ -z "$(echo "$1" | grep -w "^wl[0-2]\.[1-3]$")" ]
    then echo "" ; return 1 ; fi

    echo "$(ip route show | grep "dev $1 proto" | awk -F ' ' '{print $1}')"
}

# GUEST Network IP Address in CIDR format #
NET_IPaddr_24G="$(_Get_GuestNet_IPAddr_CIDR_ "$NET_IFname_24G")"
NET_IPaddr_50G="$(_Get_GuestNet_IPAddr_CIDR_ "$NET_IFname_50G")"

# Double-check that we're OK #
if [ -z "$NET_IPaddr_24G" ] || [ -z "$NET_IPaddr_50G" ]
then
    LOG_Tag="$(/usr/bin/basename "$0")_$$"
    LOG_Msg="Some GUEST WLAN config parameter was found EMPTY."
    /usr/bin/logger -sc -t "ERROR_$LOG_Tag" "$LOG_Msg"

    LOG_Msg="GUEST 2.4GHz Network IP address=[$NET_IPaddr_24G]"
    /usr/bin/logger -sc -t "INFO_$LOG_Tag" "$LOG_Msg"

    LOG_Msg="GUEST 5.0GHz Network IP address=[$NET_IPaddr_50G]"
    /usr/bin/logger -sc -t "INFO_$LOG_Tag" "$LOG_Msg"

    LOG_Msg="Firewall was NOT modified due to some EMPTY params."
    /usr/bin/logger -sc -t "INFO_$LOG_Tag" "$LOG_Msg"

    exit 1
fi

# Delete Rules (if found) #
iptables -D YazFiFORWARD -s $NET_IPaddr_24G -d $NET_IPaddr_50G -i $NET_IFname_24G -o $NET_IFname_50G -j ACCEPT 2>/dev/null
iptables -D YazFiFORWARD -s $NET_IPaddr_50G -d $NET_IPaddr_24G -i $NET_IFname_50G -o $NET_IFname_24G -j ACCEPT 2>/dev/null

[ -n "$1" ] && [ "$1" = "-off" ] && exit 0

# Insert Rules #
iptables -I YazFiFORWARD -s $NET_IPaddr_24G -d $NET_IPaddr_50G -i $NET_IFname_24G -o $NET_IFname_50G -j ACCEPT
iptables -I YazFiFORWARD -s $NET_IPaddr_50G -d $NET_IPaddr_24G -i $NET_IFname_50G -o $NET_IFname_24G -j ACCEPT

#EOF#

Note that with this modified version you can now more easily combine any pair of active GUEST Networks interfaces that you want.

 

[SomeWhereOverTheRainBow]

Well, thinking more about this caveat, I realized that one can programmatically get the network IP address for each of the target WLAN interfaces *once* the YazFi setup changes have been applied and the Guest Network is active.

Here is a modified version of the previous script with a few improvements:

#!/bin/sh

# For TESTING/DEBUG purposes, call with argument "-off" to only do deletion of the new rules #

# Set here valid WLAN Interface Name ID targets #
NET_IFname_24G="wl0.3"   #GUEST 2.4GHz Network#
NET_IFname_50G="wl1.3"   #GUEST 5.0GHz Network#

#--------------------------------------------------------------------#
_Get_GuestNet_IPAddr_CIDR_()
{
    if [ $# -eq 0 ] || [ -z "$1" ] || [ -z "$(echo "$1" | grep -w "^wl[0-2]\.[1-3]$")" ]
    then echo "" ; return 1 ; fi

    echo "$(ip route show | grep "dev $1 proto" | awk -F ' ' '{print $1}')"
}

# GUEST Network IP Address in CIDR format #
NET_IPaddr_24G="$(_Get_GuestNet_IPAddr_CIDR_ "$NET_IFname_24G")"
NET_IPaddr_50G="$(_Get_GuestNet_IPAddr_CIDR_ "$NET_IFname_50G")"

# Double-check that we're OK #
if [ -z "$NET_IPaddr_24G" ] || [ -z "$NET_IPaddr_50G" ]
then
    LOG_Tag="$(/usr/bin/basename "$0")_$$"
    LOG_Msg="Some GUEST WLAN config parameter was found EMPTY."
    /usr/bin/logger -sc -t "ERROR_$LOG_Tag" "$LOG_Msg"

    LOG_Msg="GUEST 2.4GHz Network IP address=[$NET_IPaddr_24G]"
    /usr/bin/logger -sc -t "INFO_$LOG_Tag" "$LOG_Msg"

    LOG_Msg="GUEST 5.0GHz Network IP address=[$NET_IPaddr_50G]"
    /usr/bin/logger -sc -t "INFO_$LOG_Tag" "$LOG_Msg"

    LOG_Msg="Firewall was NOT modified due to some EMPTY params."
    /usr/bin/logger -sc -t "INFO_$LOG_Tag" "$LOG_Msg"

    exit 1
fi

# Delete Rules (if found) #
iptables -D YazFiFORWARD -s $NET_IPaddr_24G -d $NET_IPaddr_50G -i $NET_IFname_24G -o $NET_IFname_50G -j ACCEPT 2>/dev/null
iptables -D YazFiFORWARD -s $NET_IPaddr_50G -d $NET_IPaddr_24G -i $NET_IFname_50G -o $NET_IFname_24G -j ACCEPT 2>/dev/null

[ -n "$1" ] && [ "$1" = "-off" ] && exit 0

# Insert Rules #
iptables -I YazFiFORWARD -s $NET_IPaddr_24G -d $NET_IPaddr_50G -i $NET_IFname_24G -o $NET_IFname_50G -j ACCEPT
iptables -I YazFiFORWARD -s $NET_IPaddr_50G -d $NET_IPaddr_24G -i $NET_IFname_50G -o $NET_IFname_24G -j ACCEPT

#EOF#

Note that with this modified version you can now more easily combine any pair of active GUEST Networks interfaces that you want.

Not that I don't like your method of attaining the ip addresses for the interfaces, but an alternative method would be to simply source the values from the yazfi.conf file used for value placement of the interfaces. Undoubtedly though your first method is by far the cleanest and most efficient, unless we had a specific reason to define ports or restrict subnets.

 

[fotingo]

Hello..
I would like to use this script to for 2.4 Guest #3 and 5 Ghz Guest #2.
Would I just change this part to:

NET_IFname_24G="wl0.3" #GUEST 2.4GHz Network#
NET_IFname_50G="wl1.2" #GUEST 5.0GHz Network#

or do I also need to change anything else?

 

[Martinski]

NET_IFname_24G="wl0.3" #GUEST 2.4GHz Network#
NET_IFname_50G="wl1.2" #GUEST 5.0GHz Network#

That's correct for your router model. There should be no need to modify anything else unless you want to get much more specific with port numbers & protocols.

Here's a table showing the current mappings of the virtual interface names to guest network numbers for dual-band routers (2.4GHz + 5GHz) & tri-band routers (one 2.4GHz + two 5GHz *OR* one 2.4GHz + one 5GHz + one 6GHz).

	Guest Network #1​	Guest Network #2​	Guest Network #3​
2.4GHz​	wl0.1​	wl0.2​	wl0.3​
5GHz​	wl1.1​	wl1.2​	wl1.3​
5GHz-2​	wl2.1​	wl2.2​	wl2.3​
6GHz​	wl2.1​	wl2.2​	wl2.3​

For quad-band routers, the mappings are quite different & I don't have them at the top of my head at the moment. If someone wants to know I can dig them out from my notes or the YazFi code that I wrote a while ago to support quad-band routers (e.g. GT-AXE16000).