pfSense Digest

There was a nasty bug in .79 that partially reverted the config file
version. This left a config file that had newer syntax and an older
version number. Upgrading past .79 w/out taking some corrective
measure will break your system. Again, if you installed or upgraded
to .79 and plan on using anything newer, please read.

Two issues in particular affect those that are on .79 and plan to
upgrade. During boot, we check to see if the config file version is
older than what we claim is current. If it is, we upgrade it.

One of the upgrade steps encrypts the (already encrypted) password in
the xml file leaving you with a system you couldn’t access (there are
a couple workarounds that I’ll mention shortly). The other somewhat
damaging item I’ve had mixed reports on are irreversible issues with
the DHCP config; if you don’t use the dhcp server you will be fine.
Disabling the server and re-enabling it is not enough to fix it if you
are using DHCP.

This issue _only_ affects people that upgraded/installed .79 and then
upgraded to
anything above it (.79.2 is currently the only thing above it). There
was about a three hour window where .79 was the most recent version,
so I expect very few people actually got affected.

Workarounds:
This is for those that upgraded to .79. We now version every change
that happens on your pfSense box. They are available via the
Diagnostics menu, choose Backup/Restore then click Remote. You’ll see
a list of all the times your configuration changed and at a minimum
where in the firewall the change was made (still working on exact
change details).
You should the “Current” entry showing as ” Upgraded config version
level from 1.9 to 1.1″ or similar. Clicking on the “+” (plus) symbol
on the line below will restore the previous configuration file. Then
upgrade to .79.2 w/out rebooting. .79.2 will correctly upgrade your
configuration file to version 2.0 w/out destroying anything.

For those that installed .79 and wish to upgrade. If you aren’t using
the DHCP server, the only item that should affect you is the password.
Upgrade to .79.2 and use menu option number 3 from the shell (Reset
webGUI password).

If you are using the DHCP server, be thankful this is a new install.
Hopefully you’ve installed before and have an old config laying
around. If not, you’ll be reconfiguring from scratch, there’s not
much we can do. You can try disabling/reenabling the DHCP server
after upgrading to .79.2. I’ve had one report of “that works” and one
of “that didn’t work” – if it doesn’t work, reinstall.

–Bill

PS. For those wondering… 1.10 == 1.1 I apparently failed floating point 101!

Scott and I commited code last night to get non-load balanced multiple WAN connections working. What this means is that you can now use the rules system to direct which link an arbitrary connection will go out.

Example

• On OPT2 I have a static IP’d 384/384 DSL connection
• On WAN I have a dynamic IP 6000/768 cable connection
• I’d prefer all my traffic to go through the cable connection except for my servers and a handful of things that require me to have a static IP.

Steps to make this work

• On the interface screen for OPT2 put in a gateway address.
• In the advanced outbound NAT screen set up NAT entries for your OPT2 and WAN interfaces with the traffic that you want going through it. In my case I create NAT entries for my DMZ and my LAN on the OPT2 interface and a NAT entry for the LAN on my WAN interface. This sets up the NAT side so that when traffic leaves through those interfaces it’ll use the right source address.
• Now for the fun part, rules.
• In the DMZ rules screen, I set up each pass rule to have the gateway on my OPT2 interface. Edit the rule and towards the bottom you’ll see a gateway option.
• On the LAN rules screen, I create a couple rules to direct specific traffic out OPT2.
• If the above rules aren’t created, the system will use your default gateway (the WAN gateway is considered default).

Give it a whirl!

While we’re still setup for HTTP Basic authentication, we’re no longer doing it at the web server level, it’s been moved to the PHP layer. This change will eventually allow us to move to a more robust authentication scheme that will allow for role based access and even offloading authentication to centralized servers (LDAP, RADIUS, SecurID, etc). Let us know if there are any problems (and please please let us know if somehow we missed a PHP file!) This does have the potential to impact security of the firewall so it’s important.