Traffic Shaping Rules in pfSense 2.1

Creating traffic shaping rules in pfSense 2.x is handled a bit differently than in previous versions of pfSense. In the old pfSense, traffic shaping rules were controlled by navigating to Firewall -> Traffic Shaper, clicking on the “Rules” tab, and then adding or editing rules as needed. Now, all rules, whether they invoke traffic shaping queues or not, are controlled by navigating to Firewall -> Rules.

An Example: Creating Traffic Shaping Rules for BitTorrent

Traffic Shaping Rules

Adding a traffic shaping rule to put BitTorrent traffic into the P2P queue in pfSense 2.1.

The option to place traffic into a queue can be found by scrolling down to “Advanced Features“, and pressing the “Advanced” button next to Ackqueue/Queue. To illustrate the process, let’s create traffic shaping rules to explicitly direct BitTorrent traffic coming in and out of a specific port into the P2P queue. Although we’re doing it here just to illustrate the process, if you are using BitTorrent, there may be a legitimate reason to make a special rule for this traffic. pfSense relies primarily on ports to tell what program the traffic appears to be rather than examining the packets. Since BitTorrent relies on non-standard ports, it is quite possible that such traffic will not automatically go into the P2P queue. There is a way of identifying traffic based on the content of the packets instead of just the source or destination ports known as layer 7 shaping (deep packet inspection). This feature is only found in pfSense version 2.0 and newer. Layer 7 shaping will be the subject of a future article, but for purposes of this exercise, we will assume that this is not an option. Therefore, we endeavor to take the following measures: [1] use the P2P Catchall rule; [2] treat the default queue as low priority, and [3] make rules for each type of traffic you want.

Traffic Shaping Rules

Configuring the queues under Advanced Settings at Firewall -> Rules.

The P2P Catchall rule is added by using the traffic shaper wizard, which was covered in a previous article, and editing queue settings was also covered in a previous article, so I will focus on making rules to cover BitTorrent traffic. To begin, we will go to Firewall -> Rules and click on “plus” to add a firewall rule. We want to leave the “Action” as Pass, and choose WAN as the “Interface“. For “TCP/IP Version“, we will select IPv4+IPv6. We’ll leave the “Protocol” as TCP and leave “Source” unchanged. For “Destination“, we’ll select “Single host or alias” and type in the address of the target computer (in this case, 192.168.1.10). For “Destination port range“, we will put our BitTorrent port (22453). We will not log packets, but we will enter a brief “Description“. Scrolling down to “Advanced Features“, press the “Advanced” button next to “Ackqueue/Queue“. Select “qACK” for the Ackqueue and “qP2P” for the queue. [This assumes we set up a P2P queue earlier.] Then press the “Save” button to save the rule and press “Apply changes” on the next page.


Now we have a rule to handle incoming BitTorrent traffic, but there is also outgoing traffic, and we want to set up a rule to handle that as well. To do so, click on the “plus” button. We will keep most of the settings for the previous rule, but we will change “Interface” to LAN and “Destination” to WAN subnet. We will again specify 22453 for the “Destination port range” and “qACK” and “qP2P” for the queues. Again, press “Save” to save the rule and “Apply changes” on the next page.

Now, we have traffic shaping rules for both incoming and outgoing BitTorrent traffic on port 22453 configured, thus ensuring that traffic on that port will go into the P2P queue. You’ll want to enable the P2P Catchall queue if you didn’t already, and limit the bandwidth used by the default queue, but otherwise, we should be set up to handle BitTorrent on our chosen port.


Other Articles in This Series:

Traffic Shaping in pfSense: What it Does
Traffic Shaping Wizard: Introduction
QoS Management Using the Traffic Shaper Wizard
Queue Configuration in pfSense 2.1
Layer 7 Groups in pfSense 2.1
Bandwidth Limiting with the pfSense Limiter
Deep Packet Inspection Using Layer 7 Traffic Shaping

External Links:

pfSense Bandwidth Management – How to Configure the Traffic Shaper at hubpages.com

Link Ads:


Queue Configuration in pfSense 2.1

traffic shaping queue

Configuring the qVoIP traffic shaping queue under pfSense 2.1.

In the previous articles, I covered the basics of the traffic shaper and how to configure it using the wizard. In this article, we’ll examine how to monitor traffic shaping and some advanced configuration techniques.

In order to make sure the traffic shaper is working as it should, you can monitor it. In order to do so, navigate to Status -> Queues. This screen will show each queue listed by name, its current usage, and some other statistics. The graphical bar on this screen shows you how full a queue is. The rate of data in the queue is shown as both packets per second (or pps) and bits per second (or b/s). Borrows happen when a neighboring queue is not yet full and capacity is borrowed from there when needed. Drops happen when traffic in a queue is dropped in favor of higher priority traffic. It is normal to see drops, and this does not mean that a full connection is dropped, just a packet. Usually, one side of the connection will see that a packet was missed and then resend it, often slowing down to avoid future drops. The suspends counter indicates when a delay action happens.

If you find that the rules generated by the traffic shaper do not quite fit your requirements, you may want to edit the shaper queues manually. You may have a service that is not handled by the wizard, a game that uses a different port, or other services not covered by the wizard. It should be relatively easy to cover these cases.

The queues are where bandwidth and priorities are actually allocated. In pf, each queue is assigned a priority, from 0 to 7. When there is an overload of traffic, the higher-numbered queues are preferred over the lower-numbered ones. Each queue is assigned either a hard bandwidth limit or a percentage of the total link speed. The queues can be assigned other attributes that control how they behave. Queues may be changed by navigating to Firewall -> Traffic Shaper and clicking on the Interfaces tab. You will see a list of rules here, sorted by interface. Clicking on one of the queues will enable you to edit the settings for it.


Queue Configuration Options

Editing queues is not easy, and if you do not have a thorough understanding of the settings involved, it is best to leave the settings alone. That having been said, here are the options. “Enable/Disable queue and its children” and “Queue Name” are self-explanatory. “Priority” assigns a priority to the queue from 0 to 7 (7 is highest). The “Queue limit” field specifies the queue limit in packets per second. Next is “Scheduler options“; there are five different options here:

  • Default Queue: Selects this queue as the default, the one which will handle all unmatched packets. Each interface should have one and only one default queue.
  • Random Early Detection (RED): This is a method to avoid congestion on a link; it will actively attempt to ensure that the queue does not get full. If the bandwidth is above the maximum given for the queue, drops will occur. Also, drops may occur if the average queue size approaches the maximum. Dropped packets are chosen at random, so the more bandwidth in use by a given connection, the more likely it is to see drops. The net effect is that the bandwidth is limited in a fair way, encouraging a balance. RED should only be used with TCP connections; TCP is capable of handling lost packets and can resend when needed.
  • Random Early Detection In and Out (RIO): Enables RED with in/out, which will result in having queue averages being maintained and checked against for incoming and outgoing packets.
  • Explicit Congestion Notification (ECN): Along with RED, it allows the sending of control messages that will throttle connections if both ends support ECN. Instead of dropping the packets as RED will normally do, it will set a flag in the packet indicating network congestion. If the other side sees and obeys the flag, the speed of the ongoing transfer will be reduced.
  • CoDel Active Queue: A newish form of AQM (Active Queue Management) designed to solve at least in part the problem of bufferbloat (persistently full buffers). The three primary innovations of CoDel are: [1] using the local minimum queue as the queue measure; [2] simplified single-state variable tracking of how long the minimum has been above or below the target value for standing queue delay rather than keeping a window of values to compute the minimum; and [3] use of queue-sojourn time rather than measuring queue size in bytes or packets. This simple description does not do justice to the CoDel AQM, but you can read more about it at the ACM white paper on CoDel: (HTML PDF).

The next two fields are fairly self-explanatory: at “Description“, you can enter a brief description, and at “Bandwidth“, you can specify the total bandwidth allocated to this queue. The options for “Service Curve” are interesting because they enable you to configure a Hierarchical Fair Service Curve (HFSC) for the queue. I covered HFSC in somewhat greater depth in a previous article, but here are the options in a nutshell:

  • m1: Burstable bandwidth limit
  • d: Time limit for the bandwidth burst, specified in milliseconds
  • m2: Normal bandwidth limit

For example, you need m1 bandwidth within d time, but with a normal maximum of m2. Within the time set by d, m1 is the maximum. After d milliseconds has expired, if the traffic is still above m2, it will be shaped. If you read my article about HFSC or any of the other material relating to it, you will see that m1 and m2 are two different slopes for the curve.


Each of the values m1, d and m2 can be set for the following uses:

  • Upper Limit: Maximum bandwidth allowed for the queue. Will do hard bandwidth limiting.
  • Real Time: Minimum bandwidth guarantee for the queue. This is valid only for child queues.
  • Link Share: The bandwidth share of a backlogged queue. It will share the bandwidth between classes if the Real Time guarantees have been satisfied.

Finally, at the bottom of the page, there is a “Save” button to save the changes to a queue, “Add new queue” if you want to add a queue, and “Delete queue” to delete it. This covers the queue options in pfSense 2.1. In writing this article, it has occurred to me that I have not yet addressed some of the configuration and troubleshooting issues involved with traffic shaping, so these subjects will likely be topics for future blog postings.

Other Articles in This Series:

