pfSense Digest

Thanks to Ermal, we now have support for GIF and GRE tunneling in pfSense. Integration with IPsec is coming soon. This isn’t something most people will use, but some like to use gif with IPsec and some need GRE for interoperability with other vendors’ equipment (commonly Cisco in some specific configurations that utilize it).

The use of tunneling with IPsec allows the use of routing across VPN, rather than requiring a SPD match, which is preferable in some environments. It also allows the use of routing protocols across VPN.

Thanks to the hard work of Ermal Luçi, pfSense 1.3 now contains a number of great interface and dynamic DNS related improvements. The following has all been completed.

1. PPPoE and PPTP are now possible on any interface rather than just WAN. For multi-WAN with multiple PPPoE or PPTP connections you previously needed to do the PPPoE or PPTP on the modem or other device, now pfSense handles this directly.
2. Dynamic DNS is now multi-account capable. This means you can use it with multiple WANs, and/or use multiple services on the same WAN.
3. carpdev support – This was attempted, and unfortunately backed out because of problems with carpdev in FreeBSD. If those problems are resolved, it will return. This allows the use of CARP without the static public IP requirement.
4. Interface list consistency – this isn’t really relevant to end users, but it’s a great improvement for developers. The means of obtaining the list of active interfaces obtained from m0n0wall initially had really turned into a hack as we have added functionality such as multi-WAN and single interface support. This resolves a number of development difficulties.
5. Completely reorganized back end interface support. The interfaces are all treated equally now, fully removing the “special” status that LAN and WAN formerly received.
6. Improved back end VLAN interface handling
7. Introduction for dummynet support in pf – this provides even more flexible and powerful traffic shaping abilities, including these two oft-requested features amongst numerous other possibilities:
   - Per user bandwidth limiting
   - Per local subnet bandwidth limiting
8. Improved ruleset creation speed – testing shows at least a 15% improvement here.
9. Captive Portal is now multi-WAN capable
10. Sticky connections for outbound load balancing should be fixed.

Mostly finished work

1. Replace the event system with a daemon offering better handling of events.

Work in progress

1. Better PPTP and FTP handling in NAT. The PPTP fixes will allow multiple outbound connections to the same external PPTP server using a single public IP. Details of that issue on the Features page on the website under PPTP/GRE NAT limitation.
2. More disciplines on the shaper such as shortest living connections getting higher priority, and addition of the JoBS/WFQ discipline for ALTQ.

Thanks Ermal!

Amazon has posted my review of Network Administration with FreeBSD from Packt Publishing. It may be of interest to those of you working with stock FreeBSD systems. While I wouldn’t call it a great book, as my review indicates, it’s absolutely proven useful. I’ve picked it up on a few occasions for reference purposes.

For those new to FreeBSD and wanting to learn more, the above is not intended as a book for beginners. For anyone new to FreeBSD, I recommend Absolute FreeBSD. I have not yet had a chance to read the second edition, but recommend it because the first edition was great, Michael Lucus is an excellent writer, and it has gotten exceptional reviews from people whose reviews I always find spot on, like Richard Bejtlich.

None of this is really relevant to pfSense, unless you want to become a developer. We hide all the details of FreeBSD so you don’t need to know these things. But if you’re interested in deploying FreeBSD in other uses, these may be of use.

The 1.2.1 snapshots are shaping up much quicker than we thought they would.  Please see the previous blog entry for more information and jump in and help us test!

If all goes well we will be releasing a 1.2.1-RC1 this weekend!

If you run your own DNS server and haven’t patched yet – now would be the time to do so. The details of the previously mentioned vulnerability were inadvertently made publicly available earlier today.

Our previous assertion that dnsmasq in pfSense is not vulnerable was correct. We will be putting out a version with the updated dnsmasq, however this is just to protect from the possibility of a different attack in the future. With this particular issue there is no immediate need to update caching-only DNS servers including pfSense.

So what needs to be patched?
The server that issues recursive queries to your DNS requests. What server this is varies depending on your configuration. I’ll group into two categories.

pfSense DNS Forwarder Users
For those who use the DNS forwarder on pfSense for all internal DNS, the servers that need to be patched are your ISP’s. For dynamic IP connections, in a default configuration the servers assigned by your ISP will be used for recursive lookups. You can override this by entering servers on the System -> General Setup page and unchecking the “Allow DNS server list to be overridden by DHCP/PPP on WAN” box.

