Egress Filtering with pfSense

Egress Filtering Explained

Egress Filtering

Adding a rule to allow HTTP traffic from the LAN in pfSense 2.0.

In computer networking, egress filtering is the practice of monitoring and potentially restricting the flow of information outbound from one network to another. Typically it is information from a private TCP/IP computer network to the Internet that is controlled. pfSense, like nearly all similar commercial and open source solutions, comes with a LAN rule allowing everything from the LAN out to the internet. Allowing such outbound traffic indiscriminately is not a very good idea, even though it has become the default in most firewalls, because allowing such traffic is what most users expect.

Egress filtering can be challenging, as it will increase the administrative burden, as each new application or service may require opening additional ports. It may even be cost-prohibitive in large organizations to do so. Nevertheless, you should strive to allow only the minimum amount of traffic to leave your system, for the following reasons:

  • Limiting the impact of a compromised system: Malware commonly uses ports and protocols that are not required on many networks. Many bots rely on IRC connections to receive instructions. Some use other ports to evade egress filtering, but many do not.
    Another good example is a distributed denial of service attack (DDoS) using port 80. Such attacks often use User Datagram protocol (UDP), as UDP allows you to send a large number of packets without completing a handshake. Moreover, most networks have no need for allowing outbound UDP, as only TCP is required. The real solution is to remove the malware from the compromised system or systems, but if the proper egress filtering is in place, the DDoS packets will be blocked by pfSense.
    Simple Mail Transfer Protocol (SMTP) is another example. If your mail server is behind the firewall, you should only allow TCP traffic on port 25. But if the mail server is externally hosted, you could block port 25 from accessing the WAN interface entirely. This would prevent systems in your network from becoming used as a spam zombie and thus ending up on the block list of other mail servers.
  • Preventing a system from becoming compromised: Some malware/worms require outbound access to succeed. For example, Code Red and some other worms caused infected systems to pull an executable via port 69, the Trivial File Transfer Protocol (TFTP) and then execute it. You almost definitely do not need to use port 69 not the TFTP protocol, and blocking both via egress filtering prevented infection with such worms as Code Red, even on unpatched systems.
  • Limiting unauthorized application usage: Many applications either rely on atypical ports or will port hop until they find something allowed out of your network; this is especially true of peer-to-peer software, instant messengers, and VPN clients. Egress filtering can prevent such programs from functioning.
  • Preventing information leaks: There are a number of potential examples of this, but an example from a previous posting is Simple Network Management Protocol (SMTP) on ports 161 and 162. You probably do not want this data to leave your network, as doing so will leak potentially sensitive logging information out of your network. Rather than worry about this, it is probably best to only allow the traffic that is required.
  • Preventing IP spoofing – This is not really an issue with pfSense, since pf has anti-spoofing capabilities built into it, but it is worth mentioning.

Configuring Egress Filtering in pfSense

Egress Filtering

The firewall rules table after the rules for port 80, 443 and 25 have been added.

As an example of egress filtering, here is an instance in which we will explicitly allow necessary traffic and disable everything else. Assume for purposes of this example that we have identified the following requirements:

Traffic Required
Rule Source IP Destination IP Destination port
HTTP and HTTPs any any TCP 80 and 443
SMTP from mail server Mail server IP any TCP 25

Thus, we want to allow outbound HTTP, HTTPS and SMTP traffic and nothing else.

First, navigate to Firewall -> Rules. Select the “LAN” tab to create a new LAN rule. Note that unless you have made changes, there should be a “Default allow LAN to any rule” already there. Click on the “plus” button to add a new rule. Leave “Action” set to “Pass” and “Interface” set to “LAN”. Leave “Protocol” set to “TCP”. Set both “Source” and “Destination” to “any”, and set “Destination port range” to “HTTP”. At “Description“, type an appropriate description and press the “Save” button to save the changes; then press the “Apply changes” button to apply changes if necessary.

Egress Filtering

Disabling the default allow LAN to any rule.

To create the rules for ports 443 and 25, repeat the above steps twice, substituting “HTTPS” for “Destination port range” the first time, and “SMTP” the second time. Once the new rules are added, all that is left to do is disable the “Default allow LAN to any” rule. Click on the “e” next to this rule, and next to “Disabled“, check the “Disable this rule” check box. Then click on “Save” to save the changes and “Apply changes” to apply the changes.

Now, all outbound traffic from the LAN except for these 3 ports will be blocked. This may make the admin’s job somewhat more challenging, but it should reduce the chances that malware or spam bots gain a foothold on your network.

External links:

Egress Filtering FAQ – an excellent whitepaper on egress filtering from the SANS Institute

Performing Egress Filtering – another whitepaper on egress filtering

Egress filtering on

Egress filtering on Wikipedia

Firewall Best Practices – Egress Traffic Filtering from The Security Skeptic

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

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 (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

© 2013 David Zientara. All rights reserved. Privacy Policy