@johnpoz Ok, well thank you anyway John
Tas

Cool. Yup there was a backend issue last night. It should be fixed now.

@Gertjan oh I missed that - my bad.

@stephenw10 said in Gateway monitoring still not OK:

I would still expect to have seen dpinger try to ping and show loss rather than pending.

/etc/inc/gwlb.inc:

// dpinger returns '<gwname> 0 0 0' when queried directly after it starts. // while a latency of 0 and a loss of 0 would be perfect, in a real world it doesnt happen. // or does it, anyone? if so we must 'detect' the initialization period differently..

Ah that's the issue. The partition is 200MB but the filesystem is only 766K! So that is the problem that jimps instructions should address. You should be able to copy out the EFI data, expand the filesystem to fill the partion then copy the it back.

UI Update output.

>>> Updating repositories metadata... Updating pfSense-core repository catalogue... Fetching meta.conf: . done Fetching data.pkg: . done Processing entries: . done pfSense-core repository update completed. 5 packages processed. Updating pfSense repository catalogue... Fetching meta.conf: . done Fetching data.pkg: .......... done Processing entries: .......... done pfSense repository update completed. 733 packages processed. All repositories are up to date. >>> Setting vital flag on pkg...done. >>> Setting vital flag on pfSense...done. >>> Renaming current boot environment from 25.03 to 25.03_20250719205419...done. >>> Cloning current boot environment 25.03_20250719205419...done. >>> Removing vital flag from php83...done. >>> Upgrading packages in cloned boot environment 25.03... Updating pfSense-core repository catalogue... pfSense-core repository is up to date. Updating pfSense repository catalogue... pfSense repository is up to date. All repositories are up to date. Checking for upgrades (10 candidates): .......... done Processing candidates (10 candidates): .......... done The following 10 package(s) will be affected (of 0 checked): Installed packages to be UPGRADED: if_pppoe-kmod: 25.03.b.20250515.1415.1500029 -> 25.07.r.20250715.1733.1500029 [pfSense] pfSense: 25.03.b.20250515.1415.1500029 -> 25.07.r.20250715.1733.1500029 [pfSense] pfSense-base: 25.03.b.20250515.1415 -> 25.07.r.20250715.1733 [pfSense-core] pfSense-boot: 25.03.b.20250515.1415 -> 25.07.r.20250715.1733 [pfSense-core] pfSense-default-config-serial: 25.03.b.20250515.1415 -> 25.07.r.20250715.1733 [pfSense] pfSense-kernel-pfSense: 25.03.b.20250515.1415 -> 25.07.r.20250715.1733 [pfSense-core] pfSense-pkg-Nexus: 25.03.b.20250515.1415 -> 25.07.r.20250715.1733 [pfSense] pfSense-pkg-System_Patches: 2.2.21_1 -> 2.2.21_2 [pfSense] pfSense-repoc: 20250419 -> 20250520 [pfSense] unbound: 1.22.0_1 -> 1.23.0 [pfSense] Number of packages to be upgraded: 10 The operation will free 12 MiB. 214 MiB to be downloaded. [1/10] Fetching unbound-1.23.0.pkg: .......... done [2/10] Fetching pfSense-pkg-System_Patches-2.2.21_2.pkg: ......... done [3/10] Fetching if_pppoe-kmod-25.07.r.20250715.1733.1500029.pkg: ... done [4/10] Fetching pfSense-pkg-Nexus-25.07.r.20250715.1733.pkg: .......... done [5/10] Fetching pfSense-kernel-pfSense-25.07.r.20250715.1733.pkg: .......... done [6/10] Fetching pfSense-base-25.07.r.20250715.1733.pkg: .......... done [7/10] Fetching pfSense-25.07.r.20250715.1733.1500029.pkg: .......... done [8/10] Fetching pfSense-boot-25.07.r.20250715.1733.pkg: .......... done [9/10] Fetching pfSense-default-config-serial-25.07.r.20250715.1733.pkg: . done [10/10] Fetching pfSense-repoc-20250520.pkg: .......... done Checking integrity... done (0 conflicting) [1/10] Upgrading unbound from 1.22.0_1 to 1.23.0... ===> Creating groups Using existing group 'unbound' ===> Creating users Using existing user 'unbound' [1/10] Extracting unbound-1.23.0: .......... done [2/10] Upgrading pfSense-repoc from 20250419 to 20250520... [2/10] Extracting pfSense-repoc-20250520: .. done [3/10] Upgrading if_pppoe-kmod from 25.03.b.20250515.1415.1500029 to 25.07.r.20250715.1733.1500029... [3/10] Extracting if_pppoe-kmod-25.07.r.20250715.1733.1500029: .. done [4/10] Upgrading pfSense-boot from 25.03.b.20250515.1415 to 25.07.r.20250715.1733... [4/10] Extracting pfSense-boot-25.07.r.20250715.1733: .......... done [5/10] Upgrading pfSense-pkg-System_Patches from 2.2.21_1 to 2.2.21_2... [5/10] Extracting pfSense-pkg-System_Patches-2.2.21_2: .......... done [6/10] Upgrading pfSense-pkg-Nexus from 25.03.b.20250515.1415 to 25.07.r.20250715.1733... [6/10] Extracting pfSense-pkg-Nexus-25.07.r.20250715.1733: .......... done [7/10] Upgrading pfSense-kernel-pfSense from 25.03.b.20250515.1415 to 25.07.r.20250715.1733... [7/10] Extracting pfSense-kernel-pfSense-25.07.r.20250715.1733: .......... done [8/10] Upgrading pfSense-base from 25.03.b.20250515.1415 to 25.07.r.20250715.1733... [8/10] Extracting pfSense-base-25.07.r.20250715.1733: ... done ===> Keeping a copy of current version mtree ===> Removing schg flag from base files ===> Extracting new base tarball ===> Removing static obsoleted files [9/10] Upgrading pfSense from 25.03.b.20250515.1415.1500029 to 25.07.r.20250715.1733.1500029... [9/10] Extracting pfSense-25.07.r.20250715.1733.1500029: .......... done [10/10] Upgrading pfSense-default-config-serial from 25.03.b.20250515.1415 to 25.07.r.20250715.1733... [10/10] Extracting pfSense-default-config-serial-25.07.r.20250715.1733: [10/10] Extracting pfSense-default-config-serial-25.07.r.20250715.1733... done Failed

