Topics

I upgraded from 24.1.3_1 to 24.1.4 and found that on all of my machines, I needed to upgrade twice.

There was an error message during the first update and the upgrade did not catch all upgradeable packages:

pkg-static: Fail to rename /usr/local/etc/rc.d/.pkgtemp.squid.ddRLvpFwCL9y -> /usr/local/etc/rc.d/squid:No such file or directory

On the second try after that, those packages were only then upgraded:

Code Select Expand


cpu-microcode-intel 20231114 20240312 upgrade OPNsense
ruby31-gems 3.4.20 3.5.6 upgrade OPNsense
squid 6.7 6.8 upgrade OPNsense
squid-langpack 7.0.0.20231227 7.0.0.20240307 upgrade OPNsense


[Ein paar Grundlagen, die man haben sollte]

In letzter Zeit habe ich im OpnSense-Forum immer wieder Fragen auftauchen sehen, die weniger OpnSense speziell, sondern eher Basis-Netzwerkwissen tangierten. Die Fragen waren immer wieder dieselben, oft motiviert von irrigen Annahmen und Missverständnissen, wenn jemand versucht, von einer vollintegrierten Lösung wie einer Fritzbox auf eine anspruchsvollere Lösung wie OpnSense umzusteigen.

Dieser Artikel ist nicht herablassend gemeint, sondern soll vorab klarmachen, worauf man sich dabei einlässt.

Achtung: der Artikel ist lang - wie gewohnt von mir...


Ein paar Grundlagen, die man haben sollte

Zunächst müssen wir uns klarmachen, was das Ziel eines Einsatzes von OpnSense ist: Normalerweise wollen wir unser eigenes Netzwerk (Local Area Network = LAN) mit dem Internet verbinden. Wir beschränken uns zunächst auf das dazu meist verwendete IPv4-Protokoll.

Die IPv4-Adressen von Systemen im Internet bestehen aus 4 Zahlen von 0-255, durch Punkte getrennt, z. B. 1.2.3.4. Damit ist ein bestimmtes System im Internet eindeutig bestimmt. Dar diese Adressraum auf insgesamt ca. 4 Milliarden (=2^32) Addressen beschränkt ist, stehen inzwischen nicht mehr genug IPv4-Adressen zur Verfügung. Insbesondere kann nicht jedes Gerät in unserem LAN eine eigene, öffentlich erreichbare IPv4 erhalten.

Für diese lokalen Adressen wurde deswegen ein eigener, privater Adressraum geschaffen, der im RFC1918 beschrieben ist und diese Bereiche umfasst:

Code Select Expand

10.0.0.0        -   10.255.255.255  (10/8 Präfix)
172.16.0.0      -   172.31.255.255  (172.16/12 Präfix)
192.168.0.0     -   192.168.255.255 (192.168/16 Präfix)

Damit der Zugriff auf ,,öffentliche" Adressen von diesen privaten IPs aus ermöglicht wird, benötigt man einen Router, der in der Lage ist, verschiedene Netzwerkbereiche miteinander zu verbinden. Zum einen hat ein solcher Router mindestens zwei Anschlüsse für verschiedene Netzwerke (beispielsweise 192.168.1.1/24 und 192.168.2.1/24). Dabei hat er im ersten Netz selbst die Adresse 192.168.1.1 und kann somit direkt mit allen anderen Geräten in diesem Netzwerk sprechen (192.168.1.2-255), im zweiten Netzwerk hat er die IP 192.168.2.1 und kann dort mit allen anderen Geräten sprechen. Er weiß auch, dass er Pakete, deren Quell-Adresse im ersten Netzwerk und deren Ziel-Adressen im zweiten Netzwerk liegen, weiterleiten soll (und umgekehrt). Übernimmt dieser Router nebenbei auch noch die Aufgaben einer Firewall, kann er diese Pakete nach bestimmten Regeln auch ausfiltern oder modifizieren.

Innerhalb jedes Netzwerks können sich die Geräte gegenseitig erreichen, weil sie sich per Address Resolution Protocol (ARP) finden können - sie erfahren ihre jeweiligen Kommunikationspartner per Broadcast, also Rundruf. Ein Rundruf wird aber nicht über die Grenzen eines lokalen Netzwerks hinaus gesendet.
Damit die Pakete über den Router geleitet werden, müssen die Geräte im ersten Netzwerk deswegen eine Route kennenlernen, die ihnen vorgibt, dass Pakete für das zweite Netzwerk an den Router mit der IP 192.168.1.1 in ihrem eigenen Netzwerk geschickt werden sollen, denn diese IP können sie ja direkt erreichen.

Diese Route würde also lauten:

Versende 192.168.2.0/24 (d. h. 192.168.2.0-255) über 192.168.1.1

Es gibt auch eine vereinfachte Form, eine sogenannte Standard- oder Default-Route dieser Form:

