6
RoadWarrior OpenVPN funktioniert nur in Richtung Client
Hallo Leute,
Ein funktionierender OpenVPN-Tunnel bleibt eine Einbahnstraße.
Ist der Surfstick schuld ?
Ich habe pfSense auf einem ALIX installiert. Darauf laufen bereits 2 separate OpenVPN-Tunnel als funktionierende LAN-to-LAN Verbindung.
Da ich WAN-seitig keine feste IP habe, läuft das ganze mit DynDNS seit Monaten problemlos.
Nun habe ich einen weitern Tunnel als RoadWarrior aufgebaut, der nur dazu dienen soll, meinen Laptop von unterwegs mit dem Fileserver im Homenetz zu verbinden.
Zum Test habe ich zu Hause mal einen RTL-Prepaid Surfstick in den Laptop gesteckt, um den Tunnel mal zu checken.
Das Signal war mit gerade mal 20 % nicht gerade berauschend aber ich hatte Internetverbindung.
Der Tunnel funktioniert auch, leider nur nicht wie gewünscht.
Ich habe ssh-Verbindung von meinem Rechner im LAN der pfSense, zum Laptop.
Trotz in der pfSense gesetzter Rules, push "route zum Fileserver" und stehender Tunnelverbindung, ist keine Verbindung vom Laptop zur pfSense bzw. zum Fileserver möglich.
Anpingen kann ich vom Laptop aus nur die Tunnel-IP auf dem Laptop, die auf dem Server ist nicht pingbar, obwohl der Tunnel nach wie vor funktioniert und keine Fehlermeldungen bringt.
Die Routing Tabellen würde ich auch für OK halten.
Nun habe ich im Netz darüber leider nur wiedersprüchliches gelesen, was UMTS-Provider betrifft.
Könnte das Problem mit dem Surfstick zu tun haben ?
Gruß und Danke
orcape
Ein funktionierender OpenVPN-Tunnel bleibt eine Einbahnstraße.
Ist der Surfstick schuld ?
Ich habe pfSense auf einem ALIX installiert. Darauf laufen bereits 2 separate OpenVPN-Tunnel als funktionierende LAN-to-LAN Verbindung.
Da ich WAN-seitig keine feste IP habe, läuft das ganze mit DynDNS seit Monaten problemlos.
Nun habe ich einen weitern Tunnel als RoadWarrior aufgebaut, der nur dazu dienen soll, meinen Laptop von unterwegs mit dem Fileserver im Homenetz zu verbinden.
Zum Test habe ich zu Hause mal einen RTL-Prepaid Surfstick in den Laptop gesteckt, um den Tunnel mal zu checken.
Das Signal war mit gerade mal 20 % nicht gerade berauschend aber ich hatte Internetverbindung.
Der Tunnel funktioniert auch, leider nur nicht wie gewünscht.
Ich habe ssh-Verbindung von meinem Rechner im LAN der pfSense, zum Laptop.
Trotz in der pfSense gesetzter Rules, push "route zum Fileserver" und stehender Tunnelverbindung, ist keine Verbindung vom Laptop zur pfSense bzw. zum Fileserver möglich.
Anpingen kann ich vom Laptop aus nur die Tunnel-IP auf dem Laptop, die auf dem Server ist nicht pingbar, obwohl der Tunnel nach wie vor funktioniert und keine Fehlermeldungen bringt.
Die Routing Tabellen würde ich auch für OK halten.
Nun habe ich im Netz darüber leider nur wiedersprüchliches gelesen, was UMTS-Provider betrifft.
Könnte das Problem mit dem Surfstick zu tun haben ?
Gruß und Danke
orcape
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 202351
Url: https://administrator.de/contentid/202351
Ausgedruckt am: 24.11.2024 um 13:11 Uhr
6 Kommentare
Neuester Kommentar
Firewall Rules hast du richtig gesetzt bzw. mal ins Firewall Log geschaut ob da was geblockt wird ?
Lokale Server Firewalls entsprechend angepasst um den Zugriff zu erlauben ?
Lokale Server Firewalls entsprechend angepasst um den Zugriff zu erlauben ?
Hi aqui,
die WAN-Rule mit dem Tunnelport passt und der OpenVPN Eintrag zum Fileserver stimmt auch.
Müsste also eigentlich funktionieren. In den Firewall-Logs steht auch nichts.
Ich muss das noch mal von einem Fremdnetz ohne den Stick checken.
Dir ist auch nicht bekannt, ob da bei den Providern vielleicht NAT gemacht wird und das dann in eine Richtung geblockt wird.
Der Tunnel geht trotzdem, weil ja der Server auf der pfSense ist ?
Gruß orcape
Hier steht eventuell die Ursache...
http://www.lawblog.de/index.php/archives/2010/04/19/anonym-uber-umts/
die WAN-Rule mit dem Tunnelport passt und der OpenVPN Eintrag zum Fileserver stimmt auch.
Müsste also eigentlich funktionieren. In den Firewall-Logs steht auch nichts.
Ich muss das noch mal von einem Fremdnetz ohne den Stick checken.
Dir ist auch nicht bekannt, ob da bei den Providern vielleicht NAT gemacht wird und das dann in eine Richtung geblockt wird.
Der Tunnel geht trotzdem, weil ja der Server auf der pfSense ist ?
Gruß orcape
Hier steht eventuell die Ursache...
http://www.lawblog.de/index.php/archives/2010/04/19/anonym-uber-umts/
Hi,
ich bin leider trotz einiger Recherchen im Netz nicht so richtig zum Ziel gekommen.
Der Tunnel steht, zumindest für ICMP und ssh weiter als Einbahnstraße.
nmap meldet mir "host down" für meine DMZ und für mein LAN.
Eingabe vom OpenVPN-Client aus.....
Fakt ist, der Provider blockt hier einiges einfach ab, was wohl "NAPT" zuzuschreiben ist.
Gruß orcape
ich bin leider trotz einiger Recherchen im Netz nicht so richtig zum Ziel gekommen.
Der Tunnel steht, zumindest für ICMP und ssh weiter als Einbahnstraße.
nmap meldet mir "host down" für meine DMZ und für mein LAN.
Eingabe vom OpenVPN-Client aus.....
root@schrotti:/#ip r s
default via 192.168.0.1 dev wlan0 proto static
10.15.8.1 via 10.15.8.5 dev tun0
10.15.8.5 dev tun0 proto kernel scope link src 10.15.8.6
169.254.0.0/16 dev wlan0 scope link metric 1000
192.168.0.0/24 dev wlan0 proto kernel scope link src 192.168.0.100
192.168.155.0/24 via 10.15.8.5 dev tun0
Also ist mein Netz (192.168.155.0/24) über den Tunnel auch erreichbar.default via 192.168.0.1 dev wlan0 proto static
10.15.8.1 via 10.15.8.5 dev tun0
10.15.8.5 dev tun0 proto kernel scope link src 10.15.8.6
169.254.0.0/16 dev wlan0 scope link metric 1000
192.168.0.0/24 dev wlan0 proto kernel scope link src 192.168.0.100
192.168.155.0/24 via 10.15.8.5 dev tun0
Fakt ist, der Provider blockt hier einiges einfach ab, was wohl "NAPT" zuzuschreiben ist.
Gruß orcape
Mit dem Provider kann es nichts zu tun haben ! Du hast einen SSL Tunnel mit UDP 1194, wenn der Fehlerfrei aufgebaut wird ist der Provider raus.
Alle Produktivdaten werden verschlüsselt im Tunnel selber übertragen. Daten im Tunnel sind somit vollkommen intransparent, sprich unsichtbar für den Provider.
Stell dir das wie einen Gartenschlauch vor. Der Provider sieht nur den Schlauch selber, nicht aber das Wasser was in ihm fliesst ! Er weiss noch nichtmal ob Wasser, Cola oder Bier im Gartenschlauch ist !
Folglich kann er also niemals dedizierte Inhalte aus dem "Schlauch" selber filtern.
Es sieht weiterhin irgendwie stark nach einem Regelfehler in der Firewall aus oder...nach einer Fehlkonfiguration lokaler Firewalls der Endsysteme.
Bedenek das du die Regeln beidseitig ! auf beiden Endgeräte Interfaces anpassen musst oder erstmal mit any zu any auf "Scheunentor" stellen solltest zum Test.
Alle Produktivdaten werden verschlüsselt im Tunnel selber übertragen. Daten im Tunnel sind somit vollkommen intransparent, sprich unsichtbar für den Provider.
Stell dir das wie einen Gartenschlauch vor. Der Provider sieht nur den Schlauch selber, nicht aber das Wasser was in ihm fliesst ! Er weiss noch nichtmal ob Wasser, Cola oder Bier im Gartenschlauch ist !
Folglich kann er also niemals dedizierte Inhalte aus dem "Schlauch" selber filtern.
Es sieht weiterhin irgendwie stark nach einem Regelfehler in der Firewall aus oder...nach einer Fehlkonfiguration lokaler Firewalls der Endsysteme.
Bedenek das du die Regeln beidseitig ! auf beiden Endgeräte Interfaces anpassen musst oder erstmal mit any zu any auf "Scheunentor" stellen solltest zum Test.
Hi Aqui,
Die Einstellungen auf der Serverseite (pfSense) sind identisch mit denen von 2 weiteren Tunneln, die problemlos funktionieren.
Der OpenVPN-Linux-Client ist "jungfräulich", d.h. iptables ist installiert aber keine Rule gesetzt.
Der UMTS-WLAN-Router hat keine Firewall aktiviert (NAT ist aus) unabhängig davon, nur mit UMTS-Stick, gleiches Ergebnis.
nmap liefert folgende Ergebnisse meines pfSense-DMZ-Interfaces vom Linux- (OpenVPN-Client) aus....
Es werden definitiv die Pings geblockt, warum auch immer...
Der Versuch mit ssh....
Wireshark hat mir auch nichts anderes gebracht.
Leider habe ich im Internet dazu nur Halbwahrheiten zu lesen bekommen.
UMTS-Prepaid ist so eine "Grauzone"
Gruß orcape
Kleiner Nachtrag....
Du hast einen SSL Tunnel mit UDP 1194, wenn der Fehlerfrei aufgebaut wird ist der Provider raus.
Der Tunnel steht und ist auch von Serverseite aus problemlos nutzbar. Zugriff per ssh auf Linux-Client kein Thema.Die Einstellungen auf der Serverseite (pfSense) sind identisch mit denen von 2 weiteren Tunneln, die problemlos funktionieren.
Der OpenVPN-Linux-Client ist "jungfräulich", d.h. iptables ist installiert aber keine Rule gesetzt.
Der UMTS-WLAN-Router hat keine Firewall aktiviert (NAT ist aus) unabhängig davon, nur mit UMTS-Stick, gleiches Ergebnis.
nmap liefert folgende Ergebnisse meines pfSense-DMZ-Interfaces vom Linux- (OpenVPN-Client) aus....
root@schrotti:/#nmap -sU 172.16.7.1
Starting Nmap 6.00 ( http://nmap.org ) at 2013-05-25 14:46 CEST
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.05 seconds
und....Starting Nmap 6.00 ( http://nmap.org ) at 2013-05-25 14:46 CEST
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.05 seconds
root@schrotti:/#nmap -Pn 172.16.7.1
Starting Nmap 6.00 ( http://nmap.org ) at 2013-05-25 15:47 CEST
Nmap scan report for 172.16.7.1
Host is up.
All 1000 scanned ports on 172.16.7.1 are filtered
Nmap done: 1 IP address (1 host up) scanned in 201.39 seconds
Gleiche Ergebnisse bei Zugriff auf das LAN-Interface.Starting Nmap 6.00 ( http://nmap.org ) at 2013-05-25 15:47 CEST
Nmap scan report for 172.16.7.1
Host is up.
All 1000 scanned ports on 172.16.7.1 are filtered
Nmap done: 1 IP address (1 host up) scanned in 201.39 seconds
Es werden definitiv die Pings geblockt, warum auch immer...
Der Versuch mit ssh....
root@schrotti:/#ssh -w 172.16.7.1
Bad tun device '172.16.7.1'
Siehst Du noch eine Möglichkeit das mit nmap genauer zu lokalisieren.Bad tun device '172.16.7.1'
Wireshark hat mir auch nichts anderes gebracht.
Leider habe ich im Internet dazu nur Halbwahrheiten zu lesen bekommen.
UMTS-Prepaid ist so eine "Grauzone"
Gruß orcape
Kleiner Nachtrag....
root@schrotti:/#nmap -Pn 10.15.8.1
Starting Nmap 6.00 ( http://nmap.org ) at 2013-05-25 18:49 CEST
Nmap scan report for 10.15.8.1
Host is up.
All 1000 scanned ports on 10.15.8.1 are filtered
Nmap done: 1 IP address (1 host up) scanned in 201.59 seconds
Starting Nmap 6.00 ( http://nmap.org ) at 2013-05-25 18:49 CEST
Nmap scan report for 10.15.8.1
Host is up.
All 1000 scanned ports on 10.15.8.1 are filtered
Nmap done: 1 IP address (1 host up) scanned in 201.59 seconds
Hi Aqui,
Du hattest wie fast immer mal wieder Recht.
Ich habe noch mal die pfSense Rules gecheckt.
Es war nur eine Rule auf den Server in der DMZ gesetzt, der ist aber im Moment offline.
Eine Rule von OpenVPN auf das pfSense LAN-Interface gesetzt und ich kann dieses pingen und mich per ssh verbinden.
Ändert aber nichts daran, das sich das Servertunnelende 10.15.8.1, vom OpenVPN-Client aus, nicht pingen lässt.
nmap lügt nicht...
Hast Du eine Erklärung dafür, die den Provider ausschließt ?
Gruß orcape
Du hattest wie fast immer mal wieder Recht.
Ich habe noch mal die pfSense Rules gecheckt.
Es war nur eine Rule auf den Server in der DMZ gesetzt, der ist aber im Moment offline.
Eine Rule von OpenVPN auf das pfSense LAN-Interface gesetzt und ich kann dieses pingen und mich per ssh verbinden.
Ändert aber nichts daran, das sich das Servertunnelende 10.15.8.1, vom OpenVPN-Client aus, nicht pingen lässt.
root@schrotti:/#nmap 10.15.8.1
Starting Nmap 6.00 ( http://nmap.org ) at 2013-05-26 14:32 CEST
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.04 seconds
und.....Starting Nmap 6.00 ( http://nmap.org ) at 2013-05-26 14:32 CEST
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.04 seconds
root@schrotti:/#nmap -Pn 10.15.8.1
Starting Nmap 6.00 ( http://nmap.org ) at 2013-05-26 14:42 CEST
Nmap scan report for 10.15.8.1
Host is up.
All 1000 scanned ports on 10.15.8.1 are filtered
Nmap done: 1 IP address (1 host up) scanned in 201.41 seconds
Starting Nmap 6.00 ( http://nmap.org ) at 2013-05-26 14:42 CEST
Nmap scan report for 10.15.8.1
Host is up.
All 1000 scanned ports on 10.15.8.1 are filtered
Nmap done: 1 IP address (1 host up) scanned in 201.41 seconds
nmap lügt nicht...
Hast Du eine Erklärung dafür, die den Provider ausschließt ?
Gruß orcape
