Software-update: OPNsense 21.1.7

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 2fa, openvpn, ipsec, carp en captive portal. Daarnaast kan het packetfiltering toepassen en beschikt het over een traffic shaper. De ontwikkelaars hebben OPNsense 21.1.7 uitgebracht met de volgende aankondiging:

OPNsense 21.1.7 released

Today we move to Phalcon version 4 along with new FreeBSD security advisories and fixes for firewall live log as well as new features such as shell timeout and TLS remote syslog.

Here are the full patch notes:
  • system: add shell inactivity timeout feature for csh/tcsh
  • system: add Syslog-ng TLS transport options
  • system: remove unrelated service restarts from filter_configure_xmlrpc()
  • system: rotate interface statistics widget (contributed by FingerlessGloves)
  • system: delete previous route when changed
  • system: make web GUI restart action usable in cron jobs (contributed by Frank Wall)
  • interfaces: interface_configure() checks for enabled already
  • interfaces: system match for primary address only works with compressed IPv6
  • interfaces: disable legacy CSRF output buffering when downloading a packet capture
  • interfaces: execute OpenVPN device creation earlier during boot
  • firewall: change live log address/port group matcher to correctly flip logic
  • firewall: explicit default for filter rule association in NAT port forwards
  • firewall: prevent controls overlap in live log (contributed by kulikov-a)
  • firewall: let live log use the newly provided rule log label instead of guessing it
  • firewall: calculate wildcard netmasks in aliases
  • captive portal: fix GUI drop session issue
  • dhcp: support ignore-client-uids in DHCPv4 (contributed by Kacper Why)
  • firmware: push automatic flags to firmware frontend
  • firmware: show update pending hint in system widget
  • firmware: allow manual development override on business subscription
  • intrusion detection: add YAML tag to custom.yaml.sample
  • openvpn: return "result" instead of "status" in export
  • unbound: honour space as "domainsearchlist" separator
  • lang: updated available translations
  • mvc: migrated framework to Phalcon 4
  • mvc: return UUID in ApiMutableModelControllerBase::validateAndSave() if applicable
  • rc: unconditionally configure routing on rc.syshook start facility
  • ui: change service restart icons to fa-repeat
  • plugins: added variants support to share plugin code over different third-party software versions
  • plugins: added NO_ABI marker to themes
  • plugins: remove the use of $main_buttons in relevant code
  • plugins: compatibility fixes with Phalcon 4
  • plugins: os-nginx 1.23
  • plugins: os-wireguard 1.7
  • plugins: os-zabbix4-proxy is now a plugin variant
  • src: SMAP bypass
  • src: missing message validation in libradius
  • src: pms data corruption
  • ports: curl 7.77.0
  • ports: isc-dhcp 4.4.2-P1
  • ports: nss 3.66
  • ports: openldap 2.4.59
  • ports: pcre2 10.37
  • ports: phalcon 41.2
  • ports: py-certifi 2021.5.30
  • ports: py-yaml 5.4.1
  • ports: squid 4.15

OPNsense

Versienummer 21.1.7
Releasestatus Final
Besturingssystemen Linux, BSD
Website OPNsense
Download https://opnsense.org/download/
Licentietype GPL

Door Bart van Klaveren

Downloads en Best Buy Guide

18-06-2021 • 10:10

20

Submitter: terradrone

Bron: OPNsense

Update-historie

Reacties (20)

Sorteer op:

Weergave:

Let op als je update en je gebruikt free radius. Deze is stuk in deze versie. Als je wilt upgraden wacht ff want er komt een hotfix.

Kun je niet wachten dan moet je een revert doen van de freeRADIUS plugin.
In Shell run je opnsense-revert -r 21.1.6 freeradius3
Ik heb de update net geïnstalleerd. De aangeboden versie is 21.1.7_1 met de hotfix.
A hotfix release was issued as 21.1.7_1:

mvc: rename 3 API actions to fix their compatibility with Phalcon 4
plugins: os-freeradius 1.9.13[14]

[Reactie gewijzigd door Anteros op 24 juli 2024 07:00]

