Software-update: OPNsense 25.1.2

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 tweede update voor versie 25.1 uitgebracht en de releasenotes voor die uitgave kunnen hieronder worden gevonden.

OPNsense 25.1.2 released

This was supposed to hit earlier this week, but some weeks are like this one now where QA takes more time than usual. Of note is the move of Dnsmasq to MVC and the ChartJS update to version 4 which is bundled with nice updates for widgets and the system health graphs.

The roadmap for 25.7 was also published[1]. The IPsec and OpenVPN legacy parts will move to the plugins so that the functionality can live there in community support tier. Since Kea remains a bit of an odd choice we will be offering DHCP support via Dnsmasq as a new standard feature which also offers seamless DHCP lease registration some people keep looking for.

Here are the full patch notes:

• system: adjust gateway widget to use the intended caching mechanism
• system: thermal sensors widget can now select individual sensors to display plus UX changes
• system: handle dev.pchtherm temperatures in the thermal dashboard widget (contributed by Joe Roback)
• system: use new apply button partial in tunables page
• system: move high availability option "disable preempt" to advanced mode
• system: straighten out syslog-ng rc.d scripting
• reporting: switch health graphs to ChartJS
• interfaces: add "nosync" option to VIPs and fix sync conditional
• interfaces: exclude automatic radvd like we do for manual
• firewall: properly unpack multiple source/destination items in the rules page
• firewall: hide internal aliases to align with previous legacy_list_aliases() function
• firewall: add missing "persist" on bogonsv6
• captive portal: urlencode() selector items in voucher group list
• dhcrelay: integrate layout_partials bootgrid/apply
• dnsmasq: migrate existing frontend to MVC/API
• ipsec: add deprecation notices for legacy components (will move to plugins)
• kea-dhcp: add "v6-only-preferred" option (contributed by darses)
• openvpn: add deprecation notices for legacy components (will move to plugins)
• openvpn: support "password first" for static-challenges
• unbound: add support for forward-first when configuring forwarders (contributed by Nigel Jones)
• wireguard: change tracking of peer status, improve widget and diagnostic
• backend: add an "import" rc.syshook facility
• backend: change the "monitor" rc.syshook facility and de-deprecate its use
• backend: remove unused functions and move once-used functions to their call script
• mvc: wrap locks around updates and perform some minor cleanups in ApiMutableModelControllerBase
• mvc: move "lazy loading" option to base model implementation and force usage on run_migrations.php
• mvc: safeguard checkToken() to prevent fetching an non existing POST item
• ui: upgrade ChartJS to v4
• ui: change backdrop background color to black in dark theme
• ui: create a unified layout partial for the apply button
• plugins: adjust all themes for ChartJS 4 use
• plugins: treat empty string like null on argument map
• plugins: os-acme-client 4.9
• src: ipfw: make 'ipfw show' output compatible with 'ipfw add' command
• src: pf: stop using net_epoch to synchronize access to eth rules
• src: e1000: fix vlan PCP/DEI on lem(4)
• src: igc: remove unused register IGC_RXD_SPC_VLAN_MASK
• src: ifnet: detach BPF descriptors on interface vmove event
• src: libkern: add ilog2 macro et al
• src: ipfw: add missing initializer for 'limit' table value
• src: pf: add extra SCTP multihoming probe points
• src: pf: verify SCTP v_tag before updating connection state
• src: pf: verify that ABORT chunks are not mixed with DATA chunks
• src: pf: allow ICMP messages related to an SCTP state to pass
• src: pf: add 'allow-related' to always allow SCTP multihome extra connections
• src: bpf: fix potential race conditions
• src: net: if_media for 100BASE-BX
• src: rtw89: update Realtek rtw88/rtw89 driver et al
• src: net80211: 11ac: add options to manage VHT STBC
• src: ifconfig: make -vht work
• src: iwlwifi: update Intel iwlwifi/mvm driver et al
• src: ixgbe: Add ixgbe_dev_from_hw() back
• ports: ca_root_nss / nss 3.108
• ports: curl 8.12.1
• ports: openssh-portable 9.9p2
• ports: php83 8.3.17
• ports: py-duckdb 1.2.0

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

Reacties (12)

[sambaloedjek]

Weinig spannende veranderingen in deze release, en de voorgaande. Het wordt langzaam eens tijd dat er een Linux-based versie komt van OPNsense, met ondersteuning voor nftables, fasttrack, en betere multi-core ondersteuning (PPPoE).

[Z80]

Er is bewust gekozen voor BSD. Unix. Dit ivm de veiligheid. Bij Linux moet er eerst een heleboel gestript worden.

[GeroldM]

