Software-update: OPNsense 24.1.1

OPNsense logo (79 pix) 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 hebben OPNsense 24.1.1 uitgebracht en de releasenotes voor die uitgave kunnen hieronder worden gevonden.

OPNsense 24.1.1 released

Apart from rolling back Suricata 7 to 6 the new major version is looking good. The two intertwined Suricata default config changes in version 7 have been identified and fixed in the development version so that we can move back to version 7 in 24.1.2. This minor release is intended as a small round of fixes and third party updates to ensure reliability and security.

Here are the full patch notes:
  • system: enable OpenSSL legacy provider by default to allow Google Drive backup to continue working with OpenSSL 3
  • system: bring back the interface statistics dashboard widget update interval
  • system: fix all items in the OPNsense container being synced in XMLRCP when NAT option is selected
  • interfaces: overview page UX improvements
  • firewall: align GeoIP file check with documentation
  • firewall: fix virtual IP API use with subnet/subnet_bits usage
  • wireguard: allow instances to start their ID at 0 like they used to a long time ago
  • dhcp: omit faulty comma in Kea config when control agent is disabled
  • dhcp: add opt-out automatic firewall rules for Kea server access
  • ipsec: remove AEAD algorithms without a PRF for IKE proposals in connections
  • openvpn: fix cso_login_matching being ignored during authentication
  • backend: optimise stream_handler to exit and kill running process when no listener is attached
  • plugins: os-frr 1.39
  • plugins: os-haproxy 4.3
  • plugins: os-ntopng 1.3
  • plugins: os-tor 1.10 adds MyFamily support (contributed by Mike Bishop)
  • ports: nss 3.97
  • ports: openldap 2.6.7
  • ports: openssl 3.0.13
  • ports: syslog-ng 4.6.0

OPNsense

Versienummer 24.1.1
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

07-02-2024 • 07:03

35

Submitter: smerik

Bron: OPNsense

Update-historie

Reacties (35)

Sorteer op:

Weergave:

Ik snap dat ze met Kea DHCP zijn begonnen, maar het verschil met ISC DHCP in ontsloten functionaliteit is nog best wel groot. Ik ben benieuwd wanneer het qua functionaliteit gelijk aan elkaar is en wanneer Kea ISC zal passeren.
Wat mis jij in KEA dan dat ISC-DHCP wel heeft?
De mogelijkheid om custom DHCP-attributen toe te wijzen. Dit wordt met ISC ondersteund onder 'Additional Options'. Dit is essentieel voor bijvoorbeeld Raspberry Pi network booting, en ook om andere tekortkomingen van Kea op te vangen. Denk aan dat je geen TFTP bootfiles per architectuur kan opgeven, wat essentieel is om een onderscheid te maken tussen klassieke BIOS en UEFI network booting over verschillende architecturen heen.

Niet voor mijzelf maar wel voor anderen: DHCPv6-ondersteuning.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 01:13]

KEA ondersteund IPv6 dus die snap ik niet helemaal. Mis je wellicht de configuratie optie binnen OPNsense?
https://kea.readthedocs.io/en/kea-2.2.0/man/kea-dhcp6.8.html

En volgens word TFTP ookprima ondersteund volgens https://kb.isc.org/docs/kea-configuration-sections-explained.
Architecture kon ik zo snel niet vinden.

Maar ook hier heb ik het idee dat je configuratie opties mist binnen OPNsense, niet zozeer KEA zelf?
KEA ondersteund IPv6 dus die snap ik niet helemaal. Mis je wellicht de configuratie optie binnen OPNsense?
Ik snap dat ze met Kea DHCP zijn begonnen, maar het verschil met ISC DHCP in ontsloten functionaliteit is nog best wel groot.
Gezien het onderwerp van mijn reactie OPNsense is, is dat de context van de tekst in vet.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 01:13]

