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

[andydld]

Hallo Zusammen,

seit einer Weile versuche ich bereits folgende Kombi zum Laufen zu bekommen:

Securepoint UTM - Site-to-Site zu einem Debian 10 Buster als OpenVPN-Server.

Grundsätzlich wird die OpenVPN-Verbindung aufgebaut und bleibt auch bestehen, aber allem anschein nach happerts am Routing.
Ein Ping auf die jeweiligen Endpunkte (10.8.0.1, 10.8.0.2) klappt sowohl auf der UTM und dem Debian.
Versucht man allerdings das Netz hinter der UTM zu erreichen, z.B. ping 192.168.1.10 (ist ein Server) ist Schicht im Schacht.

tcpdump auf der UTM sagt das nichts ankommt, auf Debian gibt es folgende Ausgabe wenn ich von dort aus obigen Server anpinge:

Code: Alles auswählen

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
09:52:18.467273 IP 10.8.0.1 > 192.168.1.10: ICMP echo request, id 906, seq 1, length 64

Die Routen auf der UTM:

Code: Alles auswählen

root@firewall:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.0.1     0.0.0.0         UG    0      0        0 eth0
10.8.0.0        *               255.255.255.0   U     0      0        0 tun2
127.0.0.0       *               255.0.0.0       U     0      0        0 lo
192.168.0.0     *               255.255.255.0   U     0      0        0 eth0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth1

Die Routen auf dem Debian:

Code: Alles auswählen

root@debian:/home/user# /sbin/route
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
default         192.168.0.1     0.0.0.0         UG    0      0        0 enp0s3
10.8.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 enp0s3
192.168.1.0     10.8.0.2        255.255.255.0   UG    0      0        0 tun0

Das Ganze ist ein Test-Aufbau, daher stellt das Internet/WAN das Netz "192.168.0.0/24" dar.
Ferner hat die Debian-Maschine nur eine NIC und es gibt im Moment kein Netz dahinter.
Dennoch sollte ja der Ping zu 192.168.1.10 möglich sein.

Routing ist auf dem Debian aktiviert. Mit anderen getesteten OpenVPN-Kombis (pfSense als Client, Debian als Server) klappts auch. Da sieht allerdings die Konfig. dann anders aus.

Der Aufbau in der Kombi Securepoint UTM und pfSense (als OpenVPN-Server) hat mal funktioniert. Die OpenVPN-Server-Konfig. habe ich im wesentlichen aus der pfSense übernommen:

Code: Alles auswählen

port 1195

proto udp

dev tun

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

dh dh2048.pem

topology subnet

server 10.8.0.0 255.255.255.0

ifconfig 10.8.0.1 10.8.0.2

keepalive 10 120

cipher BF-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 SHA1

route 192.168.1.0 255.255.255.0

client-config-dir /etc/openvpn/csc

Inahlt der CSC:

Code: Alles auswählen

push "route 192.168.2.0 255.255.255.0"
iroute 192.168.1.0 255.255.255.0

Auf der UTM kann man leider nicht sonderlich umfangreich an OpenVPN konfigurierern, daher "muss" mehr auf der OpenVPN-Server-Seite gemacht werden.

Das Cipher und Auth weak sind sind ist bekannt. Wie bereits erwähnt, ist aktuell nur ein Test-Aufbau. Final kann man es ja dann besser machen.

Soweit der Stand. Evtl. hat ja jemand so eine Kombi schonmal gehabt oder die zündende Idee woran es hängt.

Vielen Dank vorab schonmal.

Gruß

Andy

[Sophia]

Securepoint UTM - Site-to-Site zu einem Debian 10 Buster als OpenVPN-Server.

Was hat diese Maschine/Software mit Debian zu tun? Welche Antworten erhoffst du hier im Forum? Du solltest den Support des Herstellers befragen Jeder halbwegs professionelle Hersteller bietet Support zumindest für seine Entenscheiss-Enterprise-Produkte an.

[andydld]

Danke für die Antwort.

> Was hat diese Maschine/Software mit Debian zu tun?