Ik zou het heel graag is proberen maar ik zit met mikrotik en dat werkt allemaal perfect ... maar toch ooit ga ik wel is testen.
Als dit nu eens in een container zou kunnen daaien op een Linux host ;)
Ik weet niet of je dat bedoeld maar ik draai pfSense al jaren op proxmox, daarvoor op hyperV. Alleen dan is het ff kutten met vlan. Dat gaat het best via de host en niet in de VM zelf.
Best cool allemaal. Een server. Glas erin, een switch er achter en gas er op.

[Reactie gewijzigd door Core2016 op 24 juli 2024 07:00]

Ik draai pfsense onder vmware met een dedicated dual port nic in pci passthrough , op die manier heb je toch native vlans
Waarom zou je dat uberhaubt doen.
Is er daadwerkelijk een attack surface?
Waarom zou je dat uberhaubt doen.
Prestaties. Als het enkel/voornamelijk een router is voor zaken buiten de VM, dan heeft het weinig zin om eerst door een virtueel netwerk te gaan.

Verder sluit het gebruik van een passthrough NIC natuurlijk niet het gebruik van virtuele netwerkadapters uit. ;)

[Reactie gewijzigd door The Zep Man op 24 juli 2024 07:00]

Voor een paar procent prestaties (en dat geloof ik eigenlijk al niet echt, netwerkstack van vmware is zo goed) ga je toch niet het hele voordeel van de hardwareonafhankelijkheid van een vm onderuit halen? Bedoel doel, waarom draai je uberhaubt virtueel. Als je je daar zorgen over maakt, ga dan volledig native.
Als je pfsense onder esxi draait en op een goedkoop celeron bordje met cpu onboard dan maakt het een gigantisch verschil om een dedicated nic in passthrough te gebruiken, puur met virtual nics heb ik zeer hoge cpu usage en in pci passthrough alles normaal
Ik heb hele andere ervaringen. Draai al jaren pfSense en OPNSense virtueel thuis(op een gedeelde microserver met meerdere VM's - celeron), en haal zonder issues 200Mbit up/down "gefirewalled" en met pfblocker), en ook zakelijk gezien draaien we pfSense(weliswaar op Xeon hardware) die meerdere gigabytes/sec doet op 10Gbit connecties.
Let wel: pfSense doet wat(zelfs op 2.5) raar met cores/vCPU's waarbij CPU0 en CPU2 meestal niets doen en CPU1 en CPU4 "alles" als je b.v. 1 socket en 4 vCPU(cores) toekent. Hoe dan ook, het lijkt me sterk als je niet iedere gangbare internet connectie voor thuis helemaal vol kan trekken met een pfsense gevirtualiseerd op een celeron, tenzij er echt iets raars aan de hand is en/of je je (fysieke) driver in ESXI niet helemaal lekker werkt.
Maargoed, aan dat laatste kan je dan niet altijd zomaar iets doen.

[Reactie gewijzigd door YoMarK op 24 juli 2024 07:00]

Jup. Ik gebruikte die HP nc375T daarvoor. Alleen werd warm en een hoog verbruik. Het vroegere moederbord ondersteunde hier nooit SR-IOV, nu wel gelukkig. Echt zo cool wat je allemaal kan met zulke configuraties.

Tijd voor 10G.
pricewatch: TP-Link TX401 10 Gigabit PCI Express Network Adapter. Echter weergeeft die site niet dat het IEEE 802.1Q ondersteund. Maar op een duitse site word wel gezegt dat het werkt. Eens proberen. Dan kan ik stoppen met LACP. Nu blijf je toch hangen op 1G, ookal kan dat meerdere keren tegelijk het is maar 1G en dat is niet snel meer.
Je kan toch in VMware de poort groep > vm network op vlan 4095 zetten, dan doet VMware niets meer met VLANS en paast die alles door naar je OPNsense VM waarin je dan native je VLANS kan beheren.
Waarom niet gewoon de kracht van vmware gebruiken en een vswitch per vlan aanmaken? Je opnsense gewoon een vnic per vlan. Veel simpeler, doeltreffender en dan gebruik je de vmware netwerk stack waarvoor deze bedoeld is.
Top programma, heb hem nu al 2 maanden draaien en alles is vlekkeloos verlopen, zowel installatie alsook de stabiliteit van het internet. Wat hier imo vooral zo gaaf voor is (voor meer simpele applicaties/hobbyisten) is dat je nu een feature set en interface hebt die over de jaren vrij stabiel blijft en je niet meer hoeft te worstelen met trage Ziggoboxen. Maar ook dat je met OPNsense steeds nieuwe dingen blijft leren puur omdat je graag wilt weten dat die en die setting nu precies doet. :)
Ik ben net begonnen met pfSense in plaats van OpenWRT en wil ook graag OPNsense uitproberen. Het leek me handig om het eerst bare metal te proberen, en daarna kijken hoe het als VM in Proxmox werkt, zodat ik de rest van de machine (Thinkcentre m720q) ook nog kan gebruiken voor andere zaken. Maar ik liep tegen het probleem aan dat de OPNsense-installer me mijn GPT gepartitioneerde SSD niet handmatig laat partitioneren. De enige optie die het me geeft (voor GPT) is de hele SSD wissen en OPNsense erover installeren. Aangezien ik er al andere besturingssystemen op de SSD heb geïnstalleerd is dit voor mij geen optie. Jammer dat OPNsense dit niet lijkt te kunnen. Ik snap dit niet zo want met de pfSense is dit wel mogelijk en daar is het een fork van.