Ik zie bij ISC per interface een DHCP instelling, bij KEA heb ik dat nog niet zo terug kunnen vinden.
Wellicht dat het hier op een andere manier wordt aangevlogen?
Klinkt als een implementatie optie die mist binnen OPNsense.
Check the github en maak een feature request aan?
TIP! Voor goede werking van IPv6 moet ICMP open staan (niet alle subtypes, maar om te zien of je issue daar zit kan je het gewoon even open zetten), en mocht je een PPOE verbinding gebruiken, IPv6 heeft andere MTU/MSS instellingen nodig op een PPOE verbinding dan IPv4 vanwege een andere/grotere ovehead/header size (40 voor IPv4, 60 voor IPv6)
en mocht je een PPOE verbinding gebruiken, IPv6 heeft andere MTU/MSS instellingen nodig op een PPOE verbinding dan IPv4 vanwege een andere/grotere ovehead/header size (40 voor IPv4, 60 voor IPv6)
Wordt dit niet sinds 23.7.5 beter opgelost? Zie bijvoorbeeld hier. Als je niet expliciet een MSS invult, regelt OPNsense het dan zelf niet?

Met (voor een PPPoE verbinding) enkel de MTU geconfigureerd op 1508 op de pagina van de WAN-interface en de standaard firewall rules die voor IPv6 aangemaakt worden, passeren alle tests op test-ipv6.com. Is dat niet voldoende?

[Reactie gewijzigd door The Zep Man op 23 juli 2024 01:13]

Hangt af van je setup, of je OPNSense/pfSense fysiek hebt draaien of virtueel, en of je tagged VLANS gebruikt of untagged en ook welk OS je uiteindelijk gebruikt in je netwerk. Mijn ervaring is dat het goed werkt als je het allemaal hard instelt. Op de hypervisor gebruik ik MTU 1512 op de virtuele switch en gebruik ik tagged vlans. De WAN interface in de VM (pfSEnse) staat op MTU 1508 en de PPOE interface staat op MTU 1500 met een MSS van 1440. Netwerk clients (bekabeld/virtueel staan allemaal op MTU 1500) Fysieke switch kan tot MTU 9000. ICMP is belangrijk om IPv6 in alle gevallen goed te laten functioneren o.a. om MTU problemen in de route op te kunnen lossen
Hangt af van je setup, of je OPNSense/pfSense fysiek hebt draaien of virtueel, en of je tagged VLANS gebruikt of untagged en ook welk OS je uiteindelijk gebruikt in je netwerk. Mijn ervaring is dat het goed werkt als je het allemaal hard instelt.
Baremetal is het voor een PPPoE over VLAN WAN-verbinding in nieuwe versies enkel nodig om de MTU in te stellen op 1508 in de WAN-interface. Handmatig instellen van MTU's op andere plekken (PPPoE, VLAN, fyiseke interfaces) is niet meer nodig.
ICMP is belangrijk om IPv6 in alle gevallen goed te laten functioneren o.a. om MTU problemen in de route op te kunnen lossen
De belangrijkste ICMP-pakketten worden standaard tussen WAN-LAN toegestaan. Zie de 'Automatically generated rules' onder een LAN-interface, en dan specifiek de regels voor 'IPv6 RFC4890 requirements (ICMP)'.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 01:13]

Dat is niet mijn ervaring, maar moet er wel even bij zeggen dat ik de pfSense gebruik niet OPNSense. Als ik op pfSense geen MSS 1440 ingeef bij de PPEO interface heb ik een slechte upload die het in eerste instantie prima lijkt te doen voor enige tijd maar onder continue belasting langzaam terugloopt qua doorvoersnelheid en op een gegeven moment echt inzakt. Met bovenstaande instellingen en MSS hard ingesteld op 1440 op de PPOE interface heb ik dit probleem niet meer. Er blijken meer mensen last van te hebben ben ik op internet tegen gekomen in veel gevallen was de PPEO verbinding de gemene deler KPN, Freedom etc. zelfs op KPN devices/Fritsboxen e.d. (google maar eens trage upload, al zal niet in alle gevallen bovenstaande het issue zijn)
Dat is niet mijn ervaring, maar moet er wel even bij zeggen dat ik de pfSense gebruik niet OPNSense.
Daarom noem ik dat dit pas sinds kort is met specifiek OPNsense. Buiten de vergelijkbare naam en deels overlappende functies kan je niet meer uitgaan dat wat voor de één geldt, dat dat voor de ander geldt.

