pfSense Plus 25.07 Beta Now Available

[brezlord]

@brezlord said in pfSense Plus 25.07 Beta Now Available:

pkg-static clean -ay; pkg-static install -fy pkg pfSense-repo pfSense-upgrade

Spoke to soon. After reboot the system is still on 25.03.b.20250515.1415

I get the following error when trying to update packages:

 pkg-static update -f
Updating pfSense-core repository catalogue...
pkg-static: An error occured while fetching package
pkg-static: An error occured while fetching package
repository pfSense-core has no meta file, using default settings
pkg-static: An error occured while fetching package
pkg-static: An error occured while fetching package
pkg-static: An error occured while fetching package
pkg-static: An error occured while fetching package
Unable to update repository pfSense-core
Updating pfSense repository catalogue...
pkg-static: An error occured while fetching package
pkg-static: An error occured while fetching package
repository pfSense has no meta file, using default settings
pkg-static: An error occured while fetching package
pkg-static: An error occured while fetching package
pkg-static: An error occured while fetching package
pkg-static: An error occured while fetching package
Unable to update repository pfSense
Error updating repositories!

[brezlord]

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

[yellowRain]

I do not know if it is related to the 25.07 RC, or not, but I had an ipv6 WAN outage today, that needed a reboot, instead of a dhcp6 client retry a few moment later.

On the dashboard, WAN interface was showing 2001:xxxx:xxxx:xxxx:xxxx:: instead of 2001:xxxx:xxxx:xxxx:xxxx:yyyy:yyyy:yyyy:yyyy

Here is the offending lines in the DHCP log :

Aug 1 16:34:42 dhcp6c 77684 add an address 2001:xxxx:xxxx:xxxx::/128 on ix3
Aug 1 16:34:42 dhcp6c 77684 dhcp6c Received INFO
Aug 1 16:34:42 dhcp6c 77684 Sending Renew
Aug 1 16:08:11 kea-dhcp6 50779 ERROR [kea-dhcp6.packets.0x319bcd617400] DHCP6_PACKET_SEND_FAIL duid=[00:01:00:01:2d:4c:12:e7:f8:xx:xx:xx:xx:xx], [no hwaddr info], tid=0x3a7239: failed to send DHCPv6 packet: pkt6 send failed: sendmsg() returned with an error: Permission denied

By the way, in the web GUI Dashboard, in the Interface Widget, would it be possible to modify it to see the whole ipv6 without horizontal scrolling in the final version or next beta ?

[Gertjan]

@yellowRain said in pfSense Plus 25.07 Beta Now Available:

Aug 1 16:34:42 dhcp6c 77684 add an address 2001:xxxx:xxxx:xxxx::/128 on ix3
Aug 1 16:34:42 dhcp6c 77684 dhcp6c Received INFO
Aug 1 16:34:42 dhcp6c 77684 Sending Renew

These are dhcp6c events. Dhcp6c works on your WAN and talk with upstream "ISP" device or equipement for prefeixes and IPv6 WAN info.

This :

Aug 1 16:08:11 kea-dhcp6 50779 ERROR [kea-dhcp6.packets.0x319bcd617400] DHCP6_PACKET_SEND_FAIL duid=[00:01:00:01:2d:4c:12:e7:f8:xx:xx:xx:xx:xx], [no hwaddr info], tid=0x3a7239: failed to send DHCPv6 packet: pkt6 send failed: sendmsg() returned with an error: Permission denied

is a "Aug 1 16:08:11 kea-dhcp6 50779 ERROR [kea-dhcp6.packets.0x319bcd617400] DHCP6_PACKET_SEND_FAIL duid=[00:01:00:01:2d:4c:12:e7:f8:xx:xx:xx:xx:xx], [no hwaddr info], tid=0x3a7239: failed to send DHCPv6 packet: pkt6 send failed: sendmsg() returned with an error: Permission denied" = a LAN DHCP server event.
It could use the interface - A KLAN interface - anymore, because it was unavailable. Some ripped out the cable, or powered down the attached device ? Something like that.

@yellowRain said in pfSense Plus 25.07 Beta Now Available:

in the web GUI Dashboard, in the Interface Widget, would it be possible to modify it to see the whole ipv6 without horizontal scrolling in the final version or next beta ?

Scrolling ?

[yellowRain]

@Gertjan

Correct. I solved my issue, yet again an ISP issue on the DHCP6 server side, but they would not help me...
I had to manually change the DUID, as the old looked blacklisted. My LAN prefix, and the pfsense WAN adress has changed as a result.

My pfsense have long interface names, thus ipv6 are partially displayed, and a horizontal scrolling bar appears on the bottom of the widget:

[netblues]

@yellowRain What is exactly the point of hiding private ranges?

[yellowRain]

I did another clean upgrade 24.11 to 25.07 release, and what really changed regarding the dhcp6 client is that pfsense now picks up the manually assigned static ipv6, which is set up in my ISP box settings, instead of an auto generated one derived from MAC. In 24.11 this manual setting was ignored or malfunctionning.

So far so good !
No need to change the DUID.

Though on some ISP connections, the ipv6 ping to google from the DHCP-PD range was ok only after a few minutes, maybe due to routing check or appliance check on ISP side.

So you should plan the upgrade form a redundant ipv6 WAN, or a dedicated management network, or from a remote ipv4 access.

