@amrogers3 Now really, you are considering the ai driven forum spams? Don't mess with mtu. its not the cause for dropouts.

okay, i`m still waiting for the release of july... ;-)

Increasing the tunable 'kern.ipc.somaxconn' might help, but its possible OpenVPN internally has a much lower queue limit.

I ran into this same problem and ended up in this thread. Having since solved the problem, I wanted to return to report my findings. I had to dig into the PHP source code for the PFSense Web Configurator as well as the C source code for OpenSSL to figure this out. What I found is that these error messages indicate errors when parsing something in the config file, and since it is complaining about an empty or null name, I had some idea what to look for. In my OpenSSL configuration file, I found an empty SAN entry on line 14: /etc/ssl/openssl.cnf # pfSense: default SAN value if $ENV::SAN is not defined # SAN = /etc/ssl/openssl.cnf (after change) # pfSense: default SAN value if $ENV::SAN is not defined # SAN = DNS:myname This simple change solves the issue.

@stephenw10 so disabling didnt help so its almost like a flag if my internet fails for so long pfsense flags and disables so what happens this is with pppoe or dhcp 192.168.2.x on the WAN it will work for a long time or so.. then internet doesnt work VPN goe offline.. VPN and WAN internet no longer work.. Pfsense cant ping google.ca but it can ping 1.1.1.1 if i reboot wan comes online but it doesnt work pfsense cant ping google only like 1.1.1.1 and its not using monitor ip of 1.1.1.1 just the default DSL modem provides from bell so i tried disabling the interfaces WAN and vpns did a reboot then re enabled.. still cant get vpn or WAN to goto any websites.. pfsense cant Ping google.ca but can ping 1.1.1.1 resetting states does nothing.. but if i restore my config file.. when reboots vpn up and working, WAn is working, pfsense can ping google.ca and things working... its like the pfsense gets a flag to no longer work even reboots dont fix this flag.. except a restore of the config file.. is there something in the logs i need to capture when this happens next.. is there a glitch in pfsense maybe that does this... is there a file i need to delete that let me fix it like how you delete the dhcpd leases from shell when the gui doesnt work... is it a glitch cuz my poor internet is causing this.. i havent resolved the homedepot issue.. but for now i dealing with this locking up.. and i not sure if i just let pfsense alone an hour to see if it correct itself.. and i figured out why host names or description names dont work i had it set to the kea dhcp it doesnt seem to work so i set it back to isc and names show up.. dunno why its broken on the kea side.. but ya so i dunno what to look for or a logger to say dns resolver is down that u cant ping by web names only ips

@rfranzke Its waaaay too difficult to blame faulty installation for random crashes. If something like that happens (say, a faulty drive) then crashes are immediate and repeatable. The bsd bug that Steven has found is a better candidate. Obviously its rare, if it wasn't there would be plenty of reports here about it. Now you are able to catch full crash dumps. A debug kernel is the next thing. This is deep waters and you know it. Give it some time.

@JonesTech said in Strange DNS Issue: ;; communications error to 98.142.103.195#53: timed out ;; communications error to 98.142.103.196#53: timed out Those are the 2 name servers for that domain - if you can not talk to them, then yeah your going to have hard time getting the an IP for a record they are serving. nanjones.com. 86400 IN NS ns2.fistbumpmedia.com. nanjones.com. 86400 IN NS ns1.fistbumpmedia.com. Could be a peering problem your isp currently having.. But yeah if you are resolving and can not talk to the owning NS for a domain, your not going to be able to resolve anything from them.

@patient0 just a quick note, I updated that script to operate correctly on newer versions of pfSense (2.8/25.07). Let me know if you run into any issues.

Just a quick note, I updated my script to operate correctly on newer versions of pfSense (2.8/25.07). Let me know if you encounter any issues.

@ser There is still the IP block option which really BLOCK's it, but is maybe also a little cumbersome. You could look into using the package pfBlockerNG and then select one of two paths: 1: If you can force all clients to only use your pfSense as DNS you could block all DNS lookups that relates to Spotify. That would effectively either require a some good google-foo to find those names, or alternatively setup at test and have your DNS server log all queries when Spotify opens. 2: If Actual blocking is needed rather than just preventing nameresolution, then pfBlockerNG can also be configured to import lists that contains IP addresses. I'm sure there is some site somewhere that maintains Spotify's IP in a list - alternatively you could attempt to fetch the ASN ownership of IP blocks that Spotify owns, ,but that might not cut it (CDN's and such...) Option 1 I ususally the easiest and best working model even though it only prevents nameresolution rather than actual blocking.

@louis2 Hello ! Thank you for your work with pimd ! I have been able to test your pimd binary, it seem to work but I still have the same bug I discribed here When starting PIMD, after a few seconds it works as it should, seeing multicast sources and routing it if needed. But after about 3 minutes, PIMD is "loosing" multicast sources even if pfSense still receive this multicast traffic (packet capures, and network traffic). PIMD does not "receive" multicast source anymore. Restarting PIMD makes it see again multicast sources until it looses it again after about 3 minutes. @louis2 do you have the same problem ? I really do not understand why I have this

@dennypage Thanks for the info. Yeah, it appears somewhat complicated with IPSEC. ARD works over IPSEC but without live status and system information, which is what we had hoped to get working over our old IPSEC tunnels. ARD works fully with OPENVPN for us. Has anybody else had some successes here? Thanks, Alfredo

Indeed, not an easy way I'm aware of. I'd just reinstall clean to be honest. However you may need to wait for the 1.1 installer that has a 'low resource' mode to allow writing to a 4G eMMC.

Unless you need to accept inbound connections there it should only be an outbound NAT rule. Even if you did have inbound connections a port forward is often better. You shouldn't need to manually add any rules though as long as the gateway is added into the new interface. That will trigger the auto outbound rule to be added.

@SteveITS said in 2.8.0 fails to save SMTP Notification password: The test button text does say, "The last SAVED values will be used, not necessarily the values entered here." Ah, but that's not what actually happens. The just-entered new password IS used for the test, but then forgotten by the time you scroll down and "Save".