meerwasser
Goto Top

OpenVPN lässt keine Daten durch den Tunnel

Hallo,

ich habe ein OpenVPN auf Windows 8.1 installiert.
Ich kann mich auch problemlos zum Server verbinden.
Ich bekommen eine IP zugewiesen.
Routing Tabelle sieht auch in Ordnung aus.
Sobald ich Daten (Ping) durch den Tunnel senden möchte sieht das ganze so aus, dass der erste Ping eine Anwort Zielhost nicht erreichbar bringt (Vom richtigen Interface).
Alle weiteren Pings werden gleich beantortet aber vom default Gateway.

Von einem anderen PC läuft die Verbindung ohne Probleme.

Meine Konfig:
client
dev tun
proto tcp
remote 75.167.122.112 443
resolv-retry 5
persist-key
persist-tun
pkcs12 Zert.p12
comp-lzo
pull
verb 3

Wir haben Firewall und ähnliches deaktiviert.
Wir haben auch den TAP Adapter danach auf Privates Netzwerk gestellt.

Eine erneute Installation und mehrfache Reboots dazwischen blieben Erfolglos.

Hat jemand noch eine Idee dazu?

Danke für Eure Rückmeldungen.

ac9bec67839e5efcd4868d63c2b22604

Content-Key: 289509

Url: https://administrator.de/contentid/289509

Printed on: April 18, 2024 at 01:04 o'clock

Member: aqui
aqui Nov 27, 2015 updated at 15:32:54 (UTC)
Goto Top
Erstmal vorweg:
Es ist kontraproduktiv TCP Encapsulierung im Tunnel zu benutzen. OpenVPN rät auch dringenst aus Performancegründen davon ab !
Du solltest also immer besser UDP als Tunnel Encapsulierung belassen und niemals TCP verwenden.
Das aber nur nebenbei, es hat ursächlich erstmal mit deinem obigen Problem nichts zu tun.

Bevor wir ins Eingemachte gehen solltest du erstmal ganz genau erklären WAS du mit dem Begriff "Zielhost" genau meinst ??
Ist das der OpenVPN Server selber oder ist das ein Zielhost in einem remoten Netz ?
Nur so viel dazu erstmal:
  • Der OpenVPN Server selber muss in jedem Falle anpingbar sein ! Und zwar auf seiner internen IP Adresse des Tunnelnetzes und auf seiner LAN IP mit der er im remoten Netz ist. Klappt das bei dir ?
  • Probleme einen externen Zielhost in einem remoten Netz zu pingen können mehrere Ursachen haben:
  • 1.) Der Zielhost hat ein anderes Default Gateway. Das ist häufig der Fall wenn der VPN Server innerhalb des lokalen Netzes hinter einem NAT Router plaziert ist. Antwort Pakete schickt der Zielhost dann an den lokalen Router. Hat dieser KEINE statische IP Route konfiguriert die eine Route in das interne VPN Tunnelnetz definiert mit der LAN IP des OVPN Servers als Gateway gehen die VPN Pakete ins Nirwana beim Provider. Ein typischer Fehler hier.
  • 2.) Die lokale Firewall des Zielhostets ist NICHT entsprechend customized. Pakete von VPN Clients kommen mit der Absender IP des internen Tunnelnetzes was eine lokale Firewall sofort blockt, da es kein Paket aus dem lokalen IP LAN ist.
  • 3.) Ping Pakete (ICMP Protokoll) ist generell geblockt. Das ist bei Windows Versionen ab 7 der Fall. Wie man ICMP Echo (Ping) in der lokalen Firewall wieder aktiviert beschreibt dieses Website: https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
Traceroute und Pathping sowie das Client Log sind hier wie immer deine besten Freunde beim Troubleshooting !

Halte dich ansonsten beim Troubleshootig an das hiesige OVPN Tutorial was für alle diese probleme eine Hilfestellung gibt:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Member: LordGurke
LordGurke Nov 28, 2015 at 13:03:30 (UTC)
Goto Top
Zitat von @aqui:
Es ist kontraproduktiv TCP Encapsulierung im Tunnel zu benutzen. OpenVPN rät auch dringenst aus Performancegründen davon ab !
Du solltest also immer besser UDP als Tunnel Encapsulierung belassen und niemals TCP verwenden.

Es gibt da draußen (Kabel-)Provider, die ein Rate-Limiting auf UDP haben und nur eine bestimmte Paketrate darüber zulassen. Die liegt in der Regel hoch genug für Onlinespiele und VoIP, kommt aber bei voller Paketgröße nur auf ca. 4-5 Mbit/s Bandbreite.
Da ist es dann tatsächlich performanter TCP für den Tunnel zu nehmen - selbst mit den Performanceeinbußen durch TCP hast du dann höhere Bandbreite als mit UDP. Erschwerend kommt hinzu, dass manche Firewalls (schwachsinnigerweise) alle UDP-Pakete mit einer Größe über 512 Bytes verwerfen.
Member: aqui
aqui Nov 28, 2015 at 13:27:48 (UTC)
Goto Top
OK unter diesen Umständen (und wirklich nur unter diesen) macht das dann zweifelsohne Sinn, keine Frage.