Neue Hardware - OpenVPN geht nicht. Wo/ wie mit der Fehlersuche anfangen?

Tobi

@mike69 said in Neue Hardware - OpenVPN geht nicht. Wo/ wie mit der Fehlersuche anfangen?:

Daher ist an so einem Screenshot nichts verwerfliches.

Natürlich nicht, aber Screenshot ist doch kein Netzwerkplan

mike69

Habe die Antwort korrigiert, habt ja ne Mail bekommen.

Ehrlich gesagt, aus dem Log werde ich privater Fuzzi auch nicht schlau. Eventuell schaut sich ein OpenVPN Crack das irgend wann mal an, oder die Frage ist im internationalen Part besser aufgehoben.

Auch meine 2Cent.

Oh, Bilder. :)

Danke.

viragomann

@tobi
Was soll die "192" in den "IPv4 Local Networks" bewirken?

Tobi

@viragomann - nichts. Ist ein Fehler bei Screenshot. Ich habe weitere Netze ausgeschnitten.. Wohl nicht ganz komplett.

sebden

An sich ist die Konfiguration ja übernommen, aber ich würde mal probieren in der pf / oVPN Protokoll=UDP v4 only zu setzen.

Hatte ich mal bei einem Kunde, dass ohne die Option mit IPv6 keine Verbindung aus seinem Netz zustande kam. Laut deinem Protokoll wird eben dies verwendet.

Ist der Klient eine Box oder ein PC mit Software oVPN? Wenn letzteres, welche Version kommt denn zum Einsatz? Womöglich ist beim Einrichten der neuen pf ein neueres oVPN zum Einsatz gekommen?

Tobi

@sebden said in Neue Hardware - OpenVPN geht nicht. Wo/ wie mit der Fehlersuche anfangen?:

Womöglich ist beim Einrichten der neuen pf ein neueres oVPN zum Einsatz gekommen?

Das verstehe ich nicht - wenn die alte und neue Box mit pfSense 2.5.2 bestückt sind, sind die Pakete die immer dabei sind auch gleich oder nicht?

@sebden said in Neue Hardware - OpenVPN geht nicht. Wo/ wie mit der Fehlersuche anfangen?:

Ist der Klient eine Box oder ein PC mit Software oVPN?

In diesem Fall war es mein Handy. Im Normallfall sind es 2-3 Windows Rechner mit OpenVPN Software. Auf dem Handy wird mir Version 0.7.29 angezeigt.

Das mit Protokoll Version kann ich trotzdem probieren was dann passiert - hat aber bis jetzt auch immer funktioniert - je nach dem von wo die Verbindung kam - mal mit IPv4 mal mit IPv6

sebden

@tobi Ja dann sind die Versionen gleich, hatte ich so nicht gelesen bisher.

Mit dem IPv4 ist wie gesagt nur eine Idee, da es schon mal genützt hatte bei einem Kunde.

viragomann

@tobi said in Neue Hardware - OpenVPN geht nicht. Wo/ wie mit der Fehlersuche anfangen?:

nichts. Ist ein Fehler bei Screenshot. Ich habe weitere Netze ausgeschnitten.. Wohl nicht ganz komplett.

Ah so. Wieder so eine Sackgasse aufgrund deiner Geheimnistuerei um deine internen Netze wie schon bei den Routen. Wollte diesen Thread eigentlich eh schon aufgeben, weil es an Unterstützung mangelt, diese Sache ist mir aber ins Auge gefallen und war so nicht zu erkennen.

Kannst du eigentlich erklären, warum du deine internen Netzwerke verbirgst? Trotz einiger Erfahrung in diesem Bereich fällt mir kein vernünftiger Grund ein.

Tobi

@viragomann said in Neue Hardware - OpenVPN geht nicht. Wo/ wie mit der Fehlersuche anfangen?:

Kannst du eigentlich erklären, warum du deine internen Netzwerke verbirgst? Trotz einiger Erfahrung in diesem Bereich fällt mir kein vernünftiger Grund ein.

