Hard to say for sure, but there are a number of changes between FreeBSD 12.x and 14.x that likely improved support for that hardware.

Thank you Steve, your explanation helped me to solve my issue. Now, everything is working as expected. Have a great day, Mauro

@ewok2 said in Nut Client Server error with ESXI: Is there some port forwarding to do ? See post #2 in the NUT support thread for information on allowing network access.

@jimp So had a look into this a bit and I believe this is probably NPS expecting passwords to be ucs2 rather than the utf8 that gets sent. Think its this project https://github.com/pear/Crypt_CHAP that the authentication test uses behind the scenes that has a bug in str2unicode. similar issue here https://github.com/dapphp/radius/issues/5 Changed the str2unicode function on the pfsense 2.7 dev version I was using for testing and now a user with the password: Password!"£$%^&* works as expected when it didn't before. function str2unicode($str) { $uni = ''; $str = (string) $str; for ($i = 0; $i < mb_strlen($str); $i++) { $a = mb_ord(mb_substr($str,$i,1)) << 8; if ( $a > 65536){ echo "NPS does not support non BMP codepoints\n"; return; } $uni .= sprintf("%X", $a); } return pack('H*', $uni); } I'm no unicode expert or PHP but as UCS2 is only 16 bit it can't support any code points over 65536 so added a check to fail if it finds this. So no emojis or no 4 byte Chinese codepoints. This might still work fine in strongswan as read they added a fix for this so might just have been the authentication tab that was not working correctly. Will register for the bugtracker in the morning and update that bug.

@motivio the System Patches package: https://docs.netgate.com/pfsense/en/latest/development/system-patches.html

@johnpoz ok understood thank you so much for the help!!

There was a test kernel that contained the fix for 22.05 but at this point it's better to test 23.01 if you can. If you're running ZFS you can always roll back the BE snap to 22.05 if required.

@steveits It works now.

@pfpv Hi! Did you get this solved? I also try the same :?

@nollipfsense actually this also stopped working and I’m back at the issue.

@jarhead Thanks

@steveits said in SURICATA STREAM Packet with invalid timestamp: @draithan In our standard Suricata setup we: • check "Disable hardware checksum offload" in (System->Advanced->Networking) • Suricata: disable ALL stream-events.rules or it will block lots of traffic on false positives Ok thanks for the confirmation. Appreciate it. Not seeing anyone posting to not disable.. Appreciate everyones help!

Open a feature request: https://redmine.pfsense.org/

@netgate1100guy said in Problem with configuring the Netgate 1100: If a hacker somehow blocks downloads from the internet (happens often) and there is a hacker (numerous unknown IP addresses) What exactly are you seeing that makes you think this is happening? It's far more likely to be a compromise on your local client if it really is malicious activity. However simply being unable to download is probably a config issue. Either way Squid won't help you at all here. And on an 1100 could well be causing more problems. Steve

@keyser thank you - that's a great idea.

Mmm, that can be very ISP specific. Some will remain locked to a MAC until it's reset at their end. Though, yeah, you might hope the ISP support could see that issue!

Is 192.168.50.5 the correct IP for 4c:b0:08:2a:d4:36? You might need to capture for longer to what's triggering the movement log. That Intel MAC is odd though, I expect to see that broadcast. Can you find that device? Is it some rogue router on your network?

@jarhead said in Question about Automation and firewall rules (enable/disable using SSH/API): @bmeeks said in Question about Automation and firewall rules (enable/disable using SSH/API): @andrek said in Question about Automation and firewall rules (enable/disable using SSH/API): thank you. is the appliance open for SSH to shell so I can run pfctl from another device? When you enable the SSD daemon via the GUI, it automatically opens the necessary port on the LAN. It does not open WAN ports that I remember. Pretty sure it's open on all interfaces but you would need a firewall rule to allow it through the WAN. Not that I'm suggesting that. Yeah, the daemon listens on all interfaces, but the default firewall ruleset will only allow inbound traffic to connect from the LAN. The docs I linked explain that a little farther down (and refreshed my memory).