12
OpenVPN-Einwahl über DG-Anschluss nicht möglich per "UDP"
Hallo Leute,
habe hier ein seltsames Problem mit einer OpenVPN-Einwahl über einen Anschluss der Deutsche-Glasfaser.
Der DG-Anschluss ist in einem privaten Haushalt geschaltet.
Die OpenVPN-Einwahl wird von einem Notebook aus gemacht, das sich hinter einer FritzBox-7590 befindet.
Die FB-7590 hängt am besagten Anschluss der Deutsche-Glasfaser.
An der FritzBox liegen eine öffentliche IPv6-Adresse sowie eine CGNAT-IPv4-Adresse an.
Das Problem, um das es geht:
Die OpenVPN-Einwahl ist vom oben erwähnten Notebook nicht möglich.
Und zwar ist das der einzige Anschluss, über den die VPN-Einwahl nicht möglich ist.
Mit der gleichen VPN-Konfigurationsdatei kann das gleiche Notebook ohne Probleme
die VPN-Verbindung aufbauen, wenn es per (WLAN)-Hotspot über das Mobilfunknetz die Verbindung herstellt.
Der OpenVPN-Server läuft auf einer Sophos-XGS-Firewall mit SFOS-Version 19.5.3.
Interessant ist auch, dass ICMP-Pakete an der Firewall ankommen, wenn die (öffentliche) IPv4-Adresse
der Firewall vom besagten Notebook (über den Anschluss der Deutsche-Glasfaser) angepingt wird.
Außerdem kommen TCP-Pakete an der Firewall an, wenn ich zum Beispiel vom besagten Notebook
aus versuche die Weboberfläche der Firewall (über den Anschluss der Deutsche-Glasfaser) über dessen IPv4-Adresse aufzurufen.
Es gibt eine Packet-Capture-Funktion auf der Sophos-Firewall, mit der man die Pakete mitschneiden kann,
deshalb weiß ich also, dass ICMP-Pakete sowie TCP-Pakete an der Firewall ankommen, wenn man
dessen IPv4-Adresse als Ziel-IP anspricht.
Wenn man allerdings die OpenVPN-Verbindung versucht aufzubauen, dann kommt an der Firewall kein
einziges Paket an. Als Transportprotokoll ist im OpenVPN-Server auf der Sophos-Firewall "UDP" eingestellt,
das ist die Standardeinstellung.
Hat jemand schon mal vor diesem Problem gestanden und konnte dafür eine Lösung finden?
Aktuell habe ich folgende Ideen, um bei diesem Problem weiter zu kommen:
1. Support der Deutsche-Glasfaser kontaktieren (wofür ich die Kundennummer der Person brauche, die das VPN-Problem hat)
2. Testweise den OpenVPN-Server auf "TCP" umstellen und dann testen, ob die Person, die bisher die OpenVPN-Verbindung nicht aufbauen konnte, dann die VPN-Verbindung herstellen kann. Im Anschluss müssten sich
dann aber (leider) alle anderen Personen die VPN-Konfigurationsdatei neu aus dem Userportal der Firewall herunterladen und im OpenVPN-Client importieren (nennt sich Sophos-Connect-Client, um genau zu sein).
3. Mal testweise anstatt dem Sophos-Connect-Client den OpenVPN-Client von "openvpn.net" zu installieren und dann versuchen die VPN-Verbindung herzustellen.
Was denkt ihr dazu?
Datax
habe hier ein seltsames Problem mit einer OpenVPN-Einwahl über einen Anschluss der Deutsche-Glasfaser.
Der DG-Anschluss ist in einem privaten Haushalt geschaltet.
Die OpenVPN-Einwahl wird von einem Notebook aus gemacht, das sich hinter einer FritzBox-7590 befindet.
Die FB-7590 hängt am besagten Anschluss der Deutsche-Glasfaser.
An der FritzBox liegen eine öffentliche IPv6-Adresse sowie eine CGNAT-IPv4-Adresse an.
Das Problem, um das es geht:
Die OpenVPN-Einwahl ist vom oben erwähnten Notebook nicht möglich.
Und zwar ist das der einzige Anschluss, über den die VPN-Einwahl nicht möglich ist.
Mit der gleichen VPN-Konfigurationsdatei kann das gleiche Notebook ohne Probleme
die VPN-Verbindung aufbauen, wenn es per (WLAN)-Hotspot über das Mobilfunknetz die Verbindung herstellt.
Der OpenVPN-Server läuft auf einer Sophos-XGS-Firewall mit SFOS-Version 19.5.3.
Interessant ist auch, dass ICMP-Pakete an der Firewall ankommen, wenn die (öffentliche) IPv4-Adresse
der Firewall vom besagten Notebook (über den Anschluss der Deutsche-Glasfaser) angepingt wird.
Außerdem kommen TCP-Pakete an der Firewall an, wenn ich zum Beispiel vom besagten Notebook
aus versuche die Weboberfläche der Firewall (über den Anschluss der Deutsche-Glasfaser) über dessen IPv4-Adresse aufzurufen.
Es gibt eine Packet-Capture-Funktion auf der Sophos-Firewall, mit der man die Pakete mitschneiden kann,
deshalb weiß ich also, dass ICMP-Pakete sowie TCP-Pakete an der Firewall ankommen, wenn man
dessen IPv4-Adresse als Ziel-IP anspricht.
Wenn man allerdings die OpenVPN-Verbindung versucht aufzubauen, dann kommt an der Firewall kein
einziges Paket an. Als Transportprotokoll ist im OpenVPN-Server auf der Sophos-Firewall "UDP" eingestellt,
das ist die Standardeinstellung.
Hat jemand schon mal vor diesem Problem gestanden und konnte dafür eine Lösung finden?
Aktuell habe ich folgende Ideen, um bei diesem Problem weiter zu kommen:
1. Support der Deutsche-Glasfaser kontaktieren (wofür ich die Kundennummer der Person brauche, die das VPN-Problem hat)
2. Testweise den OpenVPN-Server auf "TCP" umstellen und dann testen, ob die Person, die bisher die OpenVPN-Verbindung nicht aufbauen konnte, dann die VPN-Verbindung herstellen kann. Im Anschluss müssten sich
dann aber (leider) alle anderen Personen die VPN-Konfigurationsdatei neu aus dem Userportal der Firewall herunterladen und im OpenVPN-Client importieren (nennt sich Sophos-Connect-Client, um genau zu sein).
3. Mal testweise anstatt dem Sophos-Connect-Client den OpenVPN-Client von "openvpn.net" zu installieren und dann versuchen die VPN-Verbindung herzustellen.
Was denkt ihr dazu?
Datax
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1624922937
Url: https://administrator.de/forum/openvpn-einwahl-ueber-dg-anschluss-nicht-moeglich-per-udp-1624922937.html
Ausgedruckt am: 25.12.2024 um 03:12 Uhr
12 Kommentare
Neuester Kommentar
AVM Plaste Elaste, die Fritte is wohl schuld ....
Paket-Beschleunigung auf der Fritze mal testweise abschalten:
https://www.ip-phone-forum.de/threads/kabel-fritzbox-blockiert-gewisse-u ...
http://fritz.box/support.lua
Webinterface der Firewall ins Internet exponieren? 💩💩
Gruß pp.
Paket-Beschleunigung auf der Fritze mal testweise abschalten:
https://www.ip-phone-forum.de/threads/kabel-fritzbox-blockiert-gewisse-u ...
http://fritz.box/support.lua
wenn ich zum Beispiel vom besagten Notebook aus versuche die Weboberfläche der Firewall (über den Anschluss der Deutsche-Glasfaser) über dessen IPv4-Adresse aufzurufen.
Alter wer macht denn bitte so ne Kacke??Webinterface der Firewall ins Internet exponieren? 💩💩
Gruß pp.
Möglich auch das der Provider an solchen Consumer Anschlüssen einige klassische VPN Ports blockiert. Das o.a. Verhalten spricht dafür. Man will Nutzer dann auf teurere Business Verträge zwingen.
Sinn würde deshalb machen den Standardport UDP 1194 einmal auf einen der Ephemeral Ports wie UDP 61194 umzustellen im Setup um dies ggf. zu umgehen. Kommen die UDP 61194 dann an der Firewall an wäre das eindeutig.
Sinn würde deshalb machen den Standardport UDP 1194 einmal auf einen der Ephemeral Ports wie UDP 61194 umzustellen im Setup um dies ggf. zu umgehen. Kommen die UDP 61194 dann an der Firewall an wäre das eindeutig.
Zitat von @aqui:
Möglich auch das der Provider an solchen Consumer Anschlüssen einige klassische VPN Ports blockiert.
Ausgehend?? Damit würden sie sich selbst ein ganz großes Eigentor schießen, und könnten sich vor Supportanfragen nicht mehr retten. Und nein, die Standard-OpenVPN Ports sind definitiv nicht blockiert oder irgendwie beschränkt, bin selbst bei der DG und mein Test per UDP verläuft hier erfolgreich.Möglich auch das der Provider an solchen Consumer Anschlüssen einige klassische VPN Ports blockiert.
Aber probieren würde ich das auf jeden Fall auch, könnte ja auch eine Route von der DG zum VPN-Server betroffen sein bei der nur der Port die Probleme macht.
1
Das schreit alles insgesamt nach einem MTU-Problem. Gib dem Client mal explizit eine MTU von 1280 Bytes in der OpenVPN-Config an und prüfe mal ob es dann geht.
Wenn bei DG der IPv4-Traffic per IPv6-Tunnel transportiert wird, kann die MTU schon deutlich zu klein werden.
Und: Kannst du dich eventuell direkt per IPv6 verbinden? Das ist in solchen Konstellationen mittlerweile nicht nur stressfreier sondern auch performanter.
Wenn bei DG der IPv4-Traffic per IPv6-Tunnel transportiert wird, kann die MTU schon deutlich zu klein werden.
Und: Kannst du dich eventuell direkt per IPv6 verbinden? Das ist in solchen Konstellationen mittlerweile nicht nur stressfreier sondern auch performanter.
1Zitat von @LordGurke:
Wenn bei DG der IPv4-Traffic per IPv6-Tunnel transportiert wird, kann die MTU schon deutlich zu klein werden.
Das ist nicht der Fall. Die DG macht kein RFC 6333 mit AFTR sondern DSLite mit IPv4/IPv6 dual stack.Wenn bei DG der IPv4-Traffic per IPv6-Tunnel transportiert wird, kann die MTU schon deutlich zu klein werden.
Und: Kannst du dich eventuell direkt per IPv6 verbinden? Das ist in solchen Konstellationen mittlerweile nicht nur stressfreier sondern auch performanter.
Performanter würde man im Normalfall meinen, aber die DG routet IPv6 Traffic je nach Standort teilweise über das Ausland obwohl man nur Ziele in DE ansteuert und die Laufzeiten sind dann oft um einiges höher als mit IPv4, so meine persönliche Erfahrung in NRW. Da macht der IPv6 Traffic erst mal ne Schleife über einen Knoten in den Niederlanden bevor er wieder zurück nach DE kommt.
Ich kenne mich mit VPN nicht aus, daher ist diese Antwort ggf. nicht hilfreich.
Aber: DG liefert ausschließlich - sofern man keinen Businessvertrag hat - IP Adressen über DS Light. Außerdem liefert DG nur IPV6 Adressen. Über die IPV4 kann man nach meiner Erfahrung nichts erreichen. Die IPV4 ist daher nicht öffentlich. Genau das ist der Grund, weshalb ich denen wieder gekündigt habe
Aber: DG liefert ausschließlich - sofern man keinen Businessvertrag hat - IP Adressen über DS Light. Außerdem liefert DG nur IPV6 Adressen. Über die IPV4 kann man nach meiner Erfahrung nichts erreichen. Die IPV4 ist daher nicht öffentlich. Genau das ist der Grund, weshalb ich denen wieder gekündigt habe
Zitat von @Willi-Zorn:
Aber: DG liefert ausschließlich - sofern man keinen Businessvertrag hat - IP Adressen über DS Light. Außerdem liefert DG nur IPV6 Adressen. Über die IPV4 kann man nach meiner Erfahrung nichts erreichen. Die IPV4 ist daher nicht öffentlich. Genau das ist der Grund, weshalb ich denen wieder gekündigt habe
Aber: DG liefert ausschließlich - sofern man keinen Businessvertrag hat - IP Adressen über DS Light. Außerdem liefert DG nur IPV6 Adressen. Über die IPV4 kann man nach meiner Erfahrung nichts erreichen. Die IPV4 ist daher nicht öffentlich. Genau das ist der Grund, weshalb ich denen wieder gekündigt habe
DSlite mit DualStack ist richtig, aber nicht DSLite nach RFC6333, das sind zwei paar unterschiedliche Schuhe, denn letzteres würde über einen Tunnel mit AFTR Endpoint realisiert, das ist hier aber nicht der Fall.
Also am Router erhält man eine öffentliche IPv6 und per IPv4 eine nicht öffentliche CGNAT IP aus 100.64.0.0./10
Danke für die Info. Wieder was gelernt. Aber soweit bin ich nie eingestiegen. Half also leider nicht weiter.
Zitat von @Willi-Zorn:
Danke für die Info. Wieder was gelernt. Aber soweit bin ich nie eingestiegen. Half also leider nicht weiter.
Danke für die Info. Wieder was gelernt. Aber soweit bin ich nie eingestiegen. Half also leider nicht weiter.
Kleiner vServer für 1-2€ im Monat zu dem man ein ausgehendes VPN offen hält oder den IPv4 Traffic über IPv6 tunnelt hätte das Problem gelöst. Aber heutzutage erhält man ja fast überall öffentliche IPv6 Adressen bei deutschen Mobilnetzbetreibern, so das der vServer im Normalfalls nur noch für die Anschlüsse daherhalten muss bei denen man keine bekommt (manche Hotspots oder Ausland).
Aber wenn ma! die Wahl hat zwischen mehreren Glasfaser-ISPs, ist das natürlich um so besser. Ist hier bei mir leider nicht der Fall da muss man sich damit abfinden und das beste draus machen, besser als die delegöm DSL-Kupfermine ist es aber allemal.
Naja, back to topic.
1
Danke euch schon mal für die Rückmeldungen.
Werde die von euch genannten Punkte in der KW 15 mal angehen,
vorher kann ich mit der Person, die den DG-Anschluss zu Hause hat, nicht sprechen.
Gebe dann hier auch ein Feedback.
Werde die von euch genannten Punkte in der KW 15 mal angehen,
vorher kann ich mit der Person, die den DG-Anschluss zu Hause hat, nicht sprechen.
Gebe dann hier auch ein Feedback.
Wenn es das denn nun war bitte deinen Thread dann auch als erledigt schliessen!
Wie kann ich einen Beitrag als gelöst markieren?
Wie kann ich einen Beitrag als gelöst markieren?
Zitat von @aqui:
Wenn es das denn nun war bitte deinen Thread dann auch als erledigt schliessen!
Wie kann ich einen Beitrag als gelöst markieren?
Wenn es das denn nun war bitte deinen Thread dann auch als erledigt schliessen!
Wie kann ich einen Beitrag als gelöst markieren?
Hi, konnte das Problem gestern lösen.
Hatte gestern den Einfall einfach mal testweise die Netzwerkverbindung des betreffenden Notebooks per Netzwerkkabel herzustellen. Mit Netzwerkverbindung per Kabel (Kabel direkt an der FritzBox angeschlossen) funktioniert die SSL-VPN-Einwahl problemlos.
Die Person, der das Notebook gehört, hat zu Hause eine größere AVM-Installation bestehend aus FritzBox, mehreren FRITZ-Repeatern (1750E) sowie mehreren AVM-Powerline-Adaptern (1260).
Muss wohl irgendein Problem innerhalb des WLAN-Netzes dieser AVM-Installation geben.
Haben an der Stelle aber nicht weiter geschaut, was die genaue Ursache für das VPN-Verbindungsproblem ist,
wenn man das WLAN-Netz dieser AVM-Installation nutzt. Normales WebSurfing funktioniert problemlos.
Da das Notebook sowieso im gleichen Raum wie die FritzBox steht,
ist das Anschließen eines Netzwerkkabels an die FritzBox kein Problem.
Bei dieser Lösung haben wir es belassen.
1