Traffic Shaping in pfSense: What it Does
Traffic Shaping Wizard: Introduction
QoS Management Using the Traffic Shaper Wizard
Traffic Shaping Rules in pfSense 2.1
Layer 7 Groups in pfSense 2.1
Bandwidth Limiting with the pfSense Limiter
Deep Packet Inspection Using Layer 7 Traffic Shaping

External Links:

Traffic Shaper in pfSense 2.0 – doesn’t cover 2.1, but it’s still a good article.

Controlling Queue Delay at queue.acm.org – this is the white paper on the CoDel AQM.

Link Ads:


QoS Management Using the Traffic Shaper Wizard

In this article, we will go through the pfSense traffic shaper wizard to achieve quality of service (QoS) goals and cover some of the options which are configurable through the wizard.

QoS Management: Queueing Disciplines and Bandwidth

QoS

Specifying the number of WAN connections in the wizard.

In the wizard, you first have to specify the number of WAN connections, and if you selected multi LAN, the number of LAN connections. On the next screen, there are several more options. At “Download Scheduler“, there are three options for queueing discipline: HFSC (Hierarchical Fair Sharing Curve), which is designed to ensure that link delay is low while bandwidth is not over-reserved. CBQ (Class-Based Queueing) allows for bandwidth to be shared equally among different classes, while PRIQ (Priority Queueing) allows for different priority levels to be assigned to classes. Under “Setup connection speed and scheduler information for WAN #n“, at “Interface” you select a valid interface. At “Upload Scheduler“, you chose a queueing discipline (again, the options are HFSC, CBQ and PRIQ). Finally, the “Connection Upload” and “Connection Download” speed must be entered.

QoS Management: VoIP, P2P, and Network Games

QoS

Configuring VoIP traffic with the wizard in pfSense 2.1.

On the next screen, there are various QoS options for VoIP traffic. The first checkbox, “Prioritize Voice over IP traffic“, is self-explanatory. The “Provider” drop-down box allows you to specify your VoIP provider. There are a few well-known providers, including Vonage, Voicepulse, and PanasonicTDA, and there’s Asterisk as well, in case you connect to an Asterisk server. If you have a different provider, you can choose “Generic“, or override this setting with the “Upstream SIP Server” field by entering the IP of your VoIP phone or an Alias containing the IPs of all your phones. With the next two fields, “Upload bandwidth for each WAN” and “Download bandwidth (speed) for Voice over IP phones“, you can choose the amount of bandwidth to guarantee to your VoIP phones. The amount of bandwidth you actually use will vary based on how many phones you have and how much each session will use.


The next screen contains options for the “Penalty Box“. The penalty box is a place where you can relegate misbehaving users or devices that would otherwise consume more bandwidth than desired. Click on the “Enable” checkbox to enable this feature, and enter the IP address of the computer to penalize at “Address“. At the “Bandwidth” field, enter the limit you wish to apply.

QoS

Configuring P2P options in the wizard.

The next screen covers “Peer to Peer networking“. Click on the “Enable” checkbox to lower the priority of P2P traffic below all other traffic. By design, P2P protocols and software will utilize all available bandwidth unless limits are put in place. If you expect P2P traffic on your network, it is a good idea to ensure that other traffic will not suffer degradation of QoS due to its use.

Many P2P technologies will deliberately try to avoid detection; Bittorrent is a good example of this. It often utilizes non-standard or random ports, or ports associated with other protocols. You can check the “p2pCatchAll” checkbox which will cause any unrecognized traffic to be assumed as P2P traffic and its priority lowered accordingly. You can also set hard bandwidth limits for this traffic in the “Bandwidth” field underneath the “p2pCatchAll” checkbox. Below this is the “Enable/Disable specific P2P protocols” section. Here you can enable or disable specific services; there are about 20 listed, including BitTorrect, DCC, Gnutella, and others.

The next page covers network games. Many games require on low latency to deliver a good online gaming experience and good QoS. Other traffic, such as downloading large files, can easily swallow up the packets associated with the game itself and cause lag or disconnections. By checking the “Enable” checkbox at the top of the page, you can raise the priority of game traffic so that it will be transferred first and given a guaranteed chunk of bandwidth. Beneath that is a section called “Enable/Disable specific games“. There are many games listed here, including Call of Duty, Doom 3, Halo 2, Quake 3 and 4, and World of Warcraft. Even if your game is not listed, you may want to check a similar game so that you have a reference rule you can modify later.


QoS Management: Everything Else

Next is the “Raise or lower other Applications” page, which lists many other commonly available applications and protocols. How these protocols should be handled will depend on the environment that your pfSense box will be protecting. Applications such as VNC, PCAnywhere (both popular remote access programs), IRC, Teamspeak (popular messenger programs) are can be raised or lowered in priority (or kept at the default level), as well as protocols such as PPTP, IPsec, HTTP, SMTP, POP3 and IMAP. If you enabled p2pCatchAll, you will want to use these options to ensure that these other protocols are recognized and treated normally, rather than being penalized by the default p2pCatchAll rule.