Die UTM als solches erstmal gar nichts, die Gegenstelle, also der Debian-basierte OpenVPN-Server, dann wenigstens das OS.
Da das Ganze irgendwie mit der Konfig. auf Debian-Seite zusammenhängt, war dieses Forum hier (m)ein naheliegender Gedanke.

> Welche Antworten erhoffst du hier im Forum?

Ich hoffe, wenig überraschend, auf eine Lösung

> Du solltest den Hersteller befragen, vielleicht betreibt der ein Forum für seine Hard- und Software. Oder nimm Hersteller-Support in Anspruch. Jede professioneller Hersteller bietet das für seine Produkte an.

Im Hersteller-Forum ist das Thema ebenfalls gepostet:

https://support.securepoint.de/viewtopi ... =27&t=8242

Und telefoniert habe ich heute früh auch schon.

[Sophia]

Und was sagte oder schrieb oder telefonierte der UTM-Hersteller-Support? Ich lese selten Cross-Posts, auf die nicht von Anfang an hingewiesen wurde. Aber schön, dass wir von dem Inhalt deines Telefonates immer noch keine Kenntnis haben - und antworten sollen. Mein Gott, was erwartest du von deinen Mitmeschen/Helfern?
Alles Liebe.

[heisenberg]

Dein tcpdump läuft auf tun0. Was sagt denn der tcpdump auf dem internen Interface der Securepoint? ... und auf dem Zielhost(wenn's da einen tcpdump gibt)?

Wenn der ping auf dem tun-Interface zu sehen ist und auf dem internen Interface nicht, dann ist es wohl eine fehlende Paketfilterregel.

Für alle anderen: Securepoint ist eine kommerzielle Firewalldistribution, für die Geräte des Herstellers, die unten drunter ein angepasstes Linux hat.

P. S.: Der Ignorieren-Button findet sich auf der Profilseite des entsprechenden Benutzers.

[andydld]

@sophia:

> Und was sagte oder schrieb oder telefonierte der UTM-Hersteller-Support?

Das man erstmal schaut was sich Debian-seitig ergibt, da es zunächst mal nichts mit der UTM zu tun zu schein hat.

> Ich lese selten Cross-Posts, auf die nicht von Anfang an hingewiesen wurde.

Sorry, vergessen, ist aber 1. der gleiche Inhalt und 2. bislang keien Antworten was 3. für den Moment nicht weiterhilft.
Sofern sich irgendwie irgendwo eine Lösung ergibt, poste ich sie (hier als auch dort).

> Aber schön, dass wir von dem Inhalt deines Telefonates immer noch keine Kenntnis haben - und antworten sollen.

S.o. hätte aber auch nichts gebracht, das zu erwähnen.

> Mein Gott, was erwartest du von deinen Mitmeschen/Helfern?

Vorarbeit und Infos wurden ja geliefert, wenn was fehlt reiche ich es gerne nach, sofern es ermittelbar ist.

Ich helfe ja auch ständig, sei es auf Arbeit, bei Kunden, bei Herstellern, Interessenten, Blog-Lesern, Antworten auf Kommenater, usw.
Zur Abwechselung brauch ich halt mal Hilfe.

> Alles Liebe.

Danke wünsche ich dir auch.

@heisenberg:

Danke für deine Antwort.

> Dein tcpdump läuft auf tun0.

Stimmt.

> Was sagt denn der tcpdump auf dem internen Interface der Securepoint?

Da kommt nichts an bzw. raus.

> ... und auf dem Zielhost(wenn's da einen tcpdump gibt)?

Der Server ist 'ne Windows-VM, laut SmartSniff kommt nichts an.

> Wenn der ping auf dem tun-Interface zu sehen ist und auf dem internen Interface nicht, dann ist es wohl eine fehlende Paketfilterregel.

Firewall dachte ich auch zurest, aber da ist alles passend und wie erwähnt in Verbindung mit einer pfSense statt dem Debian läuft's ja auch.
Das UTM-Log hat auch keine Drops erfasst, Firewall scheint es also irgendwie nicht zu sein (nehme ich an).

Zur Info: Im Test-Aufbau ist es wirklich so, wenn man die Debian-VM herunterfährt und die pfSense-VM startet sich die UTM erfolgreich verbinden kann und es "einfach" läuft.

[heisenberg]

> Wenn der ping auf dem tun-Interface zu sehen ist und auf dem internen Interface nicht, dann ist es wohl eine fehlende Paketfilterregel.

Firewall dachte ich auch zurest, aber da ist alles passend und wie erwähnt in Verbindung mit einer pfSense statt dem Debian läuft's ja auch.
Das UTM-Log hat auch keine Drops erfasst, Firewall scheint es also irgendwie nicht zu sein (nehme ich an).

Drops werden normalerweise nicht protokolliert, es sei denn Du hast eine entsprechende Regel mit Logging dafür konfiguriert.

Ich tippe mit sehr hoher Wahrscheinlichkeit darauf, dass es das ist.

Probiers doch einfach mal aus und mach in der Konsole per SSH eine temporäre Regel rein:

Code: Alles auswählen

iptables -I INPUT 1 -i tun0 -p icmp -j ACCEPT
bzw.
iptables -I FORWARD 1 -i tun0 -p icmp -j ACCEPT

Die Regel fliegt natürlich relativ schnell wieder raus. Aber für einen kurzen Test sollte es ausreichen.

[andydld]

> Drops werden normalerweise nicht protokolliert, es sei denn Du hast eine entsprechende Regel mit Logging dafür konfiguriert.

Bei Securepoint ab Werk werden die Drops im Protokoll erfasst.

Als Beispiel: Als ich noch keine Regel für's VPN drin hatte, wurden mir die Drops meiner Pings im Log angezeigt.
By the Way (sorry, vergessen zu erwähnen) auf dem Debian läuft noch gar keine Firewall.

> Probiers doch einfach mal aus und mach in der Konsole per SSH eine temporäre Regel rein:

Gute Idee.
Getestet, hat leider nichts geändert.

[andydld]

Der Vollständigkeit halber und um es mal gezeigt zu haben.
Ohne passende Portfilter-Regel auf der Securepoint UTM sieht ein Drop im Log so aus:

Code: Alles auswählen

24.06.2020 14:37:55	ulogd	DROP: (DEFAULT DROP)10.8.0.1 tun2 10.8.0.2Echo Request (Ping)

[Sophia]

Mache/initiiere Packet Captures beidersetig (Server und Client).
Poste die Firewall-Regeln für die IFs (Server und Client).
Poste die Verschhlüsselungseinstellungen (Server und Client).
Poste die Routen (aus Server- und Client-Sicht). Zeichne und poste für das Vertändnis durch Dritte den Netzwerkplan - Dokumentation für Firma, für Dich und Helfer/Dienstleister sinnvoll. Wirklich nur Site-to-site oder zusätzlich (Roadwarrior-) Einwahl-VPN?
Korrigiere Fehler, poste nun erst Packet Captures. Eigene Auswertung vorher mit wireshark.
Überlege einfach: Du musst dein oder besser das Problem deiner Firma an Dienstleister beauftragen, Problemlösungen teuer einkaufen. Welches Wissen benötigen Dritte (oder eben kostenlose Forenmitglieder)?

@heisenberg: Wie sieht deine Lösungsstrategie aus? Warum würfelst du blind, ohne irgendwas vom Kunde abzufragen, ohne Interesse daran, dessen Netz/Gegebenheiten halbwegs kennenzulernen? Ignoranz oder Betriebsblindheit oder Beamter? Jeder Autoschlosser, jede Friseuse, jeder Handwerker, jeder Arzt diagnostiziert zuerst - dann erst kommen Therapien, Reparaturen, Haarschnitte. Jeder Patient/Kunde hat andere Probleme. Ausser "Clients" von Beamten- die kriegen eine "Lösung" per Bescheid.

[andydld]

> Mache/initiiere Packet Captures beidersetig (Server und Client).

Kommt evtl. noch, bin noch dran.

> Poste die Firewall-Regeln für die IFs (Server und Client).

Ist alles auf Durchzug auf der UTM und auf Debian ist keine FW aktiv.

> Poste die Verschhlüsselungseinstellungen (Server und Client).

Die ist allem anschein nach aber auch nicht das Problem, denn der Verbindungsaufbau klappt ja grundsätzlich. Andere Cipher, etc. ändern an dem eigentlichem Problem nichts.

> Poste die Routen (aus Server- und Client-Sicht).

S. erster Eintrag

> Zeichne und poste für das Vertändnis durch Dritte den Netzwerkplan - Dokumentation für Firma, für Dich und Helfer/Dienstleister sinnvoll.

Das Ganze ist ein Testaufbau in der Werkstatt:

Securepoint UTM - 192.168.0.166/24
Debian - 192.168.0.144/24
OpenVPN-Transfer-Netz - 10.8.0.0/24

> Wirklich nur Site-to-site oder zusätzlich (Roadwarrior-) Einwahl-VPN?

Ja, nur S2S + kein Roadwarrior.

> Korrigiere Fehler, poste nun erst Packet Captures. Eigene Auswertung vorher mit Debianwireshark.

Und nochmal: Kommt evtl. noch, bin noch dran.

> Überlege einfach: Du musst dein oder besser das Problem deiner Firma an Dienstleister beauftragen, Problemlösungen teuer einkaufen. Welches Wissen benötigen Dritte (oder eben kostenlose Forenmitglieder)?

Bin selbst Dienstleister und bekomme meist weitaus weniger Infos als die bislang VÖ.

Und weiter geht's:

Habe heute mit dem Securepoint-Support dran gesessen (Danke an Jan an dieser Stelle) und der wusste auch nicht weiter. Die UTM scheint es jedenfalls nicht zu sein.
Mit ein wenig "quasi-reverse engineering" wurde nun eine andere OpenVPN-Server-Konfig. auf Debian getestet, die sozusagen dem Site-to-Site-Server von Securepoint gleicht bzw. sehr ähnelt, aber das Problem bleibt:

Code: Alles auswählen

# UTM: /etc/openvpn/openvpn.conf:

# 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

# UTM: SSL-VPN/OpenVPN Site-to-Site Server via ps aux | grep "openvpn":

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

# Ab hier die neue Debian-Konfig.:

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 BF-CBC
cipher AES-256-CBC

comp-noadapt

persist-key
persist-tun

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

log         /var/log/openvpn/openvpn.log

verb 4

explicit-exit-notify 1

auth SHA256

route 192.168.1.0 255.255.255.0

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

# Inhalt der OpenVPN-Client:

# 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

Die OpenVPN-Version auf Debian wurde zudem auf die aktuelle stable upgegradet, keine Änderung.

[heisenberg]

@heisenberg: Wie sieht deine Lösungsstrategie aus? Warum würfelst du blind, ohne irgendwas vom Kunde abzufragen, ohne Interesse daran, dessen Netz/Gegebenheiten halbwegs kennenzulernen? Ignoranz oder Betriebsblindheit oder Beamter? Jeder Autoschlosser, jede Friseuse, jeder Handwerker, jeder Arzt diagnostiziert zuerst - dann erst kommen Therapien, Reparaturen, Haarschnitte. Jeder Patient/Kunde hat andere Probleme. Ausser "Clients" von Beamten- die kriegen eine "Lösung" per Bescheid.

@Sophia: Hast Du da einen wesentlich höheren Anspruch an eine gegebene Unterstützung und hättest gerne dass sich jeder Helfer zumindest eingehend
mit einem Problem beschäftigt und es komplett versucht zu verstehen, bevor er auch nur eine Antwort erwägt?

Grundsätzlich stimme ich Dir da schon zu. Ich habe mich recht wenig mit dem Problem beschäftigt.

Gründe für meine Antwort:

a) Mein begrenztes Zeitbudget, dass ich mir für den Beitrag zur Lösung des Problems nehmen möchte.
Es ist nicht meine Aufgabe, das Problem zu lösen. Ich gebe Hinweise und entscheide mich im Einzelfall wie viel Unterstützung ich geben möchte.

b) Ich habe mit der Securepoint schon etwas gearbeitet und das ist so einer der typischen Fehler, die bei der Fehlersuche öfters mal aufgetreten ist.

