Pfsense Old Versions

In addition to being a routing platform, pfSense includes a long list of related features and a package system which allows further expandability. Popularity (hits per day): 12 months: 167 (54), 6 months: 151 (65), 3 months: 122 (87), 4 weeks: 131 (70), 1 week: 157 (51).

Important

Netgate is offering COVID-19 aid for pfSense software users, learn more. Satie piano works.

Limiters¶

On pfSense® software versions 2.2 and 2.3, limiters cannot be used on firewallrules residing on interfaces where NAT applies. This limits their use toLAN-type interfaces only, and not WANs, in most circumstances. This has beenfixed on pfSense 2.4. Bug #4326
On pfSense software versions 2.2 and 2.3, limiters cannot be used where pfsync isenabled. This has been fixed on pfSense 2.4.3.Bug #4310

IPsec Changes¶

The IPsec daemon was changed from racoon to strongSwan. Existingconfigurations work the same as always, but if any unusual configurations arepresent, take care in testing after the upgrade. Changes in behavior because ofthis change may trigger bugs in remote endpoints that weren’t previously anissue. Configurations that were always technically incorrect may exhibitproblems now where they didn’t previously. We have listed the circumstances weare aware of here, and will expand upon this list if anything new is found.

Problem in racoon with aggressive mode and NAT-D¶

Those using racoon (pfSense 2.1.x and earlier, among a variety of other similarproducts) on remote endpoints with aggressive mode may encounter a bug in racoonrelated to NAT-D and aggressive mode. Any site to site IPsec VPNs usingaggressive mode with racoon as a remote endpoint should change to main mode toprevent this from being an issue. Main mode is always preferable for itsstronger security.

glxsb Crypto Accelerator Warning¶

For those using the glxsb crypto accelerator in the ALIX and other deviceswith Geode CPUs, only AES 128 bit is supported by those cards. Any key length >128 bit has never worked, and must not be configured. There appear to becircumstances where AES on “auto” with racoon preferred 128 bit where strongswanprefers the strongest-available and is choosing 256 bit, which glxsb breaks.Input validation in 2.2.1 prevents such invalid configurations when addingconfigurations or making changes, however existing configurations are notchanged. If using glxsb and AES, ensure both phase 1 and phase 2 configurationsall use AES 128 only and never auto.

Mobile client users, verify Local Network¶

For mobile IPsec clients, clients could pass traffic in certain circumstanceswithout having specified the necessary matching local network in the mobilephase 2 configuration. The “Local Network” specified in mobile IPsec phase 2must include all networks mobile clients need to reach. If mobile IPsec clientsneed to access the Internet via IPsec, the mobile phase 2 must specify0.0.0.0/0 as the local network.

Stricter Phase 1 Identifier Validation¶

In 2.1.x and earlier versions, racoon could accept mismatched phase 1identifiers where using IP Address as the identifier. This is most commonly aproblem where one of the endpoints is behind NAT and phase 1 is using My IPAddress and Peer IP Address for identifiers. On the side with the private IPWAN, My IP Address will be its private WAN IP address. On the opposite end,Peer IP Address will be the public IP address of the opposite side. Hence,these two values do not match, and should have resulted in a connection failure.racoon would fall back to checking the source IP address of the initiating hostas an identifier, where it found the match. To resolve this issue, change thephase 1 identifiers so they actually match.

Phase 2 behavior change with incorrect network addresses¶

In 2.1.x and earlier versions a phase 2 configuration with an incorrect networkaddress would still be presented by racoon with the corrected network address.e.g. if 192.168.1.1/24 is set in a phase 2, which should be192.168.1.0/24, racoon used it as 192.168.1.0/24. In 2.2.x and newerversions, strongswan sends it exactly as configured. This may result in a phase2 mismatch where configured with an incorrect network address.

Disk Driver Changes¶

The disk drivers in FreeBSD changed between the underlying OS versions and nowthe CAM-based ATA drivers and AHCI are used by default. As such, ATA disks arelabeled as /dev/adaX rather than /dev/adX. The ada driver for ATAdisks and GEOM keeps legacy aliases in place so that old disk references willstill work post-upgrade. This does not always extend to virtualized diskdrivers, however (see the Xen note below.). The upgrade process on pfSense 2.3and 2.4 also attempts to automatically correct for this change.

A manual workaround is also possible. Running /usr/local/sbin/ufslabels.shbefore the upgrade will convert /etc/fstab to UFS labels rather thandisk device names bypassing any device name issues that could arise due to theswitch.

There is a chance that the new driver stack will have issues with certaincontroller/disk combinations that were not present in prior releases. There maybe BIOS changes or other workarounds to help. See Boot Troubleshooting.

The methods used to disable DMA and write caching have both changed on FreeBSD10.x. For most, disabling these manually is no longer necessary.

