Anleitung IPSec VPN Tunnel an OPNSense für TI-Gateway, EDIT: + Infos für Homeoffice über VPN

Sebastian Mai

Hallo zusammen,

da es die Meisten in irgendeiner Form betreffen wird und ein bisschen Ausprobieren notwendig war um die Konfiguration des IPSec-Tunnels an der OPNSense hinzubekommen, schreibe ich das ganze einfach mal hier ins Forum. Vielleicht hift es dem Ein oder Anderen ja bei der Einrichtung:

Für die Verbindung zum TI-Gateway kann man an der Firewall (bei mir OPNSense) eine Site-to-Site-VPN-VErbindung einrichten. Die Zugangsdaten kann man im ConnectiKey-Portal nach Freischaltung durch Tomedo abrufen.

Leider wird der "Alte" Einstellungsmodus an der OPNSense nicht mehr weiter supportet (hierfür gab es eine Anleitung seitens Tomedo) sodass ich die Einstellungen für die neue "Verbindungen"-Methode hier poste.

Als erstes wird ein Virtuelles Tunnel-Interface angelegt. (VPN -> IPSec -> Virtuelle Tunnelschnittstelle) (VPN funktioniert nur im VTI-Modus, daher später "Richtlinien" bei Phase 2 deaktivieren, sonst klappt es nicht).

Als nächstes die Tunnel-Schnittstelle zuweisen:

Über Schnittstellen -> Zuweisungen -> eine neue Schnittstelle Anlegen: Gerät (ipsec1 (KIM)) und Beschreibung: KIM

Dann Preshared Key anlegen (VPN -> IPSec -> Preshared Keys):

Anmerkung: in der aktuellen Version der OPNSense kann man keinen Unterstrich (_) eingeben. Siehe hierzu: https://github.com/opnsense/core/issues/9276

Dies soll wohl mit der nächsten Version repariert werden. Solange kann man sich per SSH auf die OPNSense einloggen, dort dann mit 8 auf die Shell gehen und mit dem Kommando:

opnsense-patch 5c845f4

einen entsprechenden Patch herunterladen. (Vielen Dank an Kommunity mac+net solutions)

Danach unter VPN -> IpSec - Verbindungen die eigentlichen Verbindungseinstellungen anlegen:

Danach die Authentifizierungen anlegen, lokal und Remote:

EDIT: Die ursprüngliche Angabe hier mit definierten Phase 2 Netzen hat zwar eine Verbindung zum Konnektor zugelassen, die Pakete, die in die Bestandsnetze der TI gingen, kamen jedoch auf dem WAN-Interface zurück und wurden dann von der Firewall geblockt.

Letztlich funktioniert es mit einer "Any-Regel" im Phase-2-Kontext, wenn "Richtlinien" deaktiviert wird und die Routen in die TI-Netze dann später korrekt über das Gateway gesetzt werden. (siehe unten). An der Stelle vielen Dank an Herrn Voss von Zollsoft für die Ausdauer bei der Fehlersuche.

Wichtig ist Richtlinen zu deaktivieren, da sonst der VTI-Modus nicht funktioniert.

Als ESP-Vorschläge: aes256-sha512-ecp256, aes256gcm16-sha512-ecp256

Danach noch unter System -> Gateways -> Konfiguration ein neues Gateway anlegen:

Name: TI-Tunnel

Schnittstelle: KIM

Adressfamilie ipv4

Prio 255

IP-Adresse: Remote-Tunnel-IP

Upstream-Gateway: nein

Remote-Gateway: ja

Gateway-Überwachung deaktivieren: ja

Gateway inaktiv markieren: nein

Dann noch unter System -> Routen -> Konfiguration -> Route hinzufügen:

Netwerkadresse: 100.106.0.0/20

Gateway: TI-Tunnel

Die übrigen Routen sollten schon definiert sein und müssen dann nur auf das neue Gateway umgestellt werden.

Es müssen noch 2 Outbound-NAT-Regeln angelegt werden, sodass das TI-Netz die Pakete mit der Tunnel-IP bekommt:

Als Interface muss hier das IPSec (nicht KIM-Interface) für die NAT-Regel ausgewählt werden. Vorbelegt ist normalerweise das WAN-Interface.

Homeoffice:

EDIT: Damit auch der Zugriff auf den Konnektor von zuhause funktioniert, müssen noch ein paar Einstellungen erledigt werden:

1) Verbindung zum Homeoffice:

a) Wireguard: Wird ein Wireguard-Tunnel verwendet, so wird die originäre IP aus dem Heimnetzwerk übertragen. Wird also z.B. zuhause die 192.168.150.0/24 verwendet, so muss bei einem Wireguard-Tunnel auch dieses Netz freigegeben werden (s. unter 2.).

b) Open-VPN: Bei Open-VPN erhält der VPN-Teilnehmer im Homeoffice eine IP aus dem Bereich des sog. Transportnetzes. Dieses muss dann freigegeben werden. Somit bleibt der Adressbereich der zuhause verwendet wird auch unwichtig. Dies macht es also für einen Gebrauch unterwegs bedeutend interessanter, da man ja nie weiß, welchen IP-Bereich man z.B. im Urlaub / mobiles Netz bei Hausbesuchen oder so hat.