Als iemand met OPNsense de door jou omschreven problemen zou hebben, dan zou die simpelweg een MSS van 1440 in kunnen vullen op de WAN-interface, naast de MTU van 1508. Het is dan niet nodig om te grasduinen in andere pagina's.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 01:13]

Ging mij om Zenlord -> "maar nog steeds werken bepaalde diensten niet of met een vertraging van 30 seconden"

Het niet/traag werken kan mogelijk door MTU/MSS issues komen, en/of de vertraging omdat mogelijk ICMP niet aan staat/wordt toe/door gelaten.

"Als iemand met OPNsense de door jou omschreven problemen zou hebben, dan zou die simpelweg een MSS van 1440 in kunnen vullen op de WAN-interface, naast de MTU van 1508"

Nope, MTU 1500 en MSS 1440 op de PPOE interface, MTU 1508 op de WAN interface waar de PPOE op is geconfigureerd

[Reactie gewijzigd door Verwijderd op 23 juli 2024 01:13]

Dankjewel voor je suggesties - ik kijk er zeker naar als ik opnieuw thuis ben.
Ik vermoed echter wel dat de instellingen juist zijn voor mijn bekabelde toestellen, dus denk ik dat ik mij moet focusen op de Unifi Network Application software, aangezien ik daarin mijn switches en access points beheer. Als ik het mij goed herinner, staat alles op 1500 (OPNsense, centrale switch, lokale switches, access points)
MTU van 1500 is prima en standaard voor endpoints, mijn opmerkingen gaan over dat ICMP open staat vanaf je endpoints naar internet. En mocht je een PPOE verbinding hebben (KPN Glasvezel) je daar ook even kritisch naar moet kijken als het gaat om MTU/MSS instellingen. Succes verder!
Ik heb dit laatst eens geprobeerd maar na jaren gewend te zijn aan edge os (vyatta based) kon ik niet meer wennen aan de web gui. Toch maar geswitched naar vyos
Als ik dit soort zaken lees over EdgeOS dan geeft dat geen moed. De ontwikkeling van OPNsense lijkt op volle toeren te gaan, waarbij die bij EdgeOS aan het infuus ligt.

Ik ben ooit overgestapt van pfSense naar OPNsense. Met de web GUI had ik geen problemen.
Ik draai ook geen edge os meer maar vyos https://vyos.io/
Wist niet van het bestaan af, maar wel interressant.

De gratis versie is een daily build. Hoe werkt dat voor jou?
Heb ik even geprobeerd maar had daar ook zo m’n bedenkingen bij. Uiteindelijk heb ik de officiële instructies gevolgd om de lts versie te builden

https://docs.vyos.io/en/l...ing/build-vyos.html#build

Werkte bijzonder soepel als je docker gebruikt. Ik was binnen 20 minuten door het hele proces heen en had een werkende iso
Nice, ik ga het checken.
Op zich lachen dat je dat op je Ubiquiti hardware kunt draaien.

Probleem is dat je nog steeds gebruik maakt van Mediatek ofwel Cavium. De 32-bit MIPS machines kunnen niet al teveel (niet eens 1 gbit saturaten?), de 64-bit MIPS machines wek maar kunnen MIPS heeft geen ASLR. Het is niet zo verstandig om dat nog te gebruiken. Al moet je wel kijken naar het eventuele alternatief. OPNsense werkt officieel niet op ARM, dus ben je gebonden aan x86-64. Al is dat met huidige generaties best efficient.
Vyos draait ook op x86 hardware
x86-64 mag ik hopen.
:/ bij mijn weten is de architectuur genaamd x86 en is een onderliggend type daarvan x86-64 maar dat leek me niet perse nodig om aanvullend te vermelden... bij deze ja draait op x86-64
Jarenlange gebruiker en hoewel ik enkel basis-functionaliteit gebruik, ben ik er zeer tevreden van: super stabiel, en tot voor kort kon ik zeggen dat je als netwerk-leek zelf best wel veel gedaan kan krijgen met OPNsense...

