OpnSense für Dummies (speziell für Fritzbox-Umsteiger)

[meyergru]

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:


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.
  
  
• 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.

[Monviech (Cedrik)]

Super geschrieben. Bringt alle Probleme die ich über Jahre mit Fritzbox + Opnsense gelesen habe komplett auf den Punkt. Das wird eine meiner favorisierten neuen Referenzen.

Wenn man eine Fritzbox hat, ist es nicht verkehrt sie einfach zu benutzen. Besser eine gut konfigurierte Fritzbox als eine mittelmäßig konfigurierte OPNsense.

Wenn man die Fritzbox durch OPNsense ablöst dann erwartet einem ein plötzlicher neuer Gerätezoo.

-OPNsense
-Switch
-TK-Anlage
-Modem
-Wi-Fi Access Point
etc...

[Patrick M. Hausen]

Domou arigatou gozaimasu 

[CoolTux]

Ich finde der Beitrag sollte gepinnt werden. Ist wirklich gut geschrieben.

[maze-m]

Ich kann mich @CoolTux nur anschließen und finde ebenfalls, dass der Beitrag gepinnt werden sollte.

@meyergru: Vielen Dank dir für die wirklich sehr ausführliche Erklärung.

Ich fühle mich bei einigen Punkten durchaus wiedererkannt und muss vielen (leider) in Bezug auf mich auch zustimmen.
Da ich selber ITler bin und im Unternehmensumfeld auch schon mit pfSense gearbeitet habe, war mir natürlich klar - als ich mit dem Thema "OPNSense" angefangen habe - dass das nicht leicht wird.
Nichtsdestotrotz betreibe ich meine OPNSense nun schon seit fast einem Jahr hinter der Fritzbox "immer wieder Abends" zum Testen und hab da als "Neuling" trotzdem immer noch einige Fragen:

- Wenn ich von dem Szenario:

  Internet ----> Fritzbox <---- Zwischen-LAN (192.168.178.0/24) ---> OpnSense <--- echtes LAN (192.168.2.0/24) ----> Endgerät(e)

  ...auf das Szenario umsteige:

 
Internet ----> OpnSense <----LAN (192.168.2.0/24)  +--> Endgerät(e)

  ...muss ich dasfür in der OPNSense noch einiges umstellen, oder reicht es das WAN-Interface auf DHCP zu stellen?

- Sollte ich vor einem größere Update der OPNSense ein Backup via 'bectl' machen, sodass ich ggf. zurückspringen kann?

- Wie stabil läuft generell die OPNSense, wenn Sie erstmal eingerichtet ist?

Ich hoffe, meine Punkte passen zu dem Thread und es ist okay, dass ich die Fragen hier stelle ....
                                                     

[meyergru]

Ist schon O.K., weil die Fragen bis hierhin ja allgemein sind. Wenn Du beim konkreten Umstieg dann Hilfe brauchst, kannst Du ja ein eigenes Thema eröffnen.

  ...muss ich dasfür in der OPNSense noch einiges umstellen, oder reicht es das WAN-Interface auf DHCP zu stellen?

a. Ich weiß nicht, wie Deine Fritzbox jetzt die Internet-Verbindung aufbaut, ob per DHCP oder mittels PPPoE, mit oder ohne VLAN. Fakt ist, dass diese Aufgabe dann von der OpnSense übernommen werden muss und zwar eventuell für IPv4 und IPv6.

b. Außerdem weiß ich nicht, welche der beiden Varianten NAT bzw. reines Routing aktuell auf Deiner Fritzbox im Einsatz sind. Wenn sie schon NAT macht, ist es für IPv4 kein großer Unterschied. Eine eventuelle IPv6-Subdelegation muss eventuell auch angepasst werden.

c. Falls Du die Fritzbox hinter der OpnSense weiter als VoIP-Gateway nutzen willst, müssen wahrscheinlich entsprechende Port-Weiterleitungen konfiguriert werden. Bei ISPs, die VoIP über IPv6 machen, muss der IPv6-Teil dann auch richtig laufen.

d. Falls die OpnSense von außen erreichbar sein soll, muss natürlich auch der DynDNS-Update in Zukunft dort laufen.

Das ist mit einer der Gründe, wieso ich dafür plädiere, das gleich so aufzusetzen: All diese Probleme hat man vorher schonmal mit dem alten Setup "gelöst" (leider unzureichend) und muss dann nochmal ran.

- Sollte ich vor einem größere Update der OPNSense ein Backup via 'bectl' machen, sodass ich ggf. zurückspringen kann?

