@netblues UDP using port 443 ok? Had no idea there was ai driven spam now. Thought that was one weird post. Going to change it here to UDP over 443 and download a new client Viscosity bundle. Glad I posted about the TCP error. I learned a bit. [image: 1754266878787-screenshot-2025-08-03-at-7.19.42-pm-resized.png]

@coffeecup25 If it is plus, you will need to contact support to get it re-activated. However it will work, you just can't install packages/updates/upgrades

@stephenw10 so i did more testing cuz pfsense keeps locking me out of internet on the 2.8.0 i dont remember it happening so much on 2.7.2 but when the internet stops working on WAN or vpn.. it can connect to some sites on the WAN if i unplug the lan and let the pfsense rest for an hour i still can not ping websites by there name so google.ca ebay.com amazon.com from pfsense but i can ping 1.1.1.1 8.8.8.8 i tried reboot and the wan says online, but vpn doesnt work... my site to site to my sisters pfsense is down pfsense can not not ping dns names.. i can just ping ip address's i change the wan from pppoe to dhcp so it gets 192.168.2.x ip and i can just ping ip address not dns names i do a reboot and i still cant connect site to site.. dns names dont work just ips.. i delete all in the dns reslover and set ALL ALL for incoming and outgoing.. i do reboot pfsense and still cant ping dns names from pfsense just ip address's i do a restore of the config file boom i can ping dns names again once it reboots.. so something seems to get flag and reboots cant correct it.. is it my poor internet thats causing this like seems like a flag issue.. its like a circuit breaker.. it trips and you cant use internet anymore till you reset the breaker or restore pfsense... i cant downgrade to 2.7.2 cuz its not an option in the update.. could this be a panic kernel issue where i had to set that set hint.iwm.disable="1" could the os be panicing and bricking my dns till i restore and then its solved till it breaks like a circuit breaker.. is there more tests i can test?

@ipguy Some services dont max out to the OS limit and have their own internal limit, but if it is the case then I dont know how you would raise it, I think a VPN hitting the listen queue limit is highly unlikely unless you running a public VPN server that has gone viral or something. So it seems odd to me you have this problem in the first place. 'netstat -L' shows listen queues, looks like OpenVPN has a limit of 1. My OpenVPN processes are running in client mode though. There is nothing in the manpage to tune it, and I found a very old dev post from people asking for the limit to be raised, it very likely is compiled in to the binary.

I removed the NAT rule and the router restarted cleanly. All working ok now. I will be upgrading to a Netgate 4200 in the next weeks.

@johnpoz said in Strange DNS Issue: 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. I came to the same conclusion as it's now miraculously working! I knew I dotted all my i's and crossed my t's and coming up with nothing on my end lead to me to believe it was something upstream. Thanks to everyone that chimed in!

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

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.

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

@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