Users of Internal DNS Servers
You will need to make sure your internal DNS server is patched.

How can I tell if I’m vulnerable?
Visit DoxPara and click the “Check my DNS” button.

Fixing the Issue Without Relying on your ISP
You can easily fix this without relying on your ISP applying patches by using OpenDNS, a free DNS service that was never vulnerable to this issue in the first place. To use OpenDNS, just enter 208.67.222.222 and 208.67.220.220 for your DNS servers in the General Setup page, and uncheck the “Allow DNS server list to be overridden by DHCP/PPP on WAN” box. Click Save on that page, and re-test. You will see you are no longer vulnerable.

pfSense Will Not Make Your Patched Servers Vulnerable
Unlike numerous other firewall and NAT products including some big name commercial vendors, pfSense will not un-randomize the source ports on NATed traffic leaving you vulnerable. If you are using NAT on anything other than pfSense, make sure that device isn’t defeating the purpose of the DNS server patches by improperly rewriting.  The DoxPara test will determine that.

All versions of pfSense are compatible with Xen 3.2.1 with HVM. Paravirtualization is not supported in current stable FreeBSD releases so it is not possible at this time, but HVM does work properly with the real mode boot fixes added in 3.2.1. You will need to use the make option “vmxassist=n”. To our knowledge, the Xen packages included with most major Linux distributions do not do this at this time, so you must compile it yourself with this option.

Thanks to Brian Zushi for this information. He restored his pfSense configuration from a physical box into a Xen VM and is currently running it in production.

We are pleased to welcome Matthew Grooms as our newest pfSense committer. As the developer of the Shrew Soft VPN client and an ipsec-tools developer, he brings a vast knowledge of IPsec to our development team.

Matthew recently committed some great IPsec improvements to 1.3. He provided the following, outlining these changes.

Completed Work

1. Split IPsec configuration into phase1 and phase2
2. Allow for multiple phase2 configurations for a single phase1 – this means you no longer have to create parallel tunnels for routing multiple subnets between two sites.
3. Enable a broader range of ID types to be specified
4. Improve options for variable length key cyphers ( Blowfish & AES )
5. Proper handling of address vs subnet negotiations in phase2
6. Introduce Hybrid, Xauth and modecfg support for remote access
7. Update Mobile access to allow for more secure policy generation
8. Update Mobile access configuration to define modecfg-attributes
9. Introduce initial support for user authentication
10. NAT-Traversal (NAT-T)

Remaining To Complete

1. Improve user management interface for mobile clients
2. Introduce RADIUS and LDAP support for extended auth
3. Improve IPsec SPD/SAD management to not purge active SAs on reload
4. Improve certificate management for IPsec configurations
5. Look into support for dyndns -> dyndns IPsec peers

More information
For those not exceptionally familiar with IPsec, the above lists may not tell you much of anything. More information on usage and what all this means will come in the future.

Eye Candy
New tunnels page
New mobile clients screen
New mobile clients phase 1 edit screen
New mobile clients phase 2 edit screen

Trying it out
This work is currently available in 1.3 snapshots. We encourage you to provide feedback on the mailing list or 1.3 board on the forum if you try it.

Kudos
Many thanks to Matthew for all his work on this! When completed, this will bring the most capable IPsec implementation of any open source firewall distribution to pfSense – by far. It will also provide a standards-compliant IPsec solution better than most commercial firewalls (what exists in 1.2 is already better than a number of them).

After some fixes to the package and pfSense, the siproxd package is now working. This allows you to connect multiple SIP phones to the same SIP server on the Internet. This is problematic with many NAT implementations for the reasons described under NAT Limitations on the Features page.

Wide Open Mind episode 9, Building a router with pfSense, contains a nicely done very basic overview of pfSense that offers a good introduction for the typical home user.

Not sure why he didn’t acknowledge the alert prior to recording.    That’s the first time I’ve seen that message pop up on anything other than the Intel NICs in Nokia IP110/120/130 boxes. That feature generates a random MAC address from unassigned vendor space for NICs whose MAC address show to the OS as FF:FF:FF:FF:FF:FF. This is very rare, and occurs on atypical hardware that doesn’t store its MAC address in the “usual” location for whatever reason. The alert is basically a “hey, this is weird, but I fixed it” notification.

Nicely done video though.

Recently came across a number of great reasons why you should not be using FTP.

Take a look at let me know what you think: http://stevenf.com/archive/dont-use-ftp.php