Neue Hardware - OpenVPN geht nicht. Wo/ wie mit der Fehlersuche anfangen?
-
@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.
-
@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.
-
@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
-
Danke für die zahlreiche Antworten.
Das Problem ist nicht mehr aktuell. -
Das ist ja schon mal gut
Was führte zur Lösung? -
@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. -
@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
-
@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. -
@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 lo0Das 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 -
@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 FritzeSo 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.
-
@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 -
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... -
@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?
-
@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
