[gelöst] Securepoint UTM Site-to-Site mit Debian als OpenVPN-Gegenstelle
Re: Securepoint UTM Site-to-Site mit Debian als OpenVPN-Gegenstelle
Mit NoPaste hab' ich noch nicht gearbeitet, hoffe das ist so richtig und hat geklappt.
Ich hab' verbosity mal auf 9 gesetzt und das Log inkl. zwei Ping-Versuche erfasst.
Hier die Debian-Seite:
pastebin/?mode=view&s=41074
Auf der UTM steht verbosity auf 4 und aus dem Syslog konnte ich das hier ziehen:
pastebin/?mode=view&s=41075
Ich hab' verbosity mal auf 9 gesetzt und das Log inkl. zwei Ping-Versuche erfasst.
Hier die Debian-Seite:
pastebin/?mode=view&s=41074
Auf der UTM steht verbosity auf 4 und aus dem Syslog konnte ich das hier ziehen:
pastebin/?mode=view&s=41075
- heisenberg
- Beiträge: 3567
- Registriert: 04.06.2015 01:17:27
- Lizenz eigener Beiträge: MIT Lizenz
Re: Securepoint UTM Site-to-Site mit Debian als OpenVPN-Gegenstelle
Hast Dir das selbst mal angeschaut?
Jede Rohheit hat ihren Ursprung in einer Schwäche.
Re: Securepoint UTM Site-to-Site mit Debian als OpenVPN-Gegenstelle
Meinst du den pastebin oder das Log generell?
Habe mir beides angesehen, mehrfach sogar.
Allerdings bei höheren Verbosity-Level der Logs verstehe ich nicht mehr alles.
Du fragts bestimmt wegen dem hier im UTM-Log (Zeilen 39 und 40, sowie 92 und 93):
Hab' ich gesehen und ist erst relativ neu (bei den letzten ein-zwei Versuchen glaub' ich aufgetaucht).
Das würde meines Wissens nach (korrigier mich, falls ich falsch liege) allerdings nicht erklären, warum man im tcpdump keine ICMP-Pakete durch den Tunnel ankommen sieht.
Und falls dieses hier auf der Debian-Seite gemeint ist (Zeile 293):
Habe ich auch gesehen und ist klar soweit. Wie erwähnt, ist erstmal nur ein Test-Aufbau und im gleichen Netz funktioniert's ja auch mit der Kombi UTM -> pfSense.
Die Logs habe ich gerade, nach diesem Wochenende und einem jetzt etwas freierem Kopf, nochmals überflogen.
Falls mir sonst noch etwas durch die Lappen gegangen sein sollte, lass' es mich Wissen.
Habe mir beides angesehen, mehrfach sogar.
Allerdings bei höheren Verbosity-Level der Logs verstehe ich nicht mehr alles.
Du fragts bestimmt wegen dem hier im UTM-Log (Zeilen 39 und 40, sowie 92 und 93):
Code: Alles auswählen
2020-06-26T11:20:54.367+02:00|openvpn-OpenVPN-client|23341|/sbin/ip route add 192.168.1.0/24 via 255.255.255.0
2020-06-26T11:20:54.370+02:00|openvpn-OpenVPN-client|23341|ERROR: Linux route add command failed: external program exited with error status: 2
Das würde meines Wissens nach (korrigier mich, falls ich falsch liege) allerdings nicht erklären, warum man im tcpdump keine ICMP-Pakete durch den Tunnel ankommen sieht.
Und falls dieses hier auf der Debian-Seite gemeint ist (Zeile 293):
Code: Alles auswählen
Fri Jun 26 11:57:34 2020 us=209338 NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x. Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.
Die Logs habe ich gerade, nach diesem Wochenende und einem jetzt etwas freierem Kopf, nochmals überflogen.
Falls mir sonst noch etwas durch die Lappen gegangen sein sollte, lass' es mich Wissen.
- heisenberg
- Beiträge: 3567
- Registriert: 04.06.2015 01:17:27
- Lizenz eigener Beiträge: MIT Lizenz
Re: Securepoint UTM Site-to-Site mit Debian als OpenVPN-Gegenstelle
Code: Alles auswählen
2020-06-26T11:20:54.367+02:00|openvpn-OpenVPN-client|23341|/sbin/ip route add 192.168.1.0/24 via 255.255.255.0
2020-06-26T11:20:54.370+02:00|openvpn-OpenVPN-client|23341|ERROR: Linux route add command failed: external program exited with error status: 2
Ich habe mir die Konfig von Dir jetzt nicht im einzelnen angesehen, aber der ip route Befehl sieht falsch aus. Dort wo das IP-Gateway stehen sollte, steht eine Netzmaske. Evtl. Wert in der GUI falsch eingetragen?
Jede Rohheit hat ihren Ursprung in einer Schwäche.
Re: Securepoint UTM Site-to-Site mit Debian als OpenVPN-Gegenstelle
Das wird vom Debian-OpenVPN-Server so gepusht.
Bei der Site-to-Site-Client-Einrichtung in der UTM wird man ja lediglich nach Name+Zertifikat, IPv6 ja/nein und Gegenstelle gefragt.
Ich habe die Testumgebung gerade mal gestartet (war heute noch nicht dran).
Hier der aktuelle Log-Auszug zu diesem Punkt:
Unabhängig davon: Wenn man die Routen per Hand setzt, ganz gleich auf welcher Seite, funktioniert es auch nicht.
Und der Vollständigkeit halber: Wenn man von Debian aus versucht über das VPN die UTM (192.168.1.1) zu pingen, hat man das gleiche "Fehlverhalten" wie wenn man versucht den Server (192.168.1.10) hinter der UTM zu pingen.
By the way: Als ich von "tcpdump -i any ICMP" geschrieben habe, war die Syntax falsch. Richtig wäre "tcpdump ICMP -i any", dadurch wird auf allen verfügbaren Interfaces nach ICMP Ausschau gehalten.
Bei der Site-to-Site-Client-Einrichtung in der UTM wird man ja lediglich nach Name+Zertifikat, IPv6 ja/nein und Gegenstelle gefragt.
Ich habe die Testumgebung gerade mal gestartet (war heute noch nicht dran).
Hier der aktuelle Log-Auszug zu diesem Punkt:
Code: Alles auswählen
2020-06-29T16:06:11.560+02:00|openvpn-OpenVPN-client|4247|/sbin/ip addr add dev tun0 10.8.0.2/24 broadcast 10.8.0.255
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
Und der Vollständigkeit halber: Wenn man von Debian aus versucht über das VPN die UTM (192.168.1.1) zu pingen, hat man das gleiche "Fehlverhalten" wie wenn man versucht den Server (192.168.1.10) hinter der UTM zu pingen.
By the way: Als ich von "tcpdump -i any ICMP" geschrieben habe, war die Syntax falsch. Richtig wäre "tcpdump ICMP -i any", dadurch wird auf allen verfügbaren Interfaces nach ICMP Ausschau gehalten.
Re: Securepoint UTM Site-to-Site mit Debian als OpenVPN-Gegenstelle
Den route-Befehl-Error erzeugt wohl folgende Zeile aus der CSC:
Ich habe diese jetzt erstmal auskommentiert und das Ganze neugestartet.
Kein Fehler mehr im Log, am generellen Problem ändert das allerdings auch nichts.
Hier mal die CLI der UTM für einen Site-to-site-Client:
Und hier die CLI für einen Site-to-Site-Server einer UTM:
samt zugehöriger "--client-config-dir /var/openvpn/OpenVPN-S2S-server":
Der Inhalt der "/etc/openvpn/openvpn.conf" auf der UTM:
Und jetzt wo ich das Ganze nochmal vor Augen und mit dem nötigen Abstand zu den tagelangen Versuche der vergangenen Woche habe sehe ich auch, was ich verbockt habe:
Beim Adaptieren der UTM-eigenen Site-to-Site-Server-Konfiguration auf die Debian-Maschine ist mir entgangen, das ich die Netze drehen muss. Autsch.
Kurzum: Hier die richtige CSC:
Jetzt weiß ich zwar immer noch nicht, warum die ursprünglich von pfSense adaptierte Konfig. nicht will, wobei mir da gerade auffällt das der "client-config-dir" dort wohl nicht ganz passt und es auch mit manuell gesetzten Routen nicht klappte, aber das sollte nun aber keine Rolle mehr spielen. Besser sollte in jedem Fall sein, das zu machen, was die UTM bzw. Securepoint erwartet.
Ich werd' das Ganze noch ein paar mal verifizieren um sicher zu gehen, das es wirklich passt, sauber dokumentieren und dann natürlich hier und übersall sonst wo ich "genervt" habe VÖ.
Danke heisenberg.
Code: Alles auswählen
push "route 192.168.1.0 255.255.255.0"
Kein Fehler mehr im Log, am generellen Problem ändert das allerdings auch nichts.
Hier mal die CLI der UTM für einen Site-to-site-Client:
Code: Alles auswählen
openvpn --config /etc/openvpn/openvpn.conf --management /tmp/openvpn_management_32F09F2B.sock unix --dev tun0 --mode p2p --tls-client --proto udp --tun-mtu 1500 --ca /etc/openvpn/OpenVPN-client.ca --cert /etc/openvpn/OpenVPN-client.cert --key /etc/openvpn/OpenVPN-client.cert --syslog openvpn-OpenVPN-client --client --auth-retry nointeract --lport 0 --reneg-sec 3600 --remote 192.168.0.144 --rport 1195 --remote 192.168.0.165 --rport 1195 --remote 185.84.80.164 --rport 1195 --keepalive 10 120
Code: Alles auswählen
openvpn --config /etc/openvpn/openvpn.conf --management /tmp/openvpn_management_50962C69.sock unix --dev tun1 --mode server --tls-server --proto udp --tun-mtu 1500 --ca /etc/openvpn/OpenVPN-S2S-server.ca --cert /etc/openvpn/OpenVPN-S2S-server.cert --key /etc/openvpn/OpenVPN-S2S-server.cert --syslog openvpn-OpenVPN-S2S-server --server 10.8.1.0 255.255.255.0 --multihome --topology subnet --client-config-dir /var/openvpn/OpenVPN-S2S-server --lport 1195 --reneg-sec 3600 --keepalive 10 120
Code: Alles auswählen
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
Code: Alles auswählen
# vim:set syntax=config:
iproute "/sbin/ip"
plugin "/usr/lib/openvpn/plugins/openvpn-session.so"
persist-tun
persist-key
verb 4
dev-type tun
tls-version-min 1.0
tls-version-max 1.2
tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA384:TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA384:TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA:TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA256:TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA256:TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA:TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-CBC-SHA256:TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-ECDHE-RSA-WITH-3DES-EDE-CBC-SHA:TLS-ECDHE-ECDSA-WITH-3DES-EDE-CBC-SHA:TLS-DHE-RSA-WITH-3DES-EDE-CBC-SHA:TLS-RSA-WITH-AES-256-GCM-SHA384:TLS-RSA-WITH-AES-128-GCM-SHA256:TLS-RSA-WITH-AES-256-CBC-SHA256:TLS-RSA-WITH-AES-256-CBC-SHA:TLS-RSA-WITH-AES-128-CBC-SHA256:TLS-RSA-WITH-AES-128-CBC-SHA:TLS-RSA-WITH-3DES-EDE-CBC-SHA
dh /rootdisk/config/dhparams2048.pem
Beim Adaptieren der UTM-eigenen Site-to-Site-Server-Konfiguration auf die Debian-Maschine ist mir entgangen, das ich die Netze drehen muss. Autsch.
Kurzum: Hier die richtige CSC:
Code: Alles auswählen
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
Ich werd' das Ganze noch ein paar mal verifizieren um sicher zu gehen, das es wirklich passt, sauber dokumentieren und dann natürlich hier und übersall sonst wo ich "genervt" habe VÖ.
Danke heisenberg.
Re: Securepoint UTM Site-to-Site mit Debian als OpenVPN-Gegenstelle
Das ganze Thema ist nun auch Blog-mässig verarbeitet:
https://www.andysblog.de/securepoint-ut ... egenstelle
https://www.andysblog.de/oeffentliche-i ... epoint-utm
https://www.andysblog.de/securepoint-ut ... egenstelle
https://www.andysblog.de/oeffentliche-i ... epoint-utm
- heisenberg
- Beiträge: 3567
- Registriert: 04.06.2015 01:17:27
- Lizenz eigener Beiträge: MIT Lizenz
Re: [gelöst] Securepoint UTM Site-to-Site mit Debian als OpenVPN-Gegenstelle
Danke für die Auflösung!
Das das Routing falsch rum war, habe ich tatsächlich nicht gesehen.
---
Ansonsten: Der Fall bestätigt eine meiner Erfahrungen: Probleme sind immer einfacher als man denkt. Es ist also gut
sich Zeit zu nehmen, langsam und gewissenhaft die Konfiguration anzuschauen.
Das das Routing falsch rum war, habe ich tatsächlich nicht gesehen.
---
Ansonsten: Der Fall bestätigt eine meiner Erfahrungen: Probleme sind immer einfacher als man denkt. Es ist also gut
sich Zeit zu nehmen, langsam und gewissenhaft die Konfiguration anzuschauen.
Jede Rohheit hat ihren Ursprung in einer Schwäche.