Auch wenn es im allgemeinen heißt es wäre unhöflich - kannst Du mir erklären warum es interessant sein sollte?
Es ist doch so, dass ich nach 1:1 Umstellung nicht Verbindung mit dem Server aufbauen kann und nicht weil ich plötzlich nicht an irgendein internes Netz oder Dienst kommen.

@viragomann said in Neue Hardware - OpenVPN geht nicht. Wo/ wie mit der Fehlersuche anfangen?:

aufgrund deiner Geheimnistuerei

Du magst es so empfingen ich nicht. Ich sehe es eher als Vereinfachung der Darstellung. Bis jetzt habe ich noch kein einzigen Beitrag gesehen (vielleicht von der IPv4/ IPv6 abgesehen - auch wenn es wie ich vorher geschrieben hatte für Unwahrscheinlich als Grund halte, denn es ging vorher) der sich mit dem Problem und Fehlersuche befasst. Mag natürlich auch an mir liegen. Es gibt aber auch noch andere Möglichkeit.

sebden

Vielleicht noch ein Ansatzpunkt: Wenn die pf getauscht wurde, kann das evtl. die FritzBox ins Trudeln gebracht haben. Häufig beobachtet, wenn man den Klienten fürs Forewarding aus der Liste pickt, statt die IP von Hand einzugeben.

Daher vielleicht zunächst das Forewarding nochmal neu einrichten (zwischendrin unbedingt übernehmen) und, auch wenn es unnötig sein sollte, nochmal einen Blick darauf, ob auch eingehend auf WAN der oVPN Port geöffnet ist auf der pf.

Tobi

@sebden said in Neue Hardware - OpenVPN geht nicht. Wo/ wie mit der Fehlersuche anfangen?:

Daher vielleicht zunächst das Forewarding nochmal neu einrichten

Musste ich eh machen wie ich hier schrieb.
Ich musste die alte pf erst raswerfen, sonst ging es nicht nach draußen, weil die gleiche IP aber andere MAC Adresse.

ich werde später schauen mit der IPv4 und wenn das nichts bringt stelle ich auf TCP, vielleicht sehe ich dann wenigstens im tcpdump etwas mehr.

viragomann

@tobi said in Neue Hardware - OpenVPN geht nicht. Wo/ wie mit der Fehlersuche anfangen?:

Auch wenn es im allgemeinen heißt es wäre unhöflich - kannst Du mir erklären warum es interessant sein sollte?

Wenn ein Gerät einen Fehler beim Versuch eine Route hinzuzufügen meldet, ist die aktuelle Routingtabelle das nächste, das mich interessiert, weil ich Konflikte mit am Gerät konfigurierten Netzwerken für die wahrscheinlichste Ursache halte. Deshalb war es meine erste Frage hier.

Es ist doch so, dass ich nach 1:1 Umstellung nicht Verbindung mit dem Server aufbauen kann und nicht weil ich plötzlich nicht an irgendein internes Netz oder Dienst kommen.

Es mag gewiss unterschiedliche Herangehensweisen bei der Fehlersuche geben, die früher oder später zum Erfolg führen, doch denke ich, diese Einstellung wird dich nicht weiterbringen.

micneu

@tobi JA, und ich bin sogar der meinung das war mal gewünscht in jedem post. ich denke das hilft auch anderen (nicht nur mir). ich hatte es schon öfter das leute im netzwerkplan auf einmal einen aufbau hatten mit dem man nicht gerechnet hat, der plan hat zur lösung des problems geholfen und die postersteller haben sich nochmal gedanken gemacht. also bitte IMMER einen grafischen netzwerkplan anhängen.

https://forum.netgate.com/topic/154920/wie-stelle-ich-fragen-damit-man-mir-helfen-kann

Tobi

Danke für die zahlreiche Antworten.
Das Problem ist nicht mehr aktuell.

