Mmm, so prevent source tracking for specific IPs or subnets? I did wonder if sticky connections could be per gateway group. That seems like it should be possible. You could then use rules to route specific clients or subnets to a non-sticky group.

@SteveITS Yep. The address in that /29 was given by DHCP.

@bigsy Nice! Thank you for the update.

@dennypage PoE is definitely on our feature list.

@stephenw10 This was definitely not a button push on ours either. Both units are in locked cabinets in a colo. Any access to the facility is logged. @SteveITS As for it going to standby or hibernating, the person who went on site the LEDs were normal. Nothing indicating a state change or issue.

@pst said in Router advertisement not sending default gateway: That rule shouldn't be needed, it is part of the automatic rule set added by pfSense. I get those by means of pfSense magic: (check in /tmp/rules.debug) here are some snips from that file (I can see ICMP added automatically, but not UDP): Allow only bare essential icmpv6 packets (NS, NA, and RA, echoreq, echorep) pass out quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type {129,133,134,135,136} ridentifier 1000000108 keep state pass out quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type {129,133,134,135,136} ridentifier 1000000109 keep state pass in quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type {128,133,134,135,136} ridentifier 1000000110 keep state pass in quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type {128,133,134,135,136} ridentifier 1000000111 keep state pass in quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type {128,133,134,135,136} ridentifier 1000000112 keep state pass in quick inet6 proto ipv6-icmp from :: to ff02::/16 icmp6-type {128,133,134,135,136} ridentifier 1000000113 keep state We use the mighty pf, we cannot be fooled. block log quick inet proto { tcp, udp } from any port = 0 to any ridentifier 1000000114 label "Block traffic from port 0" block log quick inet proto { tcp, udp } from any to any port = 0 ridentifier 1000000115 label "Block traffic to port 0" block log quick inet6 proto { tcp, udp } from any port = 0 to any ridentifier 1000000116 label "Block traffic from port 0" block log quick inet6 proto { tcp, udp } from any to any port = 0 ridentifier 1000000117 label "Block traffic to port 0" Furthermore I can see that I have autoadded config rules for DHCP4 and DHCP6 here: allow access to DHCP server on LAN pass in quick on $LAN proto udp from any port = 68 to 255.255.255.255 port = 67 ridentifier 1000002541 label "allow access to DHCP server" pass in quick on $LAN proto udp from any port = 68 to 192.168.2.3 port = 67 ridentifier 1000002542 label "allow access to DHCP server" pass out quick on $LAN proto udp from 192.168.2.3 port = 67 to any port = 68 ridentifier 1000002543 label "allow access to DHCP server" allow access to DHCPv6 server on LAN pass quick on $LAN inet6 proto udp from fe80::/10 to fe80::/10 port = 546 ridentifier 1000002551 label "allow access to DHCPv6 server" pass quick on $LAN inet6 proto udp from fe80::/10 to ff02::/16 port = 546 ridentifier 1000002552 label "allow access to DHCPv6 server" pass quick on $LAN inet6 proto udp from fe80::/10 to ff02::/16 port = 547 ridentifier 1000002553 label "allow access to DHCPv6 server" pass quick on $LAN inet6 proto udp from ff02::/16 to fe80::/10 port = 547 ridentifier 1000002554 label "allow access to DHCPv6 server" pass in quick on $LAN inet6 proto udp from fe80::/10 to 2001:2042:334b:c300:a236:9fff:fe7a:603f port = 546 ridentifier 1000002555 label "allow access to DHCPv6 server" pass out quick on $LAN inet6 proto udp from 2001:2042:334b:c300:a236:9fff:fe7a:603f port = 547 to fe80::/10 ridentifier 1000002556 label "allow access to DHCPv6 server" But as IPv6 seems to use port 5355 for something called link-local resolution according to google (https://www.google.com/search?q=ipv6+5355) those presets does not help. So adding the rule adds the missing config (probably could be more restrictive to only match 5355): pass in quick on $LAN inet6 from fe80::/10 to ff02::/16 ridentifier 1752488409 keep state label "USER_RULE" label "id:1752488409"

@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!

Opened a Redmine about this since this either A. needs to be explained more clearly, or B. needs to be changed so the docs say "will" instead of "may". https://redmine.pfsense.org/issues/16340

@stephenw10 No Sir, i have not tested it yet. Just finished building my M570, will test it on the M370 in the near future.

@jhg said in NUT fails to start after 2.7.2 -> 2.8.0 upgrade: Interesting. I would have thought the initial reboot, which occurred as part of the upgrade, would have done the trick, but it took a second reboot, just now, to get things working. Glad you have it sorted. There was no difference in the output of usbconfig show_ifdrv at any point -- before or after unplugging/replugging the USB cable, nor after rebooting. ... Question: What would tell me whether or not a driver was loaded? If there were an attached driver, it should have shown up with the show_ifdrv command. If you use the command and look at the other usb devices, I think they will show attached drivers. I don't expect to see a driver attached to the ups, because there is a quirk that tells the OS to ignore that device (and not attach a driver). Look for idVendor and idProduct in the above output. The Vendor ID for your device is 0764, which corresponds to Cyber Power Systems, and the Product ID for your device is 0601, which is registered as "PR1500LCDRT2U UPS" (don't sweat an exact match for the name). You can see the quirk with the following command: [25.07-RC][root@fw]/root: usbconfig dump_device_quirks | grep 0764 VID=0x0764 PID=0x0005 REVLO=0x0000 REVHI=0xffff QUIRK=UQ_HID_IGNORE VID=0x0764 PID=0x0501 REVLO=0x0000 REVHI=0xffff QUIRK=UQ_HID_IGNORE VID=0x0764 PID=0x0601 REVLO=0x0000 REVHI=0xffff QUIRK=UQ_HID_IGNORE [25.07-RC][root@fw]/root: Your device is third on the list. The HID_IGNORE quirk says to ignore the device and not attach a driver. @jhg said in NUT fails to start after 2.7.2 -> 2.8.0 upgrade: You might consider adding this resolution to the release notes for 2.8. LOL... sorry, I don't have input to the release notes (I don't work here). While I wrote and maintain various packages, including NUT, I'm still just a volunteer. Most packages are actually written by volunteers.

@GeorgeCZ58 Looks like a feature to me - once you reach so many interfaces/rows of them in the gui its better to switch over to a drop down..

@maliaga If you can find a way to report bugs in a way that Netgate respond to, let us know!

@sigulete You solved my problem, thank you !