[gelöst] Securepoint UTM Site-to-Site mit Debian als OpenVPN-Gegenstelle

Einrichten des lokalen Netzes, Verbindung zu anderen Computern und Diensten.
andydld
Beiträge: 35
Registriert: 26.10.2017 17:47:58

Re: Securepoint UTM Site-to-Site mit Debian als OpenVPN-Gegenstelle

Beitrag von andydld » 26.06.2020 12:10:36

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

Benutzeravatar
heisenberg
Beiträge: 1678
Registriert: 04.06.2015 01:17:27

Re: Securepoint UTM Site-to-Site mit Debian als OpenVPN-Gegenstelle

Beitrag von heisenberg » 26.06.2020 15:59:04

Hast Dir das selbst mal angeschaut?
Wenn ich ein Problem gelöst habe, bekomme ich zur Belohnung ein neues, größeres Problem.

andydld
Beiträge: 35
Registriert: 26.10.2017 17:47:58

Re: Securepoint UTM Site-to-Site mit Debian als OpenVPN-Gegenstelle

Beitrag von andydld » 29.06.2020 07:48:48

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):

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
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):

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.
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.

Benutzeravatar
heisenberg
Beiträge: 1678
Registriert: 04.06.2015 01:17:27

Re: Securepoint UTM Site-to-Site mit Debian als OpenVPN-Gegenstelle

Beitrag von heisenberg » 29.06.2020 14:57:52

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 meinte ich mit meiner Frage, ob Du Dir angeschaut hast.

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?
Wenn ich ein Problem gelöst habe, bekomme ich zur Belohnung ein neues, größeres Problem.

andydld
Beiträge: 35
Registriert: 26.10.2017 17:47:58

Re: Securepoint UTM Site-to-Site mit Debian als OpenVPN-Gegenstelle

Beitrag von andydld » 29.06.2020 16:15:49

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:

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
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.

andydld
Beiträge: 35
Registriert: 26.10.2017 17:47:58

Re: Securepoint UTM Site-to-Site mit Debian als OpenVPN-Gegenstelle

Beitrag von andydld » 29.06.2020 17:50:23

Den route-Befehl-Error erzeugt wohl folgende Zeile aus der CSC:

Code: Alles auswählen

push "route 192.168.1.0 255.255.255.0"
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:

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
Und hier die CLI für einen Site-to-Site-Server einer UTM:

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
samt zugehöriger "--client-config-dir /var/openvpn/OpenVPN-S2S-server":

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
Der Inhalt der "/etc/openvpn/openvpn.conf" auf der UTM:

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

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. :facepalm: 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
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.


Benutzeravatar
heisenberg
Beiträge: 1678
Registriert: 04.06.2015 01:17:27

Re: [gelöst] Securepoint UTM Site-to-Site mit Debian als OpenVPN-Gegenstelle

Beitrag von heisenberg » 30.06.2020 15:45:34

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.
Wenn ich ein Problem gelöst habe, bekomme ich zur Belohnung ein neues, größeres Problem.

Antworten