Have a nice day - stock.adobe.c
Site-to-Site-VPN mit OPNsense und OpenVPN einrichten
Ein Site-to-Site-VPN mit OPNsense verbindet Netzwerke sicher über OpenVPN. Interne Subnetze werden über einen gerouteten TUN-Tunnel ausgetauscht. NAT ist dafür nicht erforderlich.
Ein Site-to-Site-VPN auf Basis von OpenVPN in OPNsense verbindet zwei getrennte IPv4-Netze so, dass beide Standorte ihre internen Adressbereiche unverändert austauschen. Der Tunnel arbeitet im TUN-Modus und transportiert ausschließlich Layer-3-Verkehr über UDP. Eine Adressübersetzung findet innerhalb des VPN nicht statt. Dadurch bleiben produktive Quell- und Zieladressen erhalten, Firewallregeln arbeiten mit realen Netzen und Protokolle lassen sich eindeutig zuordnen.
In unserem Beispielszenario mit OPNsense und OpenVPN nutzt der zentrale Standort das LAN 192.168.1.0/24. Der entfernte Standort arbeitet mit 192.168.2.0/24. Als Transfernetz dient 100.70.100.0/24. Dieser Bereich darf sich mit keinem internen oder extern gerouteten Netz überschneiden, da OpenVPN für jeden Tunnel eine eigenständige Layer-3-Domäne benötigt.
Die Authentifizierung erfolgt ausschließlich über TLS mit Zertifikaten. Jeder Standort besitzt ein eigenes Clientzertifikat, das eindeutig identifizierbar ist. Der Server übernimmt die Rolle der Vertrauensinstanz und entscheidet über Client Specific Overrides, welchem Zertifikat welche Tunneladresse und welche Netze zugeordnet werden.
Interne CA und Zertifikate am Serverstandort konfigurieren
Die Einrichtung beginnt mit dem Aufbau einer eigenen Zertifizierungsstelle. Unter System/Trust/Authorities öffnet man das Plus-Symbol und wählt als Methode Create an internal Certificate Authority. Die Felder für Country, Organization und Common Name erhalten feste Werte, da diese Angaben später in jedem ausgestellten Zertifikat erscheinen. Nach dem Speichern steht eine interne CA zur Verfügung, die ausschließlich für diese VPN-Infrastruktur genutzt wird.
Anschließend folgt unter System/Trust/Certificates die Erstellung des Serverzertifikats. Über das Plus-Symbol wählt man Create an internal Certificate und setzt den Typ auf Server Certificate. Als Issuer wird die zuvor angelegte CA ausgewählt. Die kryptografischen Parameter bleiben auf RSA-2048 und SHA256, da diese Kombination in OpenVPN-Umgebungen stabil und breit kompatibel ist. Die Laufzeit beträgt im gezeigten Setup 397 Tage. Nach dem Speichern steht das Zertifikat für die OpenVPN-Instanz bereit.
Im gleichen Menü wird anschließend das Clientzertifikat erzeugt. Auch hier kommt Create an internal Certificate zum Einsatz, diesmal mit dem Typ Client Certificate. Als Aussteller dient erneut die interne CA. Im Feld Common Name steht im Beispiel VPN1. Dieser Wert ist technisch relevant. Der Server nutzt ihn später im Client Specific Override zur eindeutigen Zuordnung des Tunnelendpunkts.
Zertifikatsdaten für den Clientstandort exportieren
Damit sich der entfernte Standort gegenüber dem Server authentifizieren kann, werden zwei Komponenten exportiert. Unter System/Trust/Authorities öffnet man die interne CA und lädt über Download/Certificate das CA-Zertifikat im PEM-Format herunter. Diese Datei dient dem Client später zur Prüfung des Serverzertifikats.
Unter System/Trust/Certificates öffnet man das zuvor erstellte Clientzertifikat und exportiert sowohl das Zertifikat als auch den Private Key. Beide Bestandteile gehören zwingend zusammen, da OpenVPN ohne den privaten Schlüssel keine TLS-Authentifizierung durchführen kann.
WAN-Zugriff für den OpenVPN-Server freigeben
Bevor der Tunnel aufgebaut werden kann, muss der Server eingehende Verbindungen akzeptieren. Unter Firewall/Rules/WAN wird deshalb eine Regel definiert.
Die Action steht auf Pass. Das Interface bleibt WAN, die Richtung steht auf in, das Protokoll auf UDP. Als Ziel wird This Firewall gewählt. Im Feld Destination port range trägt man 1194 als Start- und Endwert ein. Nach dem Speichern aktiviert Apply die Regel.
Ohne diese Freigabe blockiert die Firewall den Verbindungsaufbau bereits auf der WAN-Schnittstelle.
OpenVPN-Serverinstanz detailliert konfigurieren
Die eigentliche VPN-Instanz richtet man unter VPN/OpenVPN/Instances ein. Über das Plus-Symbol legt man eine neue Instanz an und setzt "Role" auf Server. Die Beschreibung dient der eindeutigen Identifikation, im Beispiel VPN/Server. Das Protokoll steht auf UDP, der Port number auf 1194. Im Feld Bind address wird die WAN-Adresse des Servers eingetragen. In Hochverfügbarkeitsumgebungen würde hier eine virtuelle CARP-Adresse stehen.
Der Gerätetyp bleibt TUN. Unter Server (IPv4) wird 100.70.100.0/24 eingetragen. Die Topology steht auf subnet, damit der Server individuelle Tunneladressen innerhalb dieses Netzes vergeben kann.
Im Abschnitt Trust wählt man als Certificate das zuvor erstellte Serverzertifikat aus. Verify Remote Certificate bleibt aktiv, und Verify Client Certificate steht auf required. Dadurch akzeptiert der Server ausschließlich Clients mit gültigem Zertifikat der internen CA.
Im Routing-Abschnitt trägt man unter Local Network das Server-LAN 192.168.1.0/24 ein und unter Remote Network das Client-LAN 192.168.2.0/24. Diese Angaben definieren die Netze, die grundsätzlich über diese Instanz erreichbar sein sollen. Nach dem Speichern aktiviert Apply die Konfiguration.
Tunnel-Interface am Server einbinden und filtern
Nach dem Start der Instanz erzeugt OPNsense intern ein OpenVPN-Device. Damit Firewallregeln greifen können, muss dieses Device einem Interface zugeordnet werden. Unter Interfaces/Assignments wählt man das Device ovpns1 (OpenVPN Server VPN/Server) aus und fügt es mit Add hinzu. Anschließend öffnet man das neue Interface, aktiviert Enable Interface und speichert. Die IPv4- und IPv6-Konfiguration bleibt auf None, da die Tunneladressierung über das zuvor definierte Transfernetz erfolgt.
Erst danach erscheint unter Firewall/Rules ein eigenes Menü für dieses Interface. Dort wird eine Regel definiert, die Verkehr aus 192.168.2.0/24 in Richtung 192.168.1.0/24 erlaubt. Das Protokoll bleibt auf any. Ohne diese Regel steht zwar der Tunnel, jedoch blockiert die Firewall den Übergang in das interne Netz.
Client Specific Override korrekt setzen
Die feste Zuordnung des entfernten Standorts erfolgt unter VPN/OpenVPN/Client Specific Overrides. Ein neuer Eintrag wird angelegt und der Serverinstanz zugewiesen. Im Feld Common name steht VPN1, also der Wert des Clientzertifikats. Unter IPv4 Tunnel Network trägt man 100.70.100.2/32 ein. Damit erhält der Client eine feste Tunneladresse.
Local Network enthält 192.168.1.0/24 und Remote Network schließlich 192.168.2.0/24. Nach dem Speichern ordnet der Server diese Netze eindeutig diesem Zertifikat zu.
CA und Clientzertifikat am entfernten Standort importieren
Am Clientstandort beginnt die Einrichtung mit dem Import der CA. Unter SystemTrust/Authorities wählt man Import an existing Certificate Authority. Als Description dient CA-OpenVPN. In Certificate data fügt man den vollständigen PEM-Inhalt ein. Das Feld für den Private Key bleibt leer, da dieser ausschließlich auf dem Server verbleibt.
Anschließend importiert man unter System/Trust/Certificates das Clientzertifikat über Import an existing certificate und fügt sowohl Zertifikat als auch Private Key ein.
Firewall und Clientinstanz konfigurieren
Unter Firewall/Rules/WAN definiert man eine Regel, die UDP-Verkehr zur öffentlichen Adresse des Servers auf Port 1194 erlaubt.
Bei Firewall/Rules/LAN wird zusätzlich eine Regel angelegt, die Verkehr aus 192.168.2.0/24 in Richtung 192.168.1.0/24 freigibt.
Die Clientinstanz richtet man unter VPN/OpenVPN/Instances ein. Die Rolle steht auf Client. Das Protokoll bleibt UDP, der Gerätetyp TUN. Im Feld Remote steht die öffentliche Adresse des Servers inklusive Port 1194. Als Zertifikat wählt man das importierte Clientzertifikat. Verify Remote Certificate bleibt aktiviert. Die Felder Local Network und Remote Network bleiben leer, da der Server die Routen verteilt.
Nach dem Speichern aktiviert man die Instanz, weist das neue Device unter Interfaces/Assignments zu und definiert unter dem entsprechenden Interface eine Regel, die Verkehr aus 192.168.1.0/24 in Richtung 192.168.2.0/24 erlaubt.
Funktionsprüfung und typische Fehlerquellen
Unter VPN/OpenVPN/Connection Status sieht man auf beiden Standorten die zugewiesene Tunneladresse und die aktiven Routen.
Ein Ping zwischen einem Host im Server-LAN und einem Host im Client-LAN bestätigt die Funktion. Bleibt der Verkehr einseitig, liegt die Ursache in der Praxis fast immer in fehlenden Interface-Regeln oder in einem nicht exakt übereinstimmenden Common Name im Client Specific Override.
