Software-update: OPNsense 20.7.8

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 20.7.8 uitgebracht met de volgende aankondiging:

OPNsense 20.7.8 released

The particular volume of this stable update foreshadows the end of the 20.7 series in less than two weeks.One longstanding issue with radvd on FreeBSD 12.1 has been resolved according to multiple user feedback. The mailing lists have been archived and will no longer be used. And before there are questions: yes, consumers of the development version are now able to upgrade to 21.1-RC1.

Here are the full patch notes:
  • system: allow to recover from bad TLS certificate and/or bad settings in console interface assign
  • system: display destination port number in firewall log widget
  • system: keep compatible TLS 1 defaults for web GUI on 20.7 series
  • system: set default certificate lifetime to 397 days
  • firewall: add type 128 to outgoing IPv6 RFC4890 requirements
  • firewall: add manual refresh button to live log
  • firewall: fix typo in ICMPv6 validation
  • firewall: fix minor regression in maintaining target alias file
  • firewall: fix all state value in pfTop
  • firewall: remove duplicated destination field in live log
  • firewall: add readonly actions to aliases permission
  • firewall: category selector missing caption
  • reporting: add top talkers to revamped traffic graph page
  • reporting: fix name resolution filter change in insight
  • reporting: persist interface selection on traffic graph page
  • captive portal: disable faulty TLS on HTTP since lighttpd 1.4.56
  • dhcp: fix sorting of IPv6 static mappings
  • dhcp: fix incorrect parsing of DUID
  • firmware: opnsense-code now updates the current directory if nothing was specified
  • firmware: opnsense-code now uses flexible make.conf target from tools.git
  • firmware: opnsense-update now supports snapshot access via -z option
  • firmware: opnsense-update now fixes missing dependencies on the fly
  • firmware: fix some issues with missing repository on server
  • firmware: add version output and date to audit logs
  • ipsec: display remote host in status overview
  • opendns: add standalone mode
  • openssh: honour MAX_LISTEN_SOCKS
  • openvpn: set default certificate lifetime to 397 days in wizard
  • unbound: generate all configuration files in service controller
  • unbound: fix broken lines in large files
  • web proxy: lock ACL download to prevent duplicate execution
  • mvc: allow underscore in filter string
  • plugins: os-haproxy 2.26
  • plugins: os-hw-probe 1.0
  • plugins: os-maltrail fixes sensor start without server
  • plugins: os-nginx 1.20
  • plugins: os-tinc fixes for latest version
  • src: fix OpenSSL NULL pointer de-reference
  • src: fix partial scrub of multicast packages
  • src: free full mbuf chains in iflib when draining transmit queues
  • src: initialize oifp to avoid bogus results/panics in edge cases
  • src: 10Gigabit Ethernet driver for AMD SoC
  • ports: libressl 3.2.3
  • ports: nss 3.60.1
  • ports: php 7.3.26
  • ports: pkg fix for shell keyword by opening root file descriptor
  • ports: radvd 2.19
  • ports: sudo 1.9.5p1

OPNsense

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

Door Bart van Klaveren

Downloads en Best Buy Guide

20-01-2021 • 13:29

54

Submitter: terradrone

Bron: OPNsense

Update-historie

Reacties (54)

54
54
39
3
0
11
Wijzig sortering
Ik ben wel benieuwd naar de pros en cons t.a.v. pfsense.
Online natuurlijk veel over te vinden maar ben benieuwd naar ervaringen op tweakers.

Ik draai pfsense nu geruime tijd in active-passive op hypervisors met intel quad nic passthrough; erg tevreden mee.
Alleen het gebrek aan moderne api zit me tegen. Het product heeft de tand des tijds eigenlijk niet doorstaan. Dat lijkt zo op het eerste gezicht bij OPNSense anders te zijn.

Het lijkt een beetje op de Nas4free vs Freenas discussie ;)

[Reactie gewijzigd door ctrl-tab op 24 juli 2024 02:44]

Ik copy/paste mijn post van een jaar terug nog eens. Nog steeds volledig valide.

