OPNsense als Standort mit WireGuard anbinden

Was ein Standort ist

Eine OPNsense legen Sie als Standort an, nicht als Gerät. Der Unterschied ist nicht formal: Bei einem Standort tragen Sie das Netz dahinter ein — etwa 192.168.153.0/24 — und damit wird alles in diesem Netz erreichbar. Der Server, der Drucker, die Anlage im Keller. Ohne diese Angabe erreichen Sie nur die Firewall selbst.

Die Firewall braucht keine öffentliche IPv4-Adresse und keine Portfreigabe. Sie ruft von sich aus hinaus; an DS-Lite- und Mobilfunkanschlüssen funktioniert das genauso.

Hat die OPNsense mehrere Netze — LAN, WLAN, ein Gastnetz —, tragen Sie sie durch Komma getrennt in dasselbe Feld ein. Erreichbar wird, was dort steht, und nur das.

Beschrieben für OPNsense 25.7 und 26.x, wo WireGuard fest eingebaut ist (VPN → WireGuard). Bei älteren Fassungen mit dem Zusatzpaket os-wireguard heißen die Reiter Local und Endpoints statt Instanzen und Peers; die Werte sind dieselben. Auf englischen Installationen stehen die englischen Feldnamen in Klammern.

Was Sie brauchen

OPNsense importiert keine .conf-Datei — Sie tragen die Werte von Hand ein. Vier Angaben brauchen Sie dafür, und die stehen alle im Kundenbereich unter Fernzugriff beim jeweiligen Kunden, unter „Von Hand einrichten“ bei der Gegenstelle:

• Adresse im Tunnel
• AllowedIPs — die erreichbaren Netze
• Schlüssel der Gegenstelle — unser öffentlicher Schlüssel
• Gegenstelle (Endpunkt): vermittlung.idodns.de:51820

Ein PresharedKey steht dort nicht, und das ist kein Versehen: Wir setzen keinen. Siehe den Kasten oben.

Einrichten

Die Reihenfolge ist nicht beliebig: Den Schlüssel erzeugt die Firewall, die Tunneladresse vergeben wir. Beides braucht die andere Seite — deshalb wird die OPNsense zweimal angefasst.

1. In OPNsense die Instanz anlegen und den Schlüssel erzeugen

   VPN → WireGuard → Instanzen (Instances) → +

   Aktiviert (Enabled)

   an

   Name

   IDOVPN

   Öffentlicher / Privater Schlüssel

   erzeugen lassen (Zahnrad neben dem Feld)

   Listen-Port

   leer lassen

   MTU

   leer lassen

   Tunneladresse (Tunnel Address)

   noch leer — kommt in Schritt 4

   Speichern. Danach zeigt die Liste den öffentlichen Schlüssel der Instanz — 44 Zeichen, endet auf =. Den kopieren Sie jetzt. Der geheime Teil bleibt in der Firewall und wird uns nie gezeigt.

   Der Listen-Port spielt keine Rolle. Die Verbindung geht von innen nach außen; niemand ruft die Firewall von außen an. Eine Freigabe auf der WAN-Seite brauchen Sie deshalb nicht — und sollten Sie auch nicht anlegen.

2. Im Kundenbereich die Gegenstelle anlegen

   Fernzugriff → Kunde auswählen → Art: Standort → unter „Netze hinter diesem Standort“ die Netze eintragen, die die OPNsense bedient — mehrere durch Komma getrennt, etwa 192.168.153.0/24, 192.168.20.0/24 → den kopierten öffentlichen Schlüssel einfügen.

   Danach stehen unter „Von Hand einrichten“ die Angaben, die die Firewall noch braucht.

   Der Schlüssel lässt sich später nicht ändern. Erzeugt die Firewall ihn neu, legen Sie die Gegenstelle neu an; das dauert eine Minute.

3. Zurück in OPNsense: den Peer eintragen

   VPN → WireGuard → Peers → +

   Aktiviert (Enabled)

   an

   Name

   IDO DNS Service

   Öffentlicher Schlüssel (Public Key)

   „Schlüssel der Gegenstelle“ aus dem Kundenbereich

   Gemeinsames Geheimnis (Shared Secret)

   leer lassen

   Erlaubte IPs (Allowed IPs)

   „AllowedIPs“ aus dem Kundenbereich, z. B. 10.80.7.0/24, 10.80.9.0/24

   Endpunkt-Adresse (Endpoint Address)

   vermittlung.idodns.de

   Endpunkt-Port (Endpoint Port)

   51820

   Keepalive

   25

   Instanzen (Instances)

   die Instanz aus Schritt 1

   Bei den erlaubten IPs steht Ihr eigenes Netz nicht dabei: Die Firewall sitzt darin und würde ihren eigenen Verkehr in den Tunnel schicken. Und dort gehört auch kein 0.0.0.0/0 hin — das leitete den gesamten Internetverkehr des Hauses über den Tunnel.

   Ohne Keepalive bricht die Verbindung an Anschlüssen mit Adressumsetzung beim Anbieter nach kurzer Zeit ab und kommt erst beim nächsten Zugriff von innen wieder — Sie erreichen den Standort dann von außen nicht.