sebden

Das ist ja schon mal gut Was führte zur Lösung?

Tobi

@sebden said in Neue Hardware - OpenVPN geht nicht. Wo/ wie mit der Fehlersuche anfangen?:

Was führte zur Lösung?

Tja etwas was ich nicht verstehe und mir die Ursache nicht klar ist wie so etwas passieren konnte.
Also ich habe die alte config.xml genommen und auf das neue System kopiert. Nicht mehr nicht weniger. PF Versionen sind gleich -2.5.2.
Ich habe gestern, weil ich nicht weiterkam WireGuard als Paket erst mal nur Installiert. So und plötzlich zeigte mir OpenVPN Fehler, dass es mit dem eingetragenem Zertifikat nichts anfangen kann und deswegen der Dient gestoppt wird. (Lies sich nicht mehr starten) Gewundert hat es mich, weil bis dato gab es keinen Fehler oder sonstige Bemerkung dazu und der Dient lief ja auch. Ich hatte es auch mehrfach gestoppt und gestartet,
Ich habe also noch mal die alte Konfig (XML Datei) und die aktuelle verglichen und tatsächlich gab es bei dem OpenVPN Zertifikat unterschiede.
Im Cert Manager war das Feld bei diesem Zertifikat komplett leer. Key war gefüllt und gleich mit dem in der alter XML Datei.
Noch mal das Zertifikat aus der alter Box kopiert und schon lief das ganze. Wieso das überhaupt und auch nur bei diesem Zertifikat passiert ist - habe ich keine Ahnung.

JeGr

@tobi said in Neue Hardware - OpenVPN geht nicht. Wo/ wie mit der Fehlersuche anfangen?:

Auch wenn es im allgemeinen heißt es wäre unhöflich - kannst Du mir erklären warum es interessant sein sollte?
Es ist doch so, dass ich nach 1:1 Umstellung nicht Verbindung mit dem Server aufbauen kann und nicht weil ich plötzlich nicht an irgendein internes Netz oder Dienst kommen.

Weil es nervig ist, bei Fehleranalysen und Debugging, bei der man selbst sich den Kopf für jemand anderen zerbricht, ständig an Kleinigkeiten hängen zu bleiben, die derjenige vielleicht zu recht oder auch nicht für "unnötig", unwichtig oder "egal" hält. Wenn da keine public IPs stehen, ist es völlig egal und man braucht da nichts "rauszensieren". Wofür? Nachher stehen da 4 Netze, 2 mal ein Komma (korrekt) und das dritte ist ein Punkt. Oder ein Semikolon. Und man sucht sich in der Konfig den Wolf obwohls ein Schreibfehler ist :)

der sich mit dem Problem und Fehlersuche befasst. Mag natürlich auch an mir liegen. Es gibt aber auch noch andere Möglichkeit.

Doch, mehrfache Einwürfe waren da - die du aber verworfen hast mit "vorher gings ja". Auch wenn die Config gleich ist und es vllt. die gleiche Version ist - vorher hattest du evtl. ein System das schon 5x geupdated war und Reste von alten Versionen hatte. Jetzt ist es frisch installiert. Es kann also durchaus was anders sein. Man weiß es ja nicht, wenn mans nicht probiert hat.

Wenn ein Gerät einen Fehler beim Versuch eine Route hinzuzufügen meldet, ist die aktuelle Routingtabelle das nächste, das mich interessiert, weil ich Konflikte mit am Gerät konfigurierten Netzwerken für die wahrscheinlichste Ursache halte. Deshalb war es meine erste Frage hier.

da hat @viragomann völlig recht. Der Error sagte eindeutig, dass der FreeBSD Network Stack eine Route nicht hinzufügen kann. Entweder weils die schon gibt, er sie nicht löschen kann, etc. etc. Da er mehrere Routen hinzufügt - u.a. für alle Netze die du oben weggeschnitten hast - sehen wir so nicht was das Problem ist. Die Fehlerzeile tritt aber interessanterweise direkt nach dem add vom VPN Netz auf. Also 192.168.3.x.

