@dennypage PoE is definitely on our feature list.

@meii sending this in the original thread since there's a 1000 character "chat" limit. (tl;dr: To others reading, this is maybe a workaround to fixing the issue I reported. Instead of messing with custom FreeRADIUS or pfSense settings, I just made sure there is only ONE copy of the user certificate installed in the Computer Account and NOT any local user accounts (Standard Users, Local Admin users, etc.). And Same with the root CA certificate: only installed in the Computer Account certificate store, and this is accessed by going to "mmc" and then adding the Certificates snap-in then selecting Computer Account) First thing I changed was made sure I installed certificates in only one trust store. So my current setup I have one "standard user" account that is my main account on Windows. And I have a "Admin" account that I only use for UAC prompts, etc. I think each one has its own certificate trust store. I.e. if you are logged in as regular/standard user, just do "certmgr.msc" and I made sure to delete the cert from Personal->Certificates and the pfSense root CA cert from Trusted Root Certification Authorities->Certificates. For the admin account, either log in locally or just do "certmgr.msc" again and right-click and "Run as administrator" and it makes another window. Even there, I made sure both the user certificate and the root CA certs were deleted. So now we want to access the actual computer's certificate trust store. I went to "mmc" and "Run as administrator" then File->Add/remove snap-in. Then add "Certificates" to the menu on the right and hit ok. Then make sure to select "Computer account" and Finish. I think (if I remember correctly) this is where I installed the user certificate for WiFi in Personal --> Certificates and the root CA in Trusted Root Certification Authorities --> Certificates. I think doing all this makes sure there's no duplicate certificates. When there's two, Windows will pause and pop-up the drop-down thingy asking you to choose a cert before connecting, whereas with just one user cert (installed in the Computer account) it only has one choice. Second thing I did was in the WiFi network settings (using WPA2-Enterprise still, EAP-TLS)... one way I got there was Control Panel --> Network and Sharing Center --> click on the network if you're already connected. I think if you're not connected it only lets you change settings when you start from scratch...not sure. Anyway we want the old Windows 7 or so window, not the newer one. So "Wireless Properties" where it has the two tabs at the top: Connection and Security. On Security tab, where it says "Choose a network authentication method" I made sure it was Microsoft: Smart Card or other certificate. I have "Remember my credentials for this connection each time I'm logged in" checked. Click on Settings. When connecting, "Use a certificate on this computer" and "Use simple certificate selection (Recommended)" checked. Didn't bother with Advanced button. Below it I have "Verity the server's identity by validating the certificate" checked and also the one below it "Connect to these servers..." and I put in the FQDN for the server cert in pfSense I'm using for FreeRADIUS (in my case radius.home.internal). In the list of Trusted Root Certificate Authorities below, I made sure only my pfSense root CA was selected and nothing else. At the bottom I have "Don't prompt user to authorize new servers or trusted certification authorities" checked. Lot of these prevent WPA2-Enterprise Wi-Fi attacks in the wild. So I think the relevant part for what you're running into was in "Advanced Settings" from the main "Security" tab. "Specify authentication mode" is checked and I put "User or computer authentication". Down below, I do not have that part checked where it says "Enable single sign on for this network". On the 802.11 settings tab and "Fast roaming," I have "Enable Pairwise Master Key (PWK) caching" checked. So I don't know if any of the above settings in Step 2 helped except maybe the "User or computer authentication," but I definitely think Step 1 above helped -- making sure I only installed the user Wi-Fi cert and the pfSense Root CA cert in the computer certificate store via mmc Certificates snap-in. And made sure to first delete those certs from the Standard and Admin user accounts. (Oh! Note: I made sure to delete all those WiFi certs first to start with a clean slate because once you install them to the computer certificate store, they also magically appear in the "certmgr.msc" for both Standard and Admin user accounts, so it gets confusing. Either way, Windows no longer prompts me to select a cert when WiFi connects, and I don't see the stupid "host/" prepend string or whatever in the pfSense logs. I haven't really tested if it logs into WiFi when you first boot up the laptop before logging in -- I think it did it! So in the end I didn't even need to learn all the weird FreeRADIUS syntax since it looked like a giant pain getting custom config settings to work with the pfSense FreeRADIUS GUI. Yuck. I hope all this helps! Uh if you need screenshots lemme know since it might be clearer than a bunch of words. Hope any of this helps!