Je kunt in opnSense geen descriptions per entry in een alias meer zetten. Wel in de alias zelf, maar niet per entry daarin. Voorheen ging dat wel, ik en anderen hebben er overigens ook een discussie over gehad maar de heren waren niet voor rede vatbaar in deze.
We hadden op het moment dat 18.7 uitkwam (vanaf wanneer de descriptions eruit gingen) een dubbele setup draaien van pfSense en OPNSense. pfSense team had wat rare uitlatingen gedaan, OPNSense team trouwens niet minder. Ik weet niet wat nu de status is, maar ze gunden elkaar het licht niet in de ogen. Hoe dan ook, we wilden OPNSense doen en daar ook voor gaan betalen, maar door deze change is het bij pfSense gebleven.

Voorbeeld:
Alias 'Customer IP's for IMAPS access"
a.a.a.a <klantnaam A external IP>
b.b.b.b <klantnaam B external IP>
c.c.c.c <klantnaam C external IP>
d.d.d.d <klantnaam D external IP>
enz.

Sommige IP's hebben geen reverse DNS, en zo wel is het vaak <iets>.static.kpn.nl of <iets>.ziggozakelijk.nl. Daaraan kan ik niet zien voor welke klant het is. In het verleden in OPNSense, en in het heden nog steeds in pfSense, kan je zoals hier bovenstaand voor elke individuele entry in een alias een description opgeven. Sinds OPNSense 18.7 dus niet meer. Ze stellen 'als een entry de moeite waard is moet je er maar een eigen alias voor aanmaken en die nesten'. M.a.w. in plaats van zoals hierboven, had ik 4 aliassen aan moeten maken, met een description, en die weer nesten in de 'hoofd' alias. Als je dan de aliassen genest hebt, zie je in de 'hoofd'alias nog steeds alleen maar de naam van de geneste aliassen, en niet de description. De naam is weer heel beperkt, mag een hoop tekens niet bevatten. Dubbelklikken oid op een geneste alias is niet mogelijk. Een mouse-over kennen ze ook niet, dus er is geen mogelijkheid de daadwerkelijke description van een geneste alias te zien behalve handmatig naar die alias te browsen.
Erg omslachtig en veel meer complexiteit. Ik heb toen een script gemaakt wat de bestaande aliassen uit elkaar trok, en er geneste entries van maakte zoals ze het bij OPNSense graag hadden. De alias tabel werd daarmee ruim 4x zo groot, en dan zijn wij maar een klein clubje. Met duizenden aliassen lijkt me dat niet goed voor de performance, laat staan voor de complexiteit bij troubleshooten.

Verder had OPNSense (destijds in elk geval) geen seperator lines in de firewall rules. Dat maakte het een grote lange brij aan rules, waar je bij pfSense een gekleurde seperator lijn kunen plaatsen met een tekst erin, waardoor je gemakkelijk bv klanten, servers, subnetten oid kunt 'scheiden' op die manier.

Een kleine andere feature die we missen in OPNSense is het dubbelklikken op een rule of alias om hem te editten. Dat maakt het in pfSense weer een stuk sneller om wijzigingen te doen.

Dit maakt de GUI van pfSense in onze ogen wel degelijk wat vriendelijker, ondanks dat die er ouderwetser uitziet.

Voor de rest denk ik dat het beetje lood om oud ijzer is, zowel OPNSense als pfSense hebben hun pluspunten. Voor wat betreft de uiteindelijke werking hebben we totaal geen voorkeur, beide firewalls doen (voor ons) precies wat ze moeten doen.
Een kleine andere feature die we missen in OPNSense is het dubbelklikken op een rule of alias om hem te editten. Dat maakt het in pfSense weer een stuk sneller om wijzigingen te doen.
Tegewoordig (ik weet niet sinds welke versie) zit dat in OPNsense. Er komt een icoontje naast een alias in de rules en dan ga je naar de edit van de alias als je erop klikt.
Ik heb zojuist mn 20.7 VM die ik nog wel heb om van tijd tot tijd eens te kijken laten updaten naar de huidige 20.7.8 versie. Maar nee, nog steeds werkt het totaal niet intuitief, er is ook niks veranderd tov vorige versies. Als ik een alias open waarin geneste aliassen zitten, zie ik alleen de titel van die geneste alias. Maar geen manier om te zien wat daar dan in zit, of die te openen. Voorbeeld:
https://i.ibb.co/p2KNnQ3/Clipboard01.png

