Pass rule with !RFC1918 (pass except local networks) very slow
-
I set up multiple VLANs on an SG-1100 running pfSense+. I started at 2.4.5 but now I'm on v.21.02-p1.
I got complaints about slow web page loading from users on VLANs where I set the "Pass all except Alias" type of rule, being VLANs 30, 50, 60 and 70. See screen shot below.
I tested all of the affected VLANs and the complaints were more than justified: some web pages like Citrix.com took minutes (!) to load. Others were okay.
I myself are on VLAN10 with no block rules and my web page loading is almost instantaneous. When edit the VLAN30 rule set by disabling the !RFC1918 rule, the issue is solved immediately.
What I tried already:
- Rebooting the SG-1100 did not help
- When I disable the !RFC1918 rule and add simple block rules for blocking VLAN30.net to VLAN40.net (and similar rules for blocking to the other VLANs) the VLAN30 web page loading is as it should be. So it would seem that the !RFC1918 rule is causing the delays.
- I tried both WiFi and Ethernet connections, no difference
- I tested loading speeds for different web pages, with interesting differences:
o Apple.com: 1.5 seconds
o Citrix.com: > minute
o Macrumours.com: most is there in 2 seconds but the pages keeps loading
o bhphotovideo.com: same
o cnn.com: 75 seconds
Any ideas? Am I doing something wrong?
Thanks!
Pete -
@cabledude are the clients able to resolve DNS?
If you block all local subnets you also block access to pfsense's DNS server.......
-
@heper Sorry, forgot to mention I also have a DNS rule set up:
VLANs_DNS is an interface group which should be executed after floating and before single VLAN rules.
Also, if DNS would in fact be inaccessible, wouldn't that make pages not load at all?
-
Apparently there is an issue with pfBlockerng-devel DNSBL.
The pfBlocker dashboard widget said “DNSBL (unbound mode) is out of sync. Perform a force reload to correct”.
I did a full force reload and all was fine for a couple of minutes, then the problem returned.
Still it is very odd that only the VLANs with the !RFC1918 block rule are affected. These rules have been deployed months and months ago and have worked flawlessly.
Will need to dive into the latest pfBlockerng updates and forum talk.
-
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.
-
@cabledude
Without DNS server a client cannot resolve DNS.But clients have their own DNS cache.
&
Clients can use multiple DNS servers. If your primary DNS fails, it would try a secondary X seconds later -
@heper Yes, thank you for elaborating on that, I do understand and I have used this in the past for ad blocking scripts on other brands firewalls.
In this case though, DNS is not the issue, but I am now 100% sure that I made a mistake using the RFC1918 rule for LAN side VLAN segregation. This worked flawlessly on my previous (UniFi USG) firewall, but now with pfBlocker there is a conflict.
I created a new alias with only the local networks used by my VLANs (all within 192.168.0.0/16) and this has definitely solved the issue of slow web page loading.Thanks for your input!
Pete