plus the DD-WRT wiki, plus several additional guest wifi tutorials and articles, but I haven't found a clear discussion of how to allow access to the Internet while simultaneously blocking access to the other subnets and the router itself. The DD-WRT articles simply say "Tick the box for 'Network Isolation'", but don't explain what that does or how it works. One article does say that it "adds additional firewall rules", but doesn't explain further.
The closest thing I have found is Alex Laird's guest wifi guide; he recommends adding these firewall rules (where Bridge1 (br1) is the guest WiFi and br0 is his house LAN, and the comments are mine):
# Allow the Guest Wifi to initiate connections to anything not previously blocked
iptables -I FORWARD -i br1 -m state --state NEW -j ACCEPT # Block access from the Guest Wifi to the house LAN
iptables -I FORWARD -i br1 -o br0 -m state --state NEW -j DROP # Block access from the house LAN to the Guest Wifi
iptables -I FORWARD -i br0 -o br1 -m state --state NEW -j DROP
Does anyone know of a really good explanation of firewall rules for securing a Guest WLAN?
What does the POSTROUTING rule do?
Alex' rules specifically block access from the WLAN to one house subnet. For those of us with multiple subnets this would mean a separate FORWARD rule for each subnet; is there a simpler way to do this?
What 'additional firewall rules' does the 'Net Isolation' option in DD-WRT add?
I would take the time to understand the basics of networking and firewalls. Taking someone else's rules at face value is better than nothing, but, especially as you move past a single network, you'll need to understand what they do.
Can't help you with DD-WRT's labeling, but there are some "interesting" behaviors of the "client isolation" and "hairpin" settings of wireless as netifd and hostapd implement them. There is no "right" or "wrong", but you'll have to decide what you want as behavior.
My "guest network" firewall rules? No inbound connections, no traffic from guest VLAN to any other VLAN or vice versa, all connection attempts to any "local" networks or VLANs logged. Dedicated DNS and DHCPv4 on service hosts, not on router. I don't try to "protect" guests from guests. No IPv6 supplied to guests; you're a guest, too bad.
IPv6 and IPv4 nearly doubles the complexity of the rule set and doubles the testing complexity. I also have to supply RAs to the subnet, which can't be completely static as Comcast occasionally changes my IA_PD. It also chews up a /64, with Comcast only offering a /60 IA_PD, I'd rather keep my 16 subnets for things that provide me benefit.
Offering IPv6 to guests provides me no benefit for that work. When the day comes that all "guest" devices run IPv6 reliably, and all the services they need to access are available on IPv6, then I'll switch. That day seems to be at least a few years off.
I run my DNS and DHCP servers on hosts other than my router. My router does not provide services to any of the clients on my network other than routing.
Different than encryption -- those service hosts never "talk" over the guest network to anything but link-local guest devices.
Let's say my guest network is 192.168.168.0/32
I then have one or more dual-homed service hosts that provide:
DHCP
DNS
NTP
over their interface(s) on the 192.168.168.0/0 network. For example, their interfaces might be
192.168.168.67
192.168.168.53
192.168.168.123
or they might be on just two, or a single interface.
Now each of those hosts also has (a) a management interface on its own VLAN, and (b) an interface for upstream, let's say on the 10.168.168.0/24 network. Their default route is via that network.
So a request for DNS comes in from a guest on 192.168.168.201 to DNS on 192.168.168.53. That machine makes its upstream requests via the 10.168.168.0/24 net (or, via IPv6 over the equivalent "back-side" network). They are never seen in any way by the clients on the guest network until the "answer" is sent back to 192.168.168.201.
(This goes for all VLANs -- be they "guest", IoT, "friendly" wired, or what have you -- each gets their own services, tailored to the specific needs)
I agree, they should be easy - just a SMOP - a Small Matter Of Programming. Unfortunately firewall rules are a form of programming, and, when last I checked, programming was considerably easier to do poorly than to do well. That is why I am not simply looking for "Here's a set of perfect guest network firewall rules; use these", but an explanation of why someone chose these rules, and the advantages, tradeoffs, and security risks involved.
What firewall rules do you use, and why? What were your goals with those rules?
Well, yes and no. It's literally a little point and derp interface in LuCi to turn on forwarding from guest zone to wan and then if you have no other forwarding enabled, then it's by default isolated in OpenWRT.
If you want more than just "the guests only get access to the internet" then you have to decide what exactly you want and that will require solving "programming" problems, but it's more about deciding what you want than about what other people wanted and did.
One set of rules preventing access to the router itself (to disallow guest from reaching the router's SSH server or webui) and to selectively allow access to specific services (router's DNS and DHCP server)
Another set of rules regulating traffic forwarding. Usually you'll have one rule accepting traffic from the guest interface (e.g. wlan0-1) to wan (e.g. eth1) and another rule simply rejecting/dropping all traffic from the guest interface to any destination
This should give you some sane baseline from where you can further tighten the setup. I for example also intercept DNS traffic and forcibly redirect it to the router DNS in order to force all guest clients through the router DNS, even if they have manually configured resolvers such as 8.8.8.8.
This rule rewrites the source IP of all traffic leaving the WAN interface to the current address of the wan interface. Its a clunky way to do iptables -t nat -A POSTROUTING -o $wan_iface -j MASQUERADE.
Most router systems will have some form of NAT (SNAT or MSQUERADE) already set up by default so it is usually out of the scope of guest network rules, it should not be needed.
Yes. The approach is to first have one rule allowing traffic from the guest interface to the wan interface, and a second rule simply disallowing all traffic from the guest interface. Basically turn the blacklist approach you describe into a whitelist.
It essentially does what I described above; stage rules to disallow access to the router but accept DNS and DHCP, add forward rules to drop traffic from the guest interface/subnet anywhere else, add a rule to allow traffic from the guest/interface subnet to wan and some further special NAT exemption rules related to some transparent proxy setup.
This is wise advice -- rules are easier to check if the default is "block everything" with specific exceptions for what you want to allow, rather than the reverse.
@Pippo -- My approach is to only have traffic to/from a specific network's clients on that network segment. My service hosts get their upstream data through another network. That provides several benefits; potentially hostile guest-network clients can't snoop the service-host upstream traffic, service hosts can't be "fooled" by guest-network clients, and I can tighten down the guest-network firewall rules without impacting the services' ability to reach their upstream sources. Encryption, for example for DNS, is independent of this and can be applied as desired.
@jow, thank you for providing an excellent explanation and for initiating a good conversation about the pros and cons of different approaches. You replies are very helpful to me, and hopefully to other people who have this question.