Je ziet daar drie aliassen genest zitten in een alias. Als ik nu wil zien wat er 'in' alias tweakers.net zit heb ik geen enkele optie dan terug naar het hoofdscherm van de aliassen, en met de hand de tweakers.net alias openen. En zitten daar weer geneste aliassen in zelfde verhaal. Bovendien zie ik niet in waarom ze langs elkaar moeten staan, met allemaal verschillende breedtes aan vakjes. Dat maakt het erg onoverzichtelijk als je 40 entries of zo erin hebt zitten. Een lijst is dan veel overzichtelijker.

Ontzettend onhandig en onpraktisch in gebruik. Hij ziet er mooier uit, maar de GUI van opnSense kost ons in tijd en frustratie ZOveel meer ellende dan die van pfSense...

[Reactie gewijzigd door Rataplan_ op 24 juli 2024 02:44]

Ah ja, dat bedoel je. In andere aliassen. Klopt. Dat zou anders moeten kunnen. In Firewall rules zijn aliassen wel aanklikbaar om te editten, maar dat bedoelde je dus niet.

Ik vind, afgezien van een paar van dit soort dingen, OPNsense fijner werken dan pfSense. Ik heb een redelijk simpel netwerk met 2 VLANS en een paar dozijn firewall rules en 80 aliassen en er draait een WireGuard (server) op (veel simpeler dan OpenVPN).
Een con van opnSense is dat pfSense met 1 nic genoegen neemt, terwijl opnSense er minimaal 2 wil.
Voor mij een reden dat ik overstappen nog niet heb geprobeerd.
opnSense werkt prima met slechts 1 NIC. Draai het al jaren i.c.m. Proxmox.
Goede opmerking!

Mijn ervaring is dat ik de setup niet kon afronden met 1 (virtuele) nic. Ik moest een LAN en WAN interface hebben. Even gezocht en blijkbaar was ik niet de enige met dat probleem, maar was het toch mogelijk..
https://github.com/opnsense/core/issues/1139
ik had pfsense zo zelf een lange tijd met WAN via USB NIC draaien (de bekende tp link adapter) en dat werkte prima. is een beetje contra-intuitief om dat via usb te doen maar geen problemen gehad.

Nu via 2e hands intel quad NIC , kosten geen drol op e-bay!
Ondertussen alweer een hele tijd een dual-port intel gb nic bijgeplaatst. Nog geen 16 eu op Ali.
Een usb-nic werkte op zich ook, maar hield zijn hardware-id niet vast. Daardoor verloor die usb-nic om de haverklap zijn connectie.

[Reactie gewijzigd door JaDatIsPeter op 24 juli 2024 02:44]

Zou ik dit kunnen gebruiken met een nuc met een extra netwerk poort via usb ?
Of met een Odroid H2+.
"Of met een Odroid H2+. "
Realtek nics..... :|

[Reactie gewijzigd door EverLast2002 op 24 juli 2024 02:44]

Er is niets mis met Realteck NICs. Ooit, jaren geleden, was er een probleem met pfSense omdat de nieuwste driver niet meeleverde. Die problemen zijn allang opgelost en het werkt nu betrouwbaar en probleemloos.

Het blijft lastig oude vooroordelen de wereld uit te krijgen, helaas.
Kun je dit ook met Realtek nics doen? :

https://teklager.se/en/kn...performance-optimization/

Los hiervan en een ander voorbeeld, VMware heeft mij ook extra werk bezorgd omdat ze geen Realtek nics ondersteunden.
Ik blijf bij Intel.
Is mij niet helemaal duidelijk wat in jouw geval "dit" is.

Ik gebruik pfSense in een VirtualBox guest. Dan is een usb-nic geen probleem. Voor opnSense ook niet overigens :-)

