OpenVPN Verbindung scheitert von einem einzigen Client

cwt

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

viragomann

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.

cwt

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… :(

viragomann

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ü.

cwt

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ß

magicteddy

Moin,

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

-teddy

cwt

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.

hbauer

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

viragomann

@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.

cwt

@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

Grimson

@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.

cwt

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).

Grimson

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.

JeGr

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.