[yellowRain]

I encountered another loss of connectivity after setting a custom static ipv6 address for pfsense router in the ISP box.

Here are some tips and ideas on ipv6.

1. So I share the definitive precise sequential steps I had to follow (to get routed global ipv6 on delegated prefix ranges after a change in the address scheme) :
   -clear any previous DHCPv6 and DHCP-PD settings in the ISP box,
   -reboot the ISP box to clear routing table on ISP side,
   -then set a static ipv6 address for pfsense in the ISP Box (this static ipv6 address must be the global prefix, combined with the EIU-64. In other words, this ISP do not support random custom static suffix. Yet in other words, it must mimick the auto-conf SLAAC addrress. Otherwise I get strange global routing breakages). Think as weel to set an IPv4 static address if dual stack needed,
   -then reboot both to update routing aliases in the ISP box and set the new static ipv6(/ipv4) in pfsense,
   -then configure the static prefix to pfsense in the Prefix delegation in the ISP box,
   -then reboot both to get immediately the new delegated prefix routing.
   -then check/update/check/apply all ipv4/ipv6 firewall rules (and ipv4 Firewall/DMZ/redirection rules on both).

2. As for PFsense, I think there is another thing to improve in the Interface field, which would be useful especially for keeping LAN ipv6 connectivity during a global WAN outage :
   a "Tracking mode with ULA".
   In this mode, Pfsense would have 3 ipv6 addresses

• local-link "fe...",
• GUA through ISP SLAAC "delegated global prefix : EIU-64",
• ULA "fd..." as a local backup.
  Currently, with "Track interface" we have only the 2 former ipv6 addresses.
  OpenWRT, Win11, Linux behaves in this way.

fyi, my RA is configured in "Assisted mode"
=> this is the perfect setting for clients in the LAN (they all can set local-link, GUA through SLAAC, GUA through DHCPv6 if implemented, multiple ULA).

3. Another thing my ISP box does not allow me to do, is to set static DHCPv6 adresses in the Prefix delegation range. For the pfsense router itself, It would make sense to get a 4th ipv6 address :

• GUA set through ISP DHCPv6 "delegated global prefix : custom suffix".

4. Today, to get the ULA in combination with the GUA on PfSense itself, we need 2 LAN interfaces, at least in my understanding :

• One configured with SLAAC, with no DHCPv6, but with RA advertising "fd...".
• Another one configured with Track Interface, with DHCPv6, with RA advertising "20...".

Another setting I have not tried is RA Router mode "Stateless DHCP"

5. On OpenwRT, if one want both RA ULA & GUA on one interface, it is possible, but there is a missing setting in the WebUI Luci, that should be set manually "ra_preference" to "low", "medium", "high" in /etc/config/dhcp, to manage the race in condition of 2 RA on same subnet.

6. PfSense misses ipv6 usual configuration & bad settings such as https://openwrt.org/docs/guide-user/network/ipv6/troubleshooting

7. @netblues this question is often asked on this forum, it is because it is a public forum. The debate wether disclosing private address range, or even only disclosing part of public range, constitute a security issue should be another whole topic.

[yellowRain]

8. I think there is another useful setting in OpenWRT Router Advertisement called "ra_default" in (https://openwrt.org/docs/techref/odhcpd).
   It gives the following possibility (as seen in Luci>Network>Interfaces>LAN>DHCP SErver>IPv6 RA Settings>Default Route) :

• automatic (0, "default setting") : Announce this device as default router if a local IPV6 default route is present
• on available prefix (1, "ignore no public address") : announce this device as default router if a public IPv6 prefix is available, regardless of local default route availability
• forced (2, "ignore all") : announce this device as default router regardless of whether a prefix or default route is present

That #8 would be useful in Pfsense also at least if my #4 is not considered best practice.

[Gertjan]

@yellowRain said in pfSense Plus 25.07 Beta Now Available:

Here are some tips and ideas on ipv6.

You would have to start with the start : your ISP.
The bad news : IPv6 isn't IPv4.
After decades, for IPv4, the DHCPv4 WAN IP attribution won. Some ISPs still persist offering a PPPOE connection. What left - 1 % or so, is "totally not standard", so you have to use the ISP box, and connect pfSense as a 'LAN device' using DHCPv4 on the WAN, and you done.

For IPv6 : if your ISP was respecting all IPv6 RFCs, then 'set WAN to use DHCPv6-client, and done.
Maybe some ISP give you a page with IPv6 setting, but I guess that's pretty rare.
Some ISP propose the awkward "Negociate IPv6 over IPv4" or some other strange method.

So, normally - afaik, already this :

setting a custom static ipv6 address for pfsense router

is already quiet 'non standard'.

The ISP or ISP box should give :
An IPv6 WAN address for the pfSense WAN interface
and
as many 'prefixes' (/64 networks) for every pfSense LAN your pfSense has.

Typically, your ISP or ISP has 256 (/56) indicate with of these prefixes for you (probably minus on, as from the first prefix, only one IPv6 is used, the one for your pfSense WAN).

But, as the bad news tells us : every ISP on planet earth has probably broken something (uses their own non RFC method).

I'm not staying your 'static' method isn't good, Just that it is - again afaik - not standard.

Btw : SLAAC : things can be done differently, I guess, I just never used it.