Once you finish configuration on the “Raise of lower other Applications” screen and press the “Next” button, all the rules and queues will now be created, but not yet in use. By pressing the “Finish” button on the final screen, the rules will be loaded and active. Shaping will now be activated for all new connections. Due to the stateful nature of the shaper, however, only new connections will have the new rules applied. In order for the new configuration to be fully active on all connections, you must clear the states. To do this, navigate to Diagnostics -> States, click the “Reset States” tab, check, Firewall state table, then press the “Reset” button.

Now that you have enabled the traffic shaper, you can view the rules and queues defined when you invoked the wizard by navigating to Firewall -> Traffic Shaper and clicking on the different tabs. There should be a tree on the left side of the page; clicking on different parts of the tree should show different relevant QoS settings. For example, clicking on “qVoIP” will show the settings for the VoIP queue. But there will be more about this in a future blog posting.

Other Articles in This Series:

Traffic Shaping in pfSense: What it Does
Traffic Shaping Wizard: Introduction
Queue Configuration in pfSense 2.1
Traffic Shaping Rules in pfSense 2.1
Layer 7 Groups in pfSense 2.1
Bandwidth Limiting with the pfSense Limiter
Deep Packet Inspection Using Layer 7 Traffic Shaping

External Links:

Traffic Shaping Guide at doc.pfsense.org

Link Ads:


Traffic Shaping Wizard: Introduction

traffic shaping wizard

These are the options seen under the Wizards tab in the Traffic Shaper in pfSense 2.1.

Traffic Shaping Wizard Introduced

You can configure the traffic shaper through one of the traffic shaping wizards, manually through the pfSense web GUI, or even at by editing pf.conf in FreeBSD at the command line. It is recommended, however, that when you are using the traffic shaper for the first time, you use the traffic shaping wizard, which will guide you through the process. Due to the complexity of the shaper queues and rules, it is not a good idea to attempt starting out configuring the traffic shaper manually. If you need custom rules, step through the wizard and approximate what you will need, then make the custom rules afterward. Each screen will set up unique queues and rules that will control what traffic is assigned to the queues. If you want to configured everything manually, simply specify your WAN speed at the first screen, then click Next through all the remaining screens without actually configuring anything.


To start the traffic shaping wizard under pfSense 2.1, navigate to Firewall -> Traffic Shaper, and click on the “Wizards” tab. There are several different wizards, each one pertaining to a different pfSense network interface setup:

  • Single LAN multi WAN: There is one local network, but there are multiple interfaces for the WAN (this would be common in a load balancing scenario, in which outgoing and incoming traffic is distributed among two or more WAN interfaces). NOTE: You would also use this in the case where you only have one WAN and one LAN. Just specify 1 for the number of WAN links when going through the wizard
  • Single WAN multi LAN: There is only a single WAN interface, but there are multiple local networks.
  • Multiple LAN/WAN: This will set up traffic shaping in cases where you have both multiple local networks and multiple WAN networks.
  • Dedicated Links: This is for when you want to manage more than one link which gets routerd to a separate, different LAN in the same box. For example, assume you were providing services to 4 different customers in one building and they each had their own separate internet connections. You could run all 4 internet connections through a single pfSense box and provide different traffic shaping configurations for each. Thus, you could have several “virtual” links through a single interface.

In the next article, we will begin working our way through the traffic shaping wizard and look at the different options available within it.


Other Articles in This Series:

Traffic Shaping in pfSense: What it Does
QoS Management Using the Traffic Shaper Wizard
Queue Configuration in pfSense 2.1
Traffic Shaping Rules in pfSense 2.1
Layer 7 Groups in pfSense 2.1
Bandwidth Limiting with the pfSense Limiter
Deep Packet Inspection Using Layer 7 Traffic Shaping

External Links:

Traffic shaping at Wikipedia

External Links:

Traffic Shaping Guide at doc.pfsense.org

Link Ads:


Traffic Shaping in pfSense: What it Does

traffic shapingTraffic shaping is a computer network traffic management technique designed to delay some or all datagrams to bring them into compliance with a traffic profile. Without traffic shaping, packets are processed on a first in/first out basis by the firewall. Traffic shaping, or Quality of Service (QoS) offers a means of prioritizing different types of traffic. This ensures that higher priority services receive the bandwidth they need before lesser priority services. This helps to optimize or guarantee performance, improve latency, and/or increase usable bandwidth for some kinds of packets by delaying other kinds.

