Trying to be concise here, please ask for more info if required. I am running an SG-1100 with a UniFi stack behind it. Created some VLANs in pfSense. Some VLANs are blocked off from the others by using the “Pass VLANxx.net except to RFC1918” rule.
Machines to all VLANs that have that rule enabled have web page loading speed issues. Some sites are good (e.d. apple.com), some are quite bad (citrix.com loads in 90 seconds).
This is consistent over several VLANs and computers, i.e. apple.com loads fast on all computers and citrix.com very slowly on all computers tested.
I tried:
reboot SG-1100, no change
disable the !RFC1918 rule: no more problems
create single block rules to / from each VLAN: no more problems
WiFi and Ethernet, no difference
I have a firewall rule for all VLANs to pass traffic to “This firewall” port 53 (DNS)
I have pfBlocker running, Avahi mDNS, that’s it.
Thanks for having a look Meanwhile I tried to troubleshoot further and found an error message in DNSBL:
“DNSBL (unbound mode) is out of sync. Perform a force reload to correct”.
Performing the force reload on DNSBL only didn’t fix it. The error message in the pfSense dashboard went away, but the pages still didn’t load as they should.
Then I did a full force reload and things appear to be good now, but I’ll need to give it some more time to be sure.
The interesting thing is, why VLANs with the complete RFC1918 block were affected, while the other VLANs were not.
Edit: nope, issue still there. Appears to be intermittent. But now I know where to look for clues.
I may have found the cause of the issue. By blocking RFC1918 networks for selected VLANs I also block 10.10.10.1 which is apparently needed by pfBlocker to operate. So I slimmed down the alias to only 192.168.0.0/16 networks, which in this case is all I need as all of my VLANs are in that range.
Sounds strange, perhaps I’m not getting what you are doing but I believe blocking RFC1918 ought to be on the WAN side. If you are trying to isolate your vlan, which is what I’m guessing, might be better to create an alias with your subnets and use that in your rules.
@neogrid : yes blocking inter-VLAN traffic is exactly what I’ve been using the RFC1918 rule for. I found that method in a tutorial when I was still using UniFi USG and that worked like a charm.
When I moved up to pfSense I set up firewall rules from scratch but I adopted that method and used it in pfSense too. Everything worked as expected. But apparently the 10.10.10.1 LAN address is used by pfBlockerNG and it went unnoticed to my inexperienced eye.
Like I said in my previous post, I created a new alias with only my own subnets like you advise met to do. This works fine indeed.
Thanks,
Pete
When I started with pfSense I had so many rules it was tough to fix problems, having fewer was easier for me, so using the alias feature keeps things a bit tidy. There is RFC1918 setting on the interfaces, so perhaps when you use it elsewhere there might be unexpected effects.
You can also change those IP addresses that pfblocker uses if it conflicts with something you have setup.
OP: RFC1918 is for blocking WAN traffic that falls in the “3 private” network range. Don’t block it on interfaces that are used on your private networks or nothing will work.
Personally, I’ve always had better success blocking x-VLAN traffic this way, this is my basic boilerplate layout for allowing all internet on a device but not allowing it to talk to other networks or the gateway except for DNS (this also can be tweaked easily to only allow DNS through the gateway as well). Keep in mind you would want to add rules to allow access to the gateways webconfig for whatever networks you access it on.
@pjdouillard Thanks for tuning in and, well, I actually do want “nothing to work” on that specific VLAN. And blocking RFC1918 on those VLANs is very effective, because there is no way any device can get to my other VLANs. It did a great job on my USG and I had no problems whatsoever.
It’s just that now that I’m on pfSense and using pfBlocker, that the 10.10.10.1 address has to be accessible for the DNSBL engine. Otherwise, blocking RFC1918 would do just fine as it does when I temporarily disable pfBlocker.
Blocking RFC 1918 (what you do) is the same as allowing all except RFC1918 (what I did).
In your rules, I don’t think the allow Guest net will ever be evaluated as any traffic to guest will be in the RFC1918 address range so it will be blocked by the rule above. In order to make that to work you’ll need to move the guest net rule above the block rule.
The first rule does get evaluated take a look at the left hand side with the state count and data usage.
If I moved it above that rule then traffic would be able to travel anywhere. The destination of anything outside the firewall is not RFC1918 traffic and therefore will pass because of the first rule, and the RFC1918 rule won’t be applied as it isn’t destined for a RFC1918 host
Yes I see the state count now, sorry. Don’t know what came over me. but you’re right and I was plain wrong.
I see these are FW rules for your GUEST VLAN, right? You want to prevent GUEST traffic to get to the rest of your network by blocking RFC1918 destinations (rule #2). and then allow any other GUEST traffic to go elsewhere (rule #3), which is basically only the gateway out to the internet.
Your rule #1 (DNS port 53) I put in a group for all VLANs so I wouldn’t need to replicate it for each VLAN separately.
Actually this is how I set it up, but I combined your rules #2 and #3 in one pass-except-RFC1918 rule.
And because of the pfBlocker interaction on 10.10.10.1, I modified the RFC1918 alias to a new alias containing only the network range that my VLANs are in, so the 10.0.0.0/8 is no longer in the alias.
@CableDude, if you want “nothing to work” on a vlan, you don’t put any rules
RFC1918 is only for WAN traffic. If you start messing with it on internal networks, your mileage will vary (like the problem you stated) and wierd behavior will be hard to debug because pfsense doesn’t log RFC1918 blocked traffic. So, Pro Tip: don’t mess with RFC1918 on internal networks and you will do great.
Of course, I meant nothing to work except internet access of course. I read about the WAN traffic RFC1918 rule, thanks for that.
Meanwhile, like I stated above several times, I removed the RFC1918 alias and created a new alias blocking only the subnet my VLANs are in. So everything now works as expected.
That said, the RFC1918 block has worked perfectly fine on my previous USG router/firewall. This was more luck than wisdom, because on the USG there were no LAN addresses that needed to be accessed.
That said, there are several YouTube turorials for UniFi USG that use the RFC1918 alias to isolate an IoT VLAN.
But I agree with you: it doesn’t work well on pfSense.
@pjdouillard im missing something on why you think using the RFC1918 rules on a LAN is a bad idea? It’s a very common and easy way of allowing full internet and blocking all x-vlan traffic
@runDMG : if you know what you are doing network-wise, yes you can use it to achieve what you stated.
RFC 1918 is for the 3 private networks that allow us to build internal networks ad-nauseum. If you use the built-in firewall functionality to block it on your internal networks, then they are not internal networks anymore and your firewall is now an Internet router that forwards only legit public IPs. Are you an ISP of some sort or something similar? Probably not in 99.999% of the time so there is no reason to use that for blocking/filtering traffic as the troubleshooting is beyond intermediate skills.
Meanwhile I tried to troubleshoot further and found an error message in DNSBL:
