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.
Apparently, making this 4x SFP+ card work is not as straight forwards as I thought…
Sigh, so much for “plug and play pray”…
As per the source/s instructions, I created a /etc/networkd-dispatcher/configuring.d/90-disable-on-chip-LLDP.sh:
#!/bin/sh
if expr "$IFACE" : <interface prefix> >/dev/null; then /sbin/ethtool --set-priv-flags "$IFACE" disable-fw-lldp on fi
WARNING: Make sure your <interface prefix> is able to only address the X710 interfaces, or you will likely get errors or, worse, brick your NIC. As an example, my X710 interfaces are all named enp1s0fN so I use the <interface prefix> of “enp1s0f”
To check, simply give the command ethtool --show-priv-flags <interface prefix>.
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.
I found myself wrestling with XGA (1024×768) output on a system with only VGA output, although I was aware the display controller could get up to FHD easily (xrandr output shows the maximum “width” and “height” values surpassing that of FHD – see screenshot/s below).
I managed to wrangle the output to FHD by doing the following:
xrandr --listmonitorsxrandrcvt <width> <height> <refresh rate>cvt 1920 1080 60xrandr --newmode <text after "Modeline" from cvt output>xrandr --addmode <display> <mode name>xrandr --addmode VGA-1 "1920x1080_60.00"xrandr --output <display> --mode <mode name>
Making this stick was a completely different story in frustration…
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…