Another way of managing computer traffic is traffic policing. The difference between policing and shaping is that traffic policing propagates bursts. When the traffic rate reaches the configured maximum rate, excess traffic is dropped or remarked. The result is an output rate that appears on a graph as a saw-tooth with crests and troughs. In contrast to policing, traffic shaping retains excess packets in a queue and then schedules the excess for later transmission over increments of time. The result of traffic shaping is a smoothed packet output rate.


For purposes of this discussion, we are concerned mainly with traffic shaping in pf (and therefore pfSense). The way traffic shaping is accomplished in pf is that incoming traffic from the Internet going to a host on the LAN is actually shaped coming out of the LAN interface from the pfSense system. In the same manner, traffic going from the LAN to the Internet is shaped when leaving the WAN. This is because traffic has to be limited in a place where pf/pfSense can actually control the flow of data.

There are two means by which traffic shaping is accomplished: traffic shaping queues and traffic shaping rules. The queues are where bandwidth and priorities are actually allocated, while traffic shaping rules control how traffic is assigned into those queues. If a packet matches a shaper rule, it will be assigned into the queues specified by that rule. In that manner, traffic shaping rules are similar to firewall rules, with matching criteria and with outcomes dictated based on whether a packet matches the criteria.

Traffic Shaping: Reasons

The primary reasons you would use traffic shaping are to control access to available bandwidth, to ensure that traffic conforms to the policies established for it, and to regulate the flow of traffic in order to avoid congestion that can occur when the sent traffic exceeds the access speed of its target (remote) interface. Here are some examples why you might want to use traffic shaping:

  • Control access to bandwidth when policy dictates that the rate of a given interface should not on the average exceed a certain rate even though the access rate exceeds the speed.
  • If the network has differing access rates. Suppose that one end of the link in a Frame Relay network runs at 256 kbps and the other end of the link runs at 128 kbps. Sending packets at 256 kbps could cause failure of the applications using the link.
  • If you offer a subrate service. In this case, traffic shaping enables you to use the router to partition your T1 or T3 links into smaller channels.
  • Smoothing out asymmetric links, where the download speed differs from the upload speed (such as DSL connections). Some links are so out of balance that the maximum download speed is unattainable because it is difficult to send out enough ACK packets to keep traffic flowing. By using the traffic shaper to prioritize ACK packets you can achieve faster and more stable download speeds on asymmetric links.
  • Prioritizing VoIP calls. If your VoIP calls use the same circuit as data, then uploads and downloads may degrade your call quality. pf/pfSense can prioritize the call traffic above other protocols and ensure the calls make it through without breaking up.
  • Network gaming. There are also options to give priority to the traffic associating with networking gaming, even if you are downloading while playing.
  • P2P applications. By lowering the priority of traffic associated with known peer-to-peer ports, pf/pfSense ensures that P2P applications will not interfere with other traffic on your network.


Other Articles in This Series:

Traffic Shaping Wizard: An Introduction
QoS Management Using the Traffic Shaper Wizard
Queue Configuration in pfSense 2.1
Traffic Shaping Rules in pfSense 2.1
Layer 7 Groups in pfSense 2.1
Bandwidth Limiting with the pfSense Limiter
Deep Packet Inspection Using Layer 7 Traffic Shaping

External Links:

Traffic shaping at Wikipedia

Comparing Traffic Policing and Traffic Shaping for Bandwidth Limiting [QoS Policing] at www.cisco.com

Ad Links:


DNS Tools: Configuring DNS Forwarding in pfSense

DNS Forwarding: A Useful DNS Tool

A DNS forwarder is a DNS tool which enables a network to skip the normal DNS resolution process and instead forward certain DNS requests to specified DNS servers, asking them to do the resolution work for it. Under pfSense, the DNS forwarder allows pfSense to act as a DNS server with a number of different features. It is a useful DNS tool in that it allows pfSense to resolve DNS requests using hostnames obtained by DHCP service, static DHCP mappings, or manually entered information. The DNS forwarder can also forward all DNS requests for a particular domain to a server specified manually.

DNS Tools: Configuring Common DNS Forwarding Options

DNS tools

Configuring DNS forwarding in pfSense 2.1

Like most DNS tools, some configuration is required. To configure the DNS forwarder, first navigate to Services -> DNS Forwarder. Check the “Enable DNS forwarder” check box. If you check “Register DHCP leases in DNS forwarder“, then matches that specify their hostname when requesting a DHCP lease will be registered in the DNS forwarder, so that their name can be resolved (these are the hosts that appear in the list at Status -> DHCP Leases or, if it is an IPv6 address, DHCPv6 Leases). If “Register DHCP static mappings in DNS Forwarder” is checked, then DHCP static mappings will be registered in the DNS forwarder (these hosts are found by navigating to Services -> DHCP Server and scrolling down to “DHCP Static Mappings for this interface“).


