Funktionierender OpenVPN-Tunnel als Einbahnstrasse über UMTS-Stick/-Router
-
Hi Leute,
ich habe auf einem ALIX-Board pfSense installiert, darauf laufen 3 OpenVPN-Server.
2 Tunnel laufen als LAN-to-LAN, funktioniert super in beide Richtungen.
Ein weiterer Tunnel soll den Zugriff eines Client-Laptop auf einen Server in der DMZ an der pfSense ermöglichen.
Der Client-Laptop kommt über einen RTL-Stick (Vodafone) ins Internet.
Dieser Tunnel funktioniert auch, mit Tunnel-IP 10.15.8.6 ist der Client-Laptop (Debian) von meinem LAN über die pfSense zu erreichen.
Leider funktioniert die Gegenrichtung, die ja eigentlich benötigt wird, nicht.
Ein ping vom Laptop auf das Tunnelende 10.15.8.1 funktioniert nicht, obwohl der Tunnel steht.
Hier mal die Routing-Tabelle des OpenVPN-Clients.root@schrotti:~#route
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
default 192.168.0.1 0.0.0.0 UG 0 0 0 wlan0
10.15.8.1 10.15.8.5 255.255.255.255 UGH 0 0 0 tun0
10.15.8.5 * 255.255.255.255 UH 0 0 0 tun0
link-local * 255.255.0.0 U 1000 0 0 wlan0
192.168.0.0 * 255.255.255.0 U 0 0 0 wlan0
localnet 10.15.8.5 255.255.255.0 UG 0 0 0 tun0Wobei 192.168.0.0/24 das Netz des UMTS-WLAN-Routers ist.
Hier mal noch die Ausgabe von ifconfig für das tun0-Interface….tun0 Link encap:UNSPEC Hardware Adresse 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet Adresse:10.15.8.6 P-z-P:10.15.8.5 Maske:255.255.255.255
UP PUNKTZUPUNKT RUNNING NOARP MULTICAST MTU:1500 Metrik:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:100
RX bytes:0 (0.0 B) TX bytes:756 (756.0 B)Es werden nur TX-Pakete angezeigt ?
Hat jemand eine Idee, was mein Problem lösen könnte.
Ursache eventuell der UMTS-Provider und dessen NAT?Gruß orcape
-
ohne jetzt das Netzwerk deiner DMZ zu kennen, rate ich mal, dass das Netz nicht in Deiner route Tabelle steht?
OpenVPN muss eine route zum DMZ zum OpenVPN Client pushen, sonst versucht er das seinem default GW zu übergeben; also z.B. unter Advanced angeben:
push route 192.168.10.0 255.255.255.0 -
Hi Reiner,
danke erst mal für Dein Feedback.
ohne jetzt das Netzwerk deiner DMZ zu kennen, rate ich mal, dass das Netz nicht in Deiner route Tabelle steht?
Richtig, der Server, der allein in der DMZ steht, ist z.Zt. im Umbau und deshalb offline.
Das mit dem push "route 172.16.7.0 255.255.255" ist mir schon klar. Damit erreiche ich normalerweise den Server vom Client aus
und das steht dann auch in der Routing Tabelle.
Mein Problem ist, das ich das Tunnelende auf dem OpenVPN-Server 10.15.8.1 vom Client aus weder pingen, noch sonst irgendwie erreichen lässt, obwohl der Tunnel steht.
Das hat aber definitiv nichts mit dem push-Befehl zu tun, das wäre dann interressant, wenn ich zumindest die pfSense-Seite des Tunnels erreichen würde aber das DMZ-Interface nicht.Gruß orcape
-
Hallo orcape
Mein Problem ist, das ich das Tunnelende auf dem OpenVPN-Server 10.15.8.1 vom Client aus weder pingen, noch sonst irgendwie erreichen lässt, obwohl der Tunnel steht.
Das hat aber definitiv nichts mit dem push-Befehl zu tun, das wäre dann interressant, wenn ich zumindest die pfSense-Seite des Tunnels erreichen würde aber das DMZ-Interface nicht.hast Du denn das OpenVPN Netz von der LAN Seite aus erlaubt (bzw. nicht verboten) ? Wenn Du noch nicht mal das pfSense Interface der eigenen Seite so erreichen kannst hört sich das stark danach an…
-
Hi,
also, noch mal im Klartext….
Pfsense Openvpn-Server 10.15.8.1 ist vom LAN hinter der pfSense erreichbar.
DMZ 172.16.7.0/24 ist per Rule der pfSense freigegeben.
WAN pfSense erreichbar von remote über Dyndns.
Tunnel 10.15.8.0/24 steht.
Remoter Linux-Laptop (OpenVPN-Client) hängt wahlweise an einem UMTS-Stick oder UMTS-Router, ist über 10.15.8.6 von meinem LAN erreichbar.
Gegenrichtung, 10.15.8.1 (OpenVPN-Server) ist vom remoten Client nicht erreichbar, obwohl eine Firewallregel auf der pfSense eingerichtet ist.
Selbst wenn keine FW-Regel wäre, müsste die Tunnelend-IP des OVPN-Servers erreichbar sein.
UMTS-Provider (Prepaid) vergibt private IP's, 10.0.0.0 Netz und macht laut Info.... Network-Address-Port-Translation (NAPT) .
Ich vermute hier die Ursache....Gruß orcape
-
Hi Reiner,
hier mal ein Link, der Dir einiges mehr sagen wird, hoffe ich.
http://www.administrator.de/contentid/202351
Der Tunnel funktioniert, durch den Provider wird wohl nur ein Ping verhindert.Gruß orcape
-
Hi orcape
@orcape:Der Tunnel funktioniert, durch den Provider wird wohl nur ein Ping verhindert.
Also in den Antworten steht auch, dass der Provider nur den externen Ping verhindern kann, aber nicht den Tunnel-internen ping…
Vielleicht hilft es ja, in den OpenVPN Optionen zu spielen, dass z.B. das "Verbindung steht" ping/"keep alive" Pakete mit einer kürzeren Intervall gesendet werden oder z.B. von intern nach aussen regelmässig HTTP Requests o.ä. durchgeführt werden, die den OpenVPN Tunnel sauber offen halten.
Ob VPN Tunnel funktionieren oder nicht, kann übrigens an der Art des Vertrages liegen... die "Home" Varianten müssen sich eine IP sharen; bei Business Tarifen bekommt jede Karte eine separate IP (wichtig für IPSec z.B.).
Grüße
Reiner
-
Hi Reiner,
Also in den Antworten steht auch, dass der Provider nur den externen Ping verhindern kann, aber nicht den Tunnel-internen ping…
Nun, der Tunnel steht und ein ping auf das Servernetz funktioniert.
Ein ping auf die Tunneladresse ist ja sowieso nur zum testen nötig, wenn man den Server erreicht, muss auch der Tunnel stehen, vorausgesetzt die Firewall ist nicht offen wie ein Scheunentor. ;-)
Na ja, wieder was dazugelernt.Gruß Peter