2) Freigabe im Konnektor:

Im Portal von ConnetiKey (https://portal.connecti.service-ti.de/) kann man die entsprechenden Netze dem Konnektor hinzufügen:

Konnektor -> Details

Wenn man dann auf "Bearbeiten" klickt, kann man über Netzwerk hinzufügen die entsprechenden Netzwerke einfügen.

Durch die Angabe der Netze im Phase2-Eintrag mit 0.0.0.0/0 gehen dann auch automatisch die Homeoffice-Netze durch den Konnektor. Ein weiterer Phase2-Eintrag soll nicht erfolgen.

Nachtrag:

Wenn man die DNS-Abfragen entsprehcend der Zollsoft-Anleitung auf den Konnektor weiterschickt (siehe https://support.tomedo.de/handbuch/tomedo/telematikinfrastruktur-ti/ports-und-routen-fuer-die-ti/) (OPN-Sense -> Dienste -> UnboundDNS -> Abfrage-Weiterleitungen), muss man noch die Domains als private Domains unter Erweitert hinterlegen.

siehe hier:

und die 100.64.0.0/10 aus der Liste der Ribind-Schutznetzwerke nehmen. (Der Adressbereich 100.102.0.0/15 liegt in diesem Netzwerkbereich (100.64.0.0/10 = 100.64.0.0 bis 100.127.255.255)

.... ich hoffe ich hab kein Detail vergessen ;-)

Nachtrag:

1) Firewallregeln: Allow-All-Regel (alternativ im Verlauf einschränken?) auf der KIM- und dem IPSec-Schnittstelle

2) Firewall Regeln Überspringen bei Tunellschnittstelle.

Auf Dauer funktioniert es nur (siehe unten) wenn man die Option aktiviert.

-->>> Danke für die Hinweise ;-)

Hermann Burau

Vielen Dank!!!

Dennis Voß

Danke noch einmal für das rasche Überarbeiten und zur Verfügung stellen der Konfiguration. Mir ist gestern bei einer anderen Praxis noch aufgefallen, dass man, falls ein Router vor der OPNSense steht, in der virtuellen Tunnelschnittstelle den Punkt "Firewallregeln überspringen" aktivieren muss. Ansonsten kommt der Traffic im Rechenzentrum nicht genattet an, obwohl eine NAT-Regel existiert.

Sebastian Mai

Die DNS-Weiterleitung scheint ein Problem zu sein. Wenn man die DNS-Weiterleitung auf den Konnektor deaktiviert funktioniert es alles prima. ;-) Woran das letztlich liegt vermag ich nicht so recht zu sagen...

Tilman Hesse

Sehr geehrter Herr Mai,

danke für Ihre ausführlichen Informationen.

Was die TI DNS angeht - beim Gateway soll nur ".telematik" über den HSK aufgelöst werden, die "ti-dienste.de" nicht mehr. Das ist eine Änderung gegenüber dem bisherigen Konnektor. Ich passe das im Handbuch an.

Katharina Wieder

Hallo Herr Hesse,

wir haben eine SonicWall Firewall. Wissen Sie, ob es damit schon erfolreiche Konfigurationen gab?

Bernhard Unkel

Zunächst einmal vielen Dank Herr Mai für die Anleitung, die mir sehr geholfen hat.

Ich kann bestätigen, dass, entgegen der geforderten Weiterleitung auf den HSK, erst die Deaktivierung eine Auflösung der kim.telematik ermöglichte. Auch bei mir funktioniert es seit 2 Tagen problemlos.

Meines Erachtens sollte bei der Anlage des Tunnelschnittstelle "Firewallregel überspringen" grundsätzlich ausgewählt werden, da dies unabhängig vom Vorhandensein möglicher weiterer IPsec Verbindungen die Regelgestaltung vereinfacht, da hier nur die enc0 (IPsec) Schnittstelle beachtet werden muss und nicht zusätzlich die virtuelle Schnisstelle ipsecX.

Mussten Sie auch auf der IPsec Schnittstelle eine Regel erstellen um überhaupt NAT outbond zu ermöglichen?

Es hat lange gebraucht, bis ich darauf gekommen bin, weil ich davon ausging, dass Verkehr nach draussen ohne Regel funktionieren würde und nur Verkehr von aussen nach drinnen, wenn von aussen initiert, freigegeben werden muss.

Sebastian Mai

Hallo,

Freut mich, dass es Ihnen geholfen hat.

Die Firewall-Regeln hab ich in der Anleitung tatsächlich ganz vergessen. Habs nachgetragen. Danke für den Hinweis.

lg

Sebastian Mai

Bernhard Unkel

Ich möchte meine Erfahrungen an dieser Stelle nochmals zusammenfassen.

Ohne diese tolle Anleitung (s.o.) hätte ich es sehr viel schwerer gehabt.

1. Konfiguration wie oben beschrieben.