Direct op een host (jouw nuc)? Ik vermoed dat het dan afhangt of pfSense/opnSense (BSD) driver/module voor jouw usb-nic (chipset) ingebouwd heeft.
Als je een router wil bouwen met slechts 1 nic dan kun je dat doen in combinatie met een kleine managed switch en je maakt gewoon 2 vlans , 1 voor de lan en 1 voor de wan , dat lijkt mij een betere oplossing dan een usb nic te gebruiken
Kan ook op een NUC met 1 netwerkpoort en een VLAN.
Security technisch snap ik wel dat een tweede NIC verplicht is. Wat kost een tweede NIC tegenwoordig nog al dan niet via pci

Ik zou een firewall nooit via 1 nic willen laten lopen altijd gescheiden. Een in en een out.
Mwah.. Je kunt een heleboel met VLANs.

En voor je begint over beveiliging: Ja, je moet er verstand van hebben anders kan het flink verkeerd gaan.
Maar het kan zeker wel veilig. Kijk maar naar datacenters, die routeren internet verkeer al decennia via VLANs.
Geen idee hoe het daar zit vaak hebben ze een core router met een aantal Fysieke interfaces naar buiten.

Daarna komt een firewall en een dmz daar achter zit ook een firewall die het verkeer tussen dmz en het overige lan verkeer scheid.

Internet is aangesloten vaak op een fysieke firewall.

Natuurlijk gebruikt een datacenter vlans. Dat is om het interne verkeer te scheiden. Servers op vlan 100 gebruikers op vlan 200. Daar tussen wordt gerouteerd en hangt er een fw tussen de vlans. Waarna diensten via de FW worden uitgepoept zoals 445 voor een smb share van vlan 200 naar een file server of cluster in vlan 100. Binnen middelgrote-grote organisaties hangt er voor het internet ook nog eens een proxy in de lucht die het internet ontsluit.

Maar al het verkeer naar en van het grote boze internet gaat gewoon door zware fysieke firewall Heen

[Reactie gewijzigd door To_Tall op 24 juli 2024 02:44]

Hmm, ik werk bij een ziekenhuis en het internet komt redundant binnen op een switch, vlan publiek internet.
Die switch bevat ook server productie vlans.

Alle routers in dat vlan gaan naar de (fysieke) firewalls, zoals jij inderdaad ook schrijft.
Vervolgens weer naar dezelfde switch, maar dan naar een intern vlan.

Ik slaap er erg rustig van!
Het is mogelijk het is alleen niet aan te bevelen.

Zeker niet een later 2 switch direct aan het internet hangen een er zijn switches met een ingebouwde firewall. Veelal dan al layer3.

Een VLAN is geen security laag. Het is een virtuele laag om logische netwerken te scheiden.

Klantje van me had ook een switch op het netwerk gestoken. Weliswaar om internet naar onder verhuurder uit te porten met een eigen publiek IP adress. Daar achter kwam dan een firewall. Er zijn idd situaties waar switches best gebruikt kunnen worden. Maar liefst gewoon direct in firewall.

Intern verkeer en extern verkeer nooit over dezelfde nic laten lopen. Dat is gewoon vragen om problemen.
Een VLAN is geen security laag. Het is een virtuele laag om logische netwerken te scheiden.
Helemaal correct maar besef dan ook dat het niets anders is dan fysieke scheiding. Het doet niets meer of minder dan dat.