c) Es gibt eine Reihe einfacher Probleme, die man mit wenig Aufwand prüfen kann. Das war mein Beitrag, den ich gab, nicht mehr und nicht weniger.
Im Fall eines fehlgeschlagenen Pings, das über einen Router geht, ist das für mich ...

...wenn ein Paket am Router ankommt und nicht den gewünschten Weg weitergeht, dann wird es entweder geblockt, verworfen oder auf dem falschen Weg(falsches Routing, falsches Interface) weitergeleitet und das sind die Basics, die ich zuerst mittels tcpdump/iptables/iproute2 überprüfen würde.

[andydld]

@heisenberg:

Erstmal velen Dank für deine Unterstützung.

Am Beispiel von Securepoint und natürlich auch anderen Produkten/Routern/Firewalls/etc. stimme ich dir zu.
Meist "hängt" es ja an der Firewall oder dem Routing.

Ein Kollege hat wegen der Securepoint mal gemeint: "Wenn was nicht geht, dann liegt's am NAT" (Anmerkung: Wegen der einstellbaren Modi.)

Soviel dazu und zurück zum Thema:

Um der Sache weiter auf den Grund zu gehen habe ich zunächst mit "tcpdump -i any ICMP" mal geschaut ob der Ping nicht am falschen Interface raus (Debian-Seite) oder rein (UTM-Seite) geht.
Das ist nicht der Fall. Irgendwie geht er in den Tunnel, wie man an der zuvor gepostete Ausgabe ja sieht, und das war's dann.