@iggybuddy6 I'm just happy I could help. Today I went from thinking I knew everything about setting up wg on pfSense, to realising I did not, and that is a great reward in itself!

Hopefully your setup will remain stable going forward.

@johnpoz This even does this with the newest CE edition inside of UTM virtualized environment outside of the 2100s

Screenshot 2025-07-17 at 10.15.51.png

It is not just the 2100s this is set up for standard stuff everything else works with it just the status page

@Bob-Dig said in 25.07.r.20250709.2036 First Boot WireGuard Service not running:

These interfaces don't exist anymore, still they are in the logs, why.

They probably still exist in the configuration file for one of the traffic monitoring packages, traffic totals maybe? Resaving that with existing interfaces should remove those lines but I doubt they are causing this.

That error stopping wireguard looks to have come from the reboot script. I assume that was after you manually rebooted but before the actual reboot?

@Bob-Dig said in 25.07.r.20250709.2036 First Boot WireGuard Service not running:

If I enable the gateways by hand and then restart WireGuard, it is running fine. At least this is a solution that works.

The wiregaurd tunnel gateways? Or the WAN gateways?
I wouldn't expect the WG gateways to be available if the wireguard service is stopped. Conversely I expect them to become available when it starts and I assume that isn't happening if you have to manually start them.

Thanks @JonathanLee, that's good to know, hoping to get at least another 4 years out of the 6100

@mav3rick said in OpenVPN on 2 pfsense instance with HA - service is running on both pfsense instances:

So setting openvpn to bind only to the CARP VIP works fine for me

Multi-WAN with HA there?
If so, it would be a better idea to run openVPN server on localhost instead.
This would allow it to receive connections from all WANs.

No need to select a VIP, just forward packets from the WANs VIPs to localhost.
You can use DNS, thus the client would connect to the WAN that is UP.
Or
You can use two remote entries in the .ovpn, with timeout lets say, 2 seconds.

Then, just create the NAT rule to access the firewall-2, using the SYNC address as previously mentioned.

@viragomann I lost oversight. The customer edited stuff on his own ... and wrote he succeeded by adding fw rules and policy-based-routing. Sounds like overkill a bit, but ok if he's happy.
I have to accept that this box is out of my control somehow now ;-)

thanks for your help. I might report back if I get access again and see things.

Screenshot 2025-07-18 at 15.25.50.png

It works I had to adapt the make file again USES= tar:tgz for it to make install clean. I have to update the pr now

it comes with ROCK too!!!!

@RobbieTT

Be aware that I am not at all saying that a user can directly access the ISP-node, but I am sure that PPOE interface can !!

Whats ever I it helps, I am absolutely OK to activate PPOE debug logging for a short period!

Note that my actual config is like this
ISP => ISP-fiber-interface => one of my small switches => pfSense.

Internet should arrive via VLAN 6, IPTV via VLAN4 and (Old) VoIP via VLAN7.
Untagged routed to vlan1 and vlans (internet) are routed to pfSense.

I did add vlan1 to be quite sure that even untagged messages are passing to pfSense. Normally I would simply have blocked untagged. However the PPPOE is assigned to VLAN6.

