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.
Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.
0 Kommentare
1 Pingback