De voorbije weken ben ik op de IPv6-kar gesprongen, maar dat is me wel niet zo goed bevallen. Na 3 weken proberen, en vooral veel inlezen over de verschillen tussen IPv4 en IPv6 heb ik SLAAC werkende gekregen, maar nog steeds werken bepaalde diensten niet of met een vertaging van 30 seconden (Deezer, de app van mijn domotica-systeem, Duolingo enz.). Het lijkt er nu op dat dit niet het gevolg is van verkeerde SLAAC-configuratie ('verkeerd' als in 'werkt niet met Android devices' - het werkt voor windows, linux, sonos-apparaten, LG televisie etc.), maar dat ik toch ook nog de DNS64 en NAT64-functies van OPNsense zal moeten configureren om de IPv4-only diensten te kunnen bereiken.

Enfin, eigenlijk niet gerelateerd aan dit mooie stukje software, maar eerder aan mijn gebrekkige kennis.
De voorbije weken ben ik op de IPv6-kar gesprongen, maar dat is me wel niet zo goed bevallen. Na 3 weken proberen, en vooral veel inlezen over de verschillen tussen IPv4 en IPv6 heb ik SLAAC werkende gekregen, maar nog steeds werken bepaalde diensten niet of met een vertaging van 30 seconden (Deezer, de app van mijn domotica-systeem, Duolingo enz.). Het lijkt er nu op dat dit niet het gevolg is van verkeerde SLAAC-configuratie ('verkeerd' als in 'werkt niet met Android devices' - het werkt voor windows, linux, sonos-apparaten, LG televisie etc.), maar dat ik toch ook nog de DNS64 en NAT64-functies van OPNsense zal moeten configureren om de IPv4-only diensten te kunnen bereiken.
Ik draai IPv4 en IPv6 dual-stack, zonder DNS64 of NAT64. Geen enkel probleem met systemen. Als het niet werkt met Android-apparaten, dan lijkt het alsof je aan de slag bent gegaan met DHCPv6 en niet met Router Advertisements (RA). Dit vermoeden heb ik omdat Android totaal geen ondersteuning heeft voor DHCPv6. Stateless DHCPv6 is geen SLAAC. RA is een aparte pagina binnen OPNsense, en betreft SLAAC.

Zet DHCPv6 volledig uit. Voor een eerste configuratie, configureer RA als 'Unmanaged' voor je LAN interface. Advertise Default Gateway aan (zou standaard aan moeten staan) en starten. Daarmee is het praktisch fire and forget. Je kan nog via RA aparte DNS servers configureren als je dat wilt. Anders wordt daarvoor standaard je OPNsense router gebruikt.

Uiteraard moet je wel goed je WAN en LAN interfaces geconfigureerd hebben om je interne apparaten publieke IPv6-adressen toe te laten eigenen. Gebruik geen NPTv6 of iets dergelijks in een eerste configuratie.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 01:13]

Dankjewel!
Ik heb zeker DHCPv6 uitgezet, en heb SLAAC als 'Unmanaged' geconfigureerd. Ik heb *tig verschillende combinaties uitgeprobeerd, en scoor nu 17-19/20 op online ipv6-tests (ook op Android), maar bepaalde diensten blijven timeouts geven op mijn Android devices.
Eerder vandaag zei iemand mij dat ik de MTU op mijn netwerk maar eens moest op 1280 zetten. Ik ben de komende dagen niet thuis, maar dit ga ik zeker eens testen, want staat nu overal op 1500. Ook dank aan @Verwijderd , die hieronder een gelijkaardige suggestie doet. Ik heb enkel problemen met een handvol wireless Android devices, dus zal ik beginnen met MTU aan te passen in mijn Unifi Network Application...
Voor de volledigheid: de automatisch gegenereerde ICMPv6 regels staan aan in mijn OPNsense setup, maar ik heb ook eens getest met het opzetten van de firewall voor *alle* ICMPv6 verkeer, en dan scoor je nog een puntje hoger op https://ipv6-test.com . Waarschijnlijk heb je dat puntje niet nodig, maar ik heb er alleszins veel tijd aan gespendeerd de voorbije weken, en dan ga je iedere steen omdraaien. Volgende week dus ook de MTU-steen ;)
Ik wil graag een all-in-one oplossing maken. Weet iemand welke wifi kaarten goed werken met opnsense.