Daarom is het het de defacto standaard in alle datacenter (en bedrijf's) netwerken. Een zaal heeft honderden kasten met meer dan honderden klanten (sommige klanten delen een kast). Er wordt echt geen aparte fysieke internet kabel getrokken naar iedere klant. Die krijgen gewoon een poortje gepatched op een internet VLAN dat de zaal deelt... Dat is ook nog handiger voor klanten met meerdere kasten al vragen die meestal een directe patch aan. En weet je hoe die patch gemaakt wordt? Gewoon even een apart klant VLAN aanmaken.

En daarnaast wordt dit verkeer echt niet door allerlei firewall's gehaald. Klanten betalen voor een zo snel mogelijke internet verbinding en zijn zelf verantwoordelijk voor hun beveiliging. Waarom zou een datacenter provider een dienst aanbieden waar de klant niet voor betaald?

[Reactie gewijzigd door Verwijderd op 24 juli 2024 02:44]

Jeetje misschien ligt het aan mij hoor..
Je haalt van alles door elkaar.

je gaat helemaal voorbij dat ik aangeef dat geen maar dan ook geen enkel DC in de hele wereld. verkeer routeerd intern en extern over dezelfde kabel als die het pand in komt.. omdat er een NIC in de router mist.

[Reactie gewijzigd door To_Tall op 24 juli 2024 02:44]

je gaat helemaal voorbij dat ik aangeef dat geen maar dan ook geen enkel DC in de hele wereld. verkeer routeerd intern en extern over dezelfde kabel als die het pand in komt.. omdat er een NIC in de router mist.
Ik snap echt helemaal niets van deze zin. Het is helemaal niet relevant of hoe je verkeer routeert. Ik zou ook niet zien waarom je verkeer niet over dezelfde kabel zou laten lopen, dat is goed voor latency en als je zaken redundant uitvoert, loop je verder ook geen risico. Er worden helemaal geen NIC's geconfigureerd, alles wordt gewoon gerouteerd op de switch (L3). Niemand gebruikt netwerk kaarten, dat is helemaal geen doen in een datacenter. Alles gebeurd via VLANs....

Voorbeeld dat je misschien snapt: Neem glasvezel van KPN. Die komt bij jou binnen op 1 fysieke glasvezel verbinding. Zij leggen geen 3 kabels aan, 1 kabel met 2 VLANs:
https://www.kpn.com/servi...nstellen-en-gebruiken.htm
Wij leveren 3 diensten over de glasvezel- en koperverbinding.
Internettoegang
TV (IPTV)
Telefonie
Voor deze diensten gebruiken we virtuele netwerken, ofwel VLAN's. Je modem splitst deze VLAN's en kent de bandbreedte toe: eerst telefonie daarna IPTV en daarna internet.

VLAN 4 handelt het televisiesignaal af. VLAN 6 zorgt voor internettoegang en telefonie (VoIP
).

[Reactie gewijzigd door Verwijderd op 24 juli 2024 02:44]

LoL.. Je snapt het nog niet :+

KPN zit op de backbone. voor jij op het internet zit.. Ga je door je eigen router. door de FW van KPN naar de router van KPN het internet op.

Voor jou en mij is het verkeer van KPN extern..
Verkeer gaat eerst je modem in, dan door de router en FW.. dan pas naar je aparatuur..

Daarnaast kan je op het internet niet met VLANS werken, dat is allemaal intern KPN verkeer.

Deze hele discussie gaat DEFACTO.. over dat het niet handig is om EXTERN verkeer dus verkeer voor je eigen lan.. Niet over dezelfde kabel te laten lopen als het INTERNE verkeer wat jij wel geneerd.. Niet hoe DC's werken en ISP's....

Per DEFACTO is het een NO GO om dit verkeer over een zelfde switch al dan niet middels VLANS te scheiden. Dat zou betekenen dat je vanaf het Internet dus EXTERN de switch zou kunnen bedienen.. Dat is gewoon niet handig en onveilig.
Afijn, Als jij denkt dat het zo allemaal in elkaar zit. Denk ik dat je nog eens een rondleiding moet vragen in een DC en eventueel eens met een security expert gaan praten 1 op 1. Dan leer je dat VLANS niet veilig zijn. Grotse risico is VLAN HOPPING..

Zeker als je je switch direct aan het internet hangt en alle hackers directe toegang hebben tot je switch..
Geen FW die hem beschermd, alleen de security laag van de switch.

Want dat gebeurd als je router maar 1 nic heeft.. dan moet je de switch aan het internet hangen na de modem.
Ik snap het prima maar jij zit vast in een rare wereld waar ze fysieke kabels leggen om scheidingen te maken tussen internet en ander verkeer. Dat doet echt helemaal niemand. Niet in datacenter, niet bij bedrijven en zelfs niet bij mensen thuis (zie KPN). Ik zag dit 'idee' van fysiek scheiden misschien enkel tien jaar terug toen telefoonboeren het ook niet snapten wat een VLAN is. Dan plaatsen ze aparte switches voor telefonie. Dat is een indicatie dat ze er niet veel van begrijpen.

Ik geef als voorbeeld datacenters omdat ik je probeer in te laten zien dat het simpelweg onmogelijk is om zoveel kabels aan te leggen. Het idee van fysiek scheiden bestaat helemaal niet meer. Letterlijk alles gaat tegenwoordig virtueel, ook de netwerkomgeving. Het hele netwerk was trouwens de eerste om volledig virtueel te gaan. Je weet wel, met VLANs.

Deze hele discussie gaat DEFACTO.. over dat het niet handig is om EXTERN verkeer dus verkeer voor je eigen lan.. Niet over dezelfde kabel te laten lopen als het INTERNE verkeer wat jij wel geneerd..
Geen idee waarom je dat denkt. Ook raar, die DEFACTO... Wie denk je dat je bent? De DEFACTO wereldwijde expert op dit gebied? Je kunt wel capslock gebruiken maar dat maakt het nog niet dat je gelijk hebt.

Dat zou betekenen dat je vanaf het Internet dus EXTERN de switch zou kunnen bedienen.. Dat is gewoon niet handig en onveilig.
Waarom zou je in vredesnaam extern de switch kunnen bedienen? Je snapt volgens mij niet eens wat een VLAN is. Een VLAN zegt niets over management. Je management poort stop je altijd in een apart management VLAN. Dat is basic beveiliging.

Afijn, Als jij denkt dat het zo allemaal in elkaar zit. Denk ik dat je nog eens een rondleiding moet vragen in een DC en eventueel eens met een security expert gaan praten 1 op 1. Dan leer je dat VLANS niet veilig zijn. Grotse risico is VLAN HOPPING..
Ik heb diverse grote netwerk omgevingen ontworpen en bij twee datacenter providers gewerkt. Mijn laatste functie was het beheer van een volledig virtuele klanten omgeving op basis van NSX. Ik heb tijdens die functie nog nooit een fysieke kabel gezien.
Volgens mij ben je heel erg oud want VLAN hopping is al decenia geen probleem meer. Zie ook:
https://en.wikipedia.org/wiki/VLAN_hopping
There are two primary methods of VLAN hopping: switch spoofing and double tagging. Both attack vectors can be mitigated with proper switch port configuration.

Dus, voordelen om het wel alles in VLANs te stoppen: Je bespaart kosten door minder switchpoorten, minder NICs, minder overhead, betere utilisatie van beschikbare bandbreedte.
Nadelen: geen

Ik heb echt geen idee waarom je denkt dat dit niet veilig zou zijn.
Alle virtualisatie hosts hebben tegenwoordig gewoon een tweetal 10/100 Gbit aansluitingen en daar loopt al het verkeer overheen. Waarom zou je in vredesnaam aparte kabels aansluiten voor internet verkeer, dat is letterlijk overbodig en creëert alleen de illusie van veiligheid. Het is immers niets anders dan je het met VLANs afscheid.

Beantwoord mij de volgende vraag: Als ik nu een private cloud omgeving aanmaak (waar dan ook: Azure, AWS, GCP) dan krijg je VM's met een publieke aansluiting. Daarnaast klik je met een seconde er diverse VLANs bij aan. Denk je echt dat die hosts allemaal aparte kabels hebben voor internet / niet-internet verkeer? Denk je dat producten als VMware NSX helemaal niet bestaan?

Zeker als je je switch direct aan het internet hangt en alle hackers directe toegang hebben tot je switch.. Geen FW die hem beschermd, alleen de security laag van de switch.
Nope, je snapt er niets van. Een switch aan het internet hangen hoeft helemaal geen probleem te zijn tenzij je inderdaad er geen verstand van hebt. Je kunt gewoon een VLAN aanmaken, poorten configureren als access en daar geen L3 of management interface op zetten. Hiermee creer je simpelweg een unmanaged switch. Niemand die dan bij je andere verkeer kan komen.

Ik zou je aanraden om eens een Cisco cursus te doen. De eerste lessen bevat Router-on-a-stick:
https://en.wikipedia.org/wiki/Router_on_a_stick
Wanneer je dat begrijpt kun je verder met Firewall-on-a-stick.....
Dat is al zo oud als de weg naar Rome.
Ongeveer 75 euro voor een PCI Intel NIC met 4 RJ45 aansluitingen daarop. Met zo'n netwerk kaart kun je meerdere ISPs diensten op je adres af laten leveren en deze gaan "bonden" of automatisch schakelen tussen ISPs wanneer de ene om wat voor reden dan ook uitvalt (of onvoldoende presteert).

Een standaar PCI netwerk kaartje van Realtek kost je zo'n 8 tot 10 euro. Dan heb ik het over NICs die max 1 GBit/sec aan traffic kunnen verwerken. Deze zijn (ruimschoots) voldoende voor het gros van verbindingen in NL.Of waar dan ook ter wereld.

Het hebben van meerdere NICs geeft je nog veel meer mogelijkheden met VLANs.

Zet je dit echter af tegen de extra kosten van een managed switch, dan is een extra NIC al gauw (flink wat) goedkoper. En aangezien je nu al je routing, firewalling, DHCP, DNS, monitoring, VLANs etc in 1 centrale plek kunt afhandelen, denk ik dat je nog veel meer bespaart.

Kortom, je zult mijn OPNsense router toch echt moeten loswrikken van mijn doodsgrip.
ppst... kijk even op e-bay, zoek naar HP NC364T

pro-avit.london, daar heb ik vorige maand 4 kaartjes gekocht voor 11.50 GBP per stuk :)
pfSense is bij mij begonnen als OpenVPN en IKEv2 road-warrior oplossing. Vanaf modem/router port forwarden naar pfSense en overal veilig (via) thuis werken. Had ik geen 2 NICs voor nodig.
Voor mij was de reden van de overstap dat Opnsense meer ondersteuning heeft voor nieuwe technologieën, bijvoorbeeld Wireguard en Zerotier. Dit zijn zaken die nog steeds niet in Pfsense zitten, waarvan Wireguard toch eigenlijk wel een must is.
Deze vraag komt eigenlijk met elke release weer terug :). Als je snel antwoord wilt, kan je het beste door de opmerkingen van de vorige releases bladeren: daar staat echt een schat aan informatie!
Ik heb thuis ook een paar weken OPNsense gedraait en getest. Ook omdat op het werk veel pfSense gebruikt wordt en we ons ook twijfels hebben over de toekomst van pfSense.

