Squid provides a tunable HTTP cache with traffic throttling. As with all cache servers, it trades disk I/O for network I/O. Your performance gain is largely dependent your bandwidth, the number of users, traffic volume, and the diversity of that traffic.
Significantly, there is a pretty cool chain here, and Squid is the heart of the whole thing. HAVP, the anti-virus proxy, runs as the parent of Squid, which in turn uses SquidGuard to filter content. All web requests travel through Squid’s cache that contains (at least) twice-filtered content. This saves both bandwidth and scanning cycles for any subsequent reference to that content.
All packages are installed through the Packages menu on the System pull-down. Once installed, you need to configure Squid from Services->Proxy Server. We need to configure General settings and cache settings.
Most of the General settings are self-explanatory and PFSense has a tutorial to assist. The easy answer is that five fields have to be set as shown in Table 1.
|Proxy Interface||Interface Squid is bound to||LAN|
|Allow Users on Interface||Do not require separate subnet enumeration.||Checked|
|Transparent Proxy||Operate without separate network client configuration, everything through the proxy.||Checked|
|Log Store Directory||Where the logs live.||/var/squid/log|
|Proxy Port||Where other processes can find the proxy server, the default||3128|
Table 1: Squid general settings
Figure 3 shows the settings for Cerberus.
Figure 3: Squid proxy settings
And Figure 4 has a few more.
Figure 4: More Squid proxy settings
General Settings are now done. So save’ em and move on to the Cache Management Tab.
We need to do some math before we determine cache size values. The temptation, since we have gobs of our 250 GB disk available, is to use a large chunk for web caching. The thing is that Squid uses an in-memory index to address the cache. So it is best to balance memory against disk cache size.
The Squid User Guide recommends 5 MB of memory for every Gigabyte of disk cache (you don’t want to be thrashing, incurring a high swap rate). So determine how many megabytes of memory you have to spare for caching, divide that by 5, and you have the number of Gigabytes you should allocate to your cache.
With Cerberus under load and largely due to Snort, I run at 80% memory usage (according to System->Status), giving me about 600 MB free. I want some headroom for processing peaks, about half, so I have 300 MB available for my in-memory cache. Dividing that by the 5 to 1 guideline, I end up with a disk cache size of 60 GB.
Having calculated our sizes, we are ready to fill in the Cache Management configuration tab values, as summarized in Table 2.
|Hard disk cache size||Disk size limit in megabytes||61400|
|Hard disk cache location||Where the cache is stored||/var/squid/log|
|Memory cache size||Megabytes of memory cache||300|
|Minimum Object Size||Smallest object to cache, in kilobytes.||0 (no limit)|
|Maximum Object Size||Largest object to cache, in kilobytes||256|
Table 2: Squid Cache Management configuration tab values
I have also tweaked the optional tuning values: used threaded access to the UFS file system and since I have cycles to spare and a large cache, I’ve doubled the number of level 1 directories. I’ve also changed the memory replacement policy to Heap-LFUDA (Least Frequently Used with Dynamic Aging).
Figure 5 shows the settings for Cerberus.
Figure 5: Squid Cache Management settings
To verify your Squid install, check the System Log (Status->System Log). If you need to track down any issues, there is a more detailed log you can use. Execute a BSD command (Diagnostics->Command) to access it; it is located here: /var/squid/log/cache and should look like Figure 6.
Figure 6: Squid cache.log
Additionally, to review web accesses, you can take a look at the access.log file in the same directory. Or install the partially-integrated Squid reporting tool, LightSquid, which gives you a view of cache hits, including Top Sites and hit percentages.
With Squid installed, we are done with the prerequisites. Let’s start the main event, the functional upgrades needed to become a UTM.