Software-update: OPNsense 25.7.11

OPNsense logo Het pakket OPNsense is een firewall met uitgebreide mogelijkheden. Het is gebaseerd op het besturingssysteem FreeBSD en is oorspronkelijk een fork van m0n0wall en pfSense. Het pakket kan volledig via een webinterface worden ingesteld en heeft onder andere ondersteuning voor mfa, OpenVPN, IPsec, CARP en captive portal. Daarnaast kan het packetfiltering toepassen en beschikt het over een traffic shaper. De ontwikkelaars achter OPNsense hebben de elfde update voor versie 25.7 uitgebracht en de releasenotes voor die uitgave kunnen hieronder worden gevonden.

OPNsense 25.7.11 released

This release brings the new host discovery service which resolves and remembers MAC addresses for IPv4 and IPv6 hosts in your connected networks and provides this data for the firewall MAC aliases and captive portal clients. It is now enabled by default, but you can choose to opt out by disabling the automatic discovery option. A lot of work went into IPv6 improvements over the holidays as is tradition with the help of users debugging their networks during that time. A number of kernel fixes have been supplied and dhcp6c will also receive a larger update in 26.1 soon.

The changes are otherwise clustered around preparation for the major upgrade which brings an number of fundamental changes with the ongoing removal of ISC-DHCP from core. A plugin is already available through the development version and should auto-install. If not make sure you install it before attempting a reboot there. For the stable version everything is as it was. That being said, 26.1-RC1 will be out early next week and RC2 likely follows quickly. We are still set for a final release date of January 28. See you on the other side!

Here are the full patch notes:
  • system: add tooltip explaining active status in snapshots
  • system: add "lazy loading" model support on Trust\Cert
  • system: properly fill DNS SAN from existing certificates (contributed by Klaas Demter)
  • system: rename sudoers file to make it more sortable (David Jack Wange Olrik)
  • system: numerous safe execution changes
  • system: sort to retain order in syslog-ng source definitions
  • interfaces: fix comparison in PPP check code during assignment
  • interfaces: prefer longer lifetimes if multiple exist
  • interfaces: defer manual rtsold script execution
  • interfaces: use mwexecfb() in two instances
  • interfaces: move configure_interface_hardware() to main file
  • interfaces: migrate "sharednet" setting to its respective sysctls
  • interfaces: add and enable new host discovery feature for neighbours via hostwatch
  • firewall: automation: only show ICMP type when protocol is ICMP
  • firewall: automation: add multi-select ICMP6 options
  • firewall: use new host discovery in MAC type aliases
  • firewall: simplify port alias check
  • captive portal: assign empty array when "interface list arp json" returns invalid JSON
  • captive portal: use new host discovery service by default
  • dhcrelay: reload table to update relay status
  • intrusion detection: datakey hint was missing for rules edit
  • intrusion detection: replace "all" alert selection with explicit maximum choices
  • ipsec: most safe execution transformations done
  • isc-dhcp: interalize interfaces_staticarp_configure()
  • isc-dhcp: safeguard access to DHCPv6 "enable" property
  • kea: refactor daemon(8) call to mwexecfb()
  • network time: fix GPS coordinate display in status page (contributed by brotherla)
  • openvpn: add simple search functionality for accounts table in client export
  • openvpn: skip dynamic content when loading the model in client export
  • openvpn: convert two more exec() calls
  • openvpn: fix archive client export
  • unbound: remove delete selected button for single select overrides grid
  • unbound: add per-policy quick actions in reporting overview
  • unbound: add overrides reference counter for aliases
  • unbound: info section was larger than table width
  • backend: exec() removal in get_sysctl()/set_sysctl()
  • backend: exec() removal in auth scripts
  • mvc: reduce some call overheaad in BaseField/IntegerField
  • mvc: introduce defaultConfig property for AppConfig
  • mvc: uppercase all form labels
  • mvc: use asInt() in GidField and UidField
  • mvc: BaseField: add isSet()
  • tests: revamped config and base model tests
  • ui: bootgrid: allow conditional command rendering through a filter function
  • plugins: os-frr 1.50
  • plugins: os-ndp-proxy-go 1.3
  • plugins: os-telegraf 1.12.14
  • src: in6: modify address prefix lifetimes when updating address lifetimes
  • src: ipv6: fix off-by-one in pltime and vltime expiration checks
  • src: ipv6: do not complain when deleting an address with prefix length of 128
  • src: ifconfig: fix the -L flag when using netlink
  • src: netlink: do not directly access ifnet members
  • src: netlink: do not overwrite existing data in a linear buffer in snl_writer
  • src: netmap: Let memory allocator parameters be settable via loader.conf
  • src: pfsync: avoid zeroing the state export union
  • src: divert: fix removal of divert sockets from a group
  • src: divert: use a jenkins hash to select the target socket
  • src: divert: define semantics for SO_REUSEPORT_LB on divert sockets
  • src: divert: use CK_SLISTs for the divcb hash table
  • src: pf: rationalize the ip_divert_ptr test
  • src: pf: fix handling of IPv6 divert packets
  • src: rtsold: check RA lifetime before triggering the one-shot always script
  • ports: suricata 8.0.3

