If you use pfBlocker, check the DNSBL webserver config. Go to Firewall / pfBlocker / DNSBL and scroll down until you see “virtual IP address” and see what IP is configured as VIP. If it is in the RFC1918 range, and there is no way it isn’t, your guests will experience slow web page loading for specific web pages because pfBlocker is trying to forward rejected DNS requests to this address, but cannot reach it from the devices that are connected to the GUEST VLAN.
You may not be aware of it because, well, you probably are not connected to the GUEST network at all.
Just change the alias to whatever local networks you have in your VLANs and your GUEST network will be as fast as your own secure network.
I just used the guest network as an example. these 3 rules are setup for all of my networks( except for the untaged lan which only allows unifi adoption to the controller) so i know there is no speed issues with any of the networks
If you look at the rules I have DNS to the firewall set to allow, therefore there is no blocking of any DNS from the gateway (and pfblocker) to the hosts on that network.
To each their own on how they want to setup their networks, there is definitely more than one effective way to setup your firewall rules but to say using any RFC1918 rules inside of LAN networks, to me anyway, is misguided
I am only trying to do you a favour here, in case your setup should give you issues like I had. I’m trying to help, not to say you are wrong or right. I already agreed with you that using the RFC1918 rule is an effective way to block inter VLAN traffic and - like in my own network while I still had the RDC1918 block in place like you have - everything worked as it should except some web pages would take a little longer to load. I said some web pages would take longer, most would load just fine.
I can only see one screen shot of how your pfSense box is set up so I don’t know what other settings you have and what packages you have installed. But if it’s anwhere like my pfSense setup, you could - or should - be able to experience similar issues that I have found the fix for.
That is why I asked you to have a look in your pfBlocker settings page as you just mentioned you are in fact using that package. I can only assume that you have the “Enable DNSBL” checked. If you don’t, you won’t experience the issue anyway.
If you do in fact have DNSBL enabled, your RFC1918 rule may be blocking that IP. Have a look at this screen shot:
Check the virtual IP address that is set in pfBlocker DNSBL settings. In my case it is the default: 10.10.10.1. Then open up a terminal (Mac) or CMD (Win) session and see if you can ping that IP address:
You see that in my current setup I can ping that IP successfully, whereas under the RFC1918 rule I could not, because, obviously, 10.10.10.1 is in the RFC1918 network range. If I can’t ping it, other clients on the network can’t ping it and pfBlocker is crippled to operate from affected VLANs.
If pfBlocker cannot reach that IP it will keep trying and give up eventually. The rejected DNS requests vary from url to url and most sites loaded fine, but some took more time due to this circumstance.
This whole thing has absolutely nothing to do with your DNS port 53 rule, because that is the initial DNS request route for clients on the network. That rule is fine and should not be altered, but it is by no means helping pfBlocker with this issue. I have the very same DNS port 53 rule in place and had issues still.
I took 15 minutes of my time because I value your efforts of trying to help me, so I am trying to help you. I hope this elaboration is useful to you. Like I said I know nothing about your config so it may well be that you have set something different and don’t experience issues like mine. But if you (ever) do, the above may help.
Pete
@CableDude just skimmed the entries above. It kinda strike me you’re over thinking it perhaps because you’re trying to apply a rule you have used before.
I’m running several vlans, while I didn’t consider using RFC1918, I used an alias for my vlans instead, it then gives me precise control in my rules. My IoT vlan can’t access other vlans while having accessing to pfBlocker without too much effort.
Hi! Not sure which entries you mean, but like I wrote I’m not using RFC1918 anymore. I have a new alias containing only the subnets my VLANs are in and now all is well. So it appears as though your setup and mine are identical.
FTR I have no more problems. I just wanted to supply some information to member “runDMG” in case he encounters the same issues I did.
The ones above 
just skimmed it …
Ok if you’re using the alias feature you’ll probably find it easier to fine tune your network. It took me ages to suss out a lot of the “obvious” steps.
If you add a guest vlan you’ll need an exception to access the AP.
If you have vlan for your IP cams then you might want to control traffic even more precisely.
Found the alias feature really helps with the above.
Do you mean these entries? This is what I used until last week:
I currently only use the 192.168.0.0/16 subnet in a new alias as all of my VLANs are within that subnet.
Yes I’ve used the alias feature all along, starting years ago on my UniFi USG.
Cams
I do in fact have a VLAN for my cams (all UniFi protect). I am using two aliases for the cams FW rules:
- cams IP addresses
- unifi protect ports on the cloud key G2+
DHCP:
- Every cam has a static IP address
- Under DHCP server I “Deny unknown clients” with setting “Allow known clients from only this interface”
- Under DHCP server - scroll down to “Other options” - MAC allow: enter MAC range of cams. I ordered a bulk so all have identical beginning octets
This way it’s a little harder for a hacker with physical access to a cam wire to get his/her computer hooked up. Just a little.
Rules:
#1 Allow alias to access CKG2+ IP on Alias
#3 Block all to all (block anything else)
Then in order to be able to add a new camera I need to disable the DHCP settings above temporarily and activate an extra rule:
#2 Allow to access CKG2+ IP on Alias
As soon as the new camera has found its place in the cams VLAN I disable that rule again and set the DHCP security options again.
Guest VLAN
Not sure what you mean by “you’ll need an exception to access the AP.”
Yes aliases rock 
No no I just mean the posts in this thread
Actually I thought about my outside Cams, yes they could plug their laptop to my network via the ethernet cable. However, it would be tricky to dismantle the camera housing but possible, though I have enabled 802.1x (RADIUS running on pfsense) so a user name and password is also required before doing anything on that cable. If they get past all that, then all they can see is the CAM vlan which traffic cannot leave.
I’ve setup my GUEST vlan to be isolated from the other vlans but my AP is on my management vlan, so I’ve added a rule so that it can access that IP address only, so guests can have wifi That’s my exception (to the isolation).
Sounds like great minds think alike but fools … 
Okay, I haven’t setup RADIUS, heard of it though. Maybe I should give it some thought.
I haven’t done any ruling for my guest AP, I just setup a VLAN only for that VLAN ID in unifi and the guests can access the AP.
Yes you might want to consider RADIUS, with my AP each user has their own password which is just another layer of protection. Then it came in handy for the cams, could also further lock down ethernet ports in the house, but by then the assailants are in my house and will just walk off with my kit !!
Oh sorry, I misunderstood what you were referring to.
The last comment in regards to the RFC1918 wasn’t direct toward you, since you are obviously doing that it was about the previous conversation i was having
I use the floating rules option in pfBlocker for access to the VIP
Glad everything is working as it should be tho for you
1 Like
Okay, I get it now. I did not have that check box ticked and I didn’t know it existed for this purpose. I just tried it to see what would happen and there are two additional floating rules added allowing Pass to 10.10.10.1. This of course explains why you don’t have speed issues despite using the RFC1918 rule. Thank you for clearin that up! Learned something today 