Disable any hardware off loading you might have. Check for other errors on that interface. Maybe a bad cable or failing NIC etc. Steve

Even on an older version it should not just restart for no reason. If there is nothing logged there to indicate a reason you should open a ticket with us here: https://go.netgate.com Steve

@Gertjan said in Sending logs over Telegram: When you SSH into pfSense you are root (admin). Funnily enough, I actually have a regular user account I use for creating my own hodge-podge VPN, which is restricted to port forwarding only. (I use sshuttle, which requires Python, and since pfSense doesn't have Python, I port forward to my NAS and then use sshuttle against the NAS) As for the removal of clog, thanks for the heads up.

Hmm, I guess it retained some config then. We have seen NICs that require a complete power cycle to clear some issues. Steve

I am running 2.4.4-RELEASE-p3 (amd64) the throughout updates the issue initially mentioned is still occurring. about once or twice a year i get a new WAN IP from my provider and my VOIP service no longer works, and within the states it still has the old WAN IP. i have to manually kill the states for it to refresh and work. i also have Under System / Advanced / Networking i have checked Reset All States where it says "Reset all states if WAN IP Address changes This option resets all states when a WAN IP Address changes instead of only states associated with the previous IP Address" even with above checked, the same issue mentioned initially in my post is still occurring. is this still a known issue?

It is crashing in the pfSync code so it's to see how that could happen unless something is using it. The pfsync interface does get created on all installs but I'm not aware of ever seeing an issue like that previously without it actually syncing. Steve

@jdeloach I don't, but that is the server they run all of their tests to for some reason.

Yeah, there is some difference between what happens when you run, say, rpcinfo from pfSense directly and when it's run from Proxmox. So I would run a pcap on the OpenVPN interface and compare them. rpcinfo will create quite a lot of output so you might want to use something simpler like just telneting to a port assuming that also fails from Proxmox. Steve

Good catch @JohanÅ ! Yea, I agree with Steve on this. The combination of large pfblocker lists and the register DHCP leases option in unbound has high potential for trouble. I had to disable DHCP registration in resolver also. Let us know how it goes.

Open a feature request at https://redmine.pfsense.org I have no idea how easy that might be though. Steve

Yes, you will need to define what you mean by 'seeing' here. And, yes, also where are you expecting to 'see' it from? If you can still open connections to it by IP address directly then pfSense is not blocking traffic. Steve

Hello, at least I have something to modify if users complain tomorrow hehe Thank you!

That's nice! Thanks for the reply, that solves much of the issue. I simply did not find the Serial for next certificate since I had my mind wrapped around looking in the settings for the certificate creation, not editing the CA. My bad! how much help you give the user is always something that can be discussed, but sure I can agree with this as long as the serial can be changed. Thanks for the quick reply!

@Derelict said in Gigabit installed but speed tests are sub 300 Mbits, Verizon says it's pfsense but can't prove it's not.: @kiokoman I don't understand the reluctance to pay a knowledgeable professional for something so important. I just don't. It's all about cutting costs, forgetting that also costs in what's delivered. I believe the term is "false economy". Also, I have worked as a tech for many years. One thing I've often noticed is many others only learn as much as they need to do the job and little else. As a result, they can generally do their job, but get stuck when something unusual comes along. I have always tried to learn more.

@kiokoman Thanks - that should work

Run a packet capture on WAN and see what's there. You should see some traffic even if it's only failing ARP messages. Steve

From 2013?! Even if he did, whatever issues he may have been hitting have probably been fixed. Guessing I'd say thay user's ISP was not routing those IPs to him. So either the ISP had not enabled it yet or he needed VIPs on WAN they can ARP for. Reading your other thread I would say your ISP is not routing that IP to you. Call them. Steve

Urgh. I hate when that sort of solution works! At least it does work though. Steve

"sudo pfSsh.php playback changepassword admin" worked. Thank you very much. "sudo passwd admin" - goes through the motion but admin password doesn't change.

Nope. That is the current release version. We'd need to see the error to advise further. You might also try running at the command line pkg update That may also throw errors but with more verbose output. Steve