Is that consistent across a full power cycle? The LEDs should only ever normally show flashing green during an upgrade. So with pfSense booted. Do that still show the normal power up sequence? Initially no LEDs should be lit. Then after a few seconds the green-circle LED flashes blue.

@stephenw10 Yeah, that was kind of my thinking too. I'll stick with it for now despite the (seemingly) high error rate (0.1% if it could be believed). Do let me know if anyone has any ideas for trying to hone in on the cause of these 'errors'.

@stephenw10 That's a handy command, good to know

Yup, use python mode.

Hmm, that doesn't look good. I assume you have tried a full power cycle? But on the 4200 you can fit in NVMe SSD to install to: https://docs.netgate.com/pfsense/en/latest/solutions/netgate-4200/m-2-nvme-installation.html

I can't be if you're not using IGMP proxy in 23.01 as you said. Is that not actually the case?

@TAC57 Plex themselves had a data breech awhile ago, there Plex code had some bad malware in, infostealer. Workstations and Public Facing services should be in VLANs regardless. Look at netstat but bare in mind that it will most likely be noisy, Monitor Wireshare and pfSense together to look at logs, I would recommend wiping the system completely and starting from scratch. Change all passwords, move Public Facing services into there own VLAN with strict firewall rules, TrueNAS should be in a Storage VLAN, Workstations in their own VLAN. Having a flat network with public facing services is the worst thing you can do. Implement a IDS/IPS something like Snort or Suricata, pfblockerng with Geolocation blocking which are the things I would suggest implementing as well. Check have i been pwned also.

Oh yes if some hosts are not using pfSense as their gateway that would be an asymmetric route. That traffic could (should) be blocked by the Fortigate since it would only ever see replies. For TCP traffic at least.

Do you see any errors logged? What does Diag > System Activity show? Or at the CLI: ps -auxwwd ?

@keyser hi sir please ignore my post i figure it out now to make it work i added in dns resolver/custom option. i get this instruction from someone who posted hehe https://forum.netgate.com/topic/129365/bypassing-dnsbl-for-specific-ips thank yo man server: access-control-view: 120.10.0.0/21 bypass access-control-view: 192.168.40.0/21 bypass access-control-view: 120.50.0.0/21 bypass access-control-view: 192.168.80.0/24 dnsbl access-control-view: 192.168.100.0/24 dnsbl access-control-view: 192.168.101.0/24 dnsbl access-control-view: 192.168.200.0/24 dnsbl access-control-view: 172.100.0.0/24 dnsbl view: name: "bypass" view-first: yes view: name: "dnsbl" view-first: yes

New behaviour for dyndns in 2.8 is that it will not attempt to check a WAN that has a gateway that's offline. So some configs that were previously working even though there was some issue there will now show the issue such as this.

Hmm, pfsense.com was never a way to access the forum. I imagine it's hitting a generic forward there. The forum was previously at forum.pfsense.org and that still forwards correctly.

Yes I have seen that on the igc driver. It really only supports auto-select. For some reason when the driver sets anything it can cause link issues. Also worth noting is that if you have set autoselect and then go back to default it may not reset that since 'default' sets nothing. You may need to reboot to get the NIC and driver back to the actual default state.

If it was something upstream the port wouldn't change when you change the pfSense gui port. It pretty much has to be a floating rule or interface group passing that traffic. If you look at the states at the CLI using: pfctl -vss you can see the rule that opened the state. Then check the rules with pfctl -vsr to see what that rule is.

@stephenw10 no worries, scheduled reboot was our backup and as you say works well. We've not come across any other issues so far with our use cases.

My operating system is Windows Server 2022. I noticed that the default group policies of my domain controller are somewhat different from yours. Currently, I'm also having issues with failing LDAP connections via ports 389 and 636, but I can connect successfully using GSS-API SASL. I almost gave up, but after seeing your post, I've regained hope. Since various systems currently only support connections via port 389 or 636, I still hope to prioritize using port 389.[image: 1755148365158-398c0123-f27e-4b3d-83ad-74357589cf66-image.png] [image: 1755148525693-f6940a51-b579-4528-bc8f-5aa493be8564-image.png]

Yes it's still available for amd64 and arm64. It no longer builds for arm32.

@aGeekhere I want to play with it more in a secure environment. To compile it on a m1 in a VM it took hours

@Cornel said in Reboot removes kern.ipc.nmbclusters lline from /boot/loader.conf.local on SG-3100: kern.ipc.nmbclusters="32768" That value is specifically cleared on ARM devices in /etc/inc/pfsense-utils.inc. You could comment that out there if you really want to set it but the default value there should be good. Seeing it at 65% is not that unusual.