OpenVPN Verbindung scheitert von einem einzigen Client
-
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.
-
-
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.