Darum müsste man mal direkt sehen, was die Routing Table von Client UND Server sagt zu diesem Netz. Evtl. hat der Client da schon ein Bein drin oder du testest aus dem Netz - dann gehts natürlich schief. Manchmal hilft bei sowas aber auch den Client mal neu zu starten oder auf Serverseite nachzusehen ob die Route/das Netz ggf. schon irgendwo anders existiert (WG, IPSec, whatever).

Ich habe gestern, weil ich nicht weiterkam WireGuard als Paket erst mal nur Installiert.

Das und IPsec können bei sowas auch schonmal schön reingrätschen.

Also ich habe die alte config.xml genommen und auf das neue System kopiert. Nicht mehr nicht weniger. PF Versionen sind gleich -2.5.2.

Wie oben gesagt, neuinstalliertes System ist nicht gleich vorhandenes upgedatetes System. Beim Restore werden alle Settings wiederhergestellt. Aber manchmal eben auch Sachen, die man nur teilweise oder halb mal angefangen und dann wieder abgeschaltet hat. Beim Restore kommen die aber vielleicht dann wieder rein und werden aktiv. Daher kann es immer mal wieder zu irgendwelchen Nebeneffekten kommen. Gar nicht soo unüblich :)

Cheers

Tobi

@jegr said in Neue Hardware - OpenVPN geht nicht. Wo/ wie mit der Fehlersuche anfangen?:

da hat @viragomann völlig recht. Der Error sagte eindeutig, dass der FreeBSD Network Stack eine Route nicht hinzufügen kann. Entweder weils die schon gibt, er sie nicht löschen kann, etc. etc. Da er mehrere Routen hinzufügt - u.a. für alle Netze die du oben weggeschnitten hast - sehen wir so nicht was das Problem ist. Die Fehlerzeile tritt aber interessanterweise direkt nach dem add vom VPN Netz auf. Also 192.168.3.x.

Was mir damals als ich den Logauszug gepostet hatte nicht bewusst war - sowohl die alte Box wie auch die neue, mit funktionierender openVPN Verbindung bringt diesen Fehler, wenn der Server gestartet wird. (Vielleicht am Ende eine Fehlkonfiguration die aber irgendwie doch funktioniert)
(Zum ersten Beitrag hat sich so fern etwas verändert, dass ich die ursprüngliche VLAN.Interfaces auf Physik inzwischen umgestellt habe)
Was ich damals wie auch jetzt nicht verstanden habe - was hätte in dieser Ausgabe stehen sollen/ können was auf irgendein Fehler deuten könnte?

netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            192.168.3.118      UGS        igb0
127.0.0.1          link#10            UH          lo0
192.168.1.0/24     link#4             U          igb3
192.168.1.10       link#4             UHS         lo0
192.168.2.0/24     link#3             U          igb2
192.168.2.10       link#3             UHS         lo0
192.168.3.0/24     link#1             U          igb0
192.168.3.1        link#19            UHS         lo0
192.168.3.2        link#19            UH       ovpns1
192.168.3.10       link#1             UHS         lo0
192.168.4.0/24     link#5             U          igb4
192.168.4.10       link#5             UHS         lo0
192.168.5.0/24     link#14            U      igb3.150
192.168.5.10       link#14            UHS         lo0
192.168.6.0/24     link#15            U      igb3.250
192.168.6.10       link#15            UHS         lo0
192.168.7.0/24     link#13            U       igb3.20
192.168.7.10       link#13            UHS         lo0
192.168.8.0/24     link#16            U       igb2.30
192.168.8.10       link#16            UHS         lo0
192.168.9.0/24     link#17            U       igb2.40
192.168.9.10       link#17            UHS         lo0
192.168.10.0/24    link#18            U       igb2.50
192.168.10.10      link#18            UHS         lo0
192.168.14.0/24    link#2             U          igb1
192.168.14.10      link#2             UHS         lo0

