@stephenw10 It does. I have the fact that the TCP connection gets established AND the TLS handshake continued : [image: 1769035435054-1ddc2194-5e60-46c9-9ae1-daf333ab8beb-image.png] This screenshot also shows the handshake works and the server proves its identity but that the verification of that proof fails : [image: 1769035523499-b46cc402-a51a-4e00-9b22-197ea623106c-image.png] Last but not least, the end of the output shows that it returns 68 which is the certificate validation fail since the server certificate has been signed by a CA that uses a weak algo : [image: 1769035575833-1007faa8-f3cd-4f5e-bac2-64f454287b70-image.png] It goes all the way through but still shows the error. Would that be a valid reason the LDAPS authentication is failing?

Try setting a default backend. You don't actually need an ACL to select a backend since there is only one.

@Bob.Dig so here is what I have set on that tcp wan rule [image: 1769018604398-synonlyjpg.jpg]

@stephenw10 I have not see this reoccurring. It's been largely stable in the past 6 months. Will come back to this thread if it ever breaks again.

@dennypage That makes sense. Thanks for taking the time to reply!

Ah nice. Yeah that's a weird issue, sticks in the mind weird! I know a few users were asking for BIOS updates that allowed fully disabling the management features on that NIC in the MS01. There might be one by now. I'm not really following it that closely.

Ah actually it's probably this: https://redmine.pfsense.org/issues/14440

@stephenw10 said in StarLink as source for NTP: Naming it chronyd.exe is killing me! But it doesn't really matter. It matters a bit, because the other files in the chrony/chrony-lite package, doc, system script, etc. do not have ".exe" in the name. @Mission-Ghost said in StarLink as source for NTP: RE: the .exe. I went around and around and somehow kept getting the chrony script instead of the executable. It seems they're named the same. So to keep that from happening I added .exe. Those two things are in different directories. One of those directories is in your search path, the other is not. Regardless, anything you put in cron (or any other script startup) should be done via absolute path so there should be no confusion. The daemon executable is /usr/local/sbin/chronyd, whereas the system startup script is /usr/local/etc/rc.d/chronyd.

@sbs said in Increase SWAP size: Hello, I have seen many post stating that needing swap is bad. However, I noticed after installing suricata that the system was getting very slow, and suricate would die at random times. Log complained about swap getting filled. I increased the swap, and system was stable again. I installed the system quite a while ago, and cannot remember if I selected a swap size or just went with the default. Would it be possible to persist the "swap on" instructions so that my extra swap file can be used after reboot. FWIW : current memory swap on our system is : [image: 1768226055340-13c3ec32-1236-48bb-901c-1d3d7b74edd6-image.png] Regards, 4GB of physical memory is really small for suricata, depending on your settings. My current pfSense installation for a high bandwidth usage setup on a dual WAN 2.5 + 1 Gbps setup routinely pushes RAM past 80% of the 16GB installed. Your mileage may vary but I might look at installing more RAM.

Yes if it's linked at 1Gbps to the ONT then that's not restricting anything and it's almost certainly limited at the ISP. But you should check if that changes when it loses the connection. You would normally see any link state change there logged though. If the mpd5 logs show it trying to connect and eventually it succeeds it sounds like this could be a server side problem. You might need to swap back in the ISPs device and test that. Then complain.

@stephenw10 Thanks a LOT!! The ' Interface > Switches > Ports and VLANs tabs' setting did the trick :-)

If it is repeating you should try running the debug kernel to get more info from it: https://docs.netgate.com/pfsense/en/latest/troubleshooting/debug-kernel.html

You can open a feature request here: https://redmine.pfsense.org/ I don't see anything open matching that exactly. There is this: https://redmine.pfsense.org/issues/16097

@stephenw10 thank you for the confirmation. At least now I know that it won't work in the current setup, "it's not me, it's you" :) Hopefully with further development of if_pppoe more legacy setup will be added. I the meantime I'll try to nag my ISP to move me to something more modern.

@beerguzzle said in Should I use IGMP proxy service?: Should I be running the IGMP proxy service? I am leery of making WAN the upstream interface. IGMP Proxy is used to route multicast from one interface to another(often WAN) to one or more other interfaces (usually LAN). It's used for things like IP-TV. As a general rule, you would know if you needed to route multicast from the internet. I'm guessing you do not need IGMP Proxy. As to the IGMP query packets appearing on your internal network, that is your switch asking each of its ports what multicast groups the port is interested in. You can safely allow IGMP packets into the lan interface on the firewall, or you can safely block them. I generally recommend allowing IGMP on lan ports because there is no downside to doing so. There is a minor down side to blocking them. If you allow IGMP, the host (pfSense) will respond to queries from the switch and provide an explicit list of multicast groups that it has interest in. In turn, the switch will only forward multicast groups that the host (pfSense) is actually interested in. If you block IGMP the usual default behavior of switches is to forward all multicast groups to the port, which means that the firewall be sent multicast packets even if it has no interest in them. The host will discard them, but it's a minor waste to send them across the wire and for the host to process them. As a general rule, is more efficient to use IGMP if your switch supports it.

If you send me the NDI / Order Number in chat I can check it.

@pfpv said in The new if_pppoe doesn't write to logs: After switching from ISC there were no logs ... Read here how to add Leases logs as ISC DHCP did.