What's new

Question about Firewall - Network Services Filter & Guest Networks

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

AsusRouterUser

Occasional Visitor
Is there a way to do Firewall - Network Services Filter on a Guest Network, I need to be able to block certain IP addresses from the Guest Network. Is this possible and if so how?

Thanks in advance for any and all help,

AsusRouterUser
 
This is one of those areas the router doesn't handle well because of how guests are managed.

The Network Services Filter *only* works w/ the default bridge (br0). If you use guest network #2 or #3, they share that same bridge (and the default IP network), therefore you can't distinguish guests from non-guests on that basis. If you guest #1, for the purposes of AiMesh, those are typically assigned their own IP network (either 192.168.101.0/24 for 2.4GHz, or 192.168.102.0/24 for 5Ghz), which helps, but using new bridges (br1 and br2), which doesn't.

IOW, by design, the Network Services Filter feature just doesn't play nice w/ guest networks. It's intended for blocking devices on the default IP network (e.g., 192.168.1.0/24) without distinction as to guest or non-guest.

If that wasn't bad enough, the Network Services Filter also doesn't block access to any of the OpenVPN clients! It only blocks the WAN specifically. For the OpenVPN clients, you'd need to filter those separately using either the VPN Director or route directives.

It's all these gotchas that makes the Network Services Filter not nearly as useful as it might first appear.

What you might want to consider is YazFi. It creates a new IP network for each guest network (making them distinguishable from the private IP network) and assigns them to the default bridge (br0). So it may very well work in that case.
 
P.S. On second thought, it might NOT work w/ YazFi. It's a bit unclear to me because YazFi creates its own rules in the firewall based on the relevant wireless network interface of the guest (e.g., wl0.1). But @Jack Yaz (the author) does NOT remove that same network interface from the default bridge (br0). I don't know how that can work. Either the wireless network interface has to standalone, OR be assigned to a bridge, but it can't be both! Just one of those things the author needs to clarify.
 
I need to be able to block certain IP addresses from the Guest Network.
Do you mean block all access to the internet from certain guest clients? If so just block them like any other device using Network Map > Clients > [your_client] > Block Internet Access.

As noted above that might not be an option if you're using guest network #1.
 
Last edited:
P.S. On second thought, it might NOT work w/ YazFi. It's a bit unclear to me because YazFi creates its own rules in the firewall based on the relevant wireless network interface of the guest (e.g., wl0.1). But @Jack Yaz (the author) does NOT remove that same network interface from the default bridge (br0). I don't know how that can work. Either the wireless network interface has to standalone, OR be assigned to a bridge, but it can't be both! Just one of those things the author needs to clarify.

Jack does provide a means of adding custom iptable rules to his script. It is done via the /jffs/addons/YazFi.d/userscripts.d/myscript.sh script.

Full info here; https://github.com/jackyaz/YazFi
 
This is one of those areas the router doesn't handle well because of how guests are managed.

The Network Services Filter *only* works w/ the default bridge (br0). If you use guest network #2 or #3, they share that same bridge (and the default IP network), therefore you can't distinguish guests from non-guests on that basis. If you guest #1, for the purposes of AiMesh, those are typically assigned their own IP network (either 192.168.101.0/24 for 2.4GHz, or 192.168.102.0/24 for 5Ghz), which helps, but using new bridges (br1 and br2), which doesn't.

IOW, by design, the Network Services Filter feature just doesn't play nice w/ guest networks. It's intended for blocking devices on the default IP network (e.g., 192.168.1.0/24) without distinction as to guest or non-guest.

If that wasn't bad enough, the Network Services Filter also doesn't block access to any of the OpenVPN clients! It only blocks the WAN specifically. For the OpenVPN clients, you'd need to filter those separately using either the VPN Director or route directives.

It's all these gotchas that makes the Network Services Filter not nearly as useful as it might first appear.

What you might want to consider is YazFi. It creates a new IP network for each guest network (making them distinguishable from the private IP network) and assigns them to the default bridge (br0). So it may very well work in that case.
Thanks for the responds, I did look into that YazFi, I just don't quite understand how it works.
 
Do you mean block all access to the internet from certain guest clients? If so just block them like any other device using Network Map > Clients > [your_client] > Block Internet Access.

As noted above that might not be an option if you're using guest network #1.
Thanks for the responds. No I want to block certain IP addresses from ALL guest users.
 
You could do it quite simply in a firewall-start script. But I don't think it's possible just by using the GUI.
that sounds promising, but can I have it only apply to the guest network and if so can you tell me how or point me towards some examples?

Really appreciate the help.
 
No I want to block certain IP addresses from ALL guest users.

IOW, you want ALL guests for a given guest network to be denied access to certain destination IPs on the internet.