@SteveITS said in pfSense® CE 2.8.1 Beta Now Available!:

Release notes?

https://docs.netgate.com/pfsense/en/latest/releases/2-8-1.html

It's not a bug because that's the expected behaviour. You could consider it a missing feature if you need to make changes there. Open a feature request: https://redmine.pfsense.org/

This is the first time I've seen anyone ask about it in 10 years though so it's clearly not a huge problem.

You could just patch the file to create the config with the values you need then carry that as a custom patch in the patches package.

@stephenw10 Correct. Way longer than the tunnel rekey times, so something must prompt a configuration reload outside of that.
Or maybe the tunnel went down at some point and the config was reloaded when a reconnect was attempted.

@stephenw10 said in [2.8.1.b] Multiple limiter issue:

The major difference there is the state binding. Note they are bound to all in 2.7.2 but interface bound in 2.8.0.

Did you try reverting that change in 2.8.0 to see if that makes any difference?

It did not make a difference between Interface Bound States and Floating States on 2.8.0.

vtnet1 tcp 23.239.29.5:443 <- 192.168.1.100:42446 ESTABLISHED:ESTABLISHED [1351492337 + 63360] wscale 7 [4004094591 + 63616] wscale 7 age 00:00:39, expires in 23:59:58, 26:28 pkts, 3531:19177 bytes, rule 87, dummynet pipe (3 4) id: df107d6800000000 creatorid: 9d03805d vtnet0 tcp <WAN IP>:17951 (192.168.1.100:42446) -> 23.239.29.5:443 ESTABLISHED:ESTABLISHED [4004094591 + 63616] wscale 7 [1351492337 + 63360] wscale 7 age 00:00:39, expires in 23:59:58, 26:28 pkts, 3531:19177 bytes, rule 86 id: e0107d6800000000 creatorid: 9d03805d route-to: <WAN Gateway>@vtnet0

and

all tcp 23.239.29.5:443 <- 192.168.1.100:55138 ESTABLISHED:ESTABLISHED [2584166382 + 63360] wscale 7 [3625120434 + 63488] wscale 7 age 00:00:40, expires in 24:00:00, 40:45 pkts, 4557:37927 bytes, rule 87, dummynet pipe (3 4) id: 04137d6800000000 creatorid: 9d03805d origif: vtnet1 all tcp <WAN IP>:49985 (192.168.1.100:55138) -> 23.239.29.5:443 ESTABLISHED:ESTABLISHED [3625120434 + 63488] wscale 7 [2584166382 + 63360] wscale 7 age 00:00:40, expires in 24:00:00, 40:45 pkts, 4557:37927 bytes, rule 86 id: 05137d6800000000 creatorid: 9d03805d route-to: <WAN Gateway>@vtnet0 origif: vtnet0

The other thing is that I expect to see the limiters in the reverse order on the outbound rule but it could be you're just testing that way? That might explain one of the test failures you saw above.

If I understand this, the labeling of my limiter matches the GUI. GUI option is labeled In / Out Pipe so I have the first one labeled WAN-in-q & LAN-in, the second WAN-out-q & LAN-out. I verified bandwidths amounts set in the limiters and the order in the rules are correct and consistent between the two versions.

Also that's the non-policy routing situation?

I'm not PBRing in this case. At one site, I have 2 WANs and PBR some devices when the primary fails. There are no limiters on any PBR rule. The floating rule on the primary WAN has the same Bufferbloat limiters. The other site has a single WAN and no PBR.

@stephenw10 Confirmed fixed ty kindly sir.

@MacUsers said in Kea DHCP stops working:

all of pfSense are v24.11-RELEASE (amd64); as far as I can see now, KEA actually never worked for me since I migrated from ISC, regardless of the pfSense version.

There is a 99,99 % solution avaible now.
Right now, this one :

05190dbc-0f5c-445e-ba66-8104c93aae78-image.png

is available.
An RC version is identical to the final Release.
It stays RC so very minor issues let GUI text can get corrected.
Major changes, like 'kea not working' won't be corrected anymore.

I'm pretty sure (tens of thousands) use "25.07"(RC) right now, and they 'all' use kea.
No issues afaik.
So .... even if 25.07 won't solve your issue, you'll be sure for 99,99 % that the issue is ... on your side.
Or, you are using pfSense (hea DHCP) in a very special way, and no one else is using it that way so we can't know what your issue is ?
Do you have any details about why your 'pfSense' (DHCP kea settings) are so different that it 'break's ?
Do use an edge case scenario where things were possible with ISC DHCP, but not anymore with kea ?

Btw : we all have iMac, IPads iPhone and other iStuff in our networks, they all behave fine with kea, using classic DHCP leases, or static MAC leases.