Dynamic DNS Configuration in pfSense

Dynamic DNS Explained

Dyanmic DNS (DDNS) is a method of automatically updating a name server in the Domain Name System (DNS), often in real time, with the active DNS configuration of its configured hostnames, addresses or other information. The term is used in two different ways. At the administrative levels of the Internet, “dynamic DNS updating” refers to systems that are used to update traditional DNS records without manual editing. But another type of dynamic DNS permits lightweight and immediate updates to its local database, often using a web-based mechanism. It is used to resolve a domain name to an IP address that may change frequently, thus providing a persistent addressing method for devices that change their location or configuration.

It is the latter type of DDNS in which we are interested. End users of Internet access receive an allocation of IP addresses, often only a single address, by their service providers. If you are a residential or small business customer, you will probably have an IP address assigned dynamically. Such dynamic IP addresses present a problem if the customer wants to provide a service to other users, such as a website. As the IP address may change frequently, corresponding domain names must be quickly re-mapped in the DNS servers to maintain accessibility using a well-known domain name. To this end, many providers offer commercial or free DDNS service for this scenario, with reconfiguration generally implemented in the user’s router or computer.

Dynamic DNS providers offer a software client program that automates the discovery and registration of the client system’s public IP addresses. The client program connects to the DDNS provider from the client’s private network and links the public IP address of the home network with a hostname. Depending on the provider, the hostname is registered with a domain owned by the provider or the customer’s own domain name. These services can function by a number of mechanisms. Often the use an HTTP service request. The provider might use RFC 2136 to update the DNS servers (more on RFC 2136 later). Many home networking modem/routers have clients for several DDNS providers built into their firmware, and pfSense is no exception, making it very easy to use DDNS with pfSense.

Configuring Dynamic DNS in pfSense

Dynamic DNS

Configuring the DDNS client in pfSense 2.0.

To enable DDNS in pfSense, first navigate to Services -> Dynamic DNS. If the “DynDNS” tab is not selected already, click on it. Press the “plus” button on the right side of the page to add a new DDNS client. At “Service type“, select a DDNS service provider from the dropdown box. At “Interface to monitor“, specify an interface (typically the WAN). At “Hostname“, specify the hostname (either one supplied by the provider or your own hostname) that you wish to associate with your network’s public IP. At “MX“, set your MX record if you need one (thus allowing you to configure your subdomain for email routing) and if your service supports it. At “Wildcards“, enable wildcards if desired. This is useful if the domain name specified is not a fully qualified domain name (FQDN); for example, if your DDNS address is myplace.dyndns.org and you enable wildcards, then x.myplace.dyndns.org will work as well (x is the wildcard). At “Username” and “Password“, specify your username (username is required for all types except Namecheap and FreeDNS) and password. At “Description“, enter an appropriate description. Then press the “Save” button to save the settings and, on the next page, press “Apply Changes” to apply the changes if necessary.

Dynamic DNS

If our DDNS service provider is not one of the pre-configured ones, we can still use pfSense to act as a client for the provider if it complies with RFC 2136.

To make sure everything is working go back to Services -> Dynamic DNS. If the cached IP is green then the hostname was successfully updated. It is also probably a good idea to ping the domain to make sure the domain name resolves to the correct IP address. Even with DDNS, it can take several minutes for the changes to propagate to other DNS servers. The client will automatically update the dynamic host each time the WAN IP changes or every 25 days. You probably want to make sure your client is connecting to the service, since some providers will remove inactive hosts if they have not been updated for 30 days.

This configuration will work in most cases; however, it is possible you may be using a DDNS service provider that is not on the list at “Service type“. If this is the case, you can still use pfSense to to connect to your DDNS provider as long as the provider adheres to the RFC 2136 standard. To enable this, navigate to Services -> Dynamic DNS as before, but select the RFC 2136 tab. Press the “plus” button to add a new entry. Specify the “Interface to monitor” and “Hostname” as outlined in the instructions for the “DynDNS” tab. You can also specify a time to live for data from our client at “TTL“. You must also specify a “Key Name” that matches the key name setting on the DNS server, a “Key type” (zone, host, or user), and an HMAC-MD5 “Key“. You must specify the server address at “Server“. Check the check box at “Protocol” if the DDNS provider uses TCP instead of UDP. At “Description“, enter an appropriate description. Then press the “Save” button to save the changes and “Apply changes” to apply changes if necessary.

