Guest network. Internet access only.
I'd like to have a guest (wifi) network that has full access to internet without seeing my other subnets/VLANS.
Wifi AP and VLAN interface are already configured and working, but I need a robust way to limit the traffic to internet access only.
I have seen some videos and forum topics making a "pass all" rule and then place blocking rules on top, avoiding the guest vlan talk to those specific those restricted vlans.
But as soon as I add a new vlan, that will be accessible from guest network unless I remember to update the guest network rules at the same time. So I could accidentally give guests unwanted access by hitting the allow all rule.
So is there a better way to do this, maybe in a single rule like pass all "GUEST net" to "internet" ?
Just create an alias that blocks access to all rfc1918 space... So as long as your vlan you bring up is in rfc1918 space it would blocked...
So you have rules that allow to what you want
Block all access rfc1818
block all access "this firewall" This keep guest from accessing your wan public IP, even if changes or you bring up other wan that are on public, etc.
Allow all, ie internet
No the destination is rfc1918 alias not the source.. Lets see exactly what you put in the alias.
And dns is UDP most of the time, not tcp. You need to allow both.. Your not allowing for ntp or even to ping the firewall... So you can even check if you have connectivity...
Here is a sample basic config that allow to ask for dns to pfsense, and ntp and ping..
You don't have to use reject if you don't want - but sometimes its better to let the local client know, hey that is blocked vs them waiting for timeouts and doing retransmissions.
Rules are evaluated top down, first rule to trigger wins, no other rules are evaluated. Since your vlan is more than likely some rfc1918 space, your 2nd rule there would block it from going anywhere as the dest.. So the only thing that would ever work on that would be query to dns via TCP.
I'd also allow tcp/853 and turn on DNSoverTLS in "DNS Resolver". Android for example can already use those.
Why would you want to run dot over your local network? Seems pretty pointless, is this local network of your hostile? Do you have something sniffing dns traffic on it? All your going to do allowing that is slow down your dns queries. And use more resources for something as simple as dns query.
If you want pfsense resolver to forward and use dot, sure turn that on - but little reason to run it on your local secure network.
If anything I would block it from going outbound, I don't want iot devices for example hiding their dns queries from me. I have it blocked on my roku vlan.. And putting together a list of doh servers to block them as well.. dot is easy to block since it uses standard port.. but freaking doh - just going to be on the standard ssl port - bastards!
So far no hits on the dot block, but can you as soon as I see any hits on that will be investigating what devices are doing it - and more than likely that device will be off my network.. If there is not a simple way to disable it on the device.
but little reason to run it on your local secure network.
Same question/reason why one is/should be running HTTPS in his network. Of course I trust my home network. Why shouldn't I. But that's not the (main) reason to use HTTPS or DoT in that case, but to widen and increase usage of "TLS"-type protocols instead of unencrypted ones. So if I can simply (and with pfSense it IS simple thanks to the work on unbound and the ACME package) run secure versions of the same services, I'll do that :)
Blocking outside DNS servers is another good way to stay/force them to use the local resolver instead of going rogue and just using any DNS they want. I'm running that on most of my VLAN segments, too. Otherwise DNS Blacklisting would be pretty pointless ;)
And DoH... yeah it's another Pandora's Box yet to come... :( Already have the canary domain NX'ed with a
local-zone: "use-application-dns.net" static
entry in my DNS Resolver custom options box, so at least those in the network that have an affinity to firefox won't get auto-DOH'ed hopefully.
but to widen and increase usage of "TLS"-type protocols instead of unencrypted ones
Yeah ok - for where it makes sense sure... But something that is suppose to take ms to perform like a simple dns query has no business having to use tcp and then the even more overhead of tls on top of that..
Web gui interfaces are one thing.. But tcp and tls do nothing but add overhead and complexity to something as simple as dns.. And zero point to adding that on a secure network..