Wat voor mij redelijke dealbreakers waren (jaar geleden):
- Geen descirption veld in de entries die je aan een alias toevoegd.
- Niet mogelijk om een config.xml te restoren vanaf een USB stick bij boot
- en de 3e die ik eerder niet kon verzinnen: Geen seperator lines tussen je firewall rules (thanks @Rataplan_)

2e punt kan ik nog wel mee leven / omheen werken, maar het eerste punt niet, en 3e eigenlijk ook niet. Verder vind ik het wel een mooi product, en zijn er zeker ook een hoop zaken die wel (veel) beter werken (live firewall logging bijvoorbeeld).

Het zou mooi zijn als ze een config conversie tool bouwen voor een makkelijke migratie van pfSense naar OPNsense :)

[Reactie gewijzigd door SuperPietje op 24 juli 2024 02:44]

Het belangrijkste verschil is denk ik dat je OPNSense commercieel mag distribueren en PFSense niet.

Persoonlijk ga ik altijd voor de meer open variant. Zeker als ze beide hetzelfde kunnen. Beetje hetzelfde als owncloud en nextcloud.
Ik denk dat het grootste verschil is, dat PFSense ontwikkeling eigenlijk stil staat, terwijl OPNSense ieder 1/2 jaar. PFSense heeft wel meer plugin mogelijkheden.