As I said before, guests normally (at least #2 and #3, we'll put aside guest #1 for the time being, it's a special case due to AiMesh) use the *same* IP network as private users (i.e., NON guests). That means you can't distinguish guests from non-guests solely on the basis of their assigned IP. But that's essential for creating rules that only affect guests and NOT non-guests!

That's the point of using YazFi. YazFi makes it possible to assign guests their own IP network that is different from non-guests. And so now you can use something like the firewall script to create a rule on that basis. If we assume guests are using 192.168.3.0/24 ...

Code:
iptables -I FORWARD -s 192.168.3.0/24 -d cnet.com -j REJECT

This will NOT affect non-guests who are using 192.168.1.0/24.

As point out previously, more recent releases of YazFi support the addition of user-defined firewall rules w/o having to use the firewall-start script directly.

But in spite of all this, the Network Services Filter is NOT likely going to work w/ YazFi. It just makes working w/ guest networks easier because guests for any given guest network are always given their own unique IP network, separate from all others guest networks and non-guests. Now creating firewall rules or VPN Director rules for guest networks becomes much easier since they can be isolated/referenced based on their assigned IP network.
 
Last edited:
P.S. For completeness sake …

I treated guest #1 above as an exception because it used to be just like guest #2 and #3 until ASUS introduced AiMesh. For the sake of AiMesh, ASUS "hacked" (imo) guest #1 and now assigns either the 192.168.101.0/24 (2.4GHz) or 192.168.102.0/24 (5GHz) IP network to guest #1. So technically, you can distinguish those guests from non-guests (and the guests of #2 and #3) based on those IP networks. Even so, guest #1 still won't work w/ the Network Services Filter.

Even if it did, guest #1 suffers from other unrelated anomalies that are best avoided unless you actually are using it for AiMesh purposes. I just recommend NEVER using guest #1 for any other purposes. And as such, if makes using something like YazFi a necessity for guest #2 and #3 as I described above.
 
P.S. For completeness sake …

I treated guest #1 above as an exception because it used to be just like guest #2 and #3 until ASUS introduced AiMesh. For the sake of AiMesh, ASUS "hacked" (imo) guest #1 and now assigns either the 192.168.101.0/24 (2.4GHz) or 192.168.102.0/24 (5GHz) IP network to guest #1. So technically, you can distinguish those guests from non-guests (and the guests of #2 and #3) based on those IP networks. Even so, guest #1 still won't work w/ the Network Services Filter.

Even if it did, guest #1 suffers from other unrelated anomalies that are best avoided unless you actually are using it for AiMesh purposes. I just recommend NEVER using guest #1 for any other purposes. And as such, if makes using something like YazFi a necessity for guest #2 and #3 as I described above.
I'll say one thing for you @eibgrad, you give very threrow answers! I actually like reading your responses.

I agree with you about using guest #1. Question I have is rather or not the recent weirdness with guest #1 is also seen when the bix is in AP mode.
 
I agree with you about using guest #1. Question I have is rather or not the recent weirdness with guest #1 is also seen when the bix is in AP mode.

I honestly don't know. But realize that in AP mode, a LOT of things are different. For example, the router is bridged, so there is no active firewall! So the OP's issues regarding the Network Services Filter, hand crafted firewall rules, even the VPN Director (the OpenVPN clients are NOT available either) are moot.

In general, I do NOT like how ASUS implements guest networks based on using the same ethernet + IP network as the private network. I much prefer the DD-WRT and FreshTomato approach which keeps guest and IoT networks on their own ethernet + IP networks. Then you avoid a lot of these problems, or the need for a third-party to workaround the issue w/ something like YazFi. The fact ASUS implemented guests the way they did probably accounts for them having to hack guest #1 in the first place! They (and their users) eventually paid the price for that bad decision.
 
P.S. On second thought, it might NOT work w/ YazFi. It's a bit unclear to me because YazFi creates its own rules in the firewall based on the relevant wireless network interface of the guest (e.g., wl0.1). But @Jack Yaz (the author) does NOT remove that same network interface from the default bridge (br0). I don't know how that can work. Either the wireless network interface has to standalone, OR be assigned to a bridge, but it can't be both! Just one of those things the author needs to clarify.
It leaves the iface in the bridge but shuts off bridging traffic with ebtables, so it gets handled in the iptables layer instead. Each interface is also brought up with ifconfig so it gets its own addressing. I was working on a version of YazFi that used its own bridging for bonding WiFi networks with ports, but sidelined it when I switched away from Asus as it couldn't keep up with my gigabit connection anymore
 
It leaves the iface in the bridge but shuts off bridging traffic with ebtables, so it gets handled in the iptables layer instead. Each interface is also brought up with ifconfig so it gets its own addressing. I was working on a version of YazFi that used its own bridging for bonding WiFi networks with ports, but sidelined it when I switched away from Asus as it couldn't keep up with my gigabit connection anymore

Thanks. That was just something I always found a mystery. I just couldn't figure out how you referenced the wireless network interface in the firewall, but brctl would continue to report it was bridged to br0, making that reference invalid.

Seems fine to NOT use your own bridges if you can't configure their own VLANs as well.
 
Jack's comment ... "sidelined it when I switched away from Asus as it couldn't keep up with my gigabit connection anymore"

Switching from Asus to ????

Should we be concerned as to further future updates/maintenance of your Merlin Add-Ons?
 
I honestly don't know. But realize that in AP mode, a LOT of things are different. For example, the router is bridged, so there is no active firewall! So the OP's issues regarding the Network Services Filter, hand crafted firewall rules, even the VPN Director (the OpenVPN clients are NOT available either) are moot.

In general, I do NOT like how ASUS implements guest networks based on using the same ethernet + IP network as the private network. I much prefer the DD-WRT and FreshTomato approach which keeps guest and IoT networks on their own ethernet + IP networks. Then you avoid a lot of these problems, or the need for a third-party to workaround the issue w/ something like YazFi. The fact ASUS implemented guests the way they did probably accounts for them having to hack guest #1 in the first place! They (and their users) eventually paid the price for that bad decision.

Thanks @eibgrad and @Jack Yaz for the explanation. I am planning on repurposing an AC86U as an AP (as opposed to purchasing a new AP) to use as the AP for my RasPi4 router. I've only been able to get a hold of the AC86U for an hour at a time to see how things are setup in AP (the joys of having 5 people in the house). From what I have seen, the ebtables and iptables are blank in AP mode with the guest interfaces lumped in with the br0. So, I am looking at running the following script to group my LAN and Guests/IOT into various VLANS to work with the RasPi router. Note that credit for this script largely is not mine. I have the link to the original GitHub poster somewhere, but can't find it right now.

Code:
#!/bin/sh

# remove eth0 which will be reconfigured as a tagged port
brctl delif br0 eth0
# remove interfaces we're gonna move to other bridges
brctl delif br0 wl0.1
brctl delif br0 wl0.2

# add vlans
# interestingly, depending on the time passed since system boot,
# vlan interfaces will be named eth0.1 or vlan1, I guess some udev rules got loaded.
# so we use ip link instead of vconfig to specify a name explicitly.
ip link add link eth0 name eth0.500 type vlan id 500
ip link add link eth0 name eth0.501 type vlan id 501
ip link add link eth0 name eth0.502 type vlan id 502
ip link set eth0.500 up
ip link set eth0.501 up
ip link set eth0.502 up

# reconfigure br0, private LAN
brctl addif br0 eth0.500

# set up br1, guest LAN
brctl addbr br1
brctl addif br1 eth0.501
brctl addif br1 wl0.1
brctl setfd br1 2
ip link set br1 up

# set up br2, another guest LAN for IoT devices
brctl addbr br2
brctl addif br2 eth0.502
brctl addif br2 wl0.2
brctl setfd br2 2
ip link set br2 up

# seems like eapd reads config from these
# no need to set lan_ifname since it's already there
nvram set lan_ifnames="eth1 eth2 eth3 eth4 eth5 eth6 eth0.500"

nvram set lan1_ifnames="wl0.1 eth0.501"
nvram set lan1_ifname="br1"

nvram set lan2_ifnames="wl0.2 eth0.502"
nvram set lan2_ifname="br2"

# doesn't seem to affect anything, just make it align
nvram set br0_ifnames="eth1 eth2 eth3 eth4 eth5 eth6 eth0.500"

nvram set br1_ifnames="wl0.1 eth0.501"
nvram set br1_ifname="br1"

nvram set br2_ifnames="wl0.2 eth0.502"
nvram set br2_ifname="br2"

# we do NOT issue `nvram commit` here since it won't survive reboot anyway

# is there a better way to do this like `service restart eapd` ?
killall eapd
eapd

The only concern I have is what Asus is doing in the background with the Guest Network in AP mode. Ideally, picking up a UniFi AP would be the best solution, but I don't want to spend extra money where it does not need to be spent.

Out of curiosity @Jack Yaz, what product line are you moving to? My reasons for leaving Asus behind are varied (the RaspPi project is a learning one to keep my aged mine busy, but also I feel that Merlin has hit the upper limits of what I want to do, also I need to get my primary access to an area of the house where it is truly useful - i.e. get the wireless AP upstairs while all the cables terminate downstairs).

The issue I have with Asus is just reliability. Maybe it is me, but it seems that each GPL released now seems to be buggy or adds new issues. Just seems that Asus is trying to do too much is a small amount of time. Then there is the issue of Merlin being a one man show and he could pull the plug at any time. In the end, if PFSense would run on a Pi, it would be sweet.
 
Thanks @eibgrad and @Jack Yaz for the explanation. I am planning on repurposing an AC86U as an AP (as opposed to purchasing a new AP) to use as the AP for my RasPi4 router. I've only been able to get a hold of the AC86U for an hour at a time to see how things are setup in AP (the joys of having 5 people in the house). From what I have seen, the ebtables and iptables are blank in AP mode with the guest interfaces lumped in with the br0. So, I am looking at running the following script to group my LAN and Guests/IOT into various VLANS to work with the RasPi router. Note that credit for this script largely is not mine. I have the link to the original GitHub poster somewhere, but can't find it right now.

Code:
#!/bin/sh

# remove eth0 which will be reconfigured as a tagged port
brctl delif br0 eth0
# remove interfaces we're gonna move to other bridges
brctl delif br0 wl0.1
brctl delif br0 wl0.2

# add vlans
# interestingly, depending on the time passed since system boot,
# vlan interfaces will be named eth0.1 or vlan1, I guess some udev rules got loaded.
# so we use ip link instead of vconfig to specify a name explicitly.
ip link add link eth0 name eth0.500 type vlan id 500
ip link add link eth0 name eth0.501 type vlan id 501
ip link add link eth0 name eth0.502 type vlan id 502
ip link set eth0.500 up
ip link set eth0.501 up
ip link set eth0.502 up

# reconfigure br0, private LAN
brctl addif br0 eth0.500

# set up br1, guest LAN
brctl addbr br1
brctl addif br1 eth0.501
brctl addif br1 wl0.1
brctl setfd br1 2
ip link set br1 up

# set up br2, another guest LAN for IoT devices
brctl addbr br2
brctl addif br2 eth0.502
brctl addif br2 wl0.2
brctl setfd br2 2
ip link set br2 up

# seems like eapd reads config from these
# no need to set lan_ifname since it's already there
nvram set lan_ifnames="eth1 eth2 eth3 eth4 eth5 eth6 eth0.500"

nvram set lan1_ifnames="wl0.1 eth0.501"
nvram set lan1_ifname="br1"

nvram set lan2_ifnames="wl0.2 eth0.502"
nvram set lan2_ifname="br2"

# doesn't seem to affect anything, just make it align
nvram set br0_ifnames="eth1 eth2 eth3 eth4 eth5 eth6 eth0.500"

nvram set br1_ifnames="wl0.1 eth0.501"
nvram set br1_ifname="br1"

nvram set br2_ifnames="wl0.2 eth0.502"
nvram set br2_ifname="br2"

# we do NOT issue `nvram commit` here since it won't survive reboot anyway

# is there a better way to do this like `service restart eapd` ?
killall eapd
eapd

The only concern I have is what Asus is doing in the background with the Guest Network in AP mode. Ideally, picking up a UniFi AP would be the best solution, but I don't want to spend extra money where it does not need to be spent.

Out of curiosity @Jack Yaz, what product line are you moving to? My reasons for leaving Asus behind are varied (the RaspPi project is a learning one to keep my aged mine busy, but also I feel that Merlin has hit the upper limits of what I want to do, also I need to get my primary access to an area of the house where it is truly useful - i.e. get the wireless AP upstairs while all the cables terminate downstairs).

The issue I have with Asus is just reliability. Maybe it is me, but it seems that each GPL released now seems to be buggy or adds new issues. Just seems that Asus is trying to do too much is a small amount of time. Then there is the issue of Merlin being a one man show and he could pull the plug at any time. In the end, if PFSense would run on a Pi, it would be sweet.

Philosophically, I'm NOT a fan of hacking VLANs out of the AC86U if in the end you're going to abandon it for some other primary router like pfSense. I'd just rather take Jack's approach and make a wholesale leap to superior hardware, esp. hardware that does NOT require hacking for (what I consider) basic functionality (no native VLANs support w/ ASUS is ridiculous in this day and age). I'm NOT even a fan of this kind of VLAN hacking if the ASUS is configured in router mode, but using it for AP mode to save a few bucks, eh..., I can't see the point.

Like Jack, many of us are going to have to consider making a similar leap in the NOT too distant future UNLESS these OEMS of consumer-grade routers step up to plate and offer *MUCH* better hardware, rather than trying to "stretch the soup" w/ the current hardware and hacks like CFE/SFE/FA. That's the fundamental issue here, at least for me.
 

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