pfSense VPN: Part One

pfSense VPN

Configuring an IPsec VPN tunnel in pfSense 2.0.

Virtual Private Networking (VPN) extends a private network across a public network, such as the Internet. It enables a computer to send and receive data across shared or public networks as if it were directly connected to the private network, while benefiting from the functionality, security and management policies of the private network, and is accomplished by establishing a virtual point-to-point connection with another computer. This is done through dedicated connections, encryption, or a combination of the two. Most router/firewalls support VPN, and this article describes some of the pfSense VPN options.


There are a variety of VPN services available, and pfSense has four of the most popular implementations built right in: IPsec, L2TP, OpenVPN, and PPTP. OpenVPN is emerging as the standard VPN protocol, but OpenVPN support is not built into Windows – you’ll have to download the client software. IPsec is also a popular VPN implementation. PPTP and L2TP, on the other hand, are losing ground to OpenVPN, but are still popular and are supported by most major operating systems.

pfSense VPN: IPsec

pfSense VPN

Setting up a firewall rule to allow IPsec traffic to the LAN.

In many cases, IPsec is the preferred method for network-to-network connections. IPsec (Internet Protocol Security) is a technology protocol suite for securing Internet Protocol (IP) communications by authenticating and/or encrypting each IP packet of a communication session. IPsec also includes protocols for establishing mutual authentication between agents at the beginning of the session and negotiation of cryptographic keys to be used during the session. Setting up an IPsec connection in pfSense is easy. Browse to VPN -> IPsec. If the “Tunnels” tab is not already selected, select it. Click the “Plus” button to create an IPsec tunnel. Leave “Disable this phase 1 entry” unchecked and keep the interface as “WAN“. At “Remote Gateway“, enter the public IP address or host name of the remote gateway. At “Pre-Shared Key“, input your pre-shared key string. Now, click on “Save” to save the changes, click on “Enable IPsec“, and click on the “Save” button again. Click on “Apply changes” if necessary.


In order for IPsec traffic to pass through to the LAN, we need to create a new rule. Browse to Firewall -> Rules and select the IPsec tab. Click on the “Plus” button to add a new firewall rule. At “Destination“, set the destination to the LAN subnet, and at “Destination port“, set the destination port to “any“. Add a description at “Description” if you want, and click on “Save” to save changes. Click on “Apply changes” if necessary. This completes the set up of a pfSense VPN tunnel with IPsec.

In the next article, I will cover using VPN with the L2TP and OpenVPN protocols. Part three will cover the PPTP protocol.

External Links:

Setting up an IPsec VPN Link at doc.pfsense.org

pfSense Scheduler Options

pfSense scheduler

Schedule options in the pfSense web GUI.

The pfSense scheduler allows you to specify when firewall rules are enabled. Although they are primarily used with firewall rules, their generic design allows them to be used with other existing and future pfSense features. If a firewall rule specifies a schedule, the rule is only enabled during that time period.

Using the pfSense Scheduler

In this example, I will use the pfSense scheduler option to make the FTP server accessible only on Mondays, Wednesdays and Fridays from 11 AM to 6 PM.

First, browse to Firewall -> Schedules. We click the “plus” button to create a new schedule. Next, at “Schedule Name“, enter a schedule name (here, it could be “FTP_Hours”). At “Description“, we could also enter a description. At “Month“, click on Mon, Wed, and Fri to select those days. We could also select specific days by clicking on that day on the calendar (days will repeat every year). Clicking on a day of the week at the top of the calendar will apply the rule to that day every week, regardless of the month or year. For “Start Time“, specify 11 (11 AM), and at “Stop Time“, specify 18 (6 PM). At “Time Range Description“, you can enter a description. Then click on “Add Time”. Now the repeating time should be added to “Configured Ranges“. Click on “Save“, and then click on “Apply changes“, if necessary.


Features associated with a schedule will only be valid during the schedule specified. To associate a firewall rule with the schedule, edit an existing firewall rule, or create a new one. Under “Advanced features“, click on the “Advanced” button at “Schedule“. Now we can chose FTP_Hours as our schedule. Press the “Save” button to save the changes, and if necessary press the “Apply changes” button to apply the changes.

