Interaction between Firewall Rules (pFblocker), Squid and SquidGuard
-
I am using pFsense 2.0.1 on embedded Alix devices. I have installed Squid and Squidguard, which are happily controlling URL-based access to various sites at various times of the day. I have also installed pFblocker. I have set it up initially to use the Spamhaus DROP list (later I will sort out exactly what lists I want to use to block bad stuff, but this one is a start).
To test the settings, I looked in the Spamhuas DROP list text file and found that the first entry is 103.10.188.0/22 - so I tried to ping 103.10.188.1 just for fun. The Firewall log correctly reported that it had rejected the ICMP packets as they arrived from the LAN interface.
Then I tried to browse to 103.10.188.1 from Firefox. Up pops a dialog box asking for a username and password - it is going to this address, which seems to have something there.
But why wasn't it blocked/rejected?
I thought that the Firewall Rule (created by pFblocker) would have detected and dropped the incoming LAN packet from my browser before it ever got to Squid or Squidguard or out onto the public internet.
Is there something I don't understand about how the proxy server (Squid) and proxy filter (SquidGuard) operate and do proxy things on behalf of LAN clients that effectively circumvent the intent of the firewall rules that are created by pFblocker?
My apologies if this has been answered elsewhere - I looked around the tutorials, docs and forum but couldn't see an explanation.
-
pfBlocker applies rules on interfaces(lan,wan,etc) but squid start its connections from localhost. that's why it was not blocked by pfBlocker.
You need to create rules on Floating rules tab to apply pfBlocker rules to squid.
use lan rule format to get reject instead of block for better performance
-
Thanks for the quick and accurate reply. I added a floating rule with source "any" and destination as the blocklist alias, to reject this traffic. It works.
I can also specify "WAN Address" as the source. Squid must be originating the packet from the internal "localhost" interface but of course the source address in the packet will be the WAN address - that has to happen for everything going out the WAN, so that all the various remote hosts out on the public internet can reply. Thus, "WAN Address" matches the source.
Of course, if you have multiple WANs, then you would have to have a rule for each WAN address - so it is easier and more robust to use source "any", thus ensuring that this unwanted traffic is dropped regardless of what new WAN or other interfaces you might add in future.
As a relative newcomer to pFsense it seems a great product. I am implementing it in a number of remote places on low power embedded devices with CF cards. pFsense 2.0.n has worked out-of-the-box, is easy to install, backup and restore and has loads of functionality and ability to see what is going on. My questions seem to always have an answer on the forum. Thanks for a great product - as I get more experience I will be most happy to help others.
-
Is this floating rule good enough to encompass all blocking requirements for the pfblocker alias? In this case I'd like to remove the firewall rule that I have set on the LAN if it is redundant.
I also applied the rule to all of the available Interfaces in the rule, ex: WAN, LAN, OPT. And I chose the "Quick" option.
Thanks.
-
Disable the lan rule and test access to a blocked ip.
If you have the same result on lan and floating rule, then you leave blocking rules only on floating tab. ;)
-
Haha OK I will test…
I was being lazy. :)
Disable the lan rule and test access to a blocked ip.
If you have the same result on lan and floating rule, then you leave blocking rules only on floating tab.