4. Die Instanz um Tunneladresse und Peer ergänzen

   Zurück auf Instanzen, die Instanz bearbeiten:

   Tunneladresse (Tunnel Address)

   „Adresse im Tunnel“ aus dem Kundenbereich, mit /32 dahinter — z. B. 10.80.7.2/32

   Peers

   den Peer aus Schritt 3

   Die /32 gehört dazu. Ohne sie nimmt OPNsense je nach Fassung /24 an und legt eine Route für das ganze Tunnelnetz über die eigene Adresse — dann antwortet die Firewall sich selbst.

   Speichern, dann oben auf der Seite WireGuard aktivieren und Anwenden. Unter VPN → WireGuard → Status muss innerhalb einer halben Minute ein Letzter Handschlag erscheinen.

5. Die Schnittstelle zuweisen

   Schnittstellen → Zuweisungen (Assignments) → das Gerät wgX hinzufügen → die neue Schnittstelle öffnen:

   Schnittstelle aktivieren

   an

   Beschreibung

   IDOVPN

   IPv4-Konfigurationstyp

   Keine (None)

   IPv6-Konfigurationstyp

   Keine (None)

   Der Handschlag steht auch ohne diesen Schritt — aber ohne zugewiesene Schnittstelle gibt es keinen Ort für die Regel im nächsten Schritt, und ohne Regel kommt kein Paket durch.

6. Eine Firewall-Regel anlegen

   Firewall → Regeln → [Ihre neue Schnittstelle] → +

   Aktion

   Weiterleiten (Pass)

   Schnittstelle

   die neue Schnittstelle

   Richtung

   eingehend (in)

   Protokoll

   beliebig

   Quelle

   die Tunnelnetze aus „AllowedIPs“ — als Netz eingetippt, z. B. 10.80.7.0/24

   Ziel

   das Netz hinter der OPNsense — oder enger, z. B. 192.168.30.0/24

   Quelle und Ziel nicht verwechseln. Ein Paket, das aus dem Tunnel hier ankommt, hat als Absender eine Tunneladresse und als Ziel ein Gerät bei Ihnen — also Tunnelnetz → eigenes Netz. Andersherum beschreibt die Regel einen Weg, den es nicht gibt; sie lässt sich widerspruchsfrei speichern und erlaubt nichts.

   Nicht „[Schnittstelle] Netzwerk“ als Quelle wählen. Dieser Eintrag der Auswahlliste löst sich aus der Adresse der Schnittstelle auf — und die hat hier keine, denn ihr IPv4-Konfigurationstyp steht auf Keine (Schritt 5). Die Regel steht dann da, sieht richtig aus und trifft kein einziges Paket. Tragen Sie die Netze selbst ein, etwa 10.80.7.0/24; bei mehreren ein Alias unter Firewall → Aliase (Typ Netzwerk(e)).

   Ein Alias muss alle Netze aus „AllowedIPs“ enthalten. Fehlt eines, greift die Regel für einen Teil Ihrer Geräte nicht — und zwar unauffällig: Von einem Rechner geht es, vom nächsten nicht, und beide sehen im Kundenbereich gleich aus. Vergleichen Sie den Alias Zeile für Zeile mit den erlaubten IPs des Peers.

   Setzen Sie das Ziel so eng, wie es Ihre Arbeit zulässt. Eine Regel auf „beliebig“ ist schnell gebaut und öffnet alles, was hinter der Firewall steht. Wer nur an drei Server muss, trägt drei Adressen ein — und spart sich die Frage, die beim nächsten Audit ohnehin kommt.

   Kein NAT. Der Verkehr soll geroutet werden, nicht umgeschrieben: Sonst sieht jedes Gerät im Netz die Firewall als Absender, und im Protokoll steht nicht mehr, wer wirklich zugegriffen hat.

