OpenVPN Verbindung scheitert von einem einzigen Client



  • Aloha @all.

    Ich habe mit einem Client, welcher sich per OpenVPN verbindet, momentan ein sehr merkwürdiges Problem: die Verbindung wird einfach nicht aufgebaut (60 Sekunden Timeout).

    Ca. 1 Woche vorher hatte ich noch Snort auf der pfSense im Einsatz und dieses Paket wieder deinstalliert. Das Problem mit der nicht mehr funktionierenden Verbindung trat ungefähr zeitgleich mit der Deinstallation auf (die Option zum Belassen der Snort-Regeln hatte ich deaktiviert). pfSense hatte ich zur Sicherheit neu gestartet.

    Alle anderen User (mich eingeschlossen) können sich problemlos per OpenVPN verbinden. Auf dem Problem-Client (Windows 7 Pro) habe ich testweise andere OpenVPN-Verbindungen zu anderen Systemen erfolgreich aufbauen können. Das VPN-Profil des Users habe ich auf meinem System testweise importiert und kann von meinem PC aus die Verbindung aufbauen. Der User hat bereits seinen Router mehrfach neu gestartet und auch neue IPs erhalten. Jetzt habe ich dunkel im Verdacht, dass Snort eine IP-Range geblockt und als Leiche zurückgelassen hat, aus welcher die Einwahl des Clients erfolgt.

    Was ich auf dem Problem-PC bereits erfolglos versucht habe:

    • Deaktivierung der Win-Firewall
    • Überprüfung der Hosts-Datei
    • Deaktivierung der Security Essentials
    • Neuinstallation von SecurePoint VPN
    • Deaktivierung der UAC
    • Standardrouten überprüft

    OpenVPN funktioniert ja grundsätzlich auf dem Client. Bei den anderen Verbindungen gab es keinerlei Probleme oder Verzögerungen.

    pfSense wird in V2.3.4-RELEASE-p1 verwendet.

    In den Firewall-Logs erscheint beim scheiterenden Verbindungsversuch keinerlei Eintrag.

    Gibt es eine Möglichkeit, eventuell über die Konsole/SSH Snort-Leichen in IPTABLES zu finden? Wobei ich das auch nicht wirklich glaube, da ein Aufruf der DynDNS-Adresse des Systems mit dem Browser (Portforwarding auf Webmailer) wiederum vom Client aus funktionert…

    Danke im Voraus & LG



  • Was genau steht im Client Log?
    Zeigt das Server Log den Verbindungsversuch?

    Wenn nicht, erreicht der Client meist den Server gar nicht. Das kann natürlich auch auf Serverseite liegen.
    Um das festzustellen kannst du ein Paket Capture am WAN Interface machen, gefiltert nach jeweiligen Port und ggf. auch nach Clients-IP.



  • Im Client Log erscheint lediglich:

    TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
    TLS Error: TLS handshake failed
    SIGUSR1[soft,tls-error] received, client-instance restarting

    Im Log von pfSense wird der Verbindungsversuch gar nicht angezeigt.

    Bei allen anderen OpenVPN-Verbindungen klappt - wie erwähnt - alles reibungslos. Auch von meinem PC auf besagtes pfSense-System.

    Werde ich wohl doch mal mit Wireshark am Client ran müssen…  :(



  • Ja, dieser Fehler am Client gepaart mit dem Fehlen des Verbindungsversuchs im Server-Log deutet darauf hin, dass der Client den Server gar nicht erreicht.

    "Paket Capture" findest du in der pfSense GUI im Diagnostic-Menü.



  • Sooo…

    nachdem ich auf dem "Problem-Client" Wireshark hatte laufen lassen, bin ich nicht wirklich weitergekommen. Es kam lediglich ein Hinweis darauf, dass der Client einen ICMP des pfSense beim Verbindungsaufbau nicht beantwortet.

    Jetzt kommt aber der Witz an der Sache: momentan sitze bzw. hänge ich in einem WLAN mit Telekom VDSL und habe plötzlich genau das gleiche Problem. Nutze ich mein Smartphone als Hotspot (Vodafone) funktioniert der Zugang auch bei mir wieder ohne Probleme.

    Der "Problem-Client" verbindet sich ebenfalls via Telekom VDSL.

    Der pfSense hängt im Netz der EWETel.

    Wo setzt man denn jetzt noch an? Den Providern auf die Füße treten?

    Schönes WE!

    Gruß



  • Moin,

    hast Du "ungünstige" Ports gewählt die der Provider aus irgendeinem einschränkt bzw. blockiert?

    -teddy



  • Moin.

    Nein, es wird ganz „normal“ Port 1194 verwendet.

    Die Gemeinsamkeit der Internetzugänge ist jeweils die Telekom (VDSL) sowie ein grütziger Speedport (W724).

    Dass die Speedports ausgehenden Traffic auf 1194 plötzlich blocken, wäre mir neu. Geblockt wird auch „nur“ die Verbindung vom Telekom ins EWE—Netz. Telekom zu Kabel geht.



  • nur um sicherzugehen. der TLS key ist aber auf dem Client. richtig?



  • @cwt:

    Es kam lediglich ein Hinweis darauf, dass der Client einen ICMP des pfSense beim Verbindungsaufbau nicht beantwortet.

    Das verstehe ich nicht. Ich kann mir nicht denken, dass der Server ICMP-Anfragen an den Client, eher umgekehrt. Als erstes muss sich beim Verbindungsaufbau jedenfalls der Client beim Server melden.

    Wie sieht es mit der Namensauflösung am Client aus? Bekommst du die richtige öffentliche IP des Servers?
    Wenn ja, mach ein Packet Capture am WAN der pfSense (Diagnostic Menü) während eines Verbindungsversuchs und schaue, ob da Pakete des Clients ankommen.



  • @hbauer: Ja, der Key ist richtig. Über einen anderen Zugang als die Telekom funktioniert es.

    @viragoman: das war das Kuriose beim Logging mittels Wireshark auf dem Client. Nagel mich jetzt aber nicht fest, das war vor über 2 Wochen und ich hatte erstmal einen anderen VPN-Zugang temporär realisiert. Parallel dazu hatt ich das Capture am pfSense laufen lassen. Von der IP des Clients kam da überhaupt nichts an.

    Die Namensauflösung funktioniert ohne Probleme. Bei meinem momentanen Zugang via Telekom tritt ja das gleiche Phänomen auf.

    Keine statischen IP- oder DNS-Adressen eingetragen, alles über DHCP der Teletubby-Router. Es läuft auch keine Pseudo-Sicherheitssoftware oder zus. Firewall auf den Clients.

    Telekom VDSL -> EWE = kein Verbindungsaufbau möglich
    Vodafone LTE -> EWE = keine Probleme
    Telekom LTE -> EWE = keine Probleme
    Vodafone Kabel -> EWE = keine Probleme



  • @cwt:

    Keine statischen IP- oder DNS-Adressen eingetragen, alles über DHCP der Teletubby-Router. Es läuft auch keine Pseudo-Sicherheitssoftware oder zus. Firewall auf den Clients.

    Die neueren Telekom Router mischen sich auch in ausgehende Verbindungen ein. SMTP Verbindungen zu "unbekannten" Servern werden da z.B. auch geblockt, wenn man diese nicht im Webinterface des Routers einträgt. Würde mich nicht wundern wenn der Router auch andere Ports filtert.



  • AFAIK betrifft das aber nicht den alten Kram wie Speedport 723/724. Es sei denn, die Brüder von der Magenta-Butze haben neue Features
    via Easy-Support für die alten Boxen eingeführt. Allerdings: OpenVPN-Verbindungen zu anderen Systemen, welche nicht im EWE-Netzbereich liegen, funktionieren ja (auch auf Port 1194).



  • Na wenn am WAN port von der pfSense nix ankommt dann filtert da etwas schon vorher, bleibt also:

    • Die Client Hardware/Software

    • Der Provider des Clienten

    • Der Provider des Servers

    Beim ersten Punkt mal trial and error mit anderer Hardware probieren, ansonsten mit beiden Providern mal telefonieren und auf eine kompetente Aussage hoffen.


  • Moderator

    Alternativ zum Debugging: VPN Port auf was ganz Fremdes umstellen bzw. einen zweiten Server zum Test aufsetzen damit man hin und herschalten kann. Mir schwirrt auch noch was im Kopf rum, dass die Telejungs mal VPN gebremst/geblockt hatten in irgendeiner Situation, aber egal ob oder nicht, evtl hilft da schon ein anderer Port oder eben mal zum Test tcp/443.