Original Configuration
A dual interface pfSense install in Azure layout.
Internet<= frontend subnet WAN Interface=><=Pfsense=><=LAN Interface backend subnet=>Protected LAN
Package Update Causes Failure
I made the mistake of doing a package upgrade on a pfSense+ 23.05.1 instance without doing a pfSense version upgrade first. This broke PHP. I was seeing errors similar to:
ld-elf.so.1: Shared object "libcrypto.so.30" not found, required by "php"
The orginal plan
I was going to try to install a new version of pfSense+ from the Azure Marketplace and restore a saved configuration but I got an error of "Unable to retrieve prices and legal terms"
After ignoring the above error, going ahead and clicking create, the deployment timed out and failed.
I was also going to transfer the WAN interface (with it's fixed IP) from the old pfSense instance and move it to the new pfsense deployment from the market place so I deallocated the current Firewall and detached the WAN interface. This will be significant later. In hindsite I should have just detached the Public IP instead of the WAN NIC.
After finding I couldn't deploy the pfSense+ image from the Marketplace I went to plan B
Plan B - Restore a disk snapshot and upgrade, upgrade, upgrade
What is plan B?
Plan B ended up being upgrading from 23.05.1 to 23.09.1 to 24.11 to 25.07
Did I remove packages?
No, I had the following packages installed (although some may have been installed by the upgrades). I didn't uninstall any packages before doing the chain of upgrades
- acme
- aws-wizard
- haproxy
- ipsec-profile-wizard
- Netgate_Firmware_Upgrade
- Nexus
- ntopng
- openvpn-client-export security
- pfBlockerNG
How do you return to a clean install after a botched package update?
I had a VM snapshot of the pfSense OS Disk from before my botched package upgrade, so I converted it to a disk and swapped it onto the VM using the Settings => Disks => Swap OS Disk function in the Azure Portal
I then booted and started upgrades 23.05.1 to 23.09.1 first
Once 23.09.1 was installed this gave me the option to upgrade 24.11 which I did.
Problems caused by Detaching and re-attaching interfaces of the pfSense+ Azure VM
Arrggh the LAN / WAN interfaces became swapped inside pfSense+
I think it was due to the interface swap, after rebooting after the 24.11 upgrade the WAN interface would not come up (I waited 10+ minutes). I traced this to having detached and re-attached the WAN interface and it having re-ordered the interfaces.
The pfSense LAN interface was configured in pfSense with a static IP and because it was now the WAN interface the WAN interface just hung never requesting an IP address and coming up
Enable DHCP as the IPv4 Configuration Type on both interfaces to allow upgrade reboots to complete
To solve the non-boot problem I rolled back to the original working disk snapshot, booted it and (after resolving missing default gateway) in the webConfigurator changed the WAN and LAN interfaces to both be DHCP assigned. Then after each upgrade reboot the interfaces would successfully recieve an IP and come up.
Swapped interfaces needed re-assigning from the serial console
There was still the problem of the WAN interface being the LAN interface and I had to use the Azure Serial Console to re-assign the interfaces (hn0 originally was WAN, hn1 was LAN) so the new layout was hn1 = WAN, hn0 = LAN
This now allowed me to connect via the WAN port to the webConfigurator (See also working around the missing default route heading below)
The NAT outbound rules were also messed up they now showed LAN as the interface for the Automatic Rules. I had to change to Manual Outbound NAT rule generation and configure the correct rules, on the WAN interface.
Set to Manual to remove LAN Automatic Rules
Edit the Manual Rules to be the same as what is normally created
Missing Default Route
I also had to manually add a static route from the WAN port to the next hop gateway as it didn't work by using Automatic or the auto created WAN_DHCP gateway. I think this is because after the interface swap there is still an issue with pfSense thinking the default gateway is the LAN interface side. (visualise a person sitting on a horse backwards)
Because the default route to the internet was missing from the operating system and I couldn't login to the webConfigurator without it I had to add a route manually from the Serial Console (Available in the Azure portal under VM => Help => Serial Console). Once in the serial console get a shell and:
# to view the current routes
netstat -r
# to add a default route manually example
# if your WAN interface IP is something like 10.73.0.4 then your default gateway on that subnet will be 10.73.0.1
route add default 10.73.0.1
Enable Crypto Hardware Offloading
After I got to version 25.07 I noticed the front page of the Web Configurator said I had support to offload Crypto to the hardware, but was inactive, so I enabled both and rebooted.
AES-NI CPU Crypto: Yes (inactive)
IPsec-MB Crypto: Yes (inactive)
If hardware supports it go into System => Advanced => Miscellaneous find the Cryptographic & Thermal Hardware section and enable the support for Crypto offloading (should improve the performance of you IPSec tunnels)
Maxmind now asks for an Account ID and API key
I had to go over to MaxMind and find my Account ID and add it under Firewall => pfBlockerNG => IP and save the settings to stop the following messages. I'm using the free list...
Remove pfBlockerNG dead lists
As this firewall has been in place for a number of years the original list of block list provider URLs has changed, some lists have been discontinued, deprecated or merged.
So I also went into Firewall => pfBlockerNG => Log Browser and chose Original IP Files and looked at the content of each file many have been deprecated and so serve an empty file. Some served a webpage that a blocked notice.
The no longer working feeds included the following.
- Talos https://talosintelligence.com this has a HTML block page when attempting to connect
- Abuse_SSLBL
- Abuse_Feodo
- Spamhaus EDrop https://www.spamhaus.org/drop/edrop.txt
So each non-useable file I identified, I removed the corresponding URL/feed
View the downloaded block list files
Example of an empty block list file. Header with no IP content.
Delete the deprecated block list feed by going to Firewall => pfBlockerNG => IP => IPv4 and find Abuse_SSLBL and remove it.
Remember to save your changes
0 Comments