External Links:

Dynamic DNS on Wikipedia

Dynamic DNS on doc.pfsense.org

RFC 2136 Dynamic DNS on doc.pfsense.org

How to Configure Dynamic DNS in pfSense at HubPages

Routing Information Protocol: Notes

Routing Information ProtocolI decided to write a follow-up to the article on RIP to clarify some issues. RIP version 1 does not support classless routing, whereas RIP version 2 does. To understand the implications of this, consider the historical classful network architecture. A class A network has an 8-bit network ID and the first octet is from 0 to 127. A class B network has a 16-bit network ID and the first octet is from 128 to 191. A class C network has a 24-bit network ID and the first octet is from 192 to 223. This system served its purpose in the early stages of the Internet, but it lacked scalability in the face of the rapid expansion of the network in the 1990s. The class system of the address space was replaced with Classless Inter-Domain Routing (CIDR) in 1993. CIDR is based on variable length subnet masking (VLSM) to allow allocation and routing based on arbitrary-length prefixes.

IP Classes
Class First Decimal Value Addresses Hosts per Network
Class A 1-128 16.7 Million
Class B 128-191 65534
Class C 192-223 254
Class D 224-239 Multicast addresses
Class E 240-255 Experimental addresses

Classless Networks

The advantages of classless networks should be obvious. Assume we currently have one class C network: We have 100 hosts, and we would like to split our network into two separate networks, each with 50 hosts. We could set up a new network at This would be overkill, however, since each network allows for 254 hosts (all permutations of 1s and 0s in the final octet except 0 and 255, as we don’t want addresses that are all ones or zeros). A potentially better solution would be to divide into two separate subnets. To do this, we move our netmask two bits to the right. Doing this gives us 4 new combinations, but 2 of them are useless – 00 and 11 – so we are left with 01 and 10 as the rightmost bits of our two subnets. The subnet masks for our networks are and, or in CIDR notation, and

Problems with RIP Version 1