At “Host Overrides“, (near the bottom of the page) specify individual hosts to be served as DNS records by clicking the “plus” button to add a record. Devices in this list are checked first, so even if a record exists elsewhere, the record here takes precedence and is immediately returned. Scrolling even further down the page and just below “Host Overrides“, you will see the “Domain Overrides” section. Here you can specify a DNS server for a particular domain by clicking the “plus” button to add a record. These records are checked immediately after the individual records are defined above. Thus, a match here will take precedence over records that may exist elsewhere.

Configuring Additional Options

DNS tools

Additional options of the DNS Forwarder under pfSense 2.1

As with most DNS tools, here are some other options available. If you check “Resolve DHCP mappings first“, then DHCP mappings will be resolved before the list specified in “Host Overrides“. This only affects the name given for a reverse lookup. As of pfSense 2.1, the “DNS Query Forwarding” subsection contains three options. Checking “Query DNS servers sequentially” causes pfSense DNS Forwarder (dnsmasq) to query the DNS servers sequentially in the order specified at System -> General Setup under the DNS Servers tab, rather than all at once in parallel. Checking the “Require domain” checkbox will prevent DNS Forwarder from forwarding A or AAAA queries for plain names (without dots or domain parts) to upstream name servers. If the name is not known from /etc/hosts or DHCP, then a “not found” answer is returned. Finally, checking “Do not forward private reverse lookups” prevents DNS forwarder from forwarding reverse DNS lookups for private addresses (those defined as such in RFC 1918) to upstream name servers. Any entries in the “Domain Overrides” section forwarding “n.n.n.in-addr.arpa” private names to a specific server are still forwarded. If the IP to name is not known from /etc/hosts, DHCP or a specific domain override, then a “not found” answer is returned.


At “Listen Port“, you can specify a port used for responding to DNS queries (the default is 53), which is useful if another service needs to bind to TCP/UDP port 53. Under “Interfaces“, you can choose the IPs that will be used by the DNS Forwarder for responding to queries from clients. The default behavior is to respond to queries on every available IPv4 and IPv6 address. Each interface is listed twice; e.g. “WAN” and “WAN IPv6 Link-Local“; thus you can limit responses to those clients on a specific interface or clients on a specific interface with an IPv6 address. “Localhost” is also an option. If you check “Strict Interface Binding“, the DNS Forwarder will only bind to the interfaces containing the iP addresses selected in the “Interfaces” list box. This option does not work with IPv6. Finally, under “Advanced” you can enter any additional options you would like to add to the dnsmasq configuration, separated by a space or newline.

When you’re done configuring options in this section, press the “Save” button to save the changes, and on the next screen, press the “Apply changes” button.

External Links:

Undersanding DNS Forwarding at www.dnsmadeeasy.com

DNS Forwarder at doc.pfsense.org

Link Ads:


Gateways and Static Routes in pfSense 2.1

In this article, I will continue my look at some of the new features of pfSense introduced with the latest release (2.1). This time, I will examine some of the updates to the routing functions found under System -> Routing: gateways, static routes, and gateway groups.

Configuring Gateways

Gateways

Default gateways in pfSense 2.1

When you navigate to System -> Routing, and click on the “Gateway” tab, the first thing you will notice is that whereas in the past, there was one gateway created by default (Interface WAN Dynamic Gateway), now there are two: [1] Interface WAN_DHCP Gateway, and [2] Interface WAN_DHCPv6 Gateway. The former gateway, as you might have guessed, uses IPv4, whereas the latter uses IPv6. Both gateways seem to be created by default regardless of whether you actually have any IPv6 interfaces.

Gateways

Configuring gateways under pfSense 2.1.

If you click on the “plus” button, you can add a new gateway. The options are substantially the same as they were under pfSense 2.0.3 (I refer you to my article on pfSense gateway configuration), with one exception: there is a new option called “Address Family“. Here, you can choose either IPv4 or IPv6, underscoring the extent to which pfSense 2.1 has added support for IPv6. If you click on the “Advanced” button, you will see that “Frequency Probe” has been renamed “Probe Interval” (this is the interval at which ICMP probe will be sent, to see if the gateway is still up), but otherwise, the Advanced options are identical to what they were under 2.0.3.


Configuring Routes

If you click on the “Routes” tab and click on the “plus” button, you will see once again that the options for creating a static route are similar to the options under 2.0.3, with one exception: once again, it’s the addition of support for IPv6. With a possible CIDR of 1 to 129, the “Destination Network can be either an IPv4 or IPv6 address. The “Gateway” can be either a default gateway (WAN_DHCP or WAN_DHCP6), a user-defined gateway, the IPv4 loopback (127.0.0.1) or the IPv6 loopback (::1). If you’ve created static routes before, this is easy.