Kann nicht schaden, wenn Du nicht weiterkommst. Andererseits kannst Du ja die Konfiguration auch nach jedem Schritt sichern, zudem bietet die OpnSense eine History, mit der Du jederzeit auch einzelne Schritte rückgängig machen kannst. bectl ist eher sinnvoll, wenn vor einem Upgrade sichergestellt werden soll, dass man "zurück" kann, weniger für Konfigurationsänderungen.

- Wie stabil läuft generell die OPNSense, wenn Sie erstmal eingerichtet ist?

Das kommt darauf an: Für die meisten (wie mich) läuft sie rock solid. Es gibt aber vereinzelt Berichte von Anwendern, wo immer wieder die Verbindung zusammenbricht - dabei ist meist unklar, ob da Hardwareprobleme (z.B. fehlende Microcode-Updates), seltsame ISP-Settings (z.B. ständig wechselnde IPv6-Präfixe) oder einfach Fehlkonfigurationen die Ursache sind.

[lewald]

- Wie stabil läuft generell die OPNSense, wenn Sie erstmal eingerichtet ist?

Einmal richtig eingerichtet läuft die super Stabil. Hardware muss natürlich i.o sein. Ich habe Installation wo ich oft nur ein mal im Jahr dran komme. Die laufen ohne Neustart problemlos durch. 

[awado]

Super erklärt. Vielen Dank. Eine Idee hätte ich noch: ich habe Glasfaser, also ein Glasfasermodem. Nehmen wir an, ich hänge die Frizbox dort dran mit ihrem WAN-Port, deaktiviere DHCP und gebe ihr eine IP aus dem Intranet der OPNsense. In der OPNsense stelle ich dann eine Route ein, dass Internet über die IP der Fritzbox hinaus geroutet werden soll. So müssten doch alle Funktionen der Fritzbox (ausser DHCP und NAT) noch gehen? Und die OPNsense sollte wie gewünscht für die anderen Clients funktionieren? Oder mache ich da einen Denkfehler?

Weiß denn eigentlich jemand, wie die Fritzboxen die Trennung des Gast-WLANs erzeugen, wenn Fritz-Repeater standardmäßig (also ohne OPNsense) in deren Netz hängen? Wenn dazu kein VLAN genutzt wird, könnte wohl Packet Sniffing zwischen den Netzen betrieben werden?

[meyergru]

Warum sollte man mit einem externen Glasfasermodem die Fritzbox noch als Router nutzen? Das kann doch die OpnSense genauso. Und dann kann man die Fritzbox ja noch immer als WLAN-AP und/oder für Telefonie nutzen (modulo Gast-WLAN, das geht aber bei dieser Konstruktion eh nicht).

P.S.: Wenn das LAN der OpnSense also mit dem LAN der Fritzbox verbunden ist, was sollte denn die OpnSense noch tun können? Filtern kann sie jedenfalls nichts, sowie ein Client die Fritte als Gateway nimmt.

[awado]

Mein Beispiel war exemplarisch gemeint für Fälle, in denen man das Modem der Fritzbox nutzen muss/möchte. Hätte auch eine "Glasfaser-Fritzbox" sein können.

Ja, da ist wohl mein Denkfehler. Sobald ein Client dann die Fritzbox entdeckt und sie für WAN-Routing selbst nutzt, ist die OPNsense für die Katz…

[Baender]

Hallo meyergru,
vielen Dank für diesen Artikel. Als jemand mit Fritzbox, der sich bewusst in das Rabit Hole begeben hat, habe ich mich hier an vielen Stellen wiedergefunden. Typisches Beispiel: Fritzbox APs mit Meshing und Gast-WLAN, auf plötzlich Fritzbox im IP-Client Modus und "wie realisieren ich jetzt mein Gast-WLAN".

Wenn das möglich wäre und der Post gepinnt wird, könnte man vielleicht Links zu den typischten Posts hier verlinken. Ich denke da zum Beispiel an die VOIP-Posts.. Natürlich ist mir klar, dass das keine All-In-One Lösung wird und immer individuelle Fragen aufkommen werden.

Was ich noch fragen wollte:
1. Gibt es zu deinem Post "How (not) to expose services in your home network" eine leichter verständlichere Variante? Also das geschriebene ist bei mir schon hart an der Grenze zum verständlichen. Ich Frage, weil ich aktuell IPv6 nur via 6to4 (oder ist es andersherum?) reinbekomme und vielleicht natives IPv6 bekommen kann. Vielleicht liegt mein Problem auch daran, dass aus meinem Verständnis IPv4 einfacher zu verstehen ist.