Versende 0.0.0.0/0 (also: ,,alles andere") über 192.168.1.1

Damit würden alle Pakete über den Router mit der IP 192.168.1.1 geleitet, also zunächst an diesen adressiert.
Nun könnte man erwarten, dass ein solcher Router einfach mit dem Internet verbunden werden muss und an diesem Anschluss keine RFC1918-IP, sondern eine öffentliche IP (z. B. 1.2.3.4) erhält, damit alle Geräte im LAN jedes Ziel im Internet erreichen können. Es ist aber so, dass Adressen aus unserem LAN, die dem RFC1918-Adressraum entstammen, also z. B. die IP 192.168.1.88, im Internet nicht weitergeleitet werden. Man bedenke: Dieselbe IP könnte potentiell von sehr vielen Geräten in den verschiedensten LANs auf der ganzen Welt genutzt werden, sie ist somit nicht eindeutig.

Aus diesem Grund muss ein mit dem Internet verbundener Router normalerweise eine Übersetzung dieser privaten LAN-Adressen vornehmen (Network Address Translation = NAT). Dabei schreibt er die privaten RFC1918-Quelladressen aus dem LAN auf seine eigene öffentliche IP-Adresse um – diese eine IPv4 wird ja korrekt weiter geroutet, da sie weltweit eindeutig ist.

Wenn die Antwort-Datenpakete zurückkommen, hat sich der Router diese Verbindung gemerkt und schreibt die Zieladresse von seiner öffentlichen IP wieder auf die RFC1918-IP des Zielgeräts im privaten LAN um.

Das geht mit einer Einschränkung einher: Um die Zuordnung von Datenpaketen von außen nach innen machen zu können, muss zunächst eine Verbindung von innen nach außen geöffnet worden sein. Es ist also nicht möglich, von außen eine Verbindung zu einem Gerät im LAN zu initiieren.

Diese Form von NAT wird deshalb oft als ,,Outbound NAT" oder SNAT (für Source NAT) bezeichnet.

Um einen umgekehrten Verbindungsaufbau von außen nach innen zu ermöglichen, muss im Router eine sogenannte Port-Weiterleitung eingerichtet werden, durch die Datenpakete, die eine bestimmte Port-Nummer (sinngemäß: Anschlussnummer) zum Ziel haben, immer an eine bestimmte private IP im LAN weitergeleitet werden. Dabei wird die öffentliche Ziel-IP des Routers auf die private IP des internen Geräts umgeschrieben, weshalb diese Form als DNAT (Destination NAT) bezeichnet wird.

Damit lässt es sich z. B. erreichen, dass jede Verbindung zur öffentlichen IP 1.2.3.4 des Routers auf der Portnummer 443 (für HTTPS) an ein Gerät im LAN (z. B. 192.168.1.77) weitergeleitet wird.

Alles schon bekannt? Gut, Auffrischung kann nicht schaden.

Wo kommt OpnSense ins Spiel?

Nun, da die Grundlagen gelegt sind, stellen wir uns die Frage, was OpnSense leistet?

OpnSense kann routen und beherrscht SNAT und DNAT. OpnSense kann darüber hinaus auch zur automatischen Adressvergabe per DHCP (Dynamic Host Configuration Protocol) verwendet werden, das die privaten IPs an LAN-Geräte zuweist und diesen Geräten auch sich selbst als Default-Router bekannt macht. Außerdem kann OpnSense auch Namensdienste (Domain Name System = DNS) bereitstellen und sich den LAN-Geräten als DNS-Server bekannt geben.

OpnSense bietet darüber hinaus weitaus mehr Möglichkeiten, Netzwerkverkehr zu regulieren und zu filtern, als das der übliche ,,Baumarkt-Router" oder eine Fritzbox können – deswegen will man sie ja einsetzen.

Zugangstechnik

Was kann OpnSense denn also nicht, bzw: Was fehlt?

Tatsache ist, dass Zugangsanbieter (Internet Service Provider = ISP) heute die verschiedensten Zugangstechniken anbieten, von DSL (Digital Subscriber Line) über Telefonkabel über TV-Kabelanschlüsse bis hin zu Glasfaseranschlüssen. Es gibt auch weitere Techniken, wie LTE (Mobilfunk) oder Satelliten-Internet.

Das bedeutet, dass in der eigenen Wohnung nicht einfach ein Netzwerkkabel liegt, über das der Router eine öffentliche IP bezieht. Das gilt insbesondere für Deutschland, wo ISPs verpflichtet sind, wahlweise einen rein passiven Netzwerkanschluss zur Verfügung zu stellen.

Nehmen wir als Beispiel DSL:

Der ISP betreibt (meist am Ende der Straße) einen sogenannten DSLAM, der hochfrequente Signale in die vorhandenen Telefonkabel einspeist. Diese landen in einer Anschlussdose in der Wohnung. Der erste Schritt der Umwandlung in das gewünschte Ziel-,,Format", nämlich IP-Adressen über Ethernet ist also eine Medienkonvertierung von DSL nach Ethernet. Dies übernimmt ein sogenanntes DSL-Modem (Modulator/Demodulator). Das Ausgangssignal des DSL-Modems ist zwar bereits Ethernet, meist wird hier aber noch kein IP ,,gesprochen". Das liegt daran, dass der ISP eine Zugangskontrolle realisieren will.

Deswegen kommt – zumindest in Deutschland – oft das PPPoE (Point-to-Point Protocol over Ethernet) zum Einsatz, bei dem man Zugangsdaten (Benutzername und Passwort) benötigt, um eine öffentliche IP zu erhalten. In anderen Ländern und bei manchen Providern ist das unnötig und der Router erhält seine IP direkt per DHCP (diesmal aber nicht in der Rolle als Server, sondern als Client) oder wird statisch konfiguriert (z. B. an Business-Anschlüssen).

Oft wird hierbei auch noch ein Trick verwendet, um einerseits über diese Ethernet-Verbindung den Internet-Anschluss, aber gleichzeitig den Zugriff auf das Modem zu erhalten. Letzterer kann interessant sein, um bestimmte Parameter abzurufen, z. B. Spektralanalysen, Leitungslänge und -qualität usw. - ich erkläre gleich, wie man das ermöglicht.

Ethernet kann entweder normale Datenpakete übertragen oder mittels vorgeschalteten Präfixen (sogenannten ,,Tags") logisch getrennte Kanäle bedienen, die sogenannten VLANs (Virtual LANs). Der Anschluss des Modems läuft dann oft ohne Tags (,,untagged VLAN"), die PPPoE-Verbindung wird dagegen über ein VLAN aufgebaut. Die Telekom verwendet z. B. VLAN 7, M-Net VLAN 40, EweTel VLAN 2011,  Willi Tel VLAN 2511, NetCologne VLAN 10 usw.

OpnSense kann natürlich PPPoE, wahlweise auch per VLAN, sprechen, auch DHCP als Client ist möglich – es beinhaltet aber kein DSL-Modem. Für den Betrieb an einem DSL-Anschluss ist also ein externes DSL-Modem notwendig.

Bei Glasfaser-Anschlüssen, die in Deutschland oft mittels GPON-Technologie ausgeführt werden, tritt an die Stelle des DSL-Modems als ,,Brücke" zum Ethernet ein sogenannter ONT (Optical Network Termination). Auch bei Glasfaser- ISPs wird oft PPPoE verwendet und meist auch VLANs, aus den selben Gründen wie bei DSL-Modems. Auch hier lässt sich am ONT der Glasfaser-Status abfragen, zusätzlich sind sogar weitere Zugangsdaten (Seriennummern, PLOAM-Passworte usw.) darin abgelegt bzw. administrierbar.

Somit lautet die Antwort auf ,,Was fehlt bei OpnSense?" einfach: Der Medienkonverter auf das bereitgestellte Zugangsmedium (Glasfaser, DSL, Kabel o. ä).

Randthema: Wie kommt man über die OpnSense an die Web-Oberfläche des ONT bzw. des DSL-Modems?

Dazu muss man zunächst wissen, welche IP-Adresse das Gerät hat. Es ist meist auch eine RFC1918-Adresse wie 192.168.100.1 oder 10.0.0.1. Man konfiguriert dann für die WAN-Netzwerkschnittstelle an der OpnSense eine andere Adresse aus demselben Adressbereich, also z. B. 192.168.100.2 oder 10.0.0.7 und gibt dieser eine Netzmaske (meist /24).
Hinweis: das private LAN muss dann zwingend einen anderen IP-Bereich nutzen, sonst funktioniert das Routing nicht!

Damit ist die Kommunikation zwischen der OpnSense und dem Modem sofort möglich, aus dem privaten LAN heraus lässt sich das Modem aber noch nicht erreichen. Das liegt am Rückwärts-Routing: Das Modem kennt ja die privaten LAN-Adressen nicht, man müsste also erst auf dem Modem eine Route dorthin konfigurieren, damit die Antworten ihren Rückweg finden. Da dies meist nicht möglich ist, nutzt man wiederum NAT: Auf der OpnSense wird also eine ,,Outbound-NAT"-Regel eingerichtet, die den Verkehr mit Quelladressen aus dem LAN (z. B. 192.168.2.0/24) über die konfigurierte IP am Modem-Port der OpnSense (also z. B. 192.168.100.2 oder 10.0.0.7) umschreibt. Diese IP ist für das Modem ja direkt erreichbar, so dass die Antwort-Datenpakete ihren Weg an den Fragesteller im LAN auch ohne explizite Route zurückfinden.

Man beachte: Die IP am nicht-getaggten Modem-Port ist nicht die WAN-IP, die per DHCP oder PPPoE vom ISP über das verwendete VLAN zugewiesen wurde!

Wieso haben so viele Leute Probleme, die OpnSense einzurichten?

Oft genug ist es so, dass ihnen die Mühe, all das oben dargestellte verstehen zu müssen, bislang mit einer vollintegrierten Lösung abgenommen wurde. Viele glauben aber, sie könnten mit Einsatz einer OpnSense ihr Netzwerk ,,irgendwie sicherer machen".

Wenn man z. B. aktuell eine Fritzbox im Einsatz hat, sind die obigen Differenzierungen komplett egal, weil diese sehr viele Details ganz selbstverständlich regelt, denn sie bietet gleichzeitig diese Funktionen:

• DSL-Modem oder ONT oder Kabel-Brücke (je nach Modell)
• PPPoE- oder DHCP-Router mit SNAT und DNAT
• DHCP- und DNS-Server im LAN
• WLAN-Accesspoint
• Switch mit mehreren Anschlüssen
• Gast-Zugang ohne Zugriff auf das interne Netzwerk

Das ist für normale Nutzer ein Segen – wird beim Umstieg auf OpnSense jedoch zum vielschichtigen Problem, weil jeder der sonst enthaltenen Funktionen separat abgedeckt werden muss.

Was sind die Fallen?

Hier in absteigender Reihenfolge nach ,,gefühlter" Häufigkeit die auftretenden Probleme bzw. Irrtümer:

• Man möchte die OpnSense hinter die Fritzbox stellen, um sein Netzwerk abzusichern. Teils, weil man es sich zuerst (scheinbar) einfach machen will, teils, weil der ISP die Endgerätefreiheit mit Füßen tritt oder zumindest absichtlich erschwert und die Fritzbox ,,netterweise" stellt und eventuell selbst fernadministriert. Letzteres ist oft sogar der Grund,  warum man den Einsatz der OpnSense anstrebt.
  
  Das sieht dann ungefähr so aus:
  
  Internet ----> Fritzbox <---- Zwischen-LAN (192.168.178.0/24) ---> OpnSense <--- echtes LAN (192.168.2.0/24) ----> Endgerät(e)
  
  Bei dieser Betriebsart bleibt die Fritzbox zunächst der Eingangsrouter mit NAT zum ,,Zwischen-LAN". Wenn man die OpnSense als Firewall einsetzen will, muss sie dafür zwingend zwei unterschiedliche Netzwerke trennen, eins ist das ,,Zwischen-LAN" der Fritzbox, das andere das dahinterliegende ,,echte" LAN der OpnSense.
  
  Am Rande: Es hat schon Anwender gegeben, die eine OpnSense ausschließlich mit einem LAN-Anschluss konfiguriert hatten und sich wunderten, warum denn die eingestellten Firewall-Regeln nicht griffen? Falls sich noch jemand darüber wundert, lese nochmals den Abschnitt über Grundlagen.
  
  Diese ,,Lösung" bringt folgende Probleme mit sich:
  
  a. Man kann den WLAN-Accesspoint der Fritzbox nicht richtig nutzen, zumindest nicht in dem Sinn, dass man mit der OpnSense Firewall-Regeln für WLAN-Geräte einstellen kann, da die Pakete die OpnSense ja überhaupt nicht passieren, wenn die WLAN-Geräte im Zwischen-LAN (192.168.178.0/24) angesiedelt sind.
  
  b. Da die Fritzbox den Addressbereich des echten LANs (192.168.2.0/24) hinter der OpnSense nicht kennt, würden Pakete auch nicht dorthin geroutet werden. Entweder muss man in der Fritzbox eine Route auf das echte LAN mit der Zwischen-LAN-IP der OpnSense (z. B. 192.168.178.2) als Gateway eintragen oder man verwendet wiederum NAT auf der OpnSense, um das echte LAN hinter der Zwischen-LAN-IP der OpnSense zu verbergen. Diese Konfiguration nennt sich Double-NAT und sollte, wenn möglich, vermieden werden. Will man nämlich dabei Endgeräte im echten LAN für den Zugriff aus dem Internet freigeben, müssen die entsprechenden DNAT-Eintragungen sowohl in der Fritzbox als auch in der OpnSense gemacht werden. In der Praxis funktioniert das meist nicht bzw. scheitert an diversen NAT-Details wie statischen vs. dynamischen Ports usw.
  
  c. Man vergisst auf dem WAN-Interface "block private networks" abzuschalten und bekommt erst gar keine Verbindung zum Fritzbox-LAN.
  
  d. "reply-to" ist per default auf dem WAN an, das funktioniert natürlich nicht. "Firewall: Settings: Advanced", dort "disable reply-to" aktivieren, wenn WAN ein Broadcastnetzwerk (aka Ethernet) ist, wie hinter einer Fritzbox.
  
  
• Man glaubt, die Alternative dazu gefunden zu haben, indem man die Fritzbox nicht ,,vor", sondern ,,hinter" die OpnSense positioniert, etwa so:
  
  Internet ----> OpnSense <----LAN (192.168.2.0/24) --+--> Fritzbox
                                                                                              +--> Endgerät(e)
  
  
  In dieser Konfiguration ist die Fritzbox selbst ein reines LAN-Endgerät ohne Routing-Funktionalität. Man benötigt dann kein Doppel-NAT und die Funktionalität der Fritzbox als WLAN-Accesspoint bleibt erhalten – allerdings mit der Einschränkung, dass in diesem Betriebsmodus kein Gast-(W)LAN möglich ist. Für den Betrieb als VoIP-Telefonanlage müssen entsprechende NAT-Regeln auf der OpnSense eingerichtet werden, um die Fritzbox erreichbar zu machen.
  
  Ein weiteres technisches Detail ist, dass hierbei die (DSL-)Modem-Funktionalität der Fritzbox komplett abgeschaltet wird. Man benötigt also ein anderes Modem oder einen ONT:
  
  Internet ----> Modem/ONT <---- PPPoE oder DHCP ----> OpnSense <----LAN -----> Endgerät
  
  Als Modem bzw. ONT lassen sich Fritzboxen übrigens nur bedingt nutzen, da erstens neuere Fritzboxen den sogenannten ,,Bridge-Modus" nicht mehr anbieten und zweitens dann sämtliche anderen Funktionen (Router/WLAN-AP/Telefonie) ungenutzt bleiben müssen – wenn überhaupt, wäre die Fritzbox also nur ein (sehr teures) Modem.
  
  Merke: Man kann die Fritzbox eben nicht in Einzelkomponenten zerlegen und Teile (z. B. das DSL-Modem) ,,vor" und andere Teile (z. B. den WLAN-Accesspoint) ,,hinter" die OpnSense positionieren.
  
  
• Man glaubt, man könne sich einen Switch sparen, weil die OpnSense ja mehrere LAN-Anschlüsse hat. Prinzipiell richtig, aber:
  
  Obwohl sich mehrere LAN-Ports ,,brücken" lassen, erfordert dies eine recht aufwendige Konfiguration, zudem werden dann Pakete, die von Anschluss zu Anschluss (also im LAN) übertragen werden müssen, auch über die OpnSense vermittelt und weitergeleitet (nicht aber: gefiltert) und belasten damit deren CPU. Meist steht ohnehin nur eine überschaubare Anzahl an Anschlüssen zur Verfügung.
  
  
• Man meint, man könne mit günstiger OpnSense-Hardware auskommen und man könne z. B. Anschlüsse mit niedriger Geschwindigkeit per Anschluss-Aggregation bündeln (Link Aggregation = LAGG). Das funktioniert nicht so, wie man denkt, denn jede konkrete IP-Verbindung zwischen zwei Partnern kann jeweils nur über eine physische Leitung laufen. Link Aggregation hilft also nur rein statistisch, wenn z. B. ein Server viele Clients bedient und unterschiedliche Clients unterschiedliche Anschlüsse nutzen. Nimmt man aber als Beispiel einen Server, der Daten für einem bestimmten PC bereitstellt, wird die Verbindung nicht schneller als 1 Gbit/s, selbst wenn beide Partner jeweils mit 2 Anschlüssen per LAGG an den Switch oder die OpnSense angeschlossen werden.
  
  Was man jedoch sinnvoll tun kann, ist eine Aufteilung von lokalen (V-)LANs auf verschiedene Anschlüsse, weil dann beispielsweise der Netzverkehr vom LAN ins IoT-Netzwerk nicht zweimal (rein und raus) denselben Anschluss nutzen muss.
  
  Grundsätzlich gilt hier: Es gibt inzwischen günstige OpnSense-Hardware, die z. B. 2.5 Gbit/s pro Anschluss unterstützt, entsprechende Switches sind auch bezahlbar und viele PCs haben schon 2.5 Gbit/s onboard.
  
  P.S.: Umgekehrt gilt: Ein ,,router on a stick", d. h. ein Router, der nur eine einzige Netzwerkkarte hat, funktioniert prinzipiell, setzt aber voraus, dass man einen VLAN-fähigen Switch hat, um (mindestens) WAN und LAN zu trennen. Außerdem passiert der Quer-Verkehr denselben physischen Anschluss dann mehrfach, was die Bandbreite entsprechend vermindert.
  
  
• Man meint, ein uralter X86-Router oder ein Billigst-Mini-PC mit Realtek-Netzwerkkarte(n) würde ausreichen oder man könne einen alten ausrangierten PC dazu hernehmen.
  
  Problem Nummer 1: Alte CPUs haben oft nicht die Befehlssatz-Erweiterungen bzw. überhaupt die CPU-Leistung um erweiterte Funktionen wie VPN oder Traffic-Introspektion mit hohen Netzwerkgeschwindigkeiten erfüllen zu können. Leider ist die FreeBSD-Implementierung für PPPoE auch nicht sehr performant, so dass dies eventuell zusätzlich den Durchsatz hemmt.
  
  Problem Nummer 2: FreeBSD als Grundlage für OpnSense unterstützt Realtek-Netzwerkchips nicht besonders gut, es kommt dabei immer wieder zu Kompatibilitätsproblemen. Teilweise funktionieren die proprietären Realtek-Treiber besser, aber wenn immer möglich, sollte man diese Hardware vermeiden.
  
  Problem Nummer 3: Ein Router läuft normalerweise 24/7. Fall es ein Uralt-PC ist, kann der Stromverbrauch schmerzhaft ins Gewicht fallen.
  
  

Fazit

Zusammengefasst lässt sich also festhalten, dass der Einsatz einer OpnSense im Grunde bewirkt, dass:

• Man einen zusätzlichen Medienkonverter (DSL-Modem, Kabel-Modem, Glasfaser-ONT) benötigt. Eine vorhandene Fritzbox ohne "Bridge-Modus" ist hierfür ungeeignet.
  
• Man meistens einen Switch benötigt, damit man nicht die vorhandenen Ethernet-Ports der OpnSense ,,brücken" muss. Dieser Switch sollte vorzugsweise managebar sein und VLANs beherrschen, damit man eine Netztrennung für Gäste oder IoT-Geräte vornehmen kann. Wenn man das nicht braucht: Wozu dann überhaupt eine OpnSense?
  
• Eine vorhandene Fritzbox sich allenfalls noch sinnvoll als Telefonanlage einsetzen lässt, indem sie als LAN-Client konfiguriert wird.
  
• Eine Fritzbox sich nur dann parallel auch als WLAN-AP einsetzen lässt, wenn man auf eine Netztrennung verzichten kann, weil die Fritzbox das nicht unterstützt. Benötigt man diese Netztrennung aber, beispielsweise, weil viele IoT-Clients nur per WLAN anschließbar sind, sind eigentlich auch separate, VLAN-fähige WLAN-Accesspoints (z. B. Unifi) zwingend.
  

Eine komplette ,,Zielkonfiguration" als Ersatz für eine Fritzbox umfasst also:

• Einen (externen) Medienkonverter (d. h. ONT, DSL-Modem, Kabelmodem o. ä.) im Bridge-Modus
  
• Eine OpnSense mit einigermaßen moderner CPU – insbesondere für breitbandige Anschlüsse oder wenn VPN und/oder speziellere Firewall-Funktionen benötigt werden, die Packet-Introspektion erfordern. Ports mit mehr als Gigabit-Geschwindigkeit sind hilfreich.
  
• Einen nachgelagerten Switch, um die CPU der OpnSense nicht durch Bridging zu belasten, vorzugsweise mit VLANs und managebar. Auch hier helfen schnellere Ports, z. B. SFP+ oder 2.5 Gbit/s. Port Security über IEEE 802.1X ist auch interessant, da die OpnSense einen FreeRADIUS-Server enthält.
  
• Ein oder mehrere WLAN-Accesspoints, die mehrere VLANs auf WLANs abbilden können.
  
• Eine VoIP-Telefonanlage (hierfür kann eine Fritzbox genutzt werden).
  

Neben den Kosten für die notwendigen Komponenten muss man antizipieren, dass man sich mit recht komplexer Netzwerktechnologie auseinandersetzen muss, um nicht das Gegenteil von dem zu erreichen, was man durch den Einsatz von OpnSense eigentlich erzielen möchte, nämlich: mehr Sicherheit.

Jeder sollte sich daher die Frage stellen: Brauche ich das wirklich? Bzw.: Kann ich das wirklich? Oder bleibe ich lieber bei einer vorkonfektionierten, integrierten Lösung wie einer Fritzbox?

Abschließend: Ich habe hier bewusst IPv6 ausgespart, was insofern eine vereinfachende Annahme ist, da inzwischen einige Provider nur noch Dual-Stack-Lite (DS-Lite) mit Carrier-Grade NAT (CG-NAT) anbieten (beispielsweise Deutsche Glasfaser). Bei dieser Anschlussvariante bekommt schon der Kundenrouter aufgrund der IP-Verknappung erst gar keine öffentlich routebare IPv4 mehr, sondern eine aus einem bestimmten IP-Bereich (100.64.0.0/10, also 100.64.0.0- 100.127.255.255), genauso wie beim LAN mit RFC1918. Effektiv betreibt also der ISP einen vorgeschalteten NAT-Router, bei dem insoweit immer ,,Doppel-NAT" vorliegt.

Dies hat den Haken, dass der Kunde natürlich keine Port-Freigaben auf dem vorgeschalteten Router des ISP vornehmen kann und somit keine Dienste in seinem Netz von außen verfügbar machen kann, außer, er nutzt dazu IPv6 oder komplizierte Tunnellösungen, bei denen zuerst ein Tunnel von innen nach außen geöffnet wird und eingehende Verbindungen dann auf dem Tunnelende entgegengenommen werden (beispielsweise Cloudflare, eigener VPS-Server im Internet oder andere Tunnelprovider).

Aber wie eingangs angedeutet: IPv6 und Tunneling sind eigene Themen, die in separaten Beiträgen beleuchtet werden sollten. Das Gleiche gilt für Dynamisches DNS, TLS-Terminierung mit HAproxy, Caddy oder Nginx usw., wobei ich dazu hier schon etwas geschrieben habe – das bewegt sich allerdings auf einem deutlich anderen Anspruchsniveau als dieser Artikel.

In der Tutorial-Sektion des OpnSense-Forums gibt es neben diesen Themen zusätzlich noch viel Stoff für diverse Spezialthemen wie Dynamisches DNS, Traffic-Shaping, VoIP-Konfiguration u.v.a.m.

I have noticed that under Firewall: Settings: Normalization, the text blocks disappear when hovered in some themes (namely Tukan and Dracula), but not in others. It seems the text color is changed to something that does not contrast above the background.

Since Tukan and Dracula do not come from the same developers and since similar entries under Firewall: Settings: Advanced do no show the same issues, I suspect that the specific structure of the page elements is different. Probably there are tags set that once existed and now are outdated, but are still contained in the styles?

I have looked at the CSS, but I have no experience in that.

I love the Tukan theme for its readability and this glitch has always bothered me.

Having followed some potential ZFS corruption issues that have been found with the ongoing OpenZFS 2.2 release but really were lurking since 2.0 already, I noticed that Proxmox has just issued new kernels and ZFS utilities with fixed Open ZFS 2.2.2.

I now saw a video by Lawrence Systems about pfSense having fixed those issues as well.

@Franco: Will those FreeBSD fixes make it into 23.7.10 or a hotfix version?

P.S.: There are also some security-relevant fixes in the latest pfSense release which probably triggered this comment by Tom...

[XX]

So now I am fed up with all these discussions about IPv6 and DynDNS shortcomings... beware, this is long!  :P


First, let's talk about IPv4 and how you did it back then.

In the old days (tm) of IPv4, you wanted to expose services on your firewall or your internal machines
(you will later see why this distinction is relevant) to the internet, but alas, your ISP did not give you a static IPv4.

Thus, you set up one or more dynamic DNS name(s) which your router updated via a DynDNS (for "dynamic DNS") provider and open up ports for your services via (D)NAT and be done with it.
Well, you probably had the problem that each service had to use a different port, but you could port-translate
to the destination machine. Thus, every machine could have another port even if the internal service always used the same one.

For IPv4, you also used NAT reflection, such that your clients can use the same external IP (and hence DNS name) from within your own network(s).


But now, it's 2023 and we have IPv6 (and sometimes even only IPv6).


Alas, despite of the abundance of IPv6 addresses, most ISPs only offer dynamic IPv6. So we probably
need DynDNS for IPv6 as well. But many DynDNS providers still do not support IPv6.
Even if they do, we still face problems:

• Potentially, we want to update both the IPv4 and the IPv6 for a given service. Some DynDNS providers cannot handle both for the same DNS entry and even if they can, you cannot split both updates into two separate requests, because "the last one wins".
  
• 
  On the other hand, your firewall probably has no means to specifiy both IPv4 and IPv6 addresses in one request.
  
• Protentially, your firewall cannot reliably determine the correct IPv6 anyway, because:
  
  
  
  • 
    It cannot distinguish between routable and non-routable IPv6 addresses.
    
  • 
    Even if it can, or if you just call an external service or use the WAN IPv6 "implicitly", the routeable IPv6 of the WAN interface is potentially useless, because it is the IA_NA of the firewall itself and not the IA_PD prefix you would like because you really wanted to update the IPv6 for a local client. With IPv6, that distinction becomes vital, because NATv6 is essentially non-existent (and it should be).
    

Special case: You only have a routeable IPv6, because your ISP only offers CG-NAT for IPv4. Well, forget about the idea of exposing IPv4 services by pure firewall means anyway. You need to rely on a service to translate IPv4 to IPv6 for you or you do it yourself via a cloud VPS.

For what follows, I assume you have both inbound IPv4 and IPv6.

You will have to find ways around these DynDNS problems. We will get to this point later on.

Before that, let us discuss types of services. Roughly, we have these:

• HTTP or HTTPS, i.e. web-frontends of any kind or some APIs, like the admin UI of a switch, your local installation
  of Unifi controller, a Plex media server or a Proxmox host.
  
• TCP-based services like SSH

For type 1, I personally prefer to use HAproxy (There is a great tutorial on this by TheHellSite for OpnSense,
see https://forum.opnsense.org/index.php?topic=23339.0).
Because of termination at the firewall, the main advantages to this are:

• You can easily use both IPv4 and IPv6 for the same service.
  
• You can reach any internal service, regardless if it can handle IPv6 itself.
  
• You can translate ports, even with IPv6.
  
• You need only one IPv4 and one IPv6, so your DynDNS has to handle all the DNS names, but only two IPs.
  
• This is the most important: You can route requests based on DNS names, not via ports or IPs!
  
• You can centrally manage certificates and encryption for all of your internal sites.
  

Notes:

• c. can be a security plus, because IPv4 port scanners will find it harder to identify services on non-standard ports.
  
• e. is more secure as well, because your end services become exposed only to someone also knowing the name of the service (side-note: use a fallback with a fake certificate in order not to expose all of your service names with the real certificate, but be aware of certificate transparency!).
  
• f. is obviously more secure because it allows TLS even for services that do not have encryption built-in.
  
• Preferably, whenever it is possible, do not expose services at all. For example, I just switched from exposing a centralized Unifi network controller to using it over a Wireguard VPN.
  

For type 2, you can (and probably should) still use HAproxy, but (mostly) you cannot have e. and f.
You can also expose type 2 services directly, but there are some catches:

• Obviously, your internal service must be able to handle IPv6 in the first place (advantage b.). If it cannot, but you still do not want to use HAproxy, limit the DynDNS for this client to IPv4 (i.e. do not use a DNS entry that resolves to both IPv4 and IPv6).
  
• If you want a service to work over IPv4 and IPv6, it must have the same port over both. Since port translation over IPv6 is difficult at best, you expose the "real" port of the local machine, so you cannot have advantage c. from above.
  
• You also lose advantage d. as you must do DynDNS for your local IPv6 that is derived from the IA_PD prefix, not the firewall's IN_NA. This is usually harder.
  

Now how do we do that type of "dual" DynDNS?

As said earlier, with IPv6, every device gets their own IP, so now the distinction between your firewall and
your other devices becomes relevant (with IPv4, all used the WAN IP).
So, first thing to note: if have have multiple devices, you will need multiple DNS names.

As with IPv4, it is probably your router who does the dynamic DNS updates for you. With IPv6, it can usually do these updates only for itself. There are at least two reasons for this:

• 
  Most ISPs give you more than one routable IPv6 (globally unique adress or GUA). One is the "network address" (IA_NA for "network address"), which is assigned to the WAN interface of your router and the other one is a prefix (IA_PD for "prefix delegation"), from which you can delegate IPv6 addresses to your local devices.
  This prefix determines between 48 to 64 most-significant bits of the final IPv6 (most commonly, 56 bits are used).
  
  The rest of the address can be up to 16 bits that are interface-specific (that is, you can assign each internal VLAN a different interface prefix) plus 64 bits of EUI-64, which is derived from the MAC of the client device.
  
  
• 
  Now, where is the problem? The thing to note here is: IA_NA and IA_PD IPv6 ranges are different!
  In order for your firewall to update the dynamic DNS entry for any other local client, it would have to generate  exactly this client's IPv6. But with typical DynDNS update tools like ddclient, all it can usually do is:
  
  
  
  
  • call an external URL to find its own IPv6 - this would normally be the WAN IPv6, and this is not what we want.
    
  • find its IPv6 locally - which would be the same in the best case, but wait: since any device and even interface can have multiple IPv6 addresses, which one should it even choose?
    
  • not use a specific IPv6 at all but rely on the DynDNS provider to detect which IPv6 the request originates from - this is essentially equivalent to variant a, unless you use some trickery.
    
  
  

OpnSense has an (partial) answer to this because it can find either the IPv4 or the IPv6 of a specific interface (via "Check ip methods" "Interface [IPv4]" and "Interface [IPv6]") and provide the result via the macro __MYIP__. This is a "partial solution" because for DynDNS providers that can only accept both IP types in the same request, this will not work without a small trick.


The remedy to these problems is:

• 
  You can force your firewall to use an IPv6 from the IA_PD range by specifiying "Request only an IPv6 prefix" on the WAN interface. By doing that, your firewall WAN interface does not get a routeable IPv6 (i.e. no IA_NA).
  However, by using "Track Interface" as IPv6 configuration type for your local network interfaces, at least one
  of them will get an IPv6 GUA from the prefix delegation range (IA_PD).
  One of those local interface IPv6s will then be chosen for your firewall's outbound connections. The trick is that the delegated prefix of this IPv6 will be the same for all of your routeable IPv6s. This works even if the client is on another (V)LAN that the outbound (V)LAN interface of your OpnSense.
  
  
• 
  You need a DynDNS provider who can detect the originating IPv6 from the API request plus he is able to cut the most significant N bits from it and have the rest be configured manually for a specific DynDNS name. Preferably, he offers an update API endpoint that is IPv6 only to make sure that the update is done via IPv6 even when "prefer IPv4" is configured.
  
  

So, as an example, let us assume there are these devices:

• Your OpnSense firewall with a MAC of AA:BB:CC:DD:EE:FF, giving an EUI-64 of ::a8bb:ccff:fedd:eeff
  
• A LAN server with a LAN MAC of 11:11:11:11:11:11, with an EUI-64 of ::1311:11ff:fe11:1111
  
• An IoT device with a VLAN1 MAC of 22:22:22:22:22:22, with an EUI-64 of ::2022:22ff:fe22:2222
  

Let us further assume that your ISP fives you a /56 IPv6 dynamic public delegation prefix (say dead:beef:feed:fa00::0/56) and you used the 8 network bits as "00" for your LAN and "ce" for your IoT VLAN1 (Be aware that OpnSense wants the network bits in decimal, so this would be 0 and 206, respectively).

In that case, you could configure three DynDNS names like so:

opnsense.dyndns-x.com	dead:beef:feed:faXX:a8bb:ccff:fedd:eeff
lanserver.dyndns-x.com	dead:beef:feed:fa00:1311:11ff:fe11:1111
iotdevice.dyndns-x.com	dead:beef:feed:face:2022:22ff:fe22:2222

Note that you will have to find which interface is being chosen for outbound connections, thus the XX in the OpnSense IPv6.

Whenever your OpnSense gets another dynamic prefix (say cafe:babe:bedd:ab00::0/56), only the first 56 bits on all of these DynDNS entries get updated, because the DynDNS provider uses the new requesting IPv6 (cafe:babe:bedd:abXX:a8bb:ccff:fedd:eeff).

Of course, you have to set up firewall rules to access these devices. But for that, OpnSense has a firewall alias type of "Dynamic IPv6 Host" where you can specifiy the EUI-64 like given above plus the interface to which it is connected. The "Dynamic IPv6 Host" alias will get updated when the IPv6 prefix for the interface changes.

BTW: This assumes you use SLAAC for your internal clients and that they can handle IPv6 at all. For DHCPv6, you would have to use static reservations and use the lower 64 bits for the device instead of the EUI-64. If your clients cannot handle IPv6, many times you could still use HAproxy (there is a tutorial how to set this up) as an application-level gateway between IPv6 and IPv4.


Apart from the shortfalls I gave above, there are several weaknesses in current implementations:

• 
  ddclient tries to accumulate DynDNS entries (hostname & IP) for the same DynDNS provider into one API request. This is a problem if you want to have both an IPv4 and an IPv6 for the same name in case you create two update rules with different parameters. You can sometimes circumvent that by using different API endpoint names, if available from your DynDNS provider. In OpnSense, there is now a "native" backend which is much better suited than ddclient.
  
• 
  Many DynDNS providers handle both IPv4 and IPv6, but the last updates overwrites whatever was there before, so you cannot split updates between IPv4 and IPv6 (e.g. https://www.ddnss.de).
  
• 
  At this time, OpnSense cannot determine both IPv4 and IPv6 interface adresses to wrap into one API call (like "...&myip=__MYIPV4__&myip2=__MYIPV6__").
  
• 
  Also, OpnSense cannot determine IPv6 addresses "in lieu" of a client, like use their "Dynamic IPv6 Host" firewall alias as a variable (this could not really work like that because the content of that variable can be an array).
  It would be very helpful to directly update DynDNS entries regardless of the API connections's IP protocol and not having to rely on the DynDNS provider to strip something off the IPv6.
  Something like this would even work if the IA_NA of OpnSense was used for the API request.
  

@AdSchellevis: Fixing weaknesses 3 and 4 would be pure luxury!


Step-by-step instructions for the current, somewhat broken implementation:

• 
  Register an account at https://dynv6.com
  
  
• 
  Create a zone of your choice, e.g. "testit99.dns.army" and leave the IPv4 and IPv6 fields empty for now
  
  
• 
  Configure your OpnSense to use DHCPv6 on the WAN interface. Specify how many bits your prefix has,  most often it will be 56. Because of another trick introduced later, you can even leave IA_NA on the WAN    interface for outbound connections for this specific DynDNS provider in place.
  
  
• 
  Configure your LAN interface to "Track Interface" WAN for IPv6 and assign an "IPv6 Prefix ID".  Check that it gets an IPv6 GUA from the correct range. If you do this for multiple (V)LANs, find out which of them is being used for outgoing connections by entering "curl v6.ident.me" on the OpnSense CLI. You will see the IPv6 Prefix ID number directly preceeding the EUI-64 bits, so you know the corresponding  outbound (V)LAN interface.
  Take a note of the EUI-64 and preceeding IPv6 Prefix ID number that your OpnSense uses.
  
  
• 
  Optional: If you have a local client / service that you want to address as well, check that Router Advertisements (aka SLAAC)  is configured under "Services->Router Advertisements". Use "Unmanaged" mode and a "Minimum" / "Maximum Interval" of 200 / 600. Check that your client gets an IPv6 GUA as well and also, if it has IPv6 connectivity - if not, check your firewall rules. Take a note of its EUI-64 and which (V)LAN interface it is on.
  
  
• 
  Looking at the DynV6 zone's "Current status", you still have nothing configured for the zone itself.
  
  
• 
  Lookup the Dynv6 HTTP Token in your Dynv6 account settings (under "keys").
  
  
• 
  Set the following under your OpnSense Services->Dynamic DNS->Settings "General settings" tab (enable advanced mode"):
  
      Enable: checked
      Verbose: checked
      Allow IPv6: checked
      Interval: 300 (or as you like)
      Backend: native
  
  Apply these settings.
  
  
• 
  Create a new account under your OpnSense Services->Dynamic DNS->Settings:
  
      Enabled: checked
      Description: whatever you like
      Service: custom
      Protocol: Custom GET
      Server: https://ipv4.dynv6.com/api/update?zone=<YOUR_ZONE_HERE>&token=<YOUR_TOKEN_HERE>&ipv6=__MYIP__/56&ipv4=auto
      Username: x (because technically, you need it)
      Password: x
      Wildcard: unchecked
      Hostname(s): <YOUR_ZONE_HERE>
      Check ip method: Interface [IPv6]
      Interface to monitor: <YOUR_OPNSENSE_OUTBOUND_(V)LAN_INTERFACE>
      Check ip timeout: 10
      Force SSL: checked
  
  
  (Note: Yes, we use the IPv4-only API endpoint, which sound weird. That is because we want to have both our
  IPv4 and our IPv6 updated in one go. We can only detect one of these addresses locally and use it via the
  macro "__MYIP__" in the request URI, the other one will be autodetected by the API.
  Also, we want to specify the prefix length (/56) together with the IPv6. Because this cannot be done automatically, it determines which is which. So, we must use IPv4 auto-detection via "ipv4=auto" and for this to work, we have to connect via IPv4 to the API. By using this trick, we could even differentiate between IA_NA and IA_PD, just  because we are able to send the corresponding prefix explicitely, but we would need different zones for this.)
  
  After that, do not forget to apply the settings. Check the Dynv6 administration interface and verify that your zone now has both an IPv4 and an IPv6 prefix. The IPv6 prefix should have all zeros for the "IPv6 Prefix ID" bits. This enables the use of any VLAN for the final DNS names.
  
  
• 
  Go to the Dynv6 administration console and choose your zone. Switch to the "Records" tab and create a new AAAA record. Leave the name empty and paste the EUI-64 of your chosen outbound OpnSense interface, preceeded by the "IPv6 Prefix ID" bits into the data field and save the entry. It should look something like "::00:a8bb:ccff:fedd:eeff".
  This record will result in the DNS name "testit99.dns.army" from our example being resolvable.
  Note that when you look at the DNS records, they will automatically expand to show the full resulting IPv6 GUA by prepending the zone's IPv6 prefix. You can switch between both views by clicking on the small icon ("expand") above the data column.
  Make sure not to specify the full IPv6, because then it will not be changed by a zone update later on!
  
  
• 
  Optional: If you want your local client(s) to be accessible, create another AAAA record, but this time, assign a name (e.g. "lanserver" from our example, resulting in "lanserver.testit99.dns.army") and  the client's EUI-64 plus prepended "IPv6 Prefix ID" bits for its (V)LAN. If you like, you can also create an additional entry for your OpnSense itself as a subdomain (e.g. "opnsense", resulting in "opnsense.testit99.dns.army").
  You may use multiple zones if you do not like subdomains and prefer "opnsense.dns.army", but you need an    DynDNS update account for each zone. In addition to this, Dynv6 allows you to handle your own, custom DNS domains.
  
  

Your OpnSense now has both IPv4 and IPv6 DNS addressability as "testit99.dns.army". Your other LAN client(s) can be addressed via the subdomain name(s) you have created (e.g. "name.testit99.dns.army". You can install IPv6 firewall rules to allow traffic as needed, but be careful.

[for reference only]

As many firewall appliances suffer from neglect by they manufacturers, they often lack current microcode updates.

For example, Intel Alder Lake based CPUs (like N100, N200, N300 and I1215U have a bug that cause instabilities.

As of OpnSense 24.7.2, microcode updates can be enabled for AMD and Intel CPUs by installing the corresponding plugin os-cpu-microcode-amd or os-cpu-microcode-intel (not both!). The update will be done automatically upon next reboot.

The old post is left here for reference only:


Since 23.7.9, there should be microcode updates available, which, when enabled, should cure those problems.

Though OpnSense does not have those enabled per default (e.g. it obviously is not applicable for VM installations), the neccessary tools are provided. Here is how:

1. Install the package cpu-microcode - this is a newer variant of the old devcpu-data package. From a shell, call:

Code Select Expand

echo y | pkg install cpu-microcode

Alongside with this package, the RC scripts and firmwares for both Intel and AMD CPUs will be installed. If you had the devcpu-data package installed before, it will get replaced.

2. Use the web UI to create these two tuneables in /boot/loader.conf:

Code Select Expand

cpu_microcode_load="YES"
cpu_microcode_name="/boot/firmware/intel-ucode.bin"

Please double-check that the entires exist. Note that this is only for Intel CPUs, because this addresses only the early boot stage, which is not available for AMD CPUs. This can be fixed in the next step.

3. Add an entry to /etc/rc.conf:

Code Select Expand

echo 'microcode_update_enable="YES"' >> /etc/rc.conf

This will enable a RC script which handles both Intel and AMD CPUs during boot.

4. (Optional and only available from 23.7.6 on)

Code Select Expand

pkg install x86info
rehash
x86info -a | fgrep -i microcode

The last command will show you the current microcode version.

5. Reboot or call the CPU firmware update script once with:

Code Select Expand

service microcode_update start

You will see an error if you skipped step 3.

6. (Optional and only available from 23.7.6 on) Call:

Code Select Expand

kldload -q cpuctl; x86info -a | fgrep -i microcode
again and you will probably see a different version than in step 4.

Note that these settings and installation of packages will not be part of a configuration backup, so after a hardware migration, you have to repeat most of it.

These instructions are provided as-is, so no warranties whatsoever.

I know this was a thing with 22.7 before (there is an archived thread about this here):

On one of my OpnSense boxes, radvd stops advertising the prefix after a while. That is to say, the RAs lack the prefix info, it is not radvd stops working completely. Restarting radvd immediately helps, after the restart, the prefix is announced again. In the old thread, a cron job to restart radvd every hour was suggested, but I thought that this problem was fixed long ago?

There are two other boxes which do not have this behaviour (with the same ISP!) and I do not see any configuration difference. Also, to my knowledge, the prefix also does not even change...

Until the latest OpnSense release, I used dnsmasq instead of unbound because of two reasons:

1. It is much faster.
2. It handles local domains better IMHO, because you can define a default domain like "ttt" and have both "host" and "host.ttt" resolve to the same name. This helps a lot for devices that cannot pick up the default domain via DHCP correctly.

With 23.1.5_4, dnsmasq seems to start too early (or whatever), at least after a reboot, it does not forward requests to upstream servers any more. Thus I started to try unbound.

Now for #2 in my list: I found that I need to define a domain for each host override, such that I do not even have an option to define both "host" and "host.ttt" - strangely enough, I can skip the domain for aliases, but then they will not work either...

So, is there a way or a best practice to map queries with hostnames without a domain to a "default" domain for unbound?

I have a routing problem after update from 23.1.4_1 -> 23.1.5_4. First thing was that I had an exception (which I could not read before it was replaced by the reboot notice). The reboot did not occur, I had to manually restart the box.

After coming up again, router advertisements were being handed out, I could see the addresses, but no IPv6 routes. After a manual restart of radvd, the routes re-appeared.

Could have something to do with resequencing of events during interface startup. In my case, the WAN interface does not have a routeable IPv6, since I get only a prefix range via DHCPv6.

Vielleicht kann mir ja hier einer der DG-Nutzer helfen:

Ich habe zwei (!) relativ neue DG-Glasfaseranschlüsse mit jeweils 1000 MBit/s an zwei OpnSenses hängen. Beim ersten kam es von Zeit zu Zeit zu Ausfällen der IPv6-Connectivity (ca. 3 mal täglich), wobei die IPv4 funktionierte - wohlgemerkt, DS-Lite, also CG-NAT.

Beim zweiten Anschluss (ganz frisch) konnte ich das auch bemerken, allerdings kann ich es inzwischen provozieren, indem ich mit dem OOKLA Speedtest Client unter Linux einen Test starte (von hier: https://www.speedtest.net/de/apps/cli). Nach spätestens 5 Starts hängt dann die gesamte IPv6-Verbindung (da ich via IPv6 auf den Zielrechner gehe) und von außen gesehen ist beim letzten Router vor der Ziel-IP Schluss:

Code Select Expand


                                  My traceroute  [v0.93]
xyz.test.de (2a01:7778:243:420d::xxxx)                      2023-03-09T19:39:16+0100
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                 Packets               Pings
Host                                          Loss%   Snt   Last   Avg  Best  Wrst StDev
1. 2a01:4f8::a:24:a                            0.0%    20    0.5   1.3   0.4  12.9   2.8
2. core24.fsn1.hetzner.com                     0.0%    20    0.3   5.5   0.3  29.4   8.6
3. 2a01:4f8:0:3::4c2                           0.0%    19    5.0   5.0   4.9   5.1   0.0
4. pr1.int63-fra.dg-w.de                      73.7%    19    5.9   5.9   5.7   6.0   0.1
5. 2a00:6020:0:d::2                           15.8%    19    6.0   6.1   5.9   6.3   0.1
6. 2a00:6020:ffff:ffff::31                     5.3%    19    9.7   9.6   9.3  10.3   0.2
7. (waiting for reply)


Normal kommt bei Nummer 7 die Ziel-IP. Von innen sieht man auch, dass IPv6 down ist (z.B. zeigt https://wieistmeineip.de dann nur eine IPv4). Das Problem heilt sich nach einigen Minuten selbst, indem die OpnSense wieder die selbe IPv6 zugewiesen bekommt.

Es ist NICHT der Router, weil der erste Anschluss einen anderen hat (anderer Ort). Ich glaube auch nicht, dass die Ethernet- oder Glasfaser-Verbindung zusammenbricht, da IPv4 ja weiterläuft. Nur per IPv6 geht zeitweise nichts.


Ich hoffe, dass ich alles richtig konfiguriert habe, normalerweise funktioniert ja auch alles, die Aussetzer sind
sporadisch - bis zur Entdeckung, dass Speedtest das auslöst konnte ich es nicht mal reproduzieren.

Die einzige Besonderheit in meiner Konfiguration ist, dass ich nur einen IPv6-Präfix verlange, d.h. die OpnSense selbst nutzt ihre LAN-IPv6-Adresse, nicht die WAN-Adresse. Das macht es m.E. einfacher, bei einem DynDNS den richtigen Präfix zu zeigen, nämlich den, den auch die Clients im LAN haben - sonst wäre es ja ein anderer Präfix.

Ich denke, dass das Problem vielen DG-Kunden nicht auffallen würde, da bei ausgehenden Verbindungen ja ein IPv4-Fallback gemacht wird. Aufgrund CG-NAT bin ich aber für eingehende Verbindungen auf IPv6 angewiesen.

Bevor ich jetzt ein Fass bei DG aufmache: Beobachtet jemand das selbe Problem oder mache ich was falsch?

I have a running setup including IPv4 and IPv6, but I cannot for the life of me get QUIC to work.

Whenever I try https://cloudflare-quic.com or https://quic.nginx.org/ or https://http3.is/, nothing really happens.

When I try UDP functionality, it works fine, so I am at a loss as to why this does not work.

Has anyone gotten QUIC / HTTP/3 to work over OpnSense? And if so, how?

I have searched the forum but not found anything about this topic:

As some of you may have noticed, the HTTP3 standard is becoming more of a thing right now. Most browsers implement it and larger sites (CDNs and big providers) use it.
HTTP3 has some benefits (i.e. speed) and some drawbacks, being based on QUIC and thus on UDP.

HTTP1 and HTTP2 were based on TCP, in which we have a direction for packets because of handshakes and sessions which make it possible to have a correlation of incoming and outgoing packets. So, when I define a firewall rule that refers to a source and a destination, everything is clear.

With UDP, this is not so easy. I know of some packet filters that correlate UDP packets based on source and destination ports and a "session" cache which more or less guesses which UDP packets may be responses to UDP requests. For QUIC, this becomes even harder, since everything (including the session information) is encrypted and thus the intermediate firewalls cannot really track what is going on.

Does OPNsense offer a solution for this? In that case, one could define rules for UDP "connections" as well.

From my first observation, HTTP3 does not work out-of-the-box (as per https://cloudflare-quic.com/ and other test sites). I have IPv6 and would assume that is being preferred. I have a general "allow LAN to ANY" rule for both IPv4 and IPv6.

But only when I add a rule to allow any UDPv6 traffic for WAN, the HTTP3 test works. Alas, opening up all UDP traffic to my network is obviously not what I want.

How could I allow HTTP3 in a safer way? Allowing traffic from port 443 only cannot be the solution either.

Am I missing something or is OPNsense not able to do this?

Seems I go first here...

Upgraded a few systems from 22.1.10 to 22.7 with only a few errors from HAproxy which like depreciation warnings because of the new PHP version - no worries, HAproxy works as before.

Good work!

I tried to enable jumbo frames on ax0 today. I used 9000 as MTU, which was accepted (10000 seems to be out of range, which can be verified by ifconfig).

However, when I tried "ping -s 8972 -D xxxxx", the pings never went through. The highest I could manage was 4054, which indicates a real MTU of 4082. I tried two different targets, which among themselves can ping.

Is this a hardware limitation or a kernel/driver bug? If it is a hardware limitation, why does ifconfig not complain when such a big MTU is applied (i.e. why does the axgbe driver not bork)?

Well, yesterday, I had some bad experience using NAT reflection on port forwards...

I was trying to setup HAProxy when I noticed that my backend server could not be reached. This was strange, since I had disabled the port forward that I had for ports 80 and 443 to my main server.

After much trial and error, I narrowed this down to that my Opnsense could not reach the main server on ANY port, but could ping it. I gave the main server an additional IP and that worked. I was not aware of any firewall rule that could cause this, but after I disabled all packet filtering, I could access the ports again from my Opnsense.

Since I could not lay my fingers on anything specific by enabling all firewall logging, I suspected a NAT issue, because I still had some inbound WAN rules for my main server for other ports than 80 and 443. After I disabled them, all was fine.

I narrowed the problem down to one port forwarding rule which had a "mail" port alias with ports 143 and 587 in it and for which NAT reflection was enabled. The alias was used in both the port range and redirect target port. NAT reflection was enabled.

This rule had the side effect of blocking all ports on the destination server from the Opnsense itself. When I changed that to two separate rules for the ports, only the ports in the rules were affected.


So there are two problems with NAT reflection:

1. When you use a port forwarding rule with a port alias containing two ports and enabled NAT reflection, Opnsense cannot access any port on the target IP. There is surely a bug in how port aliases are handled there as all ports are affected and not only the ones in the alias.

2. Even when you do without port aliases and NAT reflection on a port forwarding rule to an IP X on only a single redirect target port Y, that specific combination of X:Y will not be reachable for your Opnsense box itself any more. While it is somehow intended to have NAT reflection for any incoming LAN traffic, it should never lead to the target port being masked from the Opnsense itself. To say the least, this is most unexpected and very difficult to find once you stumble on it, as there is no logging for NAT reflection.

These problems are only visible from the Opnsense box itself, as any other LAN clients usually reach the target X directly without Opnsense interfering, i.e. NAT reflection comes only into play when you access the external IP for X (and also, the port could be != Y).

Wow. You won't believe this - I at least would not, had I not seen it myself.

I moved a Topton N5105-based system (I wrote about this https://forum.opnsense.org/index.php?topic=27938) from my office to the would-be location, only to find out that the unit resets itself every 5 minutes. This behaviour is consistent and reproducable.

Since it worked without a hitch at the office, I wondered what causes this and to my great surprise, the reason is that I attached no monitor at the new location. This was really hard to find out with no log entries whatsoever and whenever I looked at the console (attaching a monitor), nothing happened.

The HDMI cable has to be plugged into a display that is turned on for the problem not to occur. When I turn the display off, the problem is as without any display. From the looks of it, I would assume that just when the screen should go blank (i.e. after 5 minutes), the system just reboots when no active display is attached, like "duh, I cannot blank a non-existent display".

I know this does not happen on similar X64-based systems I have, so there must be a BIOS bug (it has an EFI firmware) or an incompatibility to OpnSense/FreeBSD.

I already tried to set the console to "Mute console", "None", disabled the VT driver to no avail. I know that there are images for serial-only installation, I wonder if that helps?

Is there an easy way to have the system act as if it was installed from the "serial" image, thereby disabling any video drivers that may be active and try to blank the display? Or can I disable blanking, maybe with some tuneable?

Just my quick findings about this Topton system which seems quite interesting considering it is kind of in-between readily available J4125-based and non-available so far Elkheart Ridge-based x64 boxes. It is ~30% faster than a J4125.

The system has some flaws that CAN be fixed. You can read about this here (unter the second heading).

I have found an apparent problem when I define a rule on the WAN interface that allows IPv6 traffic to a host on the LAN.

The rule in question defines the LAN host by its MAC address via a firewall alias. That is mainly because my ISP assigns dynamic IPv6 prefixes, so that the rules cannot be specified via full IPv6 addresses - or at least they will be outdated when I get another prefix. Thus, specifying a destination host via its MAC seems like a good option.

However, I found that after I reboot my OpnSense or get a new IPv6 prefix, the rule does not fire, but instead the "default deny all" rule blocks incoming IPv6 packets for the LAN host. The command I use to test if the port is open is "nmap -p<port> -Pn -6 <ipv6addr>".

This starts to work only after I trigger an IPv6 neighbor discovery of that host on the OpnSense box, like a ping from OpnSense to the host. It does not work the other way around as the host uses IPv6 privacy extensions and thus usually does not communicate via its EUI-64-based, but over one of its temporary IPv6 addresses.

It can be proven that the neighbor cache is the culprit by looking at "ndp -a", which shows the hosts IPv6 when it works. Once I remove the address with "ndp -d <ipv6addr>", the connection is blocked again.

If I use a firewall rule that is based on the real IPv6 instead of the MAC of the host, it works without having to "introduce" the host in this way first. I would expect the same behavior with a MAC-based rule - I am almost sure that I tried that on 21.x and never had that problem. The MAC trick was discussed by other people as well, who did not have that problem.

I do not get what is wrong here, i.e. why is the packet not matched anyway? Is the MAC-based rule matching depending on the content of the neighbor cache and not followed blindly, like it should? What about IPv4: Is the ARP cache involved there? Is that behavior new in 22.1?

With the advent of more and more IPv6-only ISPs, such problems are becoming quite visible.

I wondered what those blocked entries in my firewall log are (see attachment):

WAN in TCP from 2603:10b0:b14:89d8:0:1:4b:73f3 port 443 to 2100::xxxxxx port yyyy tcpflags PA

All come from IPs within 2603:10b0::/32 (owned my Microsoft, apparently MS Azure), source port 443 and they have PSH and ACK flags set (which makes it hard to even create a rule to let those packets pass, because you have to use advanced options).

I would not bother about this, if it were not for the fact that the destination IPs are only Windows PCs in my network - and those are correct SLAAC temporary addresses only (not a random scan) which would be hard to guess.

Digging a little into the matter, I found that the sender IPs apparently do not react to anything and I can see no outgoing packets to those IP addresses originating from my PC (on any port). The incoming TCP payload is gibberish...

I wonder how my temporary IPv6 leak to whatever machines send these packets - is this a residue of a legit Microsoft service (like Windows update) or an indication of some malware that is already on my Windows machines, phoning home to some Azure-based command-and-control servers, but not getting answered because my firewall blocks it?

Does somebody know what this is?

Maybe I am just too dumb...

After having found out that the os-git-backup plugin does not encrypt the configuration backups (which is O.K., since that way the deltas can be investigated), I tried to setup my own git server.

After a bit of trial and error, I was very surprised to find out that I could not access SSH in my own LAN from the firewall itself (nor can I access HTTP or HTTPS). Pinging the LAN IPs works, however.

My setup is a WAN via PPPoE and outbound NAT (even with NAT reflection) plus a LAN and a GUEST network. There are some port forwarding rules as well, but they should not matter.

When I disable all traffic filtering, a 'curl https://192.168.1.3' from the firewall works, but I cannot find for the life of me which rule blocks traffic from the firewall 192.168.1.1 to the LAN server 192.168.1.3. I think it cannot be NAT, since that only applies to the outgoing WAN traffic.

I know that ICMP is allowed in the auto-generated rules, so I looked them up, but found nothing suspicious.
There are no log entries for blocked packets, and I have already tried to switch on logging for the default drop rules (can that be done for auto-generated rules, too?).

I even tried create a rule to allow anything from LAN, move it before anything else and make it 'quick' - alas, to no avail.

What am I doing wrong?

P.S.: Now that I tried something else, I found that this is correlated to port forwarding with reflection enabled: I actually can access any server/port combination that is not already on the right hand side of a port forwarding rule. It seems like there are translation rules in place for the response packets that apply to any sender, regardless if he comes from the WAN... it does not help to limit the forwarding rule to "!this firewall".

Despite a NAT reflection, accessing the WAN side of the port forwarding rule does not work, either, from the firewall itself. I thought that the port forwarding rules apply to packets from the WAN side only. While this might be the case, the response packets are always getting diverted.