Configuring Gateway Groups

Gateways

Creating a gateway group in pfSense 2.1

If you click on the “Group” tab and click on the “plus” button to add a gateway group, you will find the options are almost identical to those under 2.0.3. Under “Gateway Priority“, however, there is one new option: in addition to “Tier“, there is “Virtual IP“; this field selects what virtual IP should be used when this group applies to a local Dynamic DNS, IPsec or OpenVPN endpoint.

As you can see, a common motif in our exploration of pfSense 2.1 is the degree to which IPv6 support has been added. As the IPv4 address pool nears exhaustion, this was an essential upgrade. I’m sure I will come across other interesting features, however, as I continue my look at the new pfSense.


External Links:

World IPv6 Launch – various measurements and resources regarding IPv6 adoption, as well as a blog.

IPv6 Integration: A Look at pfSense 2.1

On September 15, 2013, pfSense 2.1 was released. This release brings many new features; the biggest change is IPv6 support in almost every portion of the system. There are also a number of bug fixes. Recently, I burned a live CD of 2.1 to see what interesting features the new version has.

Configuring an Interface for IPv6

IPv6

Configuring an interface for IPv6 in pfSense 2.1

The integration of IPv6 support is obvious to anyone who even takes a casual look at the pfSense web GUI. Under “Interfaces“, if you select an interface, under “General Configuration“, there is a new dropdown box called “IPv6 Configuration Type“. The options are: Static, DHCP, Stateless Address Auto Configuration (SLAAC), 6rd Tunnel, 6to4 Tunnel, and Track Interface. Stateless Address Auto Configuration is a mechanism that allows a host to generate its own IPv6 address even if the routable addresses are assigned or pre-configured and is required on all IPv6 configurations. 6rd is an IPv6 transitioning mechanism to allow for stateless tunneling of IPv6 over IPv4, and is intended as a mechanism to tunnel across an ISP’s IPv4-only access network. 6to4 Tunnel is yet another transition mechanism for migrating from IPv4 to IPv6, and allows IPv6 packets to be transmitted over an IPv4 network without the need to configure explicit tunnels. Choosing “None” disables IPv6 on this interface.

If you choose an IPv6 configuration type, the “Static IPv6 configuration” subsection appears. Here you must enter an IPv6 address and an optional gateway. Once you have entered this information, you can press the “Save” button and the “Apply Changes” button on the next page.


DHCPv6 Relay and DHCPv6 Server