If disabling DMA is necessary, the following may be used in/boot/loader.conf.local:

Change X to be the ATA controller ID, typically 0 or 1.

If write caching must be disabled, the following may be used in/boot/loader.conf.local:

Xen Users¶

The FreeBSD base used by pfSense 2.2 and later includes PVHVM drivers for Xen inthe kernel. This can cause Xen to automatically change the disk and networkdevice names during an upgrade to pfSense 2.2 or later, which the Hypervisorshould not do but does anyway.

The disk change can be worked around by running /usr/local/sbin/ufslabels.shbefore the upgrade to convert /etc/fstab to UFS labels rather than diskdevice names.

The NIC device change issue has no workaround. Manual reassignment is required.

vmxnet3 (VMware/ESX) users¶

Users who manually installed VMware Tools to use vmxnet3 networkadapters may encounter an issue with interface name changes when upgrading topfSense 2.2 or later, similar to those with Xen mentioned above. In pfSense2.1.x the vmxnet3 interfaces were named starting with vmx3f and onpfSense 2.2.x they are vmxToshiba 2050 driver for mac. using the built-in support. Manually reassigningthe interfaces or correcting them in config.xml followed by a restore isrequired.

Old/Broken GEOM Mirrors¶

If a manual gmirror configuration was performed post-install and not using thepfSense installer gmirror option before install, there is a chance that themirror will not function on pfSense 2.2 or later because the manual post-installmethod did not create a proper mirror setup. If an upgraded mirror does not bootor function on pfSense 2.2 or later, use the following entry to work around theintegrity check that would otherwise fail.

Add the following line to /boot/loader.conf.local:

If the disks are configured in this way, we strongly recommend backing upthe configuration and reinstalling, using one of the mirrored disk options inthe pfSense installer.

CARP Changes¶

Due to the new CARP subsystem, the old method of having a virtual interface forCARP VIPs is no longer available. CARP VIPs work more like IP Alias style VIPs,existing directly on the main interface. For most, the changes made toaccommodate this new system will be transparent, but there are some potentialissues, such as:

With no separate interface available, monitoring a CARP VIP status via SNMP isno longer possible.

FTP Proxy¶

The FTP proxy is not included in pfSense 2.2-RELEASE or later, due to changes inthe kernel and state table handling that made it it more difficult toimplement. Use of FTP is strongly discouraged as credentials are transmittedinsecurely in plain text. #4210

See FTP without a Proxy for additionalinformation and workarounds.

Another option is the recently added FTP Client Proxy package whichleverages in FreeBSD to allow clients on local interfaces to reachremote FTP servers with active FTP.

LAGG LACP Behavior Change¶

LAGG using LACP in FreeBSD 10.0 and newer defaults to “strict mode”, which meansthe lagg does not come up unless the attached switch is speaking LACP. This willcause a LAGG to not function after upgrade if the switch is not using activemode LACP.

To retain the lagg behavior in pfSense 2.1.5 and earlier versions, add a newsystem tunable under System > Advanced, System Tunables tab for thefollowing:

With value set to 0.

This can be added before upgrading to 2.2 to ensure the same behavior on firstboot after the upgrade. It will result in a harmless cosmetic error in the logson 2.1.5 since the value does not exist in that version.

If a firewall has more than one LAGG interface configured, enter a tunable foreach instance since that is a per-interface option. For lagg1, add thefollowing:

Also with the value set to 0.

Intel 10Gbit/s ixgbe/ix users with Unsupported SFP modules¶

The sysctl to allow unsupported SFP modules changed in FreeBSD betweenthe versions used for pfSense 2.1.x and 2.2.

The old tunable was:

This must be changed to:

Edit the setting in /boot/loader.conf.local before applying the update andthe behavior will be retained.

Layer 7¶

Layer 7 is deprecated and has been removed. For layer 7 applicationidentification and filtering we recommend using the Snort IDS/IPS package with OpenAppID detectors and rules.

Microsoft Load Balancing / Open Mesh Traffic¶

Windows Network Load Balancing and Open Mesh access points can use multicast MACaddress destinations which rely on broken behavior that was incorrectly allowedby default in earlier versions of FreeBSD and pfSense. The fact it worked beforewas technically a bug, acting in violation of RFC 1812.

A router MUST not believe any ARP reply that claims that the Link Layeraddress of another host or router is a broadcast or multicast address.

The default behavior on pfSense 2.2 is correct, but it may be changed.

If this behavior be required, manually add a tunable as follows:

Navigate to System > Advanced, System Tunables tab
Click
Enter the following values:
- Tunable: net.link.ether.inet.allow_multicast
- Description: Optional. It would be wise to enter the URL to this note ora similar note.
- Value: 1
Click Save