I wasted quite a bit of time attempting to implement 2FA as part of user authentication on pfSense, firstly finding out that 2FA support was not intrinsic…
Next up, grappling with the FreeRADIUS extension for pfSense 2.7.x and attempting to follow everything from Reddit posts, some time-wasting video posts, to the abbreviated instructions from Google Search and some posts from different Google Search results.
I used to swear by the very useful, but extremely complicated (and easy to break your OS if you get it wrong, but free) Comodo Internet Security suite, which included Comodo Firewall…
Unfortunately, having been forced to upgrade to Windows 11 a few months back, replete with feature retardation, my trusty ol’ CIS 12.x no longer worked (properly), and I had to switch to the “plain ‘ol Windows Firewall” – which works great except for the rules and rules management. Working with the Advanced Firewall console UI is a nightmare, and not being able to quickly allow something that was blocked renders the plain ‘ol Windows Firewall unusable.
I may have gotten the following versions and timelines wrong: When I initially tested Windows 7, I knew ZoneAlarm 7.x was not compatible (then), I actually looked at, and bought, BiniSoft’s WFC before finally settling on CIS… I returned to BiniSoft in 2024 only to find out that it had been bought out in 2018 by Malwarebytes…
Nevertheless, background and fuzzy memory aside, I was chugging along on Windows 11 (sans LACP’d 10Gbps NICs) with “just” Windows Firewall and WFC, I must have changed something, because, all of a sudden:
wf.msc with Administrator privileges) failed with a repeated “access denied” message
Checking the ‘net did not help much:
NT Service\mpssvc user and even myself to security ACL of the (default) C:\Windows\System32\LogFiles\Firewall directory and the created .log files with “Full Control” permissions did nothingI bashed my head against this issue for the better part of some 3 hours before some memory synapses lit up…
Note to self – if attempting to change the IP address of the OpenVPN server/service, you need to disable the interface then re-enable it, otherwise the DNS Forwarder selection of active interfaces will still take the old IP address (and therefore fail to start).
You will be able to see the pfSense’s debug logs showing a failed attempt to listen on the old IP.
With a /etc/netplan/00-global.yaml having the following contents:
network: version: 2 renderer: networkd
And all other .yaml files in the /etc/netplan directory not having an explicit renderer, the system should default to networkd… Just netplan apply and done! Simple, right?
Yeah, right.
Seems like netplan apply still thinks to use NetworkManager even when no single .yaml file declares its use; and since I disabled and masked the service, netplan apply was complaining NetworkManager was masked.
The secret sauce?
I was starting to get “<whatever>.service: Got notification message from PID <X>, but reception only permitted for main PID <Y>” from my journalctl – turns out the “quick fix” was simply to add NotifyAccess=all to the .service file definition.
Well, as the title implies, I was running update-initramfs -u on my Ubuntu installation after having (i) duplicated the SSD from another existing system, and (ii) having rebuilt a kernel driver (which then required the aforementioned update-initramfs command).
Unfortunately, the command threw back a “W: Couldn't identify type of root file system for fsck hook” error…
To prevent typos and OS line break-type kerfuffles, I typically copy files instead of copy-pasting any files’ contents across VNC sessions.
Somehow, I came across wanting to just copy-paste a file via a VNC session, which used to work ye long ago… But it just was not happening…
Diving into the ‘net for answers, I came across autocutsel… Although some places stated to use xstartup files, as I was using x11vnc, this was not possible, so I simply ended up creating a services file (with a dependency on the x11vnc service):
Given the Linux bridge and QEMU KVM pass-through performance hit, I tried to install OPNsense (based off FreeBSD) and attempted to dual-boot.
Why OPNsense? That was the main reason I originally bought this C3758R unit in the first place – attempting to see if higher performance-to-power efficiency could be achieved with Intel QAT – pfSense’s QAT libraries are only available in their subscription-based pfSense+ product.
In short: a f*cking huge mess…
/boot/efi, the full path in Ubuntu was /boot/efi/EFI/freebsd/loader.efi/etc/grub.d/40_custom:menuentry "OPNsense" {
insmod ufs2
insmod zfs
set root=(hd0,gpt4)
chainload (hd0,gpt1)/EFI/freebsd/loader.efi
}
ls -l” in grub, where the root is the FreeBSD UFS/ZFS partition, and the chainloader is pointing to the ESPupdate-grub/EFI/freebsd/loader.efi file) – otherwise secure boot would prevent the FreeBSD bootloader from working
That fixed, things went from bad to worse…
Just a quick update on networking experiences with this fanless (but hot) unit…
For some odd reason, throughput on stock Ubuntu 24.04 LTS via a 10GbE SFP+ module was showing asymmetrical speeds on iperf3 – ~10Gbps in, but only ~6Gbps out. Checking the firewall, ensuring jumbo packets (9000 byte MTU), ensuring ufw was disabled, disabling all forms of NIC offloading (although this may actually be inverse to the intended) did not change anything. Furthermore, htop showed one core constantly maxing out when sending (but hovering 60% to 75% on receiving).
For the longest time, I was painfully aware that I was not utilising my 10GbE network switches and NICs to its fullest.
Having to finally sit down, build, test and optimise a software firewall using 10GbE interfaces for some organisation I volunteer at and therefore having to test it in my home lab, I finally was “forced” to sit down and “optimise” my local home lab.
An iperf3 test was not showing good numbers – bouncing around the ~8Gbps mark on a 10Gbps network.
Without fluffing around with kernel and IP stack tweaks, I was aware the easiest way to eke out better performance was to increase the MTU…