Ik begrijp dat je ook een losse oplossing kan kiezen, maar daar ben ik bewust niet naar opzoek.
Een goede samenvatting.

TL;DR: niet de moeite waard voor wat je krijgt.
Dank je wel, erg jammer,
Beste OPNsense gebruikers: Ik draai thuis sinds 2016 pfSense voor mijn internetverbinding. Toen dat een tijdje geleden nog kon, heb ik een voor thuisgebruikers gratis pfSense+ key aangevraagd en gekregen.

Het draait op een bescheiden Atom C2758, met 16GiB geheugen vanaf een Intel enterprise-grade SSD: Ik vind betrouwbaarheid belangrijk.

Half vorig jaar heb ik geëxperimenteerd met een 10Gb/s netwerkkaart. Deze werd te heet, en heb ik verwijderd. Vorige week is daar een alternatief voor geïnstalleerd. Het viel me op dat er al lang geen updates geïnstalleerd waren, en ook niet beschikbaar waren. Zelfs de februari 2023 update was niet geïnstalleerd. Kwalijker was dat het systeem meldde dat het up-to-date was. Maar er was wat aan de hand, want ook de package-lijst was leeg.

Na een paar avonden lang debuggen, en met de uitmuntende hulp van Netgate op hun forum, bleek mijn Netgate ID gewijzigd te zijn, waardoor de pfSense+ versie die ik draaide, zonder licentie draaide. Jammer dat niet duidelijker werd weergegeven dat dat de oorzaak van mijn problemen was.

Netgate heeft mijn licentie met het nieuwe Netgate ID geupdate, maar heeft ook gezegd dat dat eenmalig is.

pfSense+ is dus eindig. Moet ik in de toekomst overstappen op OPNsense, of toch maar naar pfSense Community Edition? En waarom? En is dat een beetje te migreren? Want ik heb nogal een grote DHCP reserveringslijst.
DHCP config / leases kun je gewoon exporteren en in een ander OS importeren. Maakt niet zoveel uit welk OS, als het maar dezelfde DHCP server software is. ISC is populair, maar niet per definitie de beste ;)
Technisch gezien (performance, base features) zijn beide gewoon goede producten. De vraag is of je de volgende items gebruikt:

* pfblockerNG
* Tailscale
(er zullen wellicht nog andere zijn, maar deze week ik omdat dit redelijk populaire plugins zijn)

beide opties zijn plusjes voor PFsense gezien deze als plugin beschikbaar zijn. Dat wil niet zeggen dat niet mogelijk is in OPNsense, maar dan ga je in customizing gebied wat eventueel niet supported is door OPNSense.

Ander ding om rekening mee te houden is, de community van pfsense is groter, dus er is veel meer howto's en documentatie beschikbaar. OPNsense docu is ok, maar kan beter. Aan de andere kant, omdat er zoveel dingen qua features gelijk zijn is het enkel hoe je het implementeert, dus als je technisch goed onderlegt bent, kun je voor 98% kunnen bereiken op OPNsense wat je op pfsense kunt.

EDIT: Sorry deze was voor @MindBender , blijkbaar vergeten de juiste link te gebruiken in mijn response.
EDIT EDIT: Voorheen (paar versies geleden) was het redelijk eenvoudig om pfsense config om te turnen naar opnsense. Dat is helaas nu een stukje lastiger. (wellicht dat dit tooltje kan helpen https://github.com/TKCERT/pfFocus)

[Reactie gewijzigd door valhalla77 op 23 juli 2024 01:13]

Op dit item kan niet meer gereageerd worden.