Where it becomes a problem is if we are running RIP version 1. Let’s assume we have a router (Router A) for our first subnet ( and a router (Router B) for our second subnet ( Let’s further assume that there is a third router (Router C) with a path to both routers. RIP version 1 uses classful subnetting, so it will look at the first octet to determine what the subnet mask is. In this case, it will see that the first octet is 192, and assume it is a class C network with a subnet mask of It will update the routing tables to show Router A and B both with a network ID of Router C will then assume that it has two paths to the same network (instead of paths to 2 separate networks), and, as a result, if it wants to send an update to, say, (which is on Router B’s subnet), it may send the update to Router A instead.

Since we probably don’t want to abandon classless networking, the solution is to use RIP version 2, or RIPng (an extension of RIP version 2). Each supports classless networking and therefore will allow us to create new subnets.

External Links:

Classless Inter-Domain Routing at Wikipedia

Routing Information Protocol Setup in pfSense

Routing Information Protocol Explained

Routing Information Protocol

Enabling Routing Information Protocol (RIP) in pfSense.

The Routing Information Protocol (RIP) is one of the oldest distance-vector routing protocol, which employs the hop count as a routing metric. RIP prevents routing loops by implementing a limit on the number of hops allowed in a path from the source to a destination. The maximum number of hops (one portion of the path between source and destination; each time packets are passed to the next device, a hop occurs) allowed for the protocol is 15. This limit, however, also limits the size of networks that RIP can support (a hop count of 16 is considered unreachable).

RIP implements several algorithms to ensure incorrect routing information from being propagated. As a result, it is considered relatively stable. Using RIP, a gateway host sends its entire routing table, which lists all the other hosts it knows about, to its closest neighbor host every 30 seconds. The neighbor host in turn will pass the information on to its next neighbor and so on until all hosts within the network have the same knowledge of routing paths, a state known as network convergence. As networks increased in size, it became evident there could be a massive traffic burst every 30 seconds, even if the routers had been initialized at random times.

RIP uses the User Datagram Protocol (UDP) as its transport protocol, and is assigned the reserved port number 520. The original specification of RIP was defined in RFC 1058 and uses classful routing. The periodic routing updates do not carry subnet information and lack support for variable length subnet masks, making it impossible to have different-sized subnets inside the same network class. RIP version 2 was developed in 1993 and last standardized in 1998. It included the ability to carry subnet information and also multicasts the routing table (to instead of broadcasting the table, to avoid unnecessary load on hosts that do not participate in routing. It is defined in RFC 2453. To maintain compatibility with version 1, the maximum number of hops is still 15. RIPng, defined in RFC 2080, incorporates several improvements over version 2, including support for IPv6 networking, attaching arbitrary tags to routes, and sending updates on UDP port 521. pfSense does not seem to currently support RIPng.

The major alternative to RIP is the Open Shortest Path First Protocol, which was discussed in a previous blog posting. Other alternatives include Cisco’s proprietary Interior Gateway Routing Protocol (IGRP), a distance-vector routing protocol, and its replacement, Enhanced Interior Gateway Routing Protocol (EIGRP).

Enabling Routing Information Protocol in pfSense

To enable RIP in pfSense, first navigate to Services -> RIP. At “Enable RIP”, check the check box. At “Interfaces”, select at least one interface (hold CTRL down while clicking to select multiple interfaces). At “RIP Version”, select either RIP Version 1 or Version 2. At “Password”, set a password if using RIP version 2. Finally, press the “Save” button to save the changes.

External Links:

Routing Information Protocol at Wikipedia

Routing Information Protocol (RIP) at doc.pfsense.org

Routing Information Protocol (RIP)”>Routing Information Protocol at SearchNetworking

Introduction to Routing Information Protocol (RIP) on YouTube

Video: pfSense VPN, Part Four (PPTP)

I recorded another video; this one covers Point-to-Point Tunneling Protocol:

NTP Configuration in pfSense

NTP Explained


The Services list shows the NTP service is running.

The Network Time Protocol daemon (NTPD) is an operating system daemon that maintains the system time with time servers, using the Network Time Protocol. It is a complete implementation of the Network Time Protocol version 4, but retains compatibility with previous versions of NTP. NTPD performs most computations in 64-bit floating point arithmetic and uses 64-bit fixed point operations only when necessary to preserve the ultimate precision. The Network Time Protocol needs some reference clock that defines the true time to operate. All clocks are set towards that true time. NTP is a fault-tolerant protocol that will automatically select the best of several available time sources to synchronize to. Multiple candidates can be combined to minimize the accumulated error. Temporarily or permanently bad time sources will be detected and avoided. Having available several time sources (there are at least 175,000 hosts running NTP servers), NTP can select the best candidates to build its estimate of the current time. The protocol is highly accurate, using a resolution of less than a nanosecond. And even when a network connection is temporarily unavailable, NTP can use measurements from the past to estimate current time and error.

The official specification of NTP version 3 is RFC 1305. According to the NTP Version 4 Release Notes, the new features of version four are:

  • Use of floating-point arithmetic instead of fixed-point arithmetic.
  • Redesigned clock discipline algorithm that improves accuracy, handling of network jitter, and polling intervals.
  • Support of the nanokernel kernel implementation that provides nanosecond precision as well as improved algorithms.
  • Public Key cryptography known as autokey that avoids having common secret keys.
  • Automatic server discovery (manycast mode)
  • Fast synchronization at startup and after network failures (burst mode)
  • New and revised drivers for reference clocks
  • Support for new platforms and operating systems

Enabling Network Time Protocol in pfSense 

Network Time Protocol

You can edit the NTP server settings at System -> General Setup.

Enabling OpenNTP in pfSense is relatively easy. First, make sure the pfSense system’s clock is set and is reasonably accurate. If not, synchronization may fail because if there is a substantial difference between the system time and the time reported by the NTP server, the daemon will assume the server is wrong and not the other way around. Then navigate to Services -> NTP. At “Interface“, select the interface(s) the NTP daemon service will listen on (hold down CTRL while clicking to select multiple interfaces). Then press the “Save” button to save the changes. Now, NTP synchronization will be enabled on your pfSense box, but client machines can take up to a few hours (doc.pfsense.org reports 1-2 hours) to become fully synchronized with the OpenNTPD service.

If you want to edit the list of NTP time servers, navigate to System -> General Setup. Under the “System” heading, the last option is “NTP time server“. Here you can specify one or more time servers (use a space to specify multiple hosts). Then press the “Save” button to save the settings.

External Links:

Network Time Protocol on Wikipedia

ntp.org – home of the Network Time Protocol project

The Network Time Protocol  Distribution NTP Server at doc.pfsense.org

Use pfSense as an NTP Server – another post from the excellent iceflatline blog.

How to Set Up an NTP Server for Your Network

Using pfSense and OpenNTPD – a how-to guide from HubPages.

pfSense Setup HQ on Facebook (and Twitter)

pfSense Hardware RequirementsI should have done this before, but I’ve created a Facebook page for pfSense Setup HQ. There are links to the latest articles posted to this site, and I’m looking forward to adding more content to the page soon.

I also started a Twitter account for this site, which may be more convenient for those who just want to get tweets whenever a new article is posted.

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 WhatIs.com

Egress filtering on Wikipedia

Firewall Best Practices – Egress Traffic Filtering from The Security Skeptic

pfSense Hardware Requirements

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

  • Throughput required
  • Features that will be used

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

Summary of pfSense Hardware Requirements

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

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

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

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

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

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

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

External Links:

pfSense Hardware Requirements and Sizing Guidance at pfsense.org

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

How to speed up IPSec, hardware encryption devices? at forum.pfsense.org

Firmware Update with pfSense

A pfSense system can be updated through the web interface. This will let you update the router to a new version so it stays current and supported. Firmware updates are issued periodically to fix bugs, address security issues, and add features.

Downloading and Installing a Firmware Update

Firmware Update

Updating the firmware manually in pfSense 2.0.

To update the firmware, first navigate to System -> Firmware. Click on the “Auto Update” tab (the second of three tabs). Press the “Invoke Auto Upgrade” button and observe the download status in the text window. Once the download is complete, pfSense will upgrade itself and reboot. On the first login after the system has been rebooted, you will be redirected to the Package Manager status page. Assuming pfSense was able to contact pfsense.org, download the firmware and did not have any issues with installation, the firmware update is now complete.

pfSense also allows for a manual firmware update. First, download the appropriate firmware version from pfsense.org and save it locally. Then navigate to System -> Firmware and click on the “Manual Update” tab (the first of three tabs). On the next page, click the “Choose” button to browse for the firmware you have downloaded. Once you have selected the correct file, press “Open” in the file dialog box. Then press the “Upgrade firmware” button.

While the firmware is being upgraded, any attempt to access the pfSense web interface will redirect you to a page informing you that an upgrade is in progress and that the firewall will reboot when the upgrade is complete. If a new version of pfSense is available, an “Update available” notification will be displayed on the “Status: Dashboard” homepage, in the “Version” section of “System Information“.

External Links:

pfSense Firmware Update Documentation at doc.pfsense.org

Upgrade pfSense 2.0 from RC1 to RC3

Video on upgrading pfSense 2.0 from RC1 to RC2 (from YouTube)

Video: pfSense VPN Part Three (OpenVPN Pt. 1)

This is the third in my series of videos on VPNs; this video covers OpenVPN and will be continued in the next video:

© 2013 David Zientara. All rights reserved. Privacy Policy