Ik heb al mijn pfsense firewalls vorig jaar eigenlijk allemaal overgezet naar OPNSense.
Al mis ik nog wel de mogelijkheid om goede groepering van de firewall rules.
OpnSense is wat moderner, heeft een vaste release cadence, gaat sneller mee met upstream (en upstreamt zelf ook changes), heeft een API. Maar belangrijkste: heeft een community die nog normaal is. Bij pfSense is het al lang geen open source firewall meer en is het een beetje een verziekt commercieel gebeuren. Tenzij je het over betaalde diensten van netgate wil hebben is de communicatie en samenwerking beperkt tot plaatjes van de interface en schreeuwerige teksten dat er echt heus wel heel veel copyright op rust en dat het totaal verboten is als je het ooit ergens commercieel terugziet.
Kun je dit samen met OpenWRT draaien op een router?
Nee? Hoe had je dat überhaupt in gedachten dat het naast elkaar zou kunnen draaien?
Daarbij, OPNsese draait op HardenedBSD (security fork van FreeBSD) terwijl OpenWRT op GNU/Linux basis is.
Dat wist ik niet, maar bedankt voor de antwoorden. Ik dacht dat OpenWRT puur een andere firmware voor de router was en dat OPNsense dan wellicht als firewall kon dienen. Ik kon er al niets over vinden dus dacht vraag het hier eens.
het op een simpel routerkastje draaien is inderdaad niet mogelijk. Uiteraard zou je wel beide in een virtuele omgeving naast elkaar kunnen laten draaien. Openwrt in een vm en Opnsense in een vm. Daartussen zou je prima verschillende netwerk mogelijkheden uit kunnen testen. beide tegelijkertijd aan het internet hangen is inderdaad een beetje contraproductief. tenzij je meerdere publieke IP adressen hebt en deze netwerk technisch compleet van elkaar wil scheiden.

