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

What did you have in mind? You could open a feature request: https://redmine.pfsense.org

Steve

Yes, probably. The new system will be much better in that respect. https://redmine.pfsense.org/issues/9693

Steve

The pfSense base system itself cannot do that, but a reverse proxy such as the HAProxy package can.

It has to be a proxy and not at the firewall because the hostname being requested isn't visible in the packet headers when the connection is initiated, it's sent by the client when making the request after the connection is established. At that point it's too late for the firewall itself to do anything. But a proxy can accept the connection, read the request, and hand it off as needed.

The only way to validate rules on an interface is to check from client on that network, you can not test them from pfsense directly.