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

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.

JeGr

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

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.

Das ist aber falsch, denn dein TUNNEL Netzwerk ist NICHT ein Netz, was du via VPN erreichen wirst, sondern das Netz aus dem dein VPN Client eine IP bekommt. Und das KANN man nicht einfach mehrfach deklarieren - darum spuckt deine Sense auch beim Konfigurieren ROUTE Fehler, weil sie den VPN Server nicht auf ein Netz binden kann das lokal existiert. So läuft das nicht :)

Was dir fehlt/gefehlt hat ist lediglich das 192.168.3.0/24 zusätzlich beim lokalen Netzwerk einzutragen, damit der Client das auch geroutet bekommt, dann wärst du da problemlos draufgekommen. Wir haben schon problemlos via OpenVPN Einwahl und VPN Tunnel das DSL Modem auf der Remote Seite vorne erreicht - wenn das Routing passt, ist das gar keine große Sache, oder @NOCling? ;)

Cheers
\jens

NOCling

Nein ist kein Ding, man muss nur einmal verstanden haben was man wie wo per NAT verarschen muss. Dann komme ich an das Modem mit der gleichen IP wie bei mir am WAN hängend, obwohl es bei meinen Eltern steht.

Aber dazu benötigt man halt auch gescheites Netzkonzept ohne gewisse Bereiche, ohne Not mehr als 1 mal zu verwenden.

Meine HP Switche muss ich ja auch per source NAT austricksen, ebenso die FritzBox die im LAN als Client läuft.
Gewusst wie halt...

Tobi

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

Das ist aber falsch

Na jetzt bringst mich aber durcheinander.
(Zunächst sei gesagt - OpenVPN funktioniert und auf die Fritze komme ich über die VPN Verbindung drauf. Route Fehler ist noch drin, da ich an der Konfig nichts gemacht habe)

So jetzt zu dem "Tunnel" und "lokale Netzwerke"

Die Konfiguration sieht so aus:

Damit ist es doch so wie Du es schreibst oder nicht?

JeGr

@tobi Nochmal

Dein TUNNEL Netzwerk DARF sich nicht mit einem lokalen Netz überlappen. Das TUT es aber!
Nimm für dein Tunnelnetz IRGENDWAS anderes. 10.20.30.0/24 völlig egal. Das ist lediglich das Netz, was deine Clients nach der Einwahl bekommen.

Sinnvoll packt man das einfach mit dazu in den Range, den man sich definiert mit dazu, für den Fall dass man mal nen Tunnel baut und man dann eine schöne große Netzmaske macht, in der alle Netze - auch VPN - mit drin sind.

Aber es dürfen keine Netze doppelt vergeben sein! Schon gar nicht wenn da Tunnelnetz mit Uplink zur Fritze kollidiert. Das ist mal ganz mies. Das "funktioniert" aktuell gerade so mal eben weil deine Fritze nicht auf .1 oder .254 liegt sondern auf irgendeiner komisch krummen IP .118 und .10 die Sense ist. Da hast du einfach nur Glück gehabt, weil OpenVPN sich dann automatisch .1 und .2 vom Tunnelnetz klaut und es deshalb zu keiner IP Kollision kommt.

In jedem normalen Netz was .1 oder .254 als Gateways nutzt wäre dir die Konfiguration schon beim Einrichten mit Anlauf um die Ohren geflogen