OPNsense

Versienummer 25.7.11
Releasestatus Final
Besturingssystemen BSD
Website OPNsense
Download https://opnsense.org/download
Licentietype Voorwaarden (GNU/BSD/etc.)

Door Bart van Klaveren

Downloads en Best Buy Guide

16-01-2026 • 07:30

27

Submitter: smerik

Bron: OPNsense

Reacties (27)

Sorteer op:

Weergave:

Ik wacht wel op de final release van v26 als die gepland staat om over 2 wk. uit te komen :)
with the ongoing removal of ISC-DHCP from core
Ik draai nog steeds op ISC-DHCP, ik snap nog niet helemaal waar ik naar toe zou moeten migreren (Kea of dnsmasq) in een thuisomgeving. Ik gebruik AdguardHome waar ik met een NAT-rule de DNS verzoeken van m'n clients naar ombuig. OPNsense gebruikt Unbound voor z'n eigen requests.

Iemand tips?
Iemand tips?
Geen tips, maar wel een opmerking. Met ISC is het mogelijk om in de webinterface verschillende network boot images te definiëren voor verschillende architecturen. Met Kea en Dnsmasq kan dit volgens mij nog niet.

Voor nu gebruik ik nog ISC omdat dit gebruik van iPXE op ARM veel makkelijker maakt. Ik maak mij niet heel druk. Kan het onderhuids ongetwijfeld wel voor elkaar krijgen met Dnsmasq of Kea. Alleen is het jammer dat het nog niet op een gebruiksvriendelijke manier kan.
Ik gebruik dnsmasq, na de besluiteloze ISC/Kea keuze door OPNsense, en gebruik ook verschillende architecturen. Dat is per interface prima in te stellen via DHCP options en dan option 93 (match client-arch).

Kan allemaal gebruiksvriendelijk via de GUI.

RFC 4578

Type Architecture Name
---- -----------------
0 Intel x86PC
1 NEC/PC98
2 EFI Itanium
3 DEC Alpha
4 Arc x86
5 Intel Lean Client
6 EFI IA32
7 EFI BC
8 EFI Xscale
9 EFI x86-64


Voor ARM zou je option 175 kunnen gebruiken (zelf nooit gedaan) en dan te laten verwijzen naar een voor ARM geschikte ipxe.efi file.

[Reactie gewijzigd door xxs op 16 januari 2026 11:10]

Mooi om te zien dat het wel via de web interface kan! :)

Gebruiksvriendelijk is echter wat anders (DHCP match optie 93 om de architectuur te filteren, set optie 67 om te verwijzen naar het juiste image, een tag om het toe te kunnen wijzen aan een scope, ...) als je het vergelijkt met de huidige ISC-implementatie (gewoon een invulveld voor het juiste image bij het instellen van een scope).