In Firewall -> Rules, you can check the Schedule column to see if scheduling has been invoked with a particular rule. Rules with active schedules show a green arrow in the schedule column. Rules with inactive schedules (meaning the rules which are disabled) show a red x in the schedule column. You can also go to Firewall -> Schedules to see if a schedule is active or not (active schedules will show a clock icon).


External Links:

Firewall Rule Schedules at doc.pfsense.org

Firewall Rules in pfSense: Part Two

Firewall Rules

Highlighting a rule in the pfSense GUI.

In the previous article, I covered basic firewall rules in pfSense. But pfSense 2.0 has a whole new set of advanced setup options, which I will cover in this article.

pfSense rules are evaluated from the top down. The first rule to match is executed and the rest of the rules are skipped. It is a good idea to put very specific rules at the top and more generic rules at the bottom, and this is what many administrators do. To reorder a rule, simply select the rule and click the “move selected rules before this rule” button.


You also may want to create a rule that’s very similar to an existing rule. To save time, you can copy the rule with the “add a new rule based on this one” button (the plus button).

Firewall Rules: Advanced Features

Firewall Rules

Advanced features section for firewall rules in the pfSense web GUI.

With pfSense 2.0, when you add or edit firewall rules, there is an Advanced Features section. Various features can be specified as criteria for a rule. If an advanced feature is specified, the rule will only be executed if a match is found. Click the Advanced button for each feature to display configuration settings for that feature. Here are the features:

Firewall Rules

Source OS option under firewall rules in pfSense 2.0.

  • Source OS: This option will attempt to match the operating system of the source traffic. The UNIXoid world is well represented on this list, with FreeBSD, NetBSD, and OpenBSD on the list, as well as Linux and Solaris. Windows and Novell are also on the list.
  • Diffserv Code Point: Diffserv is a mechanism for providing Quality of Service of network traffic. Systems can prioritize traffic based on their code point values.
  • Advanced Options: This contains a number of options. The options are as follows:
    • Allow packets with IP options to pass: Packets with IP options are blocked by default, and for good reason: some IP options can be used by attackers to hide the true source of a packet or to gain access to a protected network, or to glean information about the topology and the addressing scheme of a network. Also, IP options tax the CPU of the router, and may be used in denial of service (DoS) attacks. Nonetheless, there may also be legitimate reasons for allowing these packets to pass.
    • Disable auto-generated reply-to for this rule: By default, pfSense replies to a host regarding a rule; this disables it.
    • Mark a packet: Mark a packet matching a rule; you can then use this mark to match on other NAT/filter rules.
    • Match packet on a mark placed before on another rule.
    • Maximum state entries this rule can create: Limits the maximum number of state entries this rule can create to a specific number. If the maximum is reached, packets that would normally create state fail to match this rule until the number of existing states falls below the limit.
    • Maximum number of unique source hosts: Limits the number of unique hosts to this number.
    • Maximum number of established connections per host: Limits the number of connections per host to this number; good for protecting against DoS attacks.
    • Maximum state entries per host: Limits the number of state entries per host to this number.
    • Maximum new connections/per seconds: Limits the number of connections to X connections per Y seconds, where X and Y are entered here.
    • Timeout in seconds
  • TCP Flags: Specific TCP flags can be set here. These flags are:
    • FIN – No more data from sender
    • SYN – Synchronize sequence numbers (seen on new connections)
    • RST – Reset the connection (seen on rejected connections)
    • PSH – Push function
    • ACK – Indicates that the ACKnowledgment field is significant
    • URG – Indicates that the URGent pointer field is significant
  • State Type: Select which type of state stracking mechanism you would like to use from the following options – keep state, sloppy state, synproxy state (to protect against TCP SYN floods), and none. If in doubt, use keep state.
  • No XMLRPC Sync: This prevents a rule from syncing with the other CARP members.
  • Schedule: Specify the schedule for when the rule is valid. Schedules defined in Firewall -> Schedules will appear in the drop-down box.
  • Gateway: Gateways other than the default may be specified here. Leave as ‘default’ to use the system routing table.
  • In/Out: Specify alternative queues and virtual interfaces. Choose the Out queue/Virtual interface only if you have also selected In. The Out selection is applied to traffic leaving the interface where the rule is created, In is applied to traffic coming into the chosen interface. If you are creating a floating rule, if the direction is In then the same rules apply, if the direction is out the selections are reverted Out is for incoming and In is for outgoing.
  • Ackqueue/Queue: Specify alternative acknowledge queries here.
  • Layer7: Choose a Layer7 container to apply application protocol inspection rules. These are valid for TCP and UDP protocols only.

