Securepoint UTM: Site-to-Site (SSL-VPN) mit Debian als Server/Gegenstelle

Seit ein paar Tagen versuche ich folgende Kombi zum Laufen zu bekommen:

Securepoint UTM als Site-to-Site-Client mit einem Debian 10 Buster als Site-to-Site-Server

+++ Gelöst: Siehe Update vom 30.06.2020 +++

Im Laufe der Jahre habe ich schon ein paar verschiedene Kombination gebaut, aber solche Schwierigkeiten wie diesmal hatte ich noch nie, zumindest nicht in Verbindung mit OpenVPN, IPsec lassen wir mal außen vor.

Grundsätzlich klappt der Verbindungsaufbau, also PKI, Verschlüsselung, ist offenbar soweit alles gut. Die Verbindung ist zudem stabil. Das gegenseitige Pingen der Tunnel-Endpunkte klappt ebenfalls. Aber z.B. der Ping von Debian aus an das LAN-Interface der UTM oder einen Server hinter der UTM klappt nicht.

Die Pakete gehen zwar vermeintlich in den Tunnel auf der Debian-Seite rein, kommen bei der UTM allerdings nicht an bzw. raus. Wunderbar beobachten kann man das mittels

tcpdump -i tun0

auf beiden Seiten.

Mit dem Securepoint-Support (Danke Jan) war ich da schon dran, aber irgendwie wusste man spontan auch nicht weiter, zumal es ja nicht an der UTM zu hängen scheint. Irgendwas läuft da auf der Debian-Seite schief.

Kurios wirkt dabei, wenn man die gleiche OpenVPN-Server-Konfiguration wie sie pfSense nutzt verwendet, das es eben bei/mit pfSense läuft, bei Debian allerdings nicht.

Als nächstes wurde eine OpenVPN-Server-Konfiguration gebaut, die in etwa der UTM-eigenen Site-to-Site-Server-Konfiguration gleicht. Wie man an die UTM-eigene Konfiguration herankommt kann man hier nachlesen:

OpenVPN-Konfiguration in verschiedenen Routern finden

Aber leider geht es auch damit nicht.

Es ist sonst nicht meine Art Cross-, Triple-, x-fach Posts an verschiedenen Stellen abzusetzen, aber ich hab‘ das Thema in verschiedenen Foren gepostet, da ich schlichtweg überhaupt nicht mehr weiter weiß:

Securepoint – Support-Forum –
Site-to-Site (SSL-VPN) mit Debian als Server/Gegenstelle

debianforum.de – Securepoint UTM Site-to-Site mit Debian als OpenVPN-Gegenstelle

OpenVPN – Support-Forum – site-to-site between Securepoint UTM & Debian – problems with routing

Da gibt es dann noch weitere Info’s und Angaben wie Config-Files, Routen, was man sonst noch getestet hat, usw.

Jede Hilfe um dieses Rätsel zu Lösen ist willkommen, sei es in den genannten Foren oder hier im Blog via Kommentar(e).

Update 30.06.2020

Gut eine Woche vergebens getestet, recherchiert und in die Tischplatte gebissen, ein Wochenende und einen halben Montag später dann Die Antwort. Ok, Spaß beiseite. So kurios das Ganze zunächst erschien, so „Marke Eigenbau“ ist der Fehler ab dem Zeitpunkt des Adaptierens der UTM-eigenen Site-to-Site-Server-Konfiguration. Warum es mit einer zuvor von einer pfSense-adaptierten Konfiguration nicht wollte habe ich noch nicht abschließend erforscht. Ist auch togal, denn je eher die Gegenstelle dem gleicht was Securepoint erwartet, desto besser.

Kurzum: Ich hab‘ vercheckt die CSC anzupassen. Hier das Original von meiner Test-UTM:

iroute 192.168.2.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"
ifconfig-push 10.8.1.2 255.255.255.0

Diese hatte ich dappischerweise 1:1 auf Debian übernommen, dabei hätten die Netze (bei iroute und push…) getauscht werden müssen.

Zur Erklärung:

  • Hinter der UTM gibt es das LAN 192.168.1.0/24.
  • Hinter dem Debian gibt es das LAN 192.168.2.0/24.

Ergo muss die jeweilige Gegenstelle eine Route zum gegenüberliegenden Netz haben.

Mit der oben gezeigten CSC wird allerdings von Debian aus auf die UTM nochmal versucht eine Route zum dort schon vorhandenen LAN zu pushen. Funktioniert natürlich nicht und erzeugt einen Fehler im Log der UTM

2020-06-29T16:06:11.562+02:00|openvpn-OpenVPN-client|4247|/sbin/ip route add 192.168.1.0/24 via 10.8.0.1
2020-06-29T16:06:11.573+02:00|openvpn-OpenVPN-client|4247|ERROR: Linux route add command failed: external program exited with error status: 2

Ich hab‘ den Fehler zwar gesehen, dachte allerdings das ist nicht mein eigentliches Problem. Falsch gedacht. Kurios oder was weiß ich was ich da evtl. noch so alles falsch gemacht habe, klappte es auch nicht mit manuell gesetzten Routen.

Schätzungsweise war ich irgendwann vor lauter trial & error blind. Unguterweise ging das manch anderen die ebenfalls auf die Konfiguration und die Logs geschaut haben offenbar ähnlich.

Lange Rede, kurzer Sinn: Hier nun eine für die UTM funktionierende OpenVPN-Site-to-Site-Server-Konfiguration für Debian (oder andere Distris):

/etc/openvpn/server.conf:

dev tun

mode server

tls-server

proto udp

tun-mtu 1500

ca ca.crt
cert OpenVPN-Server.crt
key OpenVPN-Server.key

server 10.8.0.0 255.255.255.0

topology subnet

port 1195

dh dh2048.pem

keepalive 10 120

cipher AES-256-CBC

comp-noadapt

persist-key
persist-tun

status /var/log/openvpn/openvpn-status.log

log /var/log/openvpn/openvpn.log

verb 3

explicit-exit-notify 1

auth SHA256

route 192.168.1.0 255.255.255.0

client-config-dir /etc/openvpn/csc/server

/etc/openvpn/csc/server/OpenVPN-Client:

iroute 192.168.1.0 255.255.255.0
push "route 192.168.2.0 255.255.255.0"
ifconfig-push 10.8.0.2 255.255.255.0

Die Konfiguration muss selbstverständlich für die eigene Umgebung angepasst werden. Etwas Aufmerksamkeit ist bei der Angabe des Pfads zur CSC geboten. Es muss der passende Unterordner samt Clientname sein. Zur Veranschaulichung:

/etc/openvpn/csc/<OpenVPN-Server-Konfigname>/<OpenVPN-Clientname>

Soweit läuft das im Moment. Wenn sich noch etwas ändert, gibt’s wieder ein Update.

Sorry an alle die ich genervt sowie beschäftigt habe und danke an alle, vor allem Jan von Securepoint und heisenberg aus dem debianforum, die geholfen haben.

Ein Kommentar

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.