RFC's (en errata) in moeten duiken om een systeem te configureren is ook niet gebruiksvriendelijk. Overigens lees ik in een andere bron dat de gerapporteerde waarde voor een ARM64 UEFI-systeem voor DHCP-optie 93 "11" is. Een probleem met dergelijke RFC's (en errata) is dus ook nog eens dat die achter kunnen lopen op de praktijk, wat voor nog meer uitzoekwerk zorgt.

De instelopties voor de "grote vervanger" Kea in de web interface zijn best wel summier. Daar kan het volgens mij niet mee via de web interface van OPNsense. De OPNsense documentatie noemt wel keurig voor zowel Dnsmasq als voor Kea hoe een beheerder handmatig aan de slag kan gaan met configuratiebestanden op een manier dat het goed integreert in OPNsense. De middelen zijn er dus wel, maar vooralsnog is het allesbehalve gebruiksvriendelijk (zeker voor Kea).

[Reactie gewijzigd door The Zep Man op 17 januari 2026 09:06]

Die opties zijn altijd custom. Ik ben het met je eens dat het nice is als die in de UI gedocumenteerd zijn maar dan kom je uit bij FOSS en patches welcome. Uiteindelijk heb ik vele jaren zonder GUI allerlei opties in dhcp(c)d software gebruikt (want ISC software hebben veel lekken in gezeten, en klein was het ook niet). Ik vind het dus een beetje onzin dat zoiets wel of niet met GUI moet kunnen, gezien het een kwestie is van juiste cijfertje bij custom opties. Goede documentatie legt die cijfers uit, maar zolang je die custom options erin kunt zetten zit je goed (en als dat niet per GUI kan, dan met CLI).

Wat je ook nog wel zou kunnen doen is ISC dhcpd draaien en dan bepaalde requests (zoals zoals gerelateerd aan netboot) forwarden vanuit een ander segment waar dan Kea draait. Uiteindelijk gaat het er toch om dat tftp en nfs te bereiken zijn. Ik vind deze optie niet zo elegant, maar in sommige gevallen kom je niet onderuit aan dhcp proxy/forwarder gebruiken.
dnsmasq voor kleine <1000 client omgevingen, KEA voor grotere omgevingen, aldus de documentatie :)

Ik gebruik dnsmasq zowel voor DHCP als DNS, dus Unbound is buiten gebruik.
Als je isc gewoon bent lijkt kea mij de logischere keuze.
Goedemorgen ThinkPad,


Ik was zelf overgestapt naar dnsmasq voor thuis met onderstaande filmpje van homenetworkguy.

YouTube: Migrating from ISC DHCP to dnsmasq or Kea DHCP in OPNsense
Hey die kwam ik laatst ook tegen toen ik erachter kwam dat ik schijnbaar ooit van juist dnsmasq naar ISC ben gegaan omdat ik problemen had met het registreren van DHCP leases in de DNS en ook nu had ik daar nog problemen mee en de tijd om ISC vaarwel te zeggen dringt. Uit dat filmpje haalde ik het antwoord op mijn probleem; ISC en dnsmasq gaan anders om hiermee; de een verwacht dat je reservations/static leases juist in de pool houdt, de ander erbuiten. Ook uit dat filmpje haalde ik iets anders wat me compleet ontgaan was; de exportfunctie bij ISC, superhandig!

Mijn dns loopt al via dnsmasq en mn dhcp is super simpel dus dat gaat wel goedkomen.
Je hoeft niet persé te migreren. ISC-DHCP werkt prima en gaat voorgezet worden in een plug-in. ISC-DHCP wordt echetr niet meer maintained. https://www.isc.org/blogs/isc-dhcp-eol/

Maar het blijft natuurlijk wel gewoon werken. Als je de plugin installeert. Dat kun je nu al doen in deze release.
De vraag is alleen of het ook echt wel als plugin blijft werken?

Oude IPSEC en OpenVPN gaan er ook uit in de aankomende versie, terwijl het in 25.7 naar plugins ging.
Ik heb IPTV via KPN en zit denk ik met soortgelijk probleem.

Voor IPTV via OpnSense heb je DHCP opties 28 en 60 nodig maar zover ik heb kunnen vinden zijn die (nog) niet beschikbaar in dnsmasq of KEA