That covers advanced options for firewall rules in pfSense 2.0, demonstrating the unique level of granularity that pfSense offers in firewall configuration. Most of these options can be left unchanged a majority of the time, but many of them, such as “Source OS”, will undoubtedly be useful in enterprise-level deployments.


Firewall Rules in pfSense: Part One

Firewall Rules: Part One

Firewall: Rules page in the pfSense web GUI.

In the previous article about NAT port forwarding, we used “Add associated filter rule” in order to generate the firewall rule for the Apache web server. We could, however, have chosen “None” for the “Filter Rule Association” and created the rule ourselves. This next article describes how to create firewall rules.


Adding Firewall Rules

In order to do this, first browse to Firewall -> Rules. There will be two pre-configured firewall rules by default: “Block private networks” (for blocking 10.x.x.x, 172.16.x.x, and 192.168.x.x addresses) and “Block bogon networks” (for blocking bogus addresses). There will be at least three tabs: “Floating“, “WAN” and “LAN“. Select “WAN” if it isn’t already selected. Press the “Plus” button to add a new firewall rule. Under “Action”, there are three options: “Pass“, “Block”, and “Reject“. The web GUI has the following explanation of the difference between “Block” and “Reject“:

Hint: the difference between block and reject is that with reject, a packet (TCP RST or ICMP port unreachable for UDP) is returned to the sender, whereas with block the packet is dropped silently. In either case, the original packet is discarded.

In this case, you can leave the default unchanged as “Pass“. Next is the option to “Disable this rule“; we don’t want to do this so leave this box unchecked. At “Interface”, you will again have a choice of “LAN“, “WAN” and whatever other interfaces were configured; choose “WAN“.

Firewall Rules: Part One

Adding a firewall rule in pfSense.

At “Protocol“, there are a number of options in addition to the four listed under NAT port forwarding. “ICMP” stands for Internet Control Message Protocol and is used to send error messages indicating, for example, that a requested service is not available or that a host or router could not be reached. ICMP can also be used to relay query messages. “AH” stands for Authentication Header, which is part of the IPsec suite and provides connectionless integrity and data origin authentication for IP datagrams and provides protection against replay attacks. “IGMP” stands for Internet Group Management Protocol and is a connectionless protocol used by hosts and adjacent routers on IP networks to establish multicast group memberships; it is used for one-to-many networking applications such as online streaming video and gaming, among other uses. “OSPF” stands for Open Shortest Path First, a link-state routing protocol for IP networks that uses a link state routing algorithm and falls into the group of interior routing protocols. “CARP” stands for Common Address Redundancy Protocol, 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. Finally, “pfsync” is a computer protocol used to synchronize firewall states between machines running Packet Filter (PF) for High Availability. If is used along with CARP to make sure a backup firewall has the same information as the main firewall. In this case, we should leave the default protocol “TCP” unchanged.


At “Source“, specify “any”, as the “Type” and at “Source Port Range“, also specify any. The “Type” options are the same as the options under “Source” and “Destination” for NAT port forwarding; therefore I will not go into detail on them here. In “Destination“, select “Single host or alias” as the type, and specify 192.168.1.125 (our Apache server) for the “Address”. At “Destination Port Range“, specify “HTTP“. You can leave “Log packets that are handled by this rule” unchecked unless you have reason to log the packets. Specify a “Description” if you wish and press the “Save” button to save the changes.

Firewall Rules: The Source Port Range is Usually Unknown

It should be noted that when a firewall rule is created, the “Source Port Range” is almost always set to “any“. This is because the client decides which port to open on the client computer, which may or may not be the same as the port requested on the server. The source port is an an ever-changing port which the end user probably never knows about. So most of the time, we will not know the Source Port Range of the traffic being allowed in.

In the next article, I will go into some detail on rules governing firewall rules, and some of the advanced options for firewall rules under pfSense 2.0.

External Links:

Firewall Rule Basics at doc.pfsense.org

© 2013 David Zientara. All rights reserved. Privacy Policy