@jegr said in Neue Hardware - OpenVPN geht nicht. Wo/ wie mit der Fehlersuche anfangen?:

Beim Restore werden alle Settings wiederhergestellt.

Ich habe keine Backup/ Restore Funktion benutzt, sondern wie ich schrieb 1:1 copy. Dann die /tmp/config.* löschen und "16) Restart PHP-FPM" aus Console und reboot

Und allgemein Wort zum Schluss. Ich mag total falsch liegen, dennoch, nach einigen Tagen abstand zu dem Thread habe. Ich wollte nichts verheimlichen und durch diese Unterstellung war ich durchaus "angepisst". Auf der anderer aber Seite Forderung nach "zeig mal alles" ohne ein Wort darüber zu verlieren, wofür es gut sein soll......
Ich denke es gab in dem Thread an einigen Stellen "Sender/Empfänger" Kommunikationsfehler.

JeGr

@tobi said in Neue Hardware - OpenVPN geht nicht. Wo/ wie mit der Fehlersuche anfangen?:

Ich habe keine Backup/ Restore Funktion benutzt, sondern wie ich schrieb 1:1 copy. Dann die /tmp/config.* löschen und "16) Restart PHP-FPM" aus Console und reboot

Hö? Wie das? Hart aufs Gerät kopiert und eingelesen damit?
Warum das denn? Und warum nicht simpel als Restore damit pfSense das Ding durchparsen und einlesen kann? Bin neugierig :)

Ich denke es gab in dem Thread an einigen Stellen "Sender/Empfänger" Kommunikationsfehler.

Gibt es sicher bei geschriebenem Wort immer. Daher sollte man da generell allen immer etwas "leeway"/Spielraum lassen, dass es nicht böse/unterstellend/sonstwie gemeint ist. :)

Was ich damals wie auch jetzt nicht verstanden habe - was hätte in dieser Ausgabe stehen sollen/ können was auf irgendein Fehler deuten könnte?

HA! :)
Das hier:

192.168.3.0/24     link#1             U          igb0
192.168.3.1        link#19            UHS         lo0
192.168.3.2        link#19            UH       ovpns1
192.168.3.10       link#1             UHS         lo0

Das darf eigentlich so nicht existieren. Der Eintrag sagt mir, dass du auf igb0 - einem physischen Netzwerk - das Netz 192.168.3.0 aufliegen hast UND das gleiche Netz auch versuchst wie OpenVPN zu nutzen. Das darf nicht sein. Da hast du entweder einen Denk- oder Konfigurationsfehler. Was ist denn igb0 und warum hat es den gleichen IP Range wie dein VPN?

Cheers
\jens

Tobi

@jegr said in Neue Hardware - OpenVPN geht nicht. Wo/ wie mit der Fehlersuche anfangen?:

Bin neugierig :)

Zunächst hatte ich diesen Punkt in der Konsole gar nicht so wahrgenommen.

@jegr said in Neue Hardware - OpenVPN geht nicht. Wo/ wie mit der Fehlersuche anfangen?:

Da hast du entweder einen Denk- oder Konfigurationsfehler.

Damals also vor Jahren als ich es konfiguriert habe, habe ich an mindestens einer Stelle einen Fehler eingebaut - sieht zumindest so aus.
Also warum ich das so eingetragen habe:

192.168.3.10 ist die WAN Schnittstelle der PF.
192.168.3.118 ist die LAN Schnittstelle der Fritze

So habe ich in der Konfiguration das Netz 192.168.3.0/24 als IPv4 Tunnel-Netzwerk UND auch als IPv4 Lokal-Netzwerk. Ich habe es gemacht, weil ich über VPN auch die Fritze Konfigurieren will. Ob das ohne diesen Eintrag in lokal-Networks auch ginge, weiß ich ehrlich gesagt nicht.