Wie gesagt habe ich mich bei der Konfiguration der Tunnelschnittstelle dazu entschieden die Firewallregel zu überspringen (skip firewall rules). Ohnehin ist es Pflicht wenn man zusätzlich eine policy based IPsec Konfiguration hat, macht es aber darüberhinaus insofern einfacher, weil nur auf einer Schnittstelle IPsec Regeln definiert werden müssen, auf IPsec (enc0).

Hier kann aber nur der IPsec Verkehr geregelt werden:

Schnittstelle IPsec: Eine any2any Regel

Alle weitere Regeln werden auf der Schnittstelle definiert in der sich der Rechner mit Tomedo Server befindet. In meinem Fall 192.168.115.0/24. Dort kann man dann festlegen, ob nur der Rechner mit Tomedo Server oder Clients etc Zugriff auf das TI Netzwerk haben dürfen oder nicht. Muss man aber nicht. Wenn jemand OPNsense nutzt, gehe ich davon aus, dass er ohnehin verschiedene Netzsegmente definiert hat: IT, IoT, VoIP, Gäste und was auch immer und wie bei mir, ein Praxisnetzwerk, in dem sich alle Arbeitsplätze/ Drucker (was auch immer) des Praxissystems finden (192.168.115.0/24). Die sollen alle miteinander reden dürfen.

Da ich auf dem HSK (Gateway Konrektor) mein Netz definieren muss (192.168.115.0/24), das Zugriff haben darf, muss ich mir keine Sorgen machen, dass Clients aus den anderen Netzwerksegmenten Zugriff auf das TI Netzwerk haben.

2. In unbound wurde der Adressbereich im Rebind Schutznetzwerk für CGNAT entfernt (100.64.0.0/10), da sich darin auch der Netzwebereich der Offenen Fachdienste befindet. Habe keine Ahnung wie sicherheitsrelevat dies tatsächlich ist. Im Internet sind die Meinungen dazu unterschiedlich. Möchte man allerdings nur den Bereich um 100.102.0.0/15 aus dem Rebind Schutz herausnehmen, kann man folgende Adressbereiche nach Löschen der CGNAT wieder hinzufügen (chatGPT sei Dank):

100.64.0.0/11
100.96.0.0/14
100.100.0.0/15
100.104.0.0/13
100.112.0.0/12

3. Die DNS Auflösung war ein Problem bei mir. Ich denke die Weiterleitungsregel in unbound hat bei mir nicht funktioniert. Der Konnektor ist kein DNS Dienst im klassischen Sinn und löst daher auch keine DNS Abfragen, so wie es unbound versteht, auf. Diese Einstellung habe ich deaktiviert.

KIM Dienste funktionierten bei mir nicht, weil ich unbound als rekursiven DNS Dienst nutze, wie wahrscheinlich die meisten mit OPNsense. Meine Clients bekommen alle daher vom DHCP eine private Adresse (RFC1918) als DNS Server mitgeteilt oder ich stelle manuell die Adresse der Firewall oder meines DNS Dienstes (Adguard, pihole, etc.) ein.

Nun schienen die TI Dienste privaten Adressen weniger zu vertrauen als öffentlichen DNS Diensten (9.9.9.9 oder 1.1.1.1 etc.). So habe ich die Erfahrung gemacht, dass zur Registrierung des KIM Dienstes eine öffentlicher DNS Dienst notwendig ist. Mit manuellem Eintrag in den Netzwerkeinstellungen des Tomedo Servers war das Problem gelöst.

Dank an Herrn Voss, der sich trotz reichlich anderer Arbeit sich für mich kurz Zeit genommen hat, um eine OPNsense- und nicht Tomedo- Frage zu beantworten. Hat meinen Tag gerettet!

Interessanterweise braucht es nach erfolgreicher Registrierung des KIM Dienstes erst einmal keine öffentlichen DNS Resolver mehr. Ich dachte ich wäre klüger, und könnte das Problem eleganter als durch manuelles Zufügen im Tomedo Server lösen. Ich hatte daher bei meinen Testabfragen immer Erfolg - bis zum nächsten Morgen.

Soweit eingestellt, startet um 01:00 Uhr das KIM Modul neu und registriert sich wieder, brauchte also wieder einen öffentlichen DNS Server Eintrag in den Einstellungen des Rechners auf dem der Tomedo Server läuft. Also fügte ich wieder manuell einen öffentlichen DNS Server im Rechner mit dem Tomedo Server hinzu.

Da ich nicht auf AdguardHome und unbound in meinem Setting verzichten möchte, scheint dies die einzige Möglichkeit zu sein.

Ich freue mich auf Anregungen und Kommentare.

Bernd Unkel

Dirk Schemmann

Vielen Dank für den Beitrag!

Nur eine kurze Frage/Anmerkung: Muss man beim PSK nicht LokaleIP und RemoteIP angeben? Im neuen IPSec-Verfahren werdend doch die PSKs den IPs bzw. DNS-Namen zugeordnet.

Sebastian Mai

Hallo,

in den Einstellungen steht bei der deutschen Übersetzung "lokaler Bezeichner" Es ist tatsächlich die ID nicht die IP. also hsk... so wie oben dargestellt.

lg

Sebastian Mai