Network Traffic Monitoring with vnStat

Network traffic monitoring

Configuring settings with vnStat under pfSense.

vnStat is a console-based program for network traffic monitoring in Linux and BSD. It keeps a log of hourly, daily, and monthly network traffic for the selected interfaces. It uses the network interface statistics provided by the kernel as an information source. This means two things. [1] vnStat isn’t a packet sniffer. But equally important [2] vnStat does not heavily tax system resources. A Linux kernel of at least 2.2 is required. Here, we are concerned with installing and configuring vnStat under pfSense.

Network Traffic Monitoring with vnStat: Installation and Configuration

To install vnStat under pfSense, navigate to¬†System -> Packages and click on the “Available Packages” tab. Scroll down the list of available packages to vnStat, and press the “plus” button on the right side of the entry. On the next page, press the “Confirm” button to confirm installation, which should not take more than a few minutes.

In order to create a vnStat database for an interface, you need to start an SSH session with your pfSense box or access it directly from the console. Then type “8” at the pfSense menu to start a shell session. At the command line, type the following:

vnstat -u -i eth0

where eth0 is the interface to be monitored.

Network traffic monitoring

Viewing stats for the LAN interface with vnStat.

Once installation is complete, you can begin network traffic monitoring. There should be an entry under the Status menu called “Vnstat2“. Navigate to Status -> Vnstat2 and click on the “Config” tab for VnStat configuration options. The “MonthRotate” dropdown box allows you to specify the day of month that months are expected to change. This is usually set to 1, but it can be set to alternate values. For example, if you need to track monthly billed traffic where the billing period does not start on the first day of the month, you can change this parameter accordingly. The “Enable php frontend for vnstat” check box allows you to enable the vnstat frontend (no login needed).

