8
VPN nur eine Richtung - OpenVPN - pfSense - Debian
Hallo,
ich habe folgendes Problem in einer VPN-Umgebung.
Alle Verbindungen bis auf die von pfsense 1 zu OpvenVPN on Debian sind funktionsfähig.
Die Verbindung von OpenVPN on Debian zu pfSense 1 funktioniert nicht.
Die Verbindung ist bis zum Interface (10.0.1.1) auf der pfSense0 möglich.
VPN-Config:
Open VPN on Debian:
pfSense 0:
Reichen die gegebenen Informationen aus um einen ersten Tipp zu geben oder sind weitere Konfigurationsdetails notwendendig?
Danke für die Hilfe im Voraus.
ich habe folgendes Problem in einer VPN-Umgebung.
Alle Verbindungen bis auf die von pfsense 1 zu OpvenVPN on Debian sind funktionsfähig.
Die Verbindung von OpenVPN on Debian zu pfSense 1 funktioniert nicht.
Die Verbindung ist bis zum Interface (10.0.1.1) auf der pfSense0 möglich.
VPN-Config:
Open VPN on Debian:
pfSense 0:
Reichen die gegebenen Informationen aus um einen ersten Tipp zu geben oder sind weitere Konfigurationsdetails notwendendig?
Danke für die Hilfe im Voraus.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 645551
Url: https://administrator.de/contentid/645551
Printed on: April 19, 2024 at 08:04 o'clock
8 Comments
Latest comment
Hallo digitalfrosch,
warum PING ?
geht doch viel schöner mit traceroute - zumal du da auch siehst, ab wo nicht mehr weitergrouted wird!
Ansnonsten - wer eine Antwort haben will, muß auch für die "Rückroute" sorgen
Danach sind meiner Erfahrung nach fast 99% aller "Fehler" wie weggeblasen.
Fred
warum PING ?
geht doch viel schöner mit traceroute - zumal du da auch siehst, ab wo nicht mehr weitergrouted wird!
Ansnonsten - wer eine Antwort haben will, muß auch für die "Rückroute" sorgen
Danach sind meiner Erfahrung nach fast 99% aller "Fehler" wie weggeblasen.
Fred
Viel hilfreicher zum Troubleshooting wäre einmal der Output der Routing Tabelle von den beteiligten OpenVPN Knoten pfSense 1 und Debian OpenVPN !!
Auf der pfSense unter Diagnostics und Debian mit ip route show oder netstat -r -n
Das zeigt dir doch ganz genau an welche IP Netze wo in den Tunnel gehen !
Kollege @fredmy hat ebenso recht: Traceroute ist natürlich ebenso hilfreich. Da wo es nicht mehr weitergeht ist zu 99% der Fehler.
Den Rest erklärt dir das OpenVPN Tutorial:
Merkzettel: VPN Installation mit OpenVPN
Auf der pfSense unter Diagnostics und Debian mit ip route show oder netstat -r -n
Das zeigt dir doch ganz genau an welche IP Netze wo in den Tunnel gehen !
Kollege @fredmy hat ebenso recht: Traceroute ist natürlich ebenso hilfreich. Da wo es nicht mehr weitergeht ist zu 99% der Fehler.
Den Rest erklärt dir das OpenVPN Tutorial:
Merkzettel: VPN Installation mit OpenVPN
Hallo,
danke für die Tipps.
Anbei die Routen / Traceroute:
Traceroute von Debian zu pfSense 1:
Zu sehen ist wo es stoppt.
Routen in der pfSense 0:
Routen in der pfsense 1:
Routen Debian:
Die Konfiguration / Routen in von pfSense 1 zu pfsense 3 funktionieren in beide Richtungen.
Die Konfiguration / Routen in von pfSense 1 zu pfsense 2 funktionieren in beide Richtungen.
Übersehe ich etwas?
danke für die Tipps.
Anbei die Routen / Traceroute:
Traceroute von Debian zu pfSense 1:
Routen in der pfSense 0:
Routen in der pfsense 1:
Routen Debian:
Die Konfiguration / Routen in von pfSense 1 zu pfsense 3 funktionieren in beide Richtungen.
Die Konfiguration / Routen in von pfSense 1 zu pfsense 2 funktionieren in beide Richtungen.
Übersehe ich etwas?
Was zudem etwas wirr ist sind die verschiedenen 10er OVPN Netze an pfSense 0 ?? Was haben die zu bedeuten ? Arbeitest du im internen OVPN Netz mit einem /16er Prefix ?
Wäre nicht falsch aber etwas ungewöhnlich weil man dort meist /24er nutzt. Generell auch nicht mehr mit dem völlig veralteten net30 Verfahren was jeden Client in ein dediziertes /30er Subnetz zwingt.
Normal nutzt man das modernere subnet Verfahren (push "topology subnet") um frei aus dem internen Pool (z.B. server 10.1.1.0 255.255.255.0) verteilen zu können. In sofern werfen diese Adressen etwas Rätsel bzgl. korrekter IP Adressierung auf ?!
So oder so.. Der Debian kennt das 192.168.0.0 /24 Netz was er in den Tunnel routet. Ebenso kennen beide pfSense 0 und 1 das Debian IP Netz jeweils über den VPN Tunnel. Routingtechnisch sieht das also ganz gut und auch sauber aus was den Traffic zu pfsense 1 anbetrifft.
Da kann man dann nur vermuten das irgendwo auf dem 2 Hops durch die 2 Firewalls eine FW Regel zuschlägt und den .100.0er Traffic wegfiltert. (Ggf. "First match wins Regel" nicht beachtet ?!)
Kann man aber ohne das Regelwerk genau zu kennen erstmal nur raten. Da solltest du also nochmal forschen...
Wäre nicht falsch aber etwas ungewöhnlich weil man dort meist /24er nutzt. Generell auch nicht mehr mit dem völlig veralteten net30 Verfahren was jeden Client in ein dediziertes /30er Subnetz zwingt.
Normal nutzt man das modernere subnet Verfahren (push "topology subnet") um frei aus dem internen Pool (z.B. server 10.1.1.0 255.255.255.0) verteilen zu können. In sofern werfen diese Adressen etwas Rätsel bzgl. korrekter IP Adressierung auf ?!
So oder so.. Der Debian kennt das 192.168.0.0 /24 Netz was er in den Tunnel routet. Ebenso kennen beide pfSense 0 und 1 das Debian IP Netz jeweils über den VPN Tunnel. Routingtechnisch sieht das also ganz gut und auch sauber aus was den Traffic zu pfsense 1 anbetrifft.
Da kann man dann nur vermuten das irgendwo auf dem 2 Hops durch die 2 Firewalls eine FW Regel zuschlägt und den .100.0er Traffic wegfiltert. (Ggf. "First match wins Regel" nicht beachtet ?!)
Kann man aber ohne das Regelwerk genau zu kennen erstmal nur raten. Da solltest du also nochmal forschen...
Hallo ,
ach ja.. kannst du bei pfsense keine Routenausgabe auf der Kommandozeile ?
Hatte so ein Konstrukt in einer früheren Firma am Laufen, allerdings Linux-Maschinen (kein BSD) Routing-Tables waren etwas größer
Ansonsten: alles was du nicht in der openvpn.conf an Routen setzen kannst/willst ist nach jedem Tunnelabbruch/Tunnelneuaufbau weg ! Mit dem Tunnelabbruch verschwindet das tun-device.
Hatte ein 60-sec-sleep-ping script, welches "auf Verdacht" die Routingtabelle neu initiiert hat bei Nichtantwort. Hat paar Jahre funktioniert ( Endstellen waren teilweise über UMTS/LTE angebunden)
Fred
ach ja.. kannst du bei pfsense keine Routenausgabe auf der Kommandozeile ?
Hatte so ein Konstrukt in einer früheren Firma am Laufen, allerdings Linux-Maschinen (kein BSD) Routing-Tables waren etwas größer
Ansonsten: alles was du nicht in der openvpn.conf an Routen setzen kannst/willst ist nach jedem Tunnelabbruch/Tunnelneuaufbau weg ! Mit dem Tunnelabbruch verschwindet das tun-device.
Hatte ein 60-sec-sleep-ping script, welches "auf Verdacht" die Routingtabelle neu initiiert hat bei Nichtantwort. Hat paar Jahre funktioniert ( Endstellen waren teilweise über UMTS/LTE angebunden)
Fred
kannst du bei pfsense keine Routenausgabe auf der Kommandozeile ?
Doch geht natürlich auch per PuTTY oder Teraterm mit SSH Access und dann "Shell" und dort dann wieder mit den üblichen netstat oder ip show Kommandos !Weitere Kommandos für die Conf Datei musst du im Fenster "Additional Commands" eingeben, die bleiben dann auch nach einem reload bestehen. OVPN Konfig Datei kannst du dir ebenfalls mit nano oder vi via Shell Access direkt ansehen.
Ich habe alles einmal neu gestartet. Seitdem funktioniert es.
Ist ja eigentlich typisches Winblows Verhalten ! 😉 Aber gut wenn's nun rennt.