Ik heb geen ervaring met BSD partitioning tools, en helaas heeft mijn systeem maar twee SSD aansluitingen, waarvan eentje een NVMe multiboot, en de ander een 2TB SATA waar ik uiteindelijk data op wil bewaren maar waar momenteel een overdreven 2TB OPNsense installatie staat. Linux lijkt partities met UFS alleen read-only te kunnen mounten. Weet iemand of het mogelijk is om een bare metal GPT UEFI installatie van OPNsense te verkleinen, of allicht naar die eerste NVMe te kopiëren?
Je kunt het beste de VM route bewandelen. Dit soort acties (partitioneren, multiboot) worden steeds minder gebruikt wat ervoor zorgt dat je een 'rare' non-supported installatie kan krijgen. Daar zou ik bijvoorbeeld nooit aan beginnen. Ik compartimeer alles via VM's of, bij voorkeur, in containers.
Door VM's te draaien kan je de beste opzet krijgen zoals je hem beschrijft.
Bedankt voor je reactie. Ik heb geconcludeerd dat het voor mij het makkelijkst is momenteel om voorlopig bare metal te installeren en te configureren, te kijken hoe dat werkt, en daarna het inderdaad binnen proxmox te proberen.
Toch jammer dat er geen makkelijke partitioning tools beschikbaar zijn, of dat ze niet die van pfSense overnemen eigenlijk. UEFI en de multiboot2 specificatie maken het juist mogelijk om meerdere besturingssystemen naast elkaar, zelfs op dezelfde SSD te hebben. Met Windows en Linux lukt mij dit vrij goed. Zo "rare" zou dit niet moeten zijn als je dezelfde partities hebt als in de whole disk install. Er wordt dan een UEFI bootloader toegevoegd voor elk besturingsysteem, zo ook OPNsense, aan de EFI system partition (ESP), en in het NVRAM van het moederbord wordt dan een entry toegevoegd voor deze bootloader. Op Linux, en ik verwacht ook de BSDs, kunnen deze NVRAM boot entries bewerkt worden met de efibootmgr tool.
Soms krijg ik een beetje het idee dat, vooral oudere IT'ers, nogal hardnekkig vast willen blijven houden aan legacy MBR/BIOS/CSM booten en niks willen weten van UEFI booten terwijl het juist een hoop problemen oplost.
Haha, zo’n oude IT-er ben ik. Mijn eerste Linux installatie was met Arch en om de base te compilen moest je eerst een kernel bouwen en deze handmatig op een externe schijf plaatsen (handmatig gepartitioneerd natuurlijk). Daarna 2 dagen de rest compilen op de doelmachie.

Maar ik ben het helemaal met je eens hoor. Ze mogen wel sneller meegaan met moderne technieken. Maar neem wel in beschouwing dat veel werk vrijwillig is. Niet een excuus voor opnsense trouwens.
Het enige wat ik nog mis is een cli waarbij ik hem configureren via ssh /ansible

Op dit item kan niet meer gereageerd worden.