Ben het wel met je eens dat de keuze voor FreeBSD geen slechte keuze is voor zoiets als OPNSense.

En je hebt ook gelijk dat zelfs een kale server verise van Linux (bijvoorbeeld Ubuntu, RedHat enz) ook van een heleboel extra's zijn voorzien waar een oplossing als OPNSense niks aan heeft en dus gestript moet worden van al die bijzaken.

Echter, Alpine Linux (een kreng om mee te werken, maar dat terzijde), die is echt heel minimaal en daar hoef je in principe heel weinig weg te halen en/of bij te installeren. Alpine of soortgelijke distributies kunnen dus wel degelijk als "ondergrond" dienen voor een applicatie als OPNSense.

Sterker nog, HomeAssistant (de versie die je niet op een Raspberry Pi installeert) draait op Alpine. Draait hier al zo'n 3 jaar hartstikke stabiel en wordt gebruikt voor de zonnepanelen, tuinverlichting, cameratoezicht, kleinschalige tuinbouw (koeling en humiditeitscontrole) en in de nabije toekomst controle over de vele ruimtes waar een airco mogelijk inefficient word gebruikt.

BSD is dus geen vereiste, maar zoals je zelf al aangaf, wel een verstandige keuze.

@sambaloedjek
Draai OPNSense sinds 2016, op een oude desktop machine die lag rond te slingeren AMD APU A6800 geloof ik. Zit 16 GByte aan RAM (DDR3) in, CPU is nog nooit boven de 9% belasting uitgekomen, zelfde voor geheugebruik en 3% aan opslag capaciteit. Er hangen bijna 50 computers aan OPNSense. En 10 personen loggen dagelijks in voor remote werk.

Loggen doe ik niet lokaal, maar via een toegeweidde logserver op een aparte computer. Dat zou al een boel kunnen schelen qua resource vervruik in jouw OPNSense oplossing en genoeg CPU/RAM vrij kunnen maken voor wat hogere doorvoorsnelheid.

Aannemende dat met multi-core support jij doelt op mogelijk onvoldoende CPU (en eventueel RAM) resources om doorvoorsnelheden te halen die dichterbij de grenzen van je verbinding liggen.

[xxs]

Vergeet niet dat OPNsense een fork is van M0n0wall en pfSense, M0n0wall stamt al uit een tijd dat Linux stukken minder stabiel was en minder netwerk/firewall mogelijkheden had dan Linux. We hebben het over een eerste versie van M0n0wall in 2003!

[Jerie]

Nah, lekker BSD kernel laten. Ik hoef geen nftables, ik wil pf.

Als je een Linux-based firewall wilt, dan zijn er die er ook, zoals OpenWrt.

[S-1-5-7]

openvpn: add deprecation notices for legacy components (will move to plugins)

Tijd om maar eens te migreren van OpenVPN naar WireGuard. In de roadmap staat dit gepland voor juli:

Move OpenVPN legacy to plugins as a first step to deprecation

[Reactie gewijzigd door S-1-5-7 op 1 maart 2025 09:34]

[xxs]

Voor inkomend verkeer bedoel je?

Is een appeltje eitje verhaal.

Kwesie van een instance aanmaken en de key's laten genereren, de peer generator gebruiken om voor je apparaten een config te genereren, interface assignen, enablen en firewall rules opstellen.

[S-1-5-7]

Inkomend verkeer inderdaad. Ja het staat al even op m'n to do lijstje, maar ik kom er gewoon niet aan toe. Nu een goeie stok achter de deur. Wellicht dit weekend maar even dan
Het zou als het goed is ook de performance ten goede moeten komen.

[Reactie gewijzigd door S-1-5-7 op 1 maart 2025 14:14]

[xxs]

De stap naar KEA was ook een beetje te snel, die ontwikkeling lijkt weer nagenoeg stil te liggen.
Dus onlangs van ISC DHCP naar Kea gemigreerd zoals ik, dan kan je straks weer naar Dnsmasq migreren.

Edit: Dom van me, reply op mezelf. Was voor @S-1-5-7 bedoeld.

[Reactie gewijzigd door xxs op 1 maart 2025 10:16]

[S-1-5-7]

Staat ISC ook op de planning op uit te faseren dan? Ik kan er niets over vinden op de roadmap.
Voor DNS gebruik ik al een aparte AdGuard VM, dus die migratie kan ik overslaan

[xxs]

Ik weet niet of ISC eruit gaat ook nog niks van gelezen. Dus Kea kan je gewoon overslaan en op ISC blijven zitten zolang dat er niet uitgaat.

[Jerie]

ISC DHCP heeft gewoon niet zo'n goede track record qua veilig geschreven te zijn.