7. Prüfen, dass die Verbindung steht

   Unter VPN → WireGuard → Status steht ein Letzter Handschlag vor wenigen Sekunden. Im Kundenbereich wechselt die Gegenstelle im selben Takt auf „Verbunden“. Danach erreichen Sie ein Gerät im Netz dahinter — probeweise mit einem Ping von einem anderen Standort aus.

   Prüfen Sie von außen, nicht von innen. Sitzen Sie gerade in dem Netz, das hinter der OPNsense liegt, führt jeder Weg dorthin ohnehin am Tunnel vorbei — und ist der Tunnel auf Ihrem Laptop an, überschneiden sich sein AllowedIPs mit dem Netz um Sie herum, und Antworten kommen nicht mehr an. Ein Mobilfunk-Hotspot ist der schnellste andere Standort.

   Zwei Adressen taugen nicht als Ziel einer Probe: die Tunneladresse der OPNsense selbst — die Regel aus Schritt 6 erlaubt den Weg in das Netz dahinter, nicht zur Firewall — und die Vermittleradresse 10.80.0.1, die in den erlaubten IPs gar nicht steht. Nehmen Sie ein Gerät im Kundennetz.

Wenn es nicht klappt

Kein Handschlag, gar nichts

Prüfen Sie zuerst, ob Instanz und Peer einander kennen: In der Instanz muss der Peer ausgewählt sein. Das ist der häufigste Fall, und er sieht aus wie ein Netzproblem.

Handschlag da, aber kein Paket kommt an

Dann fehlt fast immer die Firewall-Regel auf der WireGuard-Schnittstelle — oder die erlaubten IPs beim Peer decken das Netz nicht ab, das Sie erreichen wollen. Beides lässt den Tunnel „grün“ aussehen.

Handschlag da, Zähler steigen, trotzdem nichts erreichbar

Sehen Sie unter System → Routen → Status nach, welche Adresse die Firewall im Tunnel führt: die Zeile mit lo0 und dem Kennzeichen UH im Bereich 10.80.. Steht dort eine andere Adresse als die im Kundenbereich, ist die Tunneladresse der Instanz falsch — der Tunnel steht, die Antworten laufen ins Leere. Korrigieren Sie sie unter VPN → WireGuard → Instanzen (Schritt 4); Anwenden genügt, neu anlegen muss man nichts.

Regel steht, und es geht trotzdem nicht

Lesen Sie die Regel laut vor: von Tunnelnetz nach eigenem Netz. Steht es umgekehrt, oder steht in der Quelle „[Schnittstelle] Netzwerk“, trifft sie kein Paket. Unter Firewall → Protokolldateien sehen Sie es direkt: Der Verkehr taucht dort als blockiert auf, mit Absender aus 10.80. und der Bezeichnung Default deny / state violation rule. Der Absender in dieser Zeile ist die Antwort: Er muss in Ihrer Regel — oder in deren Alias — enthalten sein.

Es geht kurz und bricht dann ab

Keepalive steht nicht auf 25. An Anschlüssen mit Adressumsetzung beim Anbieter schließt sich der Rückweg nach ein bis zwei Minuten Stille.

Vom Kundennetz aus erreichbar, von Ihnen aus nicht

Die Gegenrichtung braucht ihre eigene Zulassung: Prüfen Sie, ob bei dieser Gegenstelle im Kundenbereich eine Zugriffsgrenze gesetzt ist, die das Ziel ausschließt.

Nach einem Neustart ist alles weg

Dann wurde die Instanz gespeichert, aber WireGuard nicht aktiviert oder Anwenden nicht gedrückt. Der Schalter sitzt oben auf der Seite Instanzen.

Namen und Zertifikate

Zu jedem Kundennetz gehören Namen für die Geräte im Netz und ein Zertifikat dazu, damit der Browser keine Warnung mehr zeigt. Für die OPNsense selbst lohnt sich das besonders: Ihre Oberfläche ruft man oft auf, und Nicht sicher in der Adresszeile gewöhnt man sich an — bis man eine echte Warnung übersieht.

OPNsense nimmt ein Zertifikat unter System → Vertrauen → Zertifikate entgegen und wird unter System → Einstellungen → Administration darauf umgestellt. Wie Sie Name und Zertifikat bekommen, steht bei Zertifikate für Geräte im Kundennetz.

Wie es weitergeht

Steht der Handschlag und kommt der Ping durch, ist das Netz hinter der OPNsense erreichbar — vom Laptop und vom Telefon aus, jedes als eigene Gegenstelle. Die Firewall selbst kann jetzt auch ihr Zertifikat täglich abholen und einspielen: OPNsense: Zertifikat automatisch abholen — danach ist die Adresszeile still.

Für den Windows-Server dahinter gilt dasselbe unter Remotedesktop ohne Zertifikatswarnung. Und weil der Linux-Server hinter dieser Firewall nun durch den Tunnel erreichbar ist, ist seine Sicherung mit BorgBackup in den Cloud-Speicher die nächste halbe Stunde, die sich lohnt.