Im OpenVPN hatte ich das Logging mal auf "9" gesetzt und dann das Log betrachtet, irgendwas passiert da auch passend zum Ping, Fehler/Warnungen/o.ä habe ich da nicht gesehen, muss allerdings auch dazu sagen, das ich diesen Grad des Logs dann auch nicht wirklich mehr verstehe. Ich kann das gerne mal posten.

Der Securepoint-Support meinte, das die Pakete evtl. nicht verschlüsselt werden, sicher sagen konnte man das allerdings auch nicht.

Es bleibt merkwürdig, in gut zwanzig Jahren habe ich sowas oder ähnliches noch nicht gehabt, daher ja auch der Hilferuf.

[andydld]

Um auszuschließen das meine Debian-Büchse ein Problem hat, habe ich mal einen Ubuntu Server 20.03 installiert.
Als Basis für die Firewall-Konfig. diente dabei dieser Link:

https://www.digitalocean.com/community/ ... u-18-04-de

Die OpenVPN-Konfig. habe ich von Debian übernommen, da diese ja so ziemlich der "erwarteten" UTM-Site-to-site-Server-Konfig. entspricht.

Lange Rede, kurzer Sinn: Auch auf Ubuntu exakt das gleiche Verhalten, ganz gleich ob die UFW in-/aktiv ist.

[heisenberg]

tcpdump -i any ICMP

Damit habe ich keine guten Erfahrungen gemacht. Ich weiß nicht ob das so funktioniert, wie es soll. Ich erinnere mich nur dunkel, dass es das letzte
mal nicht so funktioniert hat, wie ich es erwartet habe. Ich habe es aber damals auch nicht weiter verfolgt. Deswegen habe ich lieber die einzelnen
Interfaces separat protokolliert. Kann aber sein, dass ich mich da täusche.

Ansonsten vielleicht auch nochmal "ip rule" prüfen(Source based routing/routing policy).

Nachtrag

Mist. Ich habe mich verguckt. Die Pings kommen ja noch gar nicht am Router(SP) an. Die Pakete gehen ja nur am Debian weg. Das ist was anderes als ich vermutet habe.

Da würde ich mir mal genauer das OpenVPN-Log auf beiden Seiten anschauen. und die Parameter. Ggf. mal die Verbosity etwas hochstellen. Kannst auch mal das log vom openvpn ins NoPaste stellen.

[andydld]

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

[heisenberg]

Hast Dir das selbst mal angeschaut?

[andydld]

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.

[heisenberg]

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?

[andydld]

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]

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

[andydld]

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

[heisenberg]

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.