Yup, there was a backend issue. Should be good now.

Mmm that^.

However what you will see is that after booting back into the 24.11 BE the update branch will still be set to 25.07-RC because that was the last thing that was done before the upgrade took the snapshot. So if you plan to run 24.11 for some time after reverting you would need to set the update branch back to 24.11 in that BE before doing any package operations.

Hmm, but they are policy based tunnels? And 300 Phase 1 configs not a total of 300 Phase 2 configs for example?

I'm not aware of any issue in 2.8 that might present like that for IPSec.

Currently nothing I'm aware of but going forward some functions will likely be written in go and hence in the Nexus package. Obviously that assumes the Nexus package is always present so it is automatically re-installed at upgrade.

@cybrnook

It looks if you are referring to the pimd engine version

854cb5be-fd74-43b0-848a-b83df5637c1b-image.png

Which is quite old, and as far as I know not working under FreeBSD. I have compiled the never released pimd-3.0.b1 version (using FreeBSD15 current).

@Euroguy said in Router advertisement not sending default gateway:

So, followup after a reinstallation of the system

Short answer is, things now seem to work.

Glad to see you got it up and running :)

I get both DHCP4 and 6 clients with leases now (although status of lease seems broken, always showing black down arrow even though lease is active and remote machine is up and active

I see that from time to time too. I think there are some timers that you can tweak (can't recall which ones though) that determines how long it takes without a "sign of life" before the client is marked as offline. For IPv4 there's an ARP timer ... and for v6 it should be an equivalent NDP timer. Can be set in System / Advanced / Tunables once you find out what they are called :)

DHCP6 server fails as DHCP requests / Discovery is done on fe80::/10 and that is not considered to be LAN it seems. I had to add a LAN allow rule for fe80::10 to ff02::/16 like this for DHCP6 to work:
e98b2093-2534-4c7e-9c09-6d54251d537d-image.png

That rule shouldn't be needed, it is part of the automatic rule set added by pfSense. I get those by means of pfSense magic: (check in /tmp/rules.debug)

pass in quick on $WAN proto udp from fe80::/10 port = 546 to fe80::/10 port = 546 ridentifier 1000000463 label "allow dhcpv6 client in WAN" pass quick on $LAN inet6 proto udp from fe80::/10 to fe80::/10 port = 546 ridentifier 1000002551 label "allow access to DHCPv6 server" pass quick on $LAN inet6 proto udp from fe80::/10 to ff02::/16 port = 546 ridentifier 1000002552 label "allow access to DHCPv6 server" pass quick on $LAN inet6 proto udp from fe80::/10 to ff02::/16 port = 547 ridentifier 1000002553 label "allow access to DHCPv6 server" pass quick on $LAN inet6 proto udp from ff02::/16 to fe80::/10 port = 547 ridentifier 1000002554 label "allow access to DHCPv6 server" <snip>

Update:
the timer tweak I used a long time ago was

net.link.ether.inet.max_age=60

which make the cached ARP-entry lifetime 60 seconds, I wanted clients to go offline faster. Default is 1200s. See https://man.freebsd.org/cgi/man.cgi?query=arp&sektion=4

24319ba3-b5d5-4add-b251-9993249ff5a6-image.png

@PiAxel said in update from 25.07 beta to 25.07 RC:

The last version doesn't work for me!

??

How do you know that the latest version doesn't work for you, before installing that latest version ?

( 😊 )

Probably just that then. But you should see the set options and capabilities for those NICs like:

[2.8.0-RELEASE][admin@t70.stevew.lan]/root: ifconfig -vm igb0 igb0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500 description: WAN options=4e100bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWFILTER,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG> capabilities=4f53fbb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_UCAST,WOL_MCAST,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,NETMAP,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG>

So there you can see the NIC is both checksum offload and TSO capable but only checksum is enabled.

@SteveITS Here is the routing.

0d548741-07ae-4fed-a672-add0b522130f-image.png

@provels Thank you for the reply. Only two modes were available after the loader changes. 80x25 and 80x50. This provided me with a starting point to learn more but I got lost again as I tried to learn about KMS and DRM and Xorg and EDID and vt(4) and syscons and kernels and compiling and scteken and framebuffer and...

Yes, that's possible. Yes the 1100 would be fine for 200Mbps.

Hard for me to comment on replacing the UDM Pro. That's what I would do but I'm biased! 😉

@SteveITS Thanks, restarting the GUI fixed it and I was able to replace the routers.

@sub2010
Idee ja, jedoch keine Lösung, und letzteres ist ja, was du suchst laut Titel. 😊
Und mit Plex habe ich keinerlei Erfahrung. Daher weiß ich auch nicht, wie der Stream vom Server zum Plexamp Client kommen soll. Streamt da die App am Smartphone zum Client, oder wird das nur benötig, um die Verbindung herzustellen und den Client zu steuern?

Wenn nicht bekannt, könntest du das mal austesten. Wäre ggf. hilfreich.

Ich würde vermuten, dass die App in den Stream eingebunden ist. Und dafür könnte ein weiteres Protokoll erforderlich sein, vielleicht UPnP / DLNA.

Um herauszufinden, was die Geräte benötigen, könntest du ein Packet Capture an beiden Interfaces jeweils mit einem IP Filter auf Smartphone bzw. Plexamp Client und UDP laufen lassen.
Schau dir an, was so auf Broadcast u. Multicast IPs geht.

Dann ist mir nicht klar, was genau ist diese Unify Zeugs? Ist das tatsächlich nur ein AP und das Subnetz der Clients liegt an der pfSense an?
Ist es nicht eine Mesh-Konstrukt?

@Gertjan shame on me! Didn't see that ... thanks a lot!

@tman222 said in Upgrading Unbound version for latest pfSense Plus release?:

(I didn't see it listed in the 25.07 release notes when I looked earlier).

A couple of days (weeks ?) one of the latest pfSense Plus Beta or RC already included 1.23. That's the version I use right now.
Since February 2025, 1.22.x was used, that's according my own release notes (I always log the upgrade process, executed form console, option 13, to a file. I don't use the GUI upgrader as that one tend to hide the obfuscate the interesting stuff.)

If the newest unbound version, 1.23.1, concerns the 'pfSense' version of unbound, then 1.23.1 will probably be included soon.

edit :
@w0w => 👍

We can actually check :

[25.07-RC][root@pfSense.bhf.tld]/root: unbound -V Version 1.23.0 Configure line: --with-libexpat=/usr/local --with-libnghttp2 --with-ssl=/usr --enable-dnscrypt --disable-dnstap --with-dynlibmodule --enable-ecdsa --enable-event-api --enable-gost --with-libevent --with-pythonmodule=yes --with-pyunbound=yes ac_cv_path_SWIG=/usr/local/bin/swig LDFLAGS=-L/usr/local/lib --disable-subnet --disable-tfo-client --disable-tfo-server --with-pthreads --prefix=/usr/local --localstatedir=/var --mandir=/usr/local/share/man --infodir=/usr/local/share/info/ --build=amd64-portbld-freebsd15.0 Linked libs: libevent 2.1.12-stable (it uses kqueue), OpenSSL 3.0.16 11 Feb 2025 Linked modules: dns64 python dynlib respip validator iterator DNSCrypt feature available BSD licensed, see LICENSE in source package for details. Report bugs to unbound-bugs@nlnetlabs.nl or https://github.com/NLnetLabs/unbound/issues

so the CVE deosn't apply.

@Wolfgangthegreat For example (this is checked by default):
8544523b-d69b-4088-b221-d2532912455c-image.png

@stephenw10 I don't have enough points to upvote, so I'll just say thank you Stephen 👍 !

Now, if the seller agrees to selling me that M570, I should be good to tackle this thanks to all the good info supplied by the community in this thread :)

and then it worked...

@werter
Благодарю за ссылки!
Поток негатива на netinstaller уже пошёл.
Задушат pf CE походу...

@Bob-Dig thanks
But I cannot understand why the FTP performance is crippled when going via Wireguard and not when going via the WAN.
The same happens for NFS and SMB file sharing protocols. The performance over Wireguard is rather poor, although I haven't tried these over an unencrypted WAN for obvious reasons so can't really compare.