I have already solved the problem by using the Python library. You can delete my post. Thank you for your help)

@bmeeks Thank you. Your points are excellent. I believe I will back off from adding more supplemental apps. Adguard Home works with OPNsense as a 3rd party add-on without complaint so I will leave that alone for now. But I will also keep an eye out for issues with that configuration. Worst case is a reinstall of pfSense and a restore of the backup configuration. My Windows Adguard Home servers are available if needed.

Mmm indeed, I would expect that to be they or it depending on whether 'peer' refers to the user or the device. More likely it's a device in that reference.

From my perspective the issue is the scope for a users contingency planning on pfsense router failure (initially of unknown cause). Netgate's current device locked licensing and lack of an off line installer doubles the cost of ownership and significantly reduces pfsense functionality. It is the reason I have not purchased plus licences. My contingency planning is focussed on rapid restoration of service with minimum dependences, limited technical complexity, and a short time. Doing so involves the ability to swap out a failed physical system and replace it with another. First line using a box with pfsense pre-installed. Second line with my locally stored copy of pfsense installation media. The installation media has to work within my system without a functional router, for which an off line installer is most reliable. An online installer which uses that sites pfsense configuration may work but at best introduces higher risk in a contingency plan. To achieve this economically I run pfsense on third party hardware which also does other roles. I have multiple physical devices performing tasks of varying importance (set top box for each TV, router a several sites). As well as each device running running multiple virtual machines for other functions (PABX, Unifi controller, surveillance cameras etc). The overall effect is all hardware is utilised but relatively spare hardware can be rapidly commandeered if required. For this to work with pfsense plus I need to be able to install pfsense on multiple virtual machines and transfer a licence from a failed to a replacement device if required. Ideally by entering registration details in the replacement hardware (which would warns doing so inactivates the prior registration) or doing the same via a Netgate portal. Either of which implies such a transferable pfsense plus licensed device regularly checks licence validity with a Netgate server (making a transferable licence incompatible with a pfsense installation without online access to the Netgate licence server). I'm not sure how large the market is for off line Netgate routers. Such an installation would require a non trivial protocol to update pfsense software, which even on Netgate hardware would not be simple. With an off line installer including all patches was available, this could be taken into the secure environment and used to re-install / update pfsense. My understanding there has never been an off line installer with all patches (or packages) as such I suspect software update would require secure erasing the pfsense disk, physically moving the hardware out side of the secured environment, programming it with current pfsense software, returning it to the secure environment, import the sites pfsense configuration file. Not something done frequently and probably not a large market but I could be wrong. Similarly my use case is probably also a small market, however I suspect the market for economic contingency planning is much broader. As such many users are likely to benefit from the licence transferability and off line installation options which maybe possible it a monitored plus licence option was offered.

I don't know how Truenas would set that up but in Proxmox you could add an address to the bridge and use that to access Proxmox. It could be dhcp or static. I would probably leave it as dhcp and set a static dhcp lease in pfSense so it always get the same IP address. Just to be clear though that is config in Proxmox it is not a bridge in pfSense.

@Wylbur Thank you!

I know you said this wasn't your problem, but I had mine all set up with static reservations in DHCP and had modified them to use DHCP assignments. I was able to periodically log in and check their connection strength and whatnot without issue. At some point I needed to do a firmware update and noticed they would no longer respond to ping or bring up the webgui at the statically assigned IP. This was after switching to KEA DHCP. I had to connect to each one individually with a laptop, reset it, and flash the firmware. I then decided to set them back to DHCP and they disappeared into the void again. I haven't been able to connect to them since but assume they will be back at some point once something gets ironed out in KEA.

@tgl You're absolutely right. Hardcoding the password (and especially pushing it to a repo, even a private one) was a poor decision. That part was initially just for testing, and I forgot to replace it before pushing.

@provels said in Just a simple, informative network utility from Y2K: a 486DX4-100 Ooo fancy!