beide hebben echter wel een ander publiek. openwrt is leuk voor de thuis hobbyist die z'n thuis routertje wat meer functionaliteit wil geven.
opnsense en pfsense zijn voor wat geavanceerdere gebruikers en in sommige gevallen bedrijven.
Beiden zijn firewall/router/en meer.
OpenWRT zal meer firmware zijn dan OPNsense die je meestal installeert ergens op.
waarom zou je dat uberhaupt willen? het ingewikkeld maken terwijl 1 appliance normaal gesproken voldoende moet zijn.
Nee. Andersom kan wel. OpenWRT op x86.
"Kun je dit samen met OpenWRT draaien op een router? "
- ik snap deze vraag wel. Er staat "pakket" in het intro en als besturingssytemen Linux, BSD.
Maar het antwoord is dus nee zoals al is gezegd. OPNsense is een complete router/firewall oplossing met daarbij diverse plug-ins.
Grote nadeel van OPNsense is dat je geen VLAN aan een bridge kunt koppelen. Het algemene antwoord vanuit de community is: gebruik een externe switch voor je WAN poort.
Dus voor de ISP providers hier in NL die met VLAN's hun (meerdere) IPTV ontvangers ontkoppelen: gaat niet werken met deze software router.
Kan wel met Linux en RouterOS; maar met OPNsense; jammer maar helaas.
Je bedoeld hier bijvoorbeeld T-Mobile mee?
WAN INTERNET VLAN300
WAN TV VLAN640 > transparant naar een poortje waar een STB aan hangt.

Terwijl KPN wel zou moeten werken
PPPoE sessie over VLAN 6
IPTV interface over VLAN 4
Ja. Pure VLAN scheiding, Hoe kijg je VLAN640 gebridged met meerdere IPTV ontvangers als je geen VLAN aan een bridge kunt koppelen?
Het enige wat ik nog wel mis een volledig opensource centraal management systeem of configureren via de cli.

Voor de rest top product :)
Gisteren nog opnsense en pfSense geprobeerd.
Ik krijg het niet voor elkaar om een ziggo WAN in bridge modus via de USB 3.0 1gb-nic op volledige snelheid te laten draaien.

ik heb 500/40, krijg via speedtest 40/40 terug.

Moeten deze installaties nog van extra drivers worden voorzien?
Dat klopt wel. Met USB nic's kun je geen volledige snelheid halen, blijkbaar niet het type USB nic dat je hebt.

Op wat voor hardware draai je pfsense?

Op dit item kan niet meer gereageerd worden.