Once you have configured at least one IPv6 interface, it will be possible to configure other IPv6-related services. For example, by navigating to Services -> DHCPv6 Relay, you can add an IPv6 DHCP relay. This enables you to relay DHCPv6 requests to a server or several servers. In order to use this service, click on the “Enable” check box to enable the DHCP relay. In the “Interfaces” list box, select the interface(s) from which DHCP requests will be relayed (hold down the CTRL key while clicking to select more than one interface. Next is the “Append circuit ID and agent ID to requests“. pfSense can append its interface number (circuit ID) and agent ID to DHCP requests, just as it can with IPv4 DHCP requests. Finally, at the “Destination server” edit box, you type in the IPv6 address of the server to which DHCPv6 requests are relayed. You can enter multiple server IPv6 addresses, separated by commas. Then press the “Save” button to save the settings.

IPv6

Configuring Router Advertisements in pfSense 2.1.

Another new option under “Services” is “DHCPv6 Server/RA“. If you select this option there are two levels of tabs. On the top level, there is a tab for each IPv6 interface. You can enable a DHCPv6 server on each of these interfaces. The configuration options for the DHCPv6 server look identical to the configuration for DHCP for IPv6. There is a second tab, however, for “Router Advertisements“. There are five choices: “Disabled”, which disables router advertisements, “Router Only”, which causes pfSense to advertise only the current router; “Unmanaged”, which allows the radvd router advertisement daemon to handle advertising with stateless autoconfig; “Managed”, which causes assignment through the DHCP server, and “Assisted”, which combines the two. “Router Priority” allows you to select the priority for the Router Advertisement Daemon (low, normal, or high). You can add a Router Advertisement subnet on this page as well by clicking on the “plus” button and adding a subnet. You can also specify an alternate DNS server or domain serch list or use the same settings as the DHCPv6 server.


I have really only scratched the surface regarding IPv6 integration in pfSense 2.1, and there are many other features I have not touched upon here. As a result, it looks like there will be many more postings concerning the new features of the latest pfSense. Stay tuned.

External Links:

IPv6 at Wikipedia

Failover with CARP in PF: Part Five (Rule Set Config)

In the previous article, I covered configuration of the network interfaces of our hypothetical CARP configuration, including the two CARP interfaces and the pfsync interface. In this article, I will cover the rule set for our dual firewall system.

As far as PF is concerned, network traffic comes from the physical interface, not the CARP virtual interface (in our case, carp0, and carp1). Write your rule sets accordingly and don’t forget that an interface name in a PF rule can be either the name of a physical interface or an address associated with that interface. Thus:

pass in on if0 inet proto tcp from any to carp0 port 22

could be correct. Replacing if0 with carp0, however, will not work as intended. In addition, do not forget to pass both proto carp and proto pfsync.


We start by introducing a macro definition for the carp devices and an accompanying pass rule, such as:

pass on $carpdevs proto carp keep state

The most readable way is to introduce a macro definition for you syncdev and an accompanying pass rule, such as:

pass on $syncdev proto pfsync

If you want to take the pfsync device out of the filtering equation, use:

set skip on $syncdev

It may not always be necessary to synchronize every rule in your configuration in case of a failover because there are some rules in which it is not particularly crucial. One example would be the typical rule to allow ssh in for the administrator:

pass in on $int_if from $ssh_allowed to self

For those rules, you might consider using the state option no-sync to prevent synchronizing state changes for connections that are not relevant after the failover has happened, like so:

pass in on $int_if from $ssh_allowed to self keep state (no-sync)

With this in mind, we can create our hypothetical pf.conf file:

####################################
# Macro Defines
####################################
lop_int=”lo0″
hrt_int=”if2″
ext_int=”if0″
int_int=”if1″
carpdevs = “{ if0, if1, if2 }”

fw_addr=”50.87.147.42″

ftp_ports=”{ 21,60000:60049 }”
email_ports=”{ 25,110 }”
webmail_ports=”{ 32000,32001 }”

####################################
# Options – Set up global settings
####################################
#set timeout { interval 10, frag 30 }
#set timeout { tcp.first 120, tcp.opening 30, tcp.established 86400 }
#set timeout { tcp.closing 900, tcp.finwait 45, tcp.closed 90 }
#set timeout { udp.first 60, udp.single 30, udp.multiple 60 }
#set timeout { icmp.first 20, icmp.error 10 }
#set timeout { other.first 60, other.single 30, other.multiple 60 }
#set timeout { adaptive.start 0, adaptive.end 0 }
set limit { states 30000, frags 15000 }
set block-policy drop
set optimization conservative

#####################################
# Normalization: reassemble
# fragments and resolve or reduce
# traffic ambiguities.
####################################
scrub in all

####################################
# Filtering Rules
####################################
# Set default policy
block all

# Log any connection attempt to the firewall
block in log on $ext_int from any to $fw_addr

# Allow all Loopback
pass quick on $lop_int all

# Allow pfsync Updates In/Out
pass quick on $hrt_int proto pfsync keep state

# Allow CARP Advertisements In/Out
pass quick on $carpdevs proto carp keep state

# Allow HTTP Through
pass in quick on $ext_int proto tcp from any to port 80 keep state
pass out quick on $int_int proto tcp from any to port 80 keep state

# Allow all outgoing traffic
pass in quick on $int_int all keep state
pass out quick on $ext_int all keep state

# Allow Pings
pass in quick on $ext_int proto icmp from any to keep state
pass out quick on $int_int proto icmp from any to keep state

# Allow Pings to Firewall
pass in quick on $ext_int proto icmp from any to $fw_addr keep state

# Allow Terminal Services
pass in quick on $ext_int proto tcp from to port 3389 keep state
pass out quick on $int_int proto tcp from to port 3389 keep state

# Allow SSL Through
pass in quick on $ext_int proto tcp from any to port 443 keep state
pass out quick on $int_int proto tcp from any to port 443 keep state

# Allow FTP Through
pass in quick on $ext_int proto tcp from any to port $ftp_ports keep state
pass out quick on $int_int proto tcp from any to port $ftp_ports keep state

# Allow Email Through
pass in quick on $ext_int proto tcp from any to port $email_ports keep state
pass out quick on $int_int proto tcp from any to port $email_ports keep state

# Allow Webmail Through
pass in quick on $ext_int proto tcp from any to port $webmail_ports keep state
pass out quick on $int_int proto tcp from any to port $webmail_ports keep state

# Allow DNS Through
pass in quick on $ext_int proto { tcp, udp } from any to port 53 keep state
pass out quick on $int_int proto { tcp, udp } from any to port 53 keep state

# Allow SSH Access From Trusted on External To The FW
pass in log quick on $ext_int proto tcp from to $fw_addr port 22 keep state


External Links:

Redundant Failover Firewall with pf, pfsync and CARP under FreeBSD

© 2013 David Zientara. All rights reserved. Privacy Policy