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 sqweek.com. 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 doc.pfsense.org

PHP frontend for VnStat at sqweek.com

Open Source Software: Costs and Benefits

Some of those accessing this blog are undoubtedly considering deploying pfSense on their home network, or perhaps in a small office/home office (SOHO) environment. For that reason, I thought it might be useful to devote an article to the costs and benefits of using free and open source software (FOSS) versus commercial software and hardware when deploying a firewall/router.

Open Source Software: Factors to Consider

open source software

The Linksys WRT54G, an example of a consumer grade router.

The most obvious factor to consider is the monetary cost. Initially, this would seem to weigh heavily in favor of pfSense and other free firewall software. For $20 to $50, however, you can purchase a small Linksys, Netgear or Asus router, which uses almost no power and supports port forwarding, performs Network Address Translation (NAT), acts as a Dynamic Host Configuration Protocol (DHCP) server, and provides stateful packet filters. If you use Linux and netfilter, or for that matter m0n0wall or pfsense, even if you have an old PC on which to run the software, it will cost you at least a few dollars a month in electricity. Unless you are familiar with the software you are using, you will find it more difficult to configure than one of the cheap consumer-grade routers, so there is an additional investment of time. If you are setting it up for a small business, it will cost more to pay for the employee’s time to set up a Linux or pfSense firewall than the Linksys would cost to buy. If all you require is a router/firewall than can do port forwarding and DHCP, then there are readily available commercial solutions that are affordable.

If you require additional functionality, however, the situation may change. Commercial VPN solutions can be staggeringly expensive. Yet free solutions such as pfSense and m0n0wall will also work. Even taking into account the fact that the free solutions may not have the same features and capabilities of the commercial version, if you need to implement a virtual private network and there is open source software that meets your requirements, then you can achieve substantial savings.


There are additional factors, some of which are related to cost. For example, support: what does it cost, is it available, and how timely is the support? Moreover, what format does support take: phone, e-mail, online forums, service calls, and so on?

open source software

If installing and configuring netfilter, pfSense or another open source solution doesn’t sound intimidating, an old PC may be suitable.

Time is another factor, and this can cut both for and against open source software. Take the case where a business is considering entering into a partnership with another company. This other company is concerned because the partnership requires sending sensitive data, and the business only has a consumer-grade firewall. The IT department could recommend the purchase of an enterprise-level firewall. This will require contacting vendors, getting quotes, passing a quote on to a manager for approval, and then submitting a purchasing order to the accounting department. Or the IT department can just find an old PC, load Linux and netfilter onto it (or m0n0wall or pfSense or IPCop or any one of a number of open source software solutions), and be done with it, especially if time is of the essence. On the other hand, if your IT department is not familiar with Linux or BSD, deploying an open source solution may actually cost you time, so you would be better off seeking a commercial product.

Another related factor is performance. Speed, efficiency, and reliability are important indices of performance. A fast solution that crashes all the time isn’t very useful. Conversely, a reliable software package that runs slowly may not be the best option.

Usability is another factor, and it relates to cost. If the learning curve is very high, then your training costs will rise. You may want to consider whether a product is customizable if it does not do exactly what you want it to do.

It is often important to consider how well-established the product is. The more well-established the software is, the more likely its creators will be around in the future. A larger and more well-established project will also likely have better community support and reliability. You do not want to invest a lot of time into a product that is likely to go away. In this regard, open source software does well. The netfilter project started in 1998; m0n0wall has been around since 2004, and PF, the packet filtering software on top of which pfSense is built, has been part of OpenBSD since 2001.

Even a security product like a firewall involves security implications, which should be an important factor in your choice. Is the product secure, and will it be handling secure data? You want to consider whether it will be opening any security risks, as well as what type of auditing and logging it can produce.

Finally, you will want to review the license agreement closely. Often the free software is not free if you are a business, or there are special restrictions on the number of installations or other criteria. If your company has a legal department or if you have legal counsel, it might not be a bad idea to have them review the license agreement.

Conclusion

It may just be my bias as the owner of a blog devoted to a particular piece of open source software, but I am inclined to think that in many if not most circumstances, you will find open source software to be the more cost-effective and efficient solution. At one end of the spectrum, commercial consumer-grade routers provide a lot of functionality at a low price. At the other end of the spectrum, enterprise-level firewalls often provide a greater level of management control and logging capabilities, which a mid-sized or large company may require. These capabilities often justify the higher cost. But for those who fall in between these two extremes, often open source software provides the better alternative.