2. Zu 1. gibt es Informationen zum Thema VOIP? Aktuell habe ich IPv4-VoIP mittels SNAT und ein paar FW-Regeln gelöst. Da wäre für mich die Frage, wie man oder ob man das bisherige Setup anpassen müsste.

3. Zu dem verlinkten VIMIN 8-Port, hast du genau den im Einsatz? Da würde mich im Zusammenhang interessieren, wie du den verbunden hast. Natürlich mit einem Managed Switch? Ich habe leider damals aus Kostengründen das Managed Switch nur mit 1Gbits Anschlüssen genommen. Also auch die SFP-Anschlüsse haben nur 1Gbits

[meyergru]

1. Gibt es zu deinem Post "How (not) to expose services in your home network" eine leichter verständlichere Variante? Also das geschriebene ist bei mir schon hart an der Grenze zum verständlichen. Ich Frage, weil ich aktuell IPv6 nur via 6to4 (oder ist es andersherum?) reinbekomme und vielleicht natives IPv6 bekommen kann. Vielleicht liegt mein Problem auch daran, dass aus meinem Verständnis IPv4 einfacher zu verstehen ist.

Leider nein. Der Mix der Technologien ist eben komplex.

2. Zu 1. gibt es Informationen zum Thema VOIP? Aktuell habe ich IPv4-VoIP mittels SNAT und ein paar FW-Regeln gelöst. Da wäre für mich die Frage, wie man oder ob man das bisherige Setup anpassen müsste.

Anleitungen zum Setup für VoIP mit der Fritzbox "hinter" einer OpnSense gibt es hier zuhauf.

3. Zu dem verlinkten VIMIN 8-Port, hast du genau den im Einsatz? Da würde mich im Zusammenhang interessieren, wie du den verbunden hast. Natürlich mit einem Managed Switch? Ich habe leider damals aus Kostengründen das Managed Switch nur mit 1Gbits Anschlüssen genommen. Also auch die SFP-Anschlüsse haben nur 1Gbits

Nein, der VIMIN war nur ein Beispiel für günstige Switches. Der kann ja auch kein Management, wenn Du also VLANs brauchst, musst Du noch ein Stockwerk höher greifen. Dann eventuell noch Access Points, die PoE brauchen oder 10 GbE / SFP+, usw., man kann bei Geizhals gut nach den benötigten Features suchen. Ich selbst verwende einen Unifi USW-Enterprise-24-PoE.

[mooh]

Ich kann mich nur anschließen: Der Artikel ist top! Danke für Deinen Aufwand.

Ich fürchte nur, dass auch dieser Versuch die Zahl der Anfängerfragen nicht wesentlich reduzieren wird, weil Anfänger typischerweise keine gute Vorstellung vom zu lösenden Problem haben und deswegen keine genauen Fragen formulieren können; von der Kenntnis der nötigen Worte ganz abgesehen. Vielleicht kannst Du noch auf das OSI Modell, Schichten 1-4, verweisen?

Ich glaube auch, dass man heute besser mit IPv6 anfangen sollte, weil v4 einfach mit zu vielen Hacks betrieben wird, die der erfahrene Netzwerkadmin schon gar nicht mehr als solche wahrnimmt. Mit v6 lässt sich natürlich auch Unfug treiben...

[awado]

Habe mir nun ein Netz aus OPNsense und Fritzbox mit zwei FritzRepeatern gebaut. Auf einem alten Mac Mini mit Thunderbolt-Ethernet-Adapter läuft OPNsense sehr gut. Am Adapter hängt das Glasfaser-Modem (Zugangsdaten per PPPoE), am normalen Ethernet-Anschluss hängt ein Switch. Am Switch hängen dann die AVM-Produkte. Die Fritzbox ist als IP-Client eingerichtet. Sie kann WLAN wie gehabt inkl. Mesh. Und es hängen natürlich noch andere Clients dran (Server, Drucker etc.). Was natürlich nicht mehr geht sind der MyFritz-Zugang zur Box und VPN. Aber VPN soll ja nun auch OPNSense machen. Alles in allem eine schöne Lösung. Ich hatte mit deutlich mehr Einschränkungen bei der Fritz gerechnet.

[micneu]

Super geschrieben, den kannst du auch gerne mal ins pfsense Forum packen, ich denke den würde ich oft verlinken


Gesendet von iPhone mit Tapatalk Pro