Iemand hier al een workaround voor gevonden?
Ik heb het zelf niet nodig, en ik moet er nog in duiken, maar volgens mij kan ik in DNSMASQ DNS & DHCP - DHCP Options van alles toevoegen, inclusief 60 en 28
Ik draai versie 25.7.9_7-amd64
Iemand hier al een workaround voor gevonden?
Via Dnsmasq kan je het via de web-interface waarschijnlijk gewoon implementeren. Zie het antwoord van @rvvliet. Door handmatig met configuratiebestanden aan de slag te gaan kan het waarschijnlijk zowel met Dnsmasq als met Kea. Zie de OPNsense handleiding als startpunt.

Een makkelijke workaround is gebruikmaken van unicast in plaats van multicast, door bijvoorbeeld de KPN Android TV applicatie op een TV of mediaspeler te gebruiken. Dan hoef je niets bijzonders meer te doen op OPNsense om IPTV te gebruiken.

[Reactie gewijzigd door The Zep Man op 17 januari 2026 08:17]

Thanks @rvvliet en @The Zep Man voor de workaround!
Nog wat verder onderzoek naar gedaan en option 60 zit in idd de gui van dnsmasq, option 28 zit verstopt onder broadcast address[28].
Ik wil eigenlijk niet afhankelijk zijn van Apps op mn TV. Ik heb ook nog een ouder model en daar durf ik niet eens een netwerkkabel meer in te steken :).
Gebruik hier al een hele tijd iptv met deze opties en dnsmasq. Geen problemen hoor.

Daarnaast, kan je deze opties gewoon weglaten en zal iptv ook gewoon werken, kpn doc zegt ook niks over deze opties aan lan zijde, dus vraag mij af in hoeverre dit echt nodig is :)
goed om te weten, thanks @victoryo !
Ik heb na de ISC DHCP deprecation warning direct een migratie naar Kea DHCP gedaan zonder deze twee DHCP options en kwam vrij snel tot de conclusie dat ze inderdaad niet nodig blijken te zijn op 't IPTV VLAN. Migreren naar Kea DHCP is dus ook een mogelijkheid 8-) .
Klopt!

Gebruik zelf wel dnsmasq met deze opties, maar het hoeft niet.

Ik kwam er achter op het KPN forum waar ook scripts staan voor de edgerouter waarin dit ook helemaal niet gedaan is voor het IPTV vlan.

Het enige wat geloof ik echt belangrijk is zijn de DNS servers omdat de iptv boxen anders issues met updates binnenhalen kunnen hebben.

Is er een voordeel om Kea te gebruiken boven dnsmasq?
Inmiddels een verouderde versie door een hotfix:

A hotfix release was issued as 25.7.11_1:
  • system: fix vsprintf() error on stray % invoke
Een verwijzing naar Amerika?

A happy new year to all of you!

25.7.11 comes at a strange point in time but we will try to offer a bit of familiarity and common sense as we probably all need more of this.
Deze versie zet "hostwatch" automatisch aan. Op zich geen probleem, maar bij mij sloeg deze op hol en heeft in enkele uren 11GByte aan logfile lopen genereren. Er hebben meer mensen last van.

Gelukkig monitor ik en kreeg op tijd een melding, maar anders heb je kans dat je log partitie vol raakt. Oplossing was bij mij om via Interfaces > Neighbors > Automatic Discovery de interfaces niet op "All" te hebben staan maar ze te kiezen.

Waarschijnlijk is het bij mij fout gegaan toen 1 van m'n WireGuard verbindingen even onbeschikbaar was.
Thanks. Ik las het in de release notes en twijfelde al: dit heb ik volgens mij niet nodig, zal ik het uitzetten? Aangezien ik dagelijks wireguard gebruik, lijkt me dat voor nu een goed idee.
In welke logfile zag je deze groei? Ik wil even dubbel checken op mijn installaties.
Hotfix hiervoor is er nu 25.7.11_2

Om te kunnen reageren moet je ingelogd zijn