External Links:

The True Cost of Open Source – web site devoted to explaining how you can cut development costs and improve performance with open source software.

Open Source Applications: Benefits and Risks at www.networksolutions.com

10 Reasons Open Source Is Good for Business at www.pcworld.com

Failover with CARP in PF: Part One

Failover with CARP in PF

FailoverCommon Address Redundancy Protocol (CARP) is a protocol which allows multiple hosts on the same local network to share a set of IP addresses. Its primary purpose is to provide failover redundancy. It was developed as a non-patent-encumbered alternative to Virtual Router Redundancy Protocol (VRRP), which is defined in RFC 2281 and 3768 and was quite far along towards becoming an IETF-sanctioned standard. It is also an alternative to the Hot Standby Router Protocol (HSRP). It manages failover at the intersection of the link layer and IP layer of the OSI model. Each CARP group has a virtual MAC address, and the CARP advertisements are sent out with this as the source address, which helps switches determine which port the virtual MAC address is currently at.

One of the main purposes of CARP is to ensure that the network will keep functioning even when a firewall goes down because of errors or planned maintenance activities such as upgrades (failover). CARP works by allowing a group of hosts on the same network segment to share an IP address. This group of hosts is referred to as a “redundancy group”. The redundancy group is assigned an IP address that is shared among the group members. Within the group, one host is designated as the master and the other as backups. The master host is the one that currently holds the shared IP; it responds to any traffic or ARP requests directed at it. If the master goes down, one of the backups will inherit the IP address. The handover from one CARP host to another may be authenticated, essentially by setting a shared secret, much like a password. The master then sends out CARP advertisement messages via multicast using the CARP protocol (IP Protocol 112) on a regular basis, and the backup hosts listen for this advertisement. If the advertisements stop, the backup hosts will begin advertising. The advertisement frequency is configurable, and the host which advertises the most frequently is the one most likely to become master in the event of a failure.


CARP is rather similar to VRRP, with a few significant differences:

  • The CARP protocol is address family independent, with the OpenBSD implementation supporting both IPv4 and IPv6.
  • CARP has an “arpbalance” feature that allows multiple hosts to share a single IP address simultaneously (in this configuration, there is a virtual MAC address for each host, but only one IP address).
  • CARP uses a cryptographically strong SHA-1 keyed-hash message authentication code (HMAC) to protect each advertisement.

Some synchronization is required, an at least in the case of PF firewalls, pfsync can handle it. If it is done properly, active connections will be handed over without noticeable interruption. The purpose of pfsync in this context is to act as a virtual network interface specially designed to synchronize state information between PF firewalls. In order to ensure that pfsync meets the packet volume and latency requirements, the initial implementation has no built-in authentication. An attacker who has local link layer access to the subnet used for pfsync traffic can add, change, or remove states from the firewalls. Therefore, it is strongly recommended that a dedicated, trusted network be used for pfsync. This can be as simple as a crossover cable between interfaces on two firewalls.


Failover with CARP: Configuration

Here is a simple example CARP configuration:

sysctl -w net.inet.card.allow=1
ifconfig carp1 create
ifconfig carp1 vhid 1 pass password carpdev em0 \
advskew 100 10.0.0.1 netmask 255.255.255.0

This does the following:

  • Enales receipt of CARP packets (the default setting)
  • Creates a carp(4) interface (carp1)
  • Configures carp1 for virtual host #1, enables a password, sets em0 as the interface belonging to the group, and makes the host a backup die to the advskew of 100 (assuming the master has an advskew less than 100). The shared IP assigned to this group is 10.0.0.1/255.255.255.0.

In the next article, I will cover failover CARP configuration in BSD with some real world scenarios.

External Links:

Firewall Redundancy with CARP and pfsync at openbsd.org

Firewall Failover with pfsync and CARP at countersiege.com

Spam Blocking in BSD: Part Four (spamlogd and spamdb)

spamlogdIn parts one, two and three, I discussed the spamd daemon, how to configure it, and how to set it up for greylisting. In this part, I will discuss spamlogd and spamdb.

Using spamlogd

Spamlogd is a whitelist updater, and it works quietly in the background, recording logged connections to and from your mail servers to keep your whitelist updated. It thus manipulates the spamd database in /var/db/spamd used for greylisting. Spamlogd helps ensure valid e-mail to and from hosts you communicate with regularly goes through with a minimum of fuss.

