@dcuadrados said in Problems With WAN Loss Cobnection:

no more [WAN] disconnections

Your pfSEnse LAN is connected to switch. This connection normally never goes down.
Exactly the same thing is true for the WAN NIC. It will stay up forever.

For the LAN switch, to do things even better, hook it up,to same UPS as the one pfSense uses, now even power won't bother you anymore.
Do the same thing for the WAN upstream device.

That said, there is something else, to consdier for the WAN interface.
You, as an admin, gave pfSense the order to 'reset' the WAN interface if the ping test starts to fail.
If ping pacquets don't come back, something is wrong on the router to the ping destination.
This could be (hopefully) a local issue, so pulling down the WAN will 'inform' the upstream device to re create the connection. This was valid in the past when people where using cable modems and kind of upstream ISP devices, but way less an issue these days. If the connection goes down or bad because a satellite is hiding behind a cloud, you can have the WAN interface pulled down as many times as you want, it won't un-hide the satellite.
You can, depending on your type of connection, de activate the dpinger action :
Uncheck :
226cdfc8-2884-47b7-b6fd-0c43b65239c9-image.png

and from now on pfSense won't touch the WA interface anymore.
It's still possible that the device on the other side of the WAN cable pulls the connection down : that's ok, and you can't do anything about it. (except maybe looking for a more stable ISP, if one exist).

The the issue is more upstream, you can't do anything about it, except waiting.

Keep in mind that ICMP (ping) packets also can get lost (dropped) if you saturate the connection.
Solution : stop doing so - or, for example, create 'pipes' where you can prioritize ICMP packets.
Or call you ISP and ask them for the "max" they can make available to you.

@stephenw10 said in PPPoE: Problems getting an IPv6 address on reconnection and other problems:

Do you see the same thing of you disconnect the pppoe via the Interfaces Status page?

Yes, it is showing "pending" even if I disconnect it via GUI.

Has to be something in OVH then. If those packets never arrive at the physical NIC they must be being blocked upstream.

@Gertjan I agree. I suppose you disconnected and then reconnected?

When I restart via pfsense and then kill the driver and manually restart it with -DDD upsmon either does not notice the problem or recovers automatically. Which is why I am puzzled that exactly this did not happen. And yes I suspect an error in upsmon. But I am not experienced enough to dig into the source code.

Yup that^.

https://docs.netgate.com/pfsense/en/latest/troubleshooting/boot-issues.html#booting-with-an-alternate-console

@Luca-De-Andreis said in Strange (occasional) malfunction on captive portal and mac address whitelist:

Do I wait for version 25.03

If you want to wait ....
If you have 10 minutes :
Make a new Boot env.
Boot into it.
Upgrade to 23.03 beta.
Reboot.
Test and tell me if things are better ?

You encounter the slightest issue, Boot-click back in 24.11 land.

That said, I don't think 25.03 (beta) behaves differently.

I was somewhat hoping, that, now you have some CLI commands avaible, you could find when/why the issue happens.
From there, as the problem has been found, acknowledged and can be reproduced at will, a solution will be found and your time and hard work will be part of "25.03".

Still, using HA a,d vouchers, how many are there out there ? You and 10 others ? (and 9 don't even know this forum exist).

Anyway, If I presume that this isn't a HA issue, and that vouchers or user/passwords can be used, I could test this also.
I actually already do so all the time :

I've 5 devices MAC listed : my 5 Unifi APs which are part of the captive portal.
The communicate with a Cliud key gen unfi box, present on my LAN, and this gen gen box generates constantly stats like :
32f79f9c-7fdc-42e8-afca-112792740b54-image.png

and it doesn't miss one beat .... for nearly a year now.

Not sure if the cloud key gen contacts the APs, or if its the other way around. I know they sync up every xx seconds and that loads of 'analytic' traffic is send :
ba57036b-05d2-4420-8c98-c123bf66650a-image.png

@SteveITS

"Thinking out loud here" :
If a (DHCP) client was set to be rejected, it will do the reject (it will answer "no") and normally, the client should take "no" for an answer - the the sofware is RFC compliant (I guess).
Let's consider 'ISC DHCP' as the old generation.
But its 2025, the client is probably a new generation DHCP client and won't take no for an answer, do'nt bother with RFC, so it keeps on insisting.
Now, ISC DHCP start to log.

It's in the admin's authority to take things one level up. It was the admin after all who decided who to serve, and who to reject.
Go visit the client, and tell him who is boss in the town.
Next step : MAC black list the guy and call it a day.

@luxor84

Why editing the pork_burn.sh file ?
You started with a more clean solution : a patch. Why not including a patch for pork burn file ?

Hmm, I mean it looks like they updated it a while back for 3.2 but we are using that version, and have been for some time.

The method we are using is current AFAIK:
https://wiki.squid-cache.org/Features/CacheManager/SquidClientTool#cache-manager-access-from-squidclient

Is there some update I'm not seeing?

Well we should have new installer version available quite soon so you could try that on it.

I've tried doing this a NAT:

044467cb-9aba-43cd-9478-da27475ebcfe-image.png
Resolving in no port open and no trafik towards my host, as a simple nginx page.
This is what I would Normally do NAT a port to a service.
I'm testing with https://ismyportopen.com/ - or directly onb the IP:PORT

With my VPN-CLient created as a Interface - without any rules for that Interface:
4f35e0a9-d1fa-42c2-93a0-5cb8d1a679aa-image.png
Since my VPN-client are created as an Interface - I would like to think there should be the rules under this interface for incomming rules.
Where I should believe (as the torguard as a Interface) should look like this instead:
498a8fdc-11a4-41ff-990f-983764915838-image.png.

But I'm not getting through in any of the 2 ways to my nginx. No issue with internal IP and port - which showing nginx testpage

A bit of a necro-bump for this thread. I just pulled my SG-1100 out of storage for a new network and decided to check the status of the eMMC. I ran the mmc extcsd read /dev/mmcsd0rpmb command which returned the following:

eMMC Life Time Estimation A [EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_A]: 0x03 eMMC Life Time Estimation B [EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_B]: 0x0b eMMC Pre EOL information [EXT_CSD_PRE_EOL_INFO]: 0x01

After reading the Troubleshooting Disk Lifetime it looks as if:
EST_TYP_A]: 0x03 - The disk has used 20%-30% of its estimated life time
EST_TYP_B]: 0x0b - The disk has used 100%-110% of its estimated life time
EOL_INFO]: 0x01 - he disk has consumed less than 80% of its reserved blocks

Clearly the A and EOL are nothing to worry about but the value for B worries me. Realistically, does this really mean that this element of the storage is on it's way out? ANy guidance people can offer?

The move to a unified installer I can understand a bit, but the lack of offline install support is a bad move by Netgate. With this single decision Netgate has chosen to almost completely eliminate themselves as a option for every non-internet connected, high security, or classified system around the globe. I highly suggest Netgate reconsider releasing offline install packages.

@chudak said in pfSense Plus 25.03-BETA is here!:

Why is 25.0x taking so long this time?

Because it is a really good update.

☕️

Thanks again for the video. It solved my problem.

If anyone bumps into this thread in the future, the static route showed in a screenshot above here was correct, however here's what I did wrong:

On site2 I had set "IPv4 Upstream gateway" in the interface config to the gateway on site1. This makes pfsense NAT the traffic instead of routing it. Here's a timestamped link to the video where this is explained.

QR code for pfSense WireGuard will be awesome!