On the second tab, “Vnstati“, you can see pie charts, bar graphs and tables detailing usage of the interface selected from the dropdown box. You can only see information, however, with interfaces for which databases were created. By clicking on the “Access vnstat php frontend” tab, you can access the php frontend, if it is installed and enabled (you can download this frontend from From the “vnstat info” tab, you can see information about selected interfaces (once you select an interface, the information presented can be filtered via the dropdown box at the top – for example, you can choose to see only activity for the last 24 hours). The “vnstat summary” tab allows you to see a summary of all interfaces for which databases were created.

External Links:

Vnstat at

PHP frontend for VnStat at

Unbound DNS: Additional Settings

In the previous article, we introduced Unbound and covered some of the most common settings. In this article, we will cover some additional settings.

Under Services -> Unbound DNS, the “Unbound DNS Settings” tab has a subheading called “Statistics“. Unbound provides various statistics relating to the number of queries that Unbound handles. These statistics are printed to the Unbound log file, which can be found at /var/log/unbound.log. This log file is viewable via Status: Package logs or via the command line using the command “clog“.

There are a few configurable options. The “Enable Statistics” check box allows you to enable the use of statistics. Checking this will cause Unbound to generate statistics which can be used to generate other information. The “Statistics Interval” dropdown box allows you to select the time as to when statistics will be written to the Unbound log file (anywhere from 5 minutes to 2 hours). If “Yes” is selected in the “Enter Cumulative Statistics” dropdown box, the statistics collected will be cumulative and will not be cleared after each report has been logged. The “Extended Statistics” check box will cause Unbound to log the type of queries that have been handled by the resolver. Otherwise, Unbound only logs the total number of queries collected.

Advanced Settings and ACL Lists

The “Unbound DNS Advanced Settings” tab has a number of additional settings that may be useful. The “Hide Identity” check box will cause Unbound (if checked) to refuse id.server and hostname.bin queries. The “Hide Version” checkbox will cause Unbound (if checked) to refuse version.server and version.bind queries. As a result, any attempt to hack Unbound will potentially be thwarted by depriving the hacker of this vital information. The “Log level verbosity” check box allows you to select the logging verbosity. “Level 0” specifies no verbosity (only errors are logged), while each higher level of logging verbosity (up to Level 5) provides additional information. The “Message Cache Size” dropdown box allows you to alter the size of the message cache. The message cache stores DNS rcodes and validation statuses. The RRSet cache will automatically be set to twice this amount (the RRSet cache contains the RR data).

The “Outgoing TCP Buffers” dropdown box allows you to select the number of outgoing TCP buffers to allocate per thread. If the value is set to 0, no TCP queries to authoritative servers are done. The “Incoming TCP Buffers” dropdown box allows you to select the number of incoming TCP buffers to allocate per thread. Once again, if the value is set to 0, then no TCP queries from clients are accepted.

The next tab is “Unbound DNS ACLs“. Here you can define access control lists for Unbound. Click on the “plus” sign on the right side of the page to add a new ACL. The “ACL name” edit box allows you to provide an ACL name. The “Action” dropdown box allows you to choose what to do with DNS requests that match the specified criteria. “Deny” causes Unbound to stop queries from hosts within the specified netblock. “Refuse” will also stop queries from hosts within the specified netblock, but will send a DNS rcode REFUSED error message back to the client. “Allow” will allow queries from hosts within the specified netblock. “Allow Snoop” will allow recursive and nonrecursive access from hosts within the specified netblock.

At “Networks“, you can press the “plus” button and specify a netblock or series of netblocks (along with descriptions) to which the action will be applied. Finally, you can add a description in the “Description” edit box. When you are done setting up the ACL, press the “Save” button to save the changes (or “Cancel” to cancel).

Unbound also provides various command line utilities to manage your DNS cache server. To remove a name from the cache, type:

unbound-control flush [name]

where [name] is a record of any type (including A, AAAA, NS<SOA, CNAME, DNAME, MX, PTR, SRV and NAPTR). If you want to remove a name of a specific type, then type:

unbound-control flush_type [name] [type]

If you want to flush an entire zone, type:

unbound-control flush_zone [name]

This will remove all information at or below the name from the cache. For example, if you specify .com, all entries below .com will be removed.

To determine the name servers that will be queried to lookup a zone, type:

unbound-control lookup [name]

External Links:

Unbound package at

Web-Based SSH with Anyterm

web-based SSH

Anyterm settings page under pfSense 2.1.3.

Sometimes, you may want to access Secure Shell (SSH) servers but the access point you are using blocks port 22 or whatever port your SSH server is using. Fortunately, there is a solution: web-based SSH makes it possible to access SSH servers through standard web browsers. Respective clients are based on JavaScript/Ajax or JavaScript/WebSockets and can be used to access SSH servers from behind a firewall or proxy.

Anyterm is one such web-based SSH program. It is written in C++ for the server side and JavaScript for the client side, and uses server-side terminal emulation. It also utilizes long polling for client/server communication. The server-side implementation is a stand-alone daemon which is typically used with a reverse proxy, such as Apache’s mod_proxy. Anyterm is licensed under the terms of the GPL.

Anyterm consists of some JavaScript on a web page, an XmlHttpRequest channel on standard ports back to the server, an HTTP proxy and the Anyterm daemon. The daemon uses a pseudo-terminal to communicate with a shell or other application, and includes terminal emulation. Key presses are picked up by the JavaScript, which sends them to the daemon. Changes to the emulated screen are sent from the daemon to the JavaScript which updates its display. SSL can be used to secure the connection, and is recommended.

Web-Based SSH with Anyterm: Installation and Configuration

To install Anyterm in pfSense, navigate to System -> Packages; Anyterm should be at the top or near the top of the list. Press the “plus” button to the right of the listing for Anyterm; on the next screen, click the “Confirm” button to confirm installation. It will take a few minutes for installation to complete, after which there will be a new menu item on the Diagnostics menu (Anyterm).

When you navigate to Diagnostics -> Anyterm, there are two tabs. The first tab, “Settings“, has four options. The first two fields are “Username” and “Password“, in which you can specify the username and password for accessing Anyterm. The third field is “Port“, where you can enter the port that Anyterm will use (default is 8080). The last field is “STunnel Port” where you can enter the STunnel port if you have an STunnel forward. Press the “Save” button at the bottom of the page to save the settings.

You probably want to set up port forwarding for the Anyterm port so you can use Anyterm from other networks. Navigate to Firewall -> NAT, and press the “plus” button on the bottom right to add a new entry. For “Destination port range”, enter the Anyterm port, and for “Redirect target IP“, type the IP of your pfSense system. For “Redirect target port“, enter the Anyterm port again. At “Description”, add a brief description, and leave “Filter rule association” at the default of “Add associated filter rule“. Press the “Save” button to save the entry. Press “Apply changes” on the next page to apply the changes.

web-based SSH

Anyterm in action, used to access the pfSense shell.

You should be able to use Anyterm to gain shell access to pfSense now and thus take full advantage of its web-based SSH capabilities, but you probably want to install STunnel as well so you have an SSL encryption tunnel between you and pfSense. STunnel can be installed from System -> Packages, and installation should only take a minute. Once you install stunnel, it will be an option on the “Services” menu.

Under “STunnel”, there are two tabs: “Tunnels” and “Certificates“. “Listen on IP” and “Listen on port” specifies the listening socket IP address and port. “Certificate” specifies the certificate to use for the listening socket. “Redirects to IP” and “Redirects to Port” specifies the target IP address and port. The “Outgoing source IP” is the IP address to bind to when connecting to the target.

Certificates are managed by requiring the user to provide an RSA key and certificates/chains in PEM format. The Certificates tab will list the configured certificates along with status information, indicating whether the certificate is valid, will expire soon, or is already expired. A check is also performed to make sure the key and certificate matches. Once you finish setting up stunnel, remember to go back to the Anyterm “Settings” tab to enter the STunnel forward port.

By now, you should be able to use web-based SSH to access the shell of your pfSense system from outside your local network by entering your WAN IP address and the Anyterm port. If you installed STunnel, you will have an SSL encryption tunnel, so your web-based SSH session should be relatively secure.

External Links:

The official Anyterm web site

Reverse Proxy Services with Varnish (Part One)

reverse proxy

Backend server settings page for Varnish under pfSense 2.1.3.

I recently ran a series of articles on Squid, a proxy server which began life as a client-side cache and can be used under pfSense as such. In contrast, Varnish is a reverse proxy HTTP accelerator designed for content-heavy dynamic web sites. It is focused exclusively on HTTP, unlike other reverse proxy servers that support other network protocols.

The Varnish Reverse Proxy: Architecture and Performance

Varnish works by storing data in virtual memory and leaving the task of deciding what is stored in memory and what gets paged out to disk to the operating system. This helps avoid the situation where the operating system starts caching data while it is moved to disk by the application. In addition, Varnish is heavily threaded, with each client connection being handled by a separate worker thread, and an overflow queue to handle incoming connections once the configured limit on the number of active worker threads is reached. When the overflow queue limit is reached, incoming connections will be rejected.

Varnish uses the Varnish Configuration Language (VCL), which is used to write hooks that are called at critical points in the handling of each request. When a VCL script is loaded, it is translated to C, compiled into a shared object by the system compiler, and loaded directly into the accelerator.

The creators of Varnish claim that it speeds up delivery by a factor of 300-1000 times, depending on your architecture. When the Varnish cache is enabled, performance is bound by the speed of the network, thus turning web server performance into a non-issue. It is free software licensed under a two-clause BSD license, also known as the FreeBSD license.

The Varnish Reverse Proxy: Installation and Configuration

reverse proxy

The Settings tab in Varnish.

Installation of Varnish under pfSense is similar to installation of other packages. From the pfSense web GUI, navigate to System -> Packages and scroll down. You will see both “Varnish” and “Varnish 3” on the packages list. Click on the “plus” sign to the right of the listing for Varnish 3 to install the Varnish reverse proxy. On the next screen, press the “Confirm” button to confirm that you want the package installed. It should take about 3-4 minutes for installation to complete.

Once Varnish is installed, you will have a new item on the “Services” menu called “Varnish“. If you navigate there, you will see seven tabs covering different settings for the Varnish reverse proxy server: “Backends“, “Settings“, “Custom VCL“, “LB Directors“, ‘XMLRPC Sync“, “View Configuration“, and “VarnishSTAT“. Before you can enable Varnish, you need to configure at least one backend server, so click on the “Backends” tab.

Varnish has a concept of “backend” or “origin” servers. A backend server is the server providing the content Varnish will accelerate. To add a backend server, click on the “plus” button on the “Backends” tab. There are four sections on this page. “Backend settings” covers the most basic settings. “Backend name” is the name of the backend web server, and “IP address” is the IP address (on your local network) of the backend web server. At “Port“, you enter the port of the web server (usually 80), and for “Description“, you can enter a description.

The next section is “Performance metrics“. “First byte timeout” represents the time to wait for the first byte for the backend and the time to wait between each received byte. “Connect timeout” is simply the time to wait for a backend connection.

Next is “Probe settings“. If this is configured properly, the Varnish reverse proxy will check the health of each backend with a probe. “Probe URL” is the URL that Varnish will use to ensure that the backend is healthy. “Probe interval” specifies how often we should poll. “Timeout” simply specifies the timeout of the probe; this is the amount of time (in seconds) that Varnish will wait for a backend probe. “Probe Window” specifies how many probes Varnish will retain when considering backend health. “Threshold” specifies how many of the probes specified by “Window” must have succeeded for us to consider the backend healthy. Finally, checking the “Disable Probe” check box disables probing for this backend. In the last section, “Backend Mappings“, you can map either a hostname or a URL to this server. It can either match a string or a regular expression.

The second tab is the “Settings” tab. Under “Daemon options” you can enable Varnish by checking the “Enable Varnish” check box. At “Listening port” you can set the port Varnish will listen on. The “Management interface” specifies the IP address and port for the management interface, and “Advanced startup options” specifies any startup options to include in the rc.d configuration file.

If you specify settings for these options and check the “Enable Varnish” check box, you should have Varnish up and running and working with any web servers you specified as a backend. There are several other settings that you might find useful, and we will cover those in the next article.

External Links:

The official Varnish web site

Varnish at Wikipedia

Squid Proxy Configuration in pfSense

Squid proxy

Installing Squid under pfSense 2.1.3.

Squid is a proxy server and web cache daemon. It was originally developed as part of the Harvest project at the University of Colorado Boulder. Further work on the program was completed at the University of California, San Diego (UCSD) and funded via two grants from the National Science Foundation. Duane Wessels forked the last pre-commercial version of Harvest and renamed it Squid, and Squid version 1.0.0 was released in July 1996. It has a number of uses. Under pfSense, it can be used to cache repeated requests.

Squid Proxy Installation

Installing and configuring a Squid proxy server under pfSense is relatively easy. From the pfSense web GUI, go to the top menu and navigate to System -> Preferences. Scroll down to “squid” on the list of packages, and click on the “plus” button on the right to install Squid. On the next screen, press the “Confirm” button to confirm that you want to install Squid. It will take a few minutes for the package installer to unpack and install Squid.

Squid Proxy Configuration

Once installation is complete, “Proxy Server” will show up as an option under Services. Navigate to Services -> Proxy Server to configure Squid. Most users will find the default settings to be acceptable, but there are several settings worth noting. There are 7 tabs in the Squid proxy settings: General, Upstream Proxy, Cache Mgmt, Access Control, Traffic Mgmt, Auth Settings, and Local Users.

Squid proxy

The General settings tab in Squid proxy configuration.

General Settings: This covers the most commonly configured Squid proxy settings. The first setting, “Proxy Interface“, determines which interface or interfaces the proxy will bind to. You probably want to leave this set to “LAN” so that the proxy server is accessible to hosts connected. You probably want to leave “Allow users on interface” checked, to allow users connected to the interface selected in the Proxy Interface field to use the proxy. You probably also want to check the “Transparent proxy” check box so all requests for destination port 80 will be forwarded to the proxy server.

Upstream Proxy: If you want Squid to forward requests to an upstream proxy server, you can enable forwarding here. There are also settings to specify the IP address/hostname of the proxy, TCP and ICP port, and username and password, if the upstream proxy requires them.

Cache Mgmt: This controls a number of settings relating to the cache size. “Hard disk cache size” sets the total amount of hard disk space Squid will use to cache objects. If you have a large hard drive, you can increase this setting to cache more objects; otherwise you can probably leave it at the default value (100 MB).

Memory cache size” is the amount of physical RAM to be used for negative cache and in-transit objects. Objects that squid cannot store in memory end up getting swapped to disk which is much slower than RAM. Squid recommends that this setting should be 50% or less of the installed RAM.

Maximum object size” sets the maximum size of objects saved on disk. The default value is 4 KB. You can increase this parameter to save bandwidth, or lower it to improve speed. Most cache hits tend to take place on small files, although you probably want to increase this parameter from the default of 4 KB.

Access Control: This controls a number of settings regarding who is allowed to access the proxy server. In “Allowed subnets“, you can enter each subnet that is allowed to use the proxy (the proxy interface subnet specified in “General” is already an allowed subnet, so you don’t have to specify it here). “Unrestricted IPs” allows you to specify IP addresses that will not be filtered out by the other access control directives set out in this section. “Banned host addresses” allows you to specify IP addresses that are not allowed to use the proxy. “Whitelist” allows you to specify domains that will be accessible to users that are allowed to use the proxy. “Blacklist” allows you to specify domains that will be blocked to users that are allowed to use the proxy.

Traffic Mgmt: This controls a number of traffic settings. “Maximum download size” limits the maximum total download size to the size specified here (the default is no limit). “Maximum upload size” limits the maximum total upload size to the size specified here (the default is no limit). “Overall bandwidth throttling” specifies the bandwidth throttle for downloads; users will gradually have their download speed increased to this value (default is no throttling). “Per host throttling” specifies the download throttling per host (again, the default is no throttling).

Proxy server

The Authentication settings tab.

Auth Settings: Here, you can enable authentication of Squid proxy users. Squid supports local authentication, as well as authentication through an external LDAP, RADIUS or NT server. The default setting is “None” for no authentication.

Local Users: This allows you to set usernames and passwords for individual users. Assuming authentication is enabled and you chose the local authentication option, users will then be able to use the credentials set here to log in to the Squid proxy server.

For basic Squid proxy usage, the above may be all the information you need. If you really want to understand some of the more advanced options, though, you probably should read the Squid man page. You can use these command-line options by [1] executing a command from the Command prompt option in the Diagnostics menu; [2] SSH-ing into your pfSense box; or [3] accessing pfSense directly from the console.

To shut down Squid, issue this command:

squid -k shutdown

To restart squid, issue this command:

/usr/local/sbin/squid -D

However, it should be noted that pfSense seems to start Squid on its own if it notices Squid is not running. Some of the more interesting options are -u port (to specify a different ICP port than 3130; this can also be done from the pfSense GUI), and -z to create swap directories (useful if you have just deleted the cache and want to recreate the swap directories). There is also a loader.conf.local file in the /boot directory with settings that can be configured. The “Squid Package Tuning” document on suggests changing the kern.ipc.nmbclusters parameter from “0” to “32768”. This increases the amount of memory used for socket buffers, and may improve performance.

External Links:

Squid on Wikipedia

How to Set Up a Transparent Squid Proxy Server Using pfSense at

Squid Package Tuning at

Proxy Servers at

pfSense Hardware Requirements

pfSense Hardware RequirementsBefore you set up your pfSense system, you probably want to consider pfSense hardware requirements. The two main factors that will determine your requirements are:

  • Throughput required
  • Features that will be used

If you require less than 10 Mbps of throughput, then even a Pentium I with a 100 MHz CPU will do. If you require greater throughput, the official pfSense website has the following guidelines (they assure us that the guidelines offer a bit of breathing room):

Summary of pfSense Hardware Requirements

pfSense Hardware Requirements
Throughput Minumum CPU Speed Minimum Interface
10-20 Mbps 266 MHz PCI
21-50 Mbps 500 MHz PCI
51-200 Mbps 1 GHz PCI
201-500 Mbps 2 GHz PCI-X or PCI-e
501+ Mbps 3 GHz PCI-X or PCI-e

Virtually all network cards are supported by pfSense, but not all network cards are created equal. Intel Pro 100/1000 NICs have solid driver support in FreeBSD. NICs such as the Realtek 8139, however, do not perform as well and may require slightly more overhead. Moreover, with some NICs, there are some things that may not work properly at all, such as VLANs or promiscuous mode required for bridging. Generally if you are buying NICs for a new deployment, Intel Pros are the most reliable.

In addition to these guidelines, pfSense’s hardware sizing guidance page mentions the following about pfSense features and how they may relate to pfSense hardware requirements:

  • VPN – Heavy use of any VPN services will increase CPU requirements. Encrypting and decrypting traffic is CPU intensive. A CPU’s encrypted throughput is roughly 20 percent of its unencrypted throughput. For example, a 266 MHz CPU will max out around 4 Mbps of IPsec throughput; a 500 MHz CPU can push 10-15 Mbps of IPSec; and relatively new server hardware deployments (Xeon 800 FSB) are pushing over 100 Mbps with plenty of capacity to spare. Encryption cards can, however, reduce CPU requirements. Check the FreeBSD hardware compatibility list (HCL) before making a purchase, but Soekris VPN-1401 seems to be well-supported. In addition, you may have better luck by switching protocols. OpenVPN, for example, requires less CPU usage than L2TP/IPSec. I am not sure how well PPTP competes with OpenVPN, but presumably it is less CPU intensive, if for no other reason than the fact that it only offers 128-bit encryption versus 256 bits for OpenVPN. As always, the most recent pfSense build will likely provide the best performance. The number of connections is not as significant as the overall throughput required.
  • Captive portal – While the primary concern is typically throughput, environments with hundreds of simultaneous captive portal users will require slightly more CPU power than otherwise, thus increasing the pfSense hardware requirements.
  • Large state tables – State table entries require about 1 KB of RAM each. The default state table, when full at 10,000 entries, takes up a little less than 10 MB RAM. For large environments requiring state stables with hundreds of thousands of connections, you will want to ensure adequate RAM is available.
  • Packages – Some of the packages require more RAM; Snort and ntop are two that should not be installed on a system with less than 512 MB RAM. Also, the Squid package is used for caching web content and requires extensive use of a hard disk with a large amount of storage. It is not for use with an embedded installation where writes to the compact flash card are kept to a minimum.

To show how these pfSense hardware requirements work in practice, let’s assume we want to set up a pfSense box for a small office. The office has a 50 Mbps net connection; we want to anticipate future use, but we don’t anticipate the office getting a connection faster than 100 Mbps in the forseable future. We also anticipate making use of VPNs for remote connections to the office, but we don’t plan on having more than a few VPN connections at any given time. Of the packages available, we opt to install Snort. From this information, we can determine our minimum hardware requirements:

  • 1 GHz CPU
  • 512 MB RAM (1 GB recommended)
  • Unencrypted throughput of 50 Mbps; unencrypted throughput of 10 Mbps
  • 100 Mbps network interface cards (1 Gbps recommended)

If we want to have a failover for the firewall, our requirements would include a second machine to be used as a failover. Keep in mind that the firewall’s throughput is only a bottleneck for traffic passing through it. Traffic to and from the Internet from the LAN and the DMZ meet that requirement, as does traffic between the LAN and the DMZ. Traffic between two systems on the LAN, however, or two systems on the DMZ would not be affected.
This is my take on minimum pfSense hardware requirements, but those of you who have experience in deploying pfSense firewalls may have a different take on this. If so, feel free to add your own comments on this subject.

External Links:

pfSense Hardware Requirements and Sizing Guidance at

VPN Protocol Comparison List – provides some guidance as to overhead for the different protocols

How to speed up IPSec, hardware encryption devices? at

© 2013 David Zientara. All rights reserved. Privacy Policy