In order to perform its job properly, spamlogd needs you to log SMTP connections to and from your mail servers (this will enable it to add IP addresses that receive e-mail from you to the whitelist). On OpenBSD 4.1 and later, you can create several pflog interfaces and specify which interface a rule should log to. If you want to separate the data spamlogd needs to read from the rest of your PF logs, create a separate pflog1 interface using this command:

ifconfig pflog1 create

Alternatively, you can create a hostname.pflog1 file that contains only the line “up”. We want to add this to the rules, or if you already have rules for logging, change them accordingly:

pass log (to pflog1) proto tcp from any to $emailserver port $email

pass log (to pflog1) proto tcp from $emailserver to any port smtp


Where $emailserver is the IP address of the e-mail server and $email is the port the server is listening on. Next you need to add:

-l pflog1

to spamlogd’s setup parameters. Now you have separated the spamd-related logging from the rest of the logging. Now, spamlogd will add the IP addresses that receive e-mail you send to the whitelist.

Using spamdb

If you need to view or change the contents of your blacklists, whitelists or greylists, then spamdb should be your main interface to managing the lists. From the earliest times, spamdb offered the capability of adding whitelist entries to the database (spamdb -a x.x.x.x) or deleting entries (spamdb -d x.x.x.x). Now, spamdb has even more capabilities, such as the capability of adding a client to a traplist for greytrapping. A traplist is a key component in greylisting; it contains a list of invalid e-mail addresses on servers for which we handle e-mail. When the spammer connects to our server for the first time, he will be greylisted, just like any client who has not connected to the server before. The second time, if the spammer tries to resend the same e-mail without waiting long enough or if he tries to send an e-mail to an address on the traplist, he will be caught in our tarpit and the SMTP header will be sent 1 byte at a time. The command:

sudo spamdb -T -a <e-mail address>

will add the e-mail address specified to the traplist.


External Links:

spamlogd at openbsd.org

spamdb at openbsd.org

Spam Blocking in BSD with spamd: Part Three (Greylisting)

greylistingIn part one and part two of this series, I discussed the advantages of using spamd and some basic configuration steps. In this article, I will cover greylisting in more detail.

The Problem

Spammers try to use other people’s equipment to send their messages. In addition, the software they install without the legal owner’s permission needs to be lightweight in order to run undetected. Moreover, spammers do not typically consider any individual message they send to be important. From this we can conjecture that the typical spam sender is probably not set up to interpret SMTP status codes correctly, if at all.

The current standard for Internet e-mail transmission is defined in RFC 2821. Section 4.5.4 covers retry strategies, and subsection 4.5.4.1 covers sending strategies. This section specifies the following:

  1. Mail that cannon be transmitted MUST be queued and periodically retried by the sender.
  2. The sender MUST delay retrying a particular destination after one attempt has failed. In general, the retry interval SHOULD be at least 30 minutes; however, more sophisticated and variable strategies will be beneficial when the SMTP clients can determine the reason for non-delivery.
  3. Retries continue until the message is transmitted or the sender gives up; the give-up time generally needs to be at least 4-5 days. The parameters to the retry algorithm MUST be configurable.


The Solution

We can use these requirements to our advantage. When a compromised machine is used to send spam, the sender application tends to try delivery only once, without checking for any results or return codes. Real SMTP implementations interpret SMTP return codes and act on them, as explained above. E-mail, like most other Internet services, are described as best-effort services, with a significant amount of design and development being put into make services such as SMTP fault tolerant. Thus, real mail servers retry if the initial attempt fails with any kind of temporary error.
This is what is so elegant about greylisting. spamd reports a temporary local problem to the client. Well-behaved senders with legitimate messages will try to resend the message later, but spammers have no interest in waiting for the chance to retry, since it will increase their cost of delivering the messages. Thus, the spammers will keep hammering spamd, and will get greylisted.


Configuring spamd for Greylisting

Setting up spamd for greylisting is fairly easy, although under FreeBSD, you need to have a file descriptor filesystem mounted on /dev/fd. You can do this by adding this line to your /etc/fstab file (fstab lists all the available static disks and disk partitions and where they are to be mounted):

fdescfs /dev/fd fdescfs rw 0 0

You also want to place the relevant lines in /etc/rc.conf or /etc/rc.conf.local; e.g.:

spamd_flags = “-v -G 2:4:864”
spamd_grey = YES

This tells spamd to enable vpopmail configuration (-v); -G sets the passtime for greylisting to 2 minutes, greyexp to 4 hours and whiteexp to 864 hours (36 days). This means that the client must wait 2 minutes before resending an e-mail to avoid getting greylisted. A client will remain on the the greylist for 4 hours after violating this standard. If the client waits 2 minutes before resending, it will get whitelisted, and remain on the whitelist for 864 hours.

Why It Might Not Work

The reason why greylisting should work is because any standards compliant SMTP client is required to retry delivery after some reasonable amount of time. But there are circumstances in which it may not work. First of all, the first e-mail message sent from any site which has not contacted you for as long as the greylister keeps its data aroun will be delayed for some random amount of time which depends mainly on the sender’s retry interval. There are some circumstances where avoiding even a minimal delay is desirable. In addition, you are bound to encounter misconfigured mail servers which either do not retry at all or retry at all or retry too quickly, perhaps stopping delivery retries after a few attempts. Finally, there are some sites which are large enough to have several outgoing SMTP servers (e.g. GMail); these sites do not work well with greylisting since they are not guaranteed to retry delivery of any given message from the same IP address as the last delivery attempt for that message. The RFCs do not state that they new delivery attempts have to come from the same IP address, so these sites can legitimately claim to comply with the RFCs.

If you need to make allowances for such situations in your setup, it is fairly easy. One approach is to define a table for a local whitelist; the list should be fed from a text file in case of reboots:

table <my_localwhite> file “/etc/mail/local_whitelist.txt”

To make sure SMTP traffic from the addresses in the table is not fed to spamd, you add a no rdr rule at the top of your redirection block:

no rdr proto tcp from <my_localwhite> to $mailservers port smtp

Once you have added these changes to your rule set, enter the addresses you need to protect from redirection into the local_whitelist.txt file, then reload your rule set using pfctl -f.

External Links:

Greylisting on Wikipedia

RFC 2821 – the RFC with the specifications for Simple Mail Transfer Protocol (SMTP).

Greylisting.org – a site devoted to articles and tools related to greylisting.

Greylisting: The Next Step in the Spam Control War – Greylisting site created by Evan Harris, the guy who originally came up with the idea of greylisting. Also contains whitepapers and a fully functional example of greylisting called relaydelay.

 

 

Spam Blocking in BSD with spamd: Part Two

spamdIn part one of this series, I discussed some of the advantages of spamd and how it works. In this article, I will cover spamd configuration.

spamd Configuration

Configuring the spamd daemon is pretty straightforward. First, you have to edit your rule set in /etc/pf.conf to include the following:

table persist
table persist
 pass on $ext_if inet proto tcp from <spamd> to \
( $ext_if, $localnet ) smtp rdr-to 127.0.0.1 port 8025
pass on $ext_if inet proto tcp from \

!<spamd-white> to ( $ext_if, $localnet ) port smtp rdr-to 127.0.0.1 port 8025

These rules set up two tables, (a table of known spammers) and (a list of whitelisted hosts which we assume are not spammers). SMTP traffic from the addresses in the first table () plus the ones not in the second table () is redirected to a daemon listening at port 8025 of the machine. The application which uses these tables, of course, is spamd, which is designed to waste spammers’ time and keep their traffic off our network.


You also need to edit your spamd.conf file (under FreeBSD. it should be located at /usr/local/etc/spamd/spamd.conf). First, you need to define which lists you will use:

all:\
:my_blacklist:my_whitelist:

This is where you add all the blacklists you want to use, separated by colons (:). If you want to use whitelists to subtract addresses from your blacklist, you add the name of the whitelist immediately after the name of each blacklist.

Next, you need to define your blacklist:

my_blacklist:\
:black:\
:msg=”SPAM. Your address %A has sent pam with the last 24 hours”:\
:method=http:\
:file=www.openbsd.org/spamd/traplist.gz

After the name, the first data field specifies the list type (black). The msg field contains the message to display to blacklisted senders during the SMTP dialogue. The method field specifies how spamd-setup fetches the list data. In this example, the type is http, but there are other options: you can fetch the list data via ftp, from a file in a mounted file system or via exec of an exernal program. The file filed specifies the name of the file spamd expects to receive.


You also need to define a whitelist:

my_whitelist:\
:white:\
:method=file:\
:file=/etc/mail/whitelist.txt

The whitelist in this example is similar to the blacklist, only the message parameter is omitted since it is not needed, and the source is a file on the local system.

You should be aware that enabling the suggested blacklists in the default spamd.conf could lead to blacklisting of large blocks of the internet, including several countries such as South Korea. Using other lists than the default ones is possible, and its within your discretion to use other ones or to make your own copy of the default blacklist and edit it as needed.

Next, put the lines for spamd and the startup parameters you want in /etc/rc.conf or /etc/rc.conf.local. In FreeBSD, spamd_grey has to be set to YES to enable greylisting (on OpenBSD 4.1 and later, spamd runs in greylisting mode by default and you need to set spamd_black to YES to run spamd in pure blacklisting mode. There are several parameters that can be used; see the spamd man page for a complete list of these options.

You can then view the table contents using pfctl or other applications. If you want to change or delete entries, you should use the spamdb utility, not pfctl. Also, note that if the redirection (rdr) rules you use do not include a “pass” part, you need to set up pass rules to let through traffic to your redirection, and also set up rules to let legitimate e-mail through.

External Links:

spamd man page at openbsd.org

The Apache SpamAssassin Project – download SpamAssassin here; you can also find SpamAssassin’s documentation.

Book Review: The Book of PF

The Book of PFThe Book of PF: A No-Nonsense Guide to the OpenBSD Firewall (2nd Edition)
Author: Peter N.M. Hansteen
Publisher: No Starch Press
Publishing Date: November 19, 2010 (2nd Edition)
216 pages (paperback edition)

Book Review

In all my years in IT, I have read a number of computer books, but relatively few of these books I would count as indispensible. For C/C++, there was the elegantly written C Programming Language book written by Kernighan and Ritchie. When I learned Windows programming, Programming Windows® by Charles Petzold proved to be an invaluable resource. Around 1995-96 when I became interested in Java, I used one of the O’Reilly books as my tutorial. Some of the O’Reilly books (as well as ones produced by Sams Publishing) were invaluable in providing some of my initial education in Linux in the 1990s. So when I came across The Book of PF: A No-Nonsense Guide to the OpenBSD Firewall by Peter N.M. Hansteen (2nd Edition, No Starch Press, 2010), I was curious to see how it would measure up.

As it turned out, The Book of PF is a worthwhile read, and for those seeking a more detailed understanding of PF, it should prove quite useful. The book is not a cookbook, as the author states fairly explicitly in the introduction. Thus it does not contain a series of how-to instruction sets; nonetheless, those with little knowledge of pf need not fear, as Hansteen starts with simple concepts and builds on these concepts in subsequent chapters. In this way, he is able to progress from very simple PF rule sets (e.g. block all outside traffic except the ports that need to be open, and only the protocols that are needed) sets to somewhat more involved rule sets (ones for networks that run SSH, FTP, and e-mail services), to even more complex rule sets that start to approximate real world scenarios. It also stresses the importance of making rule sets that are as granular as possible so as to allow only the traffic you really want. I like Hansteen’s attitude as well: he challenges readers not to cut and paste rule sets, but to think for themselves, and he also seems to disdain what he considers overly prophylactic policies such as blocking ping and traceroute. The book will also be a good guide for those who want to effectively protect their networks using such services as synproxy, relayd (for expiring nonfunctional hosts from a load balancing pool), and spamd (for blocking spam).


For those techies who only want to learn about pfSense, there are other books. If you just want to know the basics about how to configure your pfSense box, there’s the pfSense 2 Cookbook by Matt Williamson. If you want a more comprehensive explanation of pfSense’s features, pfSense: The Definitive Guide by Christopher M. Buechler (one of the co-founders of pfSense), Jim Pingle and Michael W. Lucas is likely the book for you. But for the network tech or admin who does not mind working primarily at the command line and editing rule sets manually, “The Book of PF” is a potentially valuable guide. Whether or not its worth your time to understand the nuances of pf is a cost-benefit analysis you will have to make yourself. But you will gain a greater degree of control you could ever hope to have working with the pfSense user interface alone. For example, take the problem of SSH brute force attacks. pfSense allows you to set a maximum number of connections per second, and you can block an IP address or a range of IP addresses. But as far as I know, pfSense does not enable you to set a maximum connection rate and add an IP address to a table of blocked IP addresses if it exceeds the rate. pf makes this possible, and this book shows you how. And this is just one example of how this book demonstrates how you can fine-tune your firewall’s settings; there are many other such instances.


For those really wanting to acquire an in-depth knowledge of pf, BSD and networking in general, Hansteen has included a list of resources as the first appendix to the book. Needless to say, it is chock full of helpful links and contains a bibliography which should provide a good starting point for anyone whose interest in BSD has been piqued.

In conclusion, The Book of PF is not for everyone, but if you are serious about network security, it can potentially be a useful guide. Not only will you be able to customize your firewall rules to meet your requirements, a working knowledge of pf is arguably even more valuable in the long term than a working knowledge of pfSense. pfSense superseded m0n0wall as the firewall/router of choice among many network security experts and will likely be superseded itself someday. pf may or may not be replaced as the primary packet filter for BSD users, but even if it is, my guess is that the structure of the rules will likely be similar, so if you have a good knowledge of pf, the learning curve should not be that steep. As the only in-depth book on pf, The Book of PF is recommended for anyone who wants to gain a better understanding of OpenBSD’s packet filtering engine.

External Links:

The Book of PF: A No-Nonsense Guide to the OpenBSD Firewall at Amazon

pfSense VPN: Part Three (PPTP)

pfSense VPN

VPN PPTP configuration page in the pfSense GUI.

In the previous two articles on pfSense VPN, I covered how to configure a VPN tunnel using IPsec and also the L2TP and OpenVPN protocols. In this article, I will cover how to set up a VPN tunnel using PPTP.


pfSense VPN: PPTP

First, browse to VPN -> PPTP. You should be at the “Configuration” tab. You will see the following warning message:

PPTP is no longer considered a secure VPN technology because it relies upon MS-CHAPv2 which has been compromised. If you continue to use PPTP be aware that intercepted traffic can be decrypted by a third party, so it should be considered unencrypted. We advise migrating to another VPN type such as OpenVPN or IPsec.

Click on the “Enable PPTP server” radio button. At “No. PPTP users“, select the number of PPTP users. At “Server address“, etner an unused IP address. PfSense’s PPTP service will listen on this address. In the next box, Enter the start of the “Remote address range” for clients that connect (it must be large enough for the number of users specified at “No. PPTP users“). Check the “Require 128-bit encryption” checkbox just above the “Save” button. Click on “Save” to save the configuration.

pfSense VPN

Users tab in the VPN PPTP setup in pfSense.

Now select the “Users” tab and hit the “plus” button to add a user. Specify a “Username” and “Password” and an “IP address” if you want the user to be assigned a specific IP address. Click on “Save” to save changes, and then click on “Apply changes” if necessary.

Now it is necessary to set up a firewall rule to allow PPTP VPN traffic. Browse to Firewall -> Rules. Select the “PPTP VPN” tab. At “Destination“, set it to “LAN subnet“. Set the “Destination port range” to “any“, and at “Description“, enter a description if desired. Then press “Save” to save the changes and press “Apply changes” if necessary.


Now, your pfSense router will be configured to use VPN with PPTP. Moreover, PPTP is natively supported by Windows, Linux and MacOS, so you should be able to easily connect to your VPN tunnel from any of those platforms.

External Links:

PPTP VPN at doc.pfsense.org

 

pfSense Setup: Part Two

pfSense Setup

The General Setup menu in the pfSense web GUI.

If you followed the setup instructions in pfSense Setup: Part One, pfSense should be running and accessible via the web interface at 192.168.1.1 (or another IP address if you assigned a different one). You should be able to log in using the default username (admin) and password (pfsense).

You will want to change some of the basic settings in General Setup. In the web interface, browse to System | General Setup. At “Hostname”, enter your hostname (the name that will be used to access the machine by name instead of the IP address.

Below this, enter your domain (Domain in the General Settings).

DNS Servers can also be specified. By default, pfSense will act as the primary DNS server. However, other DNS servers may be used, and the place to enter them are in the four boxes for DNS servers.

Check Allow DNS server list to be overridden by DHCP/PPP on WAN. This ensures that DNS requests that cannot be resolved internally are passed on to the WAN and resolved by the external DNS servers provided by your internet service provider.


Next, select the correct time zone; you probably want to leave the default NTP time server as it is.

Next is the theme, which allows you to change the look and feel of the pfSense web GUI. You can probably keep the default theme, pfSense_ng.

pfSense Setup

pfSense’s User Manager, which has been part of the pfSense web GUI since version 2.0.

NOTE: You probably want to change the admin password. You can do this under System -> User Manager. Here you can change the admin password, add new users, and delete users, including the admin.

That’s it for the General Setup within the web GUI. In pfSense Setup: Part Three, I will cover how to configure the WAN and LAN interfaces using the web GUI. Part four will cover configuring optional interfaces.


External Links:

Another useful guide on installing and configuring pfSense (from the iceflatline blog)

Ad Links:


pfSense Setup: Part One

pfSense setup

Initial pfSense menu when pfSense is booted from the CD.

For purposes of this article on pfSense setup, we will assume that you already have a system that meets the minimum specifications to run pfsense (if you have not acquired the components yet or if you’re not sure if your equipment meets the specs, you may want to check this document on pfsense requirements). In a nutshell, however, the minimum hardware requirements are:

  • 100 MHz Pentium CPU
  • 128 MB RAM
  • CD-ROM (for installation or for the LIve CD if you run it off the CD)
  • 1 GB hard drive (if you install it onto a hard drive)
  • Two network interface cards

You can run pfsense from a Live CD or a bootable USB drive.

Download the latest version of pfSense. You can find it at: this FTP site. You probably want to verify the integrity of the download with the MD5 checksum as well. Once this is done, burn the pfSense ISO to a CD or to the media of your choice. You can burn the ISO with the program of your choice; you can do it at the Linux command line with this command:

sudo cdrecord -v speed=20 dev=/dev/sr0 pfSense-LiveCD-2.0.3-RELEASE-i386-20130412-1022.iso

Boot your PC with the pfSense CD. You will be presented with a “Welcome to pfSense!” menu with several options. For this screen, you can choose the default option (Boot pfSense). At this point, you can press “I” to invoke the installer, or continue the LiveCD bootup. If you want to boot the LiveCD, either do nothing or hit “C”, and you can skip the following section. [In this case, continue with pfSense setup here.

pfSense Setup: Installation Onto a Hard Drive

If you hit “I”, then the next screen will be the “Configure Console” menu. Most likely you can choose the “Accept these Settings” option and press [Enter].


The next menu is the “Select Task” menu. There are several options: “Quick/Easy Install”, “Custom Install”, “Rescue config.xml”, “Reboot”, and “Exit”. If you just want to install onto the first hard drive, you can select “Quick/Easy Install” and press [Enter].

The next dialog box is the “Are you SURE” dialog box, which will ask you to confirm your decision to install pfSense by highlighting “OK” and pressing [Enter]. Any data on the first hard drive will be erased in order to install pfSense.

Installation will take a few minutes, as pfSense formats your drive and copies the software to it. Next is the “Install Kernel(s)” screen. Select “Symmetric multiprocessing kernel” and press [Enter].

At the “Reboot” screen, remove the pfSense CD from the CD/DVD drive, highlight “Reboot” and press [Enter].

After the system reboots, you will see the initial “Welcome to pfSense!” menu. Press [Enter] to select the default, or just wait for the pause timer to run out.

pfSense Setup: Further Configuration

[Resume here if you are booting from the LiveCD.]

As pfSense boots, the detected network interface cards will be listed. If all your network cards are not listed, you will want to exit out of the install by hitting [CTRL-C] and selecting “6” on the menu. Otherwise, the next choice will be:

Do you want to set up VLAN’s now [y|n]?

Assuming that this is a basic pfSense setup, you can type [n] and continue.

The next option is:

Enter your LAN interface name

Here, type the name of the network interface card that will be directly connected to your internal network. The next option is:

Enter your WAN interface name

Here, type the name of the network interface card that will be be connected to the internet.

If you installed more than two network cards, then pfSense will prompt you to enter the names of them. For the third card it will prompt:

Enter the Optional 1 interface name

When there are no more network cards to name, you will get the prompt:

Do you want to proceed [y|n]?

Be sure to type [y]. You have completed the first phase of pfSense setup. Now pfSense will be running and fully functional. If you wish, you can connect via the web interface, which pfSense by default assigned an IP address of 192.168.1.1.

Part Two of this article on pfSense setup will go step-by-step through configuring pfSense via the web interface.


The Rest of the Guide:

Part Three (WAN and LAN Settings)

Part Four (Setting Up a DMZ)

Ad Links:


© 2013 David Zientara. All rights reserved. Privacy Policy