13402570474
31.07.2024, aktualisiert um 07:46:42 Uhr
1016
11
0
Lokaler Wireguardserver - ohne PortForwarding trotzdem connected?
Hallo liebe Kolleginnen und Kollegen,
ich spiele gerade etwas mit einem lokal(Ubuntu VM, DMZ) aufgesetzten Wireguardserver herum.
Verbindungen klappen butterweich und schnell. Da dies nur ein Testsystem ist, habe ich das Portforwarding zum Server nach meinen Tests deaktiviert. Ich kann aber dennoch die VPN am Handy aktivieren und es zeigt auch "verbunden" an. Auch gehen Pakete raus.
Auf das lokale Netzwerk komme ich aber nicht mehr (funktioniert wieder sobald PF aktiviert wurde).
Ich bin gerade etwas irritiert. Wie kann ein Server eine Verbindung annehmen, obwohl dieser nicht erreichbar ist (sein kann)?
Kurz:
Port Forwarding aus => iPhone (wireguardapp) zeigt dennoch verbunden mit IP und Port an, auch gehen Pakete weg (soweit verständlich).
App zeigt mir Endpunkt sowie private Adresse an. iPhone meldet auch "VPN aktiv". ICMP funktioniert nicht ins Zielnetz, auch sind die Server nicht zu erreichen.
Nachtrag: Connect via IPv4, v6 zu Testzwecken deaktiviert.
Wie kann das funktionieren?
Bug in der App? Vermittlungsserver?!
Ein Portscan sagt, dass der Port geschlossen sei.
Danke + viele Grüße,
/me
ich spiele gerade etwas mit einem lokal(Ubuntu VM, DMZ) aufgesetzten Wireguardserver herum.
Verbindungen klappen butterweich und schnell. Da dies nur ein Testsystem ist, habe ich das Portforwarding zum Server nach meinen Tests deaktiviert. Ich kann aber dennoch die VPN am Handy aktivieren und es zeigt auch "verbunden" an. Auch gehen Pakete raus.
Auf das lokale Netzwerk komme ich aber nicht mehr (funktioniert wieder sobald PF aktiviert wurde).
Ich bin gerade etwas irritiert. Wie kann ein Server eine Verbindung annehmen, obwohl dieser nicht erreichbar ist (sein kann)?
Kurz:
Port Forwarding aus => iPhone (wireguardapp) zeigt dennoch verbunden mit IP und Port an, auch gehen Pakete weg (soweit verständlich).
App zeigt mir Endpunkt sowie private Adresse an. iPhone meldet auch "VPN aktiv". ICMP funktioniert nicht ins Zielnetz, auch sind die Server nicht zu erreichen.
Nachtrag: Connect via IPv4, v6 zu Testzwecken deaktiviert.
Wie kann das funktionieren?
Bug in der App? Vermittlungsserver?!
Ein Portscan sagt, dass der Port geschlossen sei.
Danke + viele Grüße,
/me
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: 91782790068
Url: https://administrator.de/contentid/91782790068
Ausgedruckt am: 21.11.2024 um 08:11 Uhr
11 Kommentare
Neuester Kommentar
Moin.
Das ist normal. Bei Wireguard und UDP gibt es quasi keinen echten Verbindungszustand, das arbeitet mit Handshakes. Pakete werden on the fly mit dem Public Key der Gegenseite verschlüsselt an die Zieladresse geschickt, nimmt sie dort niemand an und es kommt kein Handshake zustande landen sie halt im Nirvana bzw. werden vom Router der Gegenstelle verworfen. Die GUIs bei Wireguard zeigen hier quasi nur an, dass das Routing auf den WG-Endpoint aktiv ist , nicht das die Gegenstelle auch online ist.
Ob die Gegenstelle reagiert sieht man stattdessen an den Countern bei RX Bytes des Clients, also das die Gegenstelle auch mit Traffic antwortet.
Gruß Strods
Das ist normal. Bei Wireguard und UDP gibt es quasi keinen echten Verbindungszustand, das arbeitet mit Handshakes. Pakete werden on the fly mit dem Public Key der Gegenseite verschlüsselt an die Zieladresse geschickt, nimmt sie dort niemand an und es kommt kein Handshake zustande landen sie halt im Nirvana bzw. werden vom Router der Gegenstelle verworfen. Die GUIs bei Wireguard zeigen hier quasi nur an, dass das Routing auf den WG-Endpoint aktiv ist , nicht das die Gegenstelle auch online ist.
Ob die Gegenstelle reagiert sieht man stattdessen an den Countern bei RX Bytes des Clients, also das die Gegenstelle auch mit Traffic antwortet.
Gruß Strods
1
Moin @13910172396,
Danke Dir. Irgendwie uncool und blöd zu debuggen, wenn es Probleme geben sollte.
Da mag ich dann "nö, keine Gegenstelle für Dich"-Meldungen lieber.
Aber gut zu wissen, ich dachte schon, ich sollte umschulen...
Gruß
Danke Dir. Irgendwie uncool und blöd zu debuggen, wenn es Probleme geben sollte.
Da mag ich dann "nö, keine Gegenstelle für Dich"-Meldungen lieber.
Aber gut zu wissen, ich dachte schon, ich sollte umschulen...
Gruß
Zitat von @13402570474:
Danke Dir. Irgendwie uncool und blöd zu debuggen, wenn es Probleme geben sollte.
Das sieht man ja i.d. R. an den ausbleibenden eingehenden Bytes im Status. Das kann entweder bedeuten das beim Routing etwas schief läuft oder das die Keys nicht stimmen.Danke Dir. Irgendwie uncool und blöd zu debuggen, wenn es Probleme geben sollte.
Vorteil ist unter anderem, dass du damit flexibel zwischen unterschiedlichen Medien roamen kannst ohne die Verbindung explizit immer wieder neu initiieren zu müssen .
Zitat von @13910172396:
Vorteil ist, dass du damit Roamen kannst ohne die Verbindung neu aufzubauen.
Zitat von @13402570474:
Danke Dir. Irgendwie uncool und blöd zu debuggen, wenn es Probleme geben sollte.
Das sieht man ja i.d. R. an den ausbleibenden eingehenden Bytes im Status. Das kann entweder bedeuten das beim Routing etwas schief läuft oder das die Keys nicht stimmen.Danke Dir. Irgendwie uncool und blöd zu debuggen, wenn es Probleme geben sollte.
Vorteil ist, dass du damit Roamen kannst ohne die Verbindung neu aufzubauen.
Ja, das stimmt schon. Irritiert aber den Enduser(oder mich :D) im dümmsten Fall. Egal, abgefrühstückt. Ist halt so :D
Danke Dir
Irgendwie uncool und blöd zu debuggen, wenn es Probleme geben sollte.
Dann benutzt du besser nicht Wireguard sondern einen IPsec IKEv2 VPN Server.IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi
Hat den großen Vorteil das du in keinem Endgerät mit irgendwelcher zusätzlichen VPN Software und Konfigs rumfrickeln musst, sondern kannst bequem die immer onboard vorhandenen VPN Clients auf allen Endgeräten nutzen!
Zitat von @aqui:
IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi
Hat den großen Vorteil das du in keinem Endgerät mit irgendwelcher zusätzlichen VPN Software und Konfigs rumfrickeln musst, sondern kannst bequem die immer onboard vorhandenen VPN Clients auf allen Endgeräten nutzen!
Irgendwie uncool und blöd zu debuggen, wenn es Probleme geben sollte.
Dann benutzt du besser nicht Wireguard sondern einen IPsec IKEv2 VPN Server.IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi
Hat den großen Vorteil das du in keinem Endgerät mit irgendwelcher zusätzlichen VPN Software und Konfigs rumfrickeln musst, sondern kannst bequem die immer onboard vorhandenen VPN Clients auf allen Endgeräten nutzen!
Das geht aber nur ohne Split-Tunnel, oder?
EDIT: Ok, geht doch, nur für den Enduser "umständlich".
Geht beides, Split Tunnel und Redirect. Wird im Client gesetzt.
Wer dennoch mit externer Software und Konfig Dateien am Client frickeln will kann sich ja parallel noch WG und/oder OVPN installieren und erhält so einen eierlegenden VPN Wollmilchsauserver der alle gängigen VPN Protokolle supportet. 😉
nur für den Enduser "umständlich".
Gerade nicht! Denn es muss nicht umständlich zusätzliche Software installiert werden. Zudem sind die onboard VPN Clients deutlich besser in die jeweiligen Betriebssysteme integriert und bieten damit erhebliche Vereinfachungen im Handling und in der Performance. Für Windows z.B. kann man sowas vollkommen automatisiert ausrollen.Wer dennoch mit externer Software und Konfig Dateien am Client frickeln will kann sich ja parallel noch WG und/oder OVPN installieren und erhält so einen eierlegenden VPN Wollmilchsauserver der alle gängigen VPN Protokolle supportet. 😉
Zitat von @aqui:
Geht beides, Split Tunnel und Redirect. Wird im Client gesetzt.
Wer dennoch mit externer Software und Konfig Dateien am Client frickeln will kann sich ja parallel noch WG und/oder OVPN installieren und erhält so einen eierlegenden VPN Wollmilchsauserver der alle gängigen VPN Protokolle supportet. 😉
Geht beides, Split Tunnel und Redirect. Wird im Client gesetzt.
nur für den Enduser "umständlich".
Gerade nicht! Denn es muss nicht umständlich zusätzliche Software installiert werden. Zudem sind die onboard VPN Clients deutlich besser in die jeweiligen Betriebssysteme integriert und bieten damit erhebliche Vereinfachungen im Handling und in der Performance. Für Windows z.B. kann man sowas vollkommen automatisiert ausrollen.Wer dennoch mit externer Software und Konfig Dateien am Client frickeln will kann sich ja parallel noch WG und/oder OVPN installieren und erhält so einen eierlegenden VPN Wollmilchsauserver der alle gängigen VPN Protokolle supportet. 😉
Ich gehe von Fortigate aus. Da ist es mit dem FortiClient VPN schon sehr einfach, überhaupt für den unbedarften Endanwender. Ich denke da ist es schwieriger eine Anleitung zu schreiben dass er das auch bei Windows schafft.
Und zumindest bei der Forti muss man in den Eigenschaften des Netzwerkadapters etwas umstellen. (habs nicht getesetet) https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-enable- ...
Na ja, aber leider wieder externe Software und zudem weitere finanzielle (Lizenzen) und Support (Security) Abhängigkeit beim Client von nicht OS interner Hersteller Software. Nie eine gute Wahl in Bezug auf Kosten und Sicherheit!
Gute Firewall Hersteller supporten allesamt auch immer IKEv2 Setups oder zumindestens L2TP Setups so das man immer die onboard VPN Clients überall nutzen kann.
Für unbedarfte Anwender rollt man sowas immer automatisiert aus. Zumindestens bei Windows ja mit ein paar Mausklicks im AD erledigt.
Entscheidet halt jeder für sich selbst was für ihn sinnvoll ist und was nicht...
Gute Firewall Hersteller supporten allesamt auch immer IKEv2 Setups oder zumindestens L2TP Setups so das man immer die onboard VPN Clients überall nutzen kann.
Für unbedarfte Anwender rollt man sowas immer automatisiert aus. Zumindestens bei Windows ja mit ein paar Mausklicks im AD erledigt.
Entscheidet halt jeder für sich selbst was für ihn sinnvoll ist und was nicht...
Zitat von @aqui:
Na ja, aber leider wieder externe Software und zudem weitere finanzielle (Lizenzen) und Support (Security) Abhängigkeit beim Client von nicht OS interner Hersteller Software. Nie eine gute Wahl in Bezug auf Kosten und Sicherheit!
Gute Firewall Hersteller supporten allesamt auch immer IKEv2 Setups oder zumindestens L2TP Setups so das man immer die onboard VPN Clients überall nutzen kann.
Für unbedarfte Anwender rollt man sowas immer automatisiert aus. Zumindestens bei Windows ja mit ein paar Mausklicks im AD erledigt.
Entscheidet halt jeder für sich selbst was für ihn sinnvoll ist und was nicht...
Na ja, aber leider wieder externe Software und zudem weitere finanzielle (Lizenzen) und Support (Security) Abhängigkeit beim Client von nicht OS interner Hersteller Software. Nie eine gute Wahl in Bezug auf Kosten und Sicherheit!
Gute Firewall Hersteller supporten allesamt auch immer IKEv2 Setups oder zumindestens L2TP Setups so das man immer die onboard VPN Clients überall nutzen kann.
Für unbedarfte Anwender rollt man sowas immer automatisiert aus. Zumindestens bei Windows ja mit ein paar Mausklicks im AD erledigt.
Entscheidet halt jeder für sich selbst was für ihn sinnvoll ist und was nicht...
Bei Forti zumindest keine weiteren Kosten.
Bin aber da eh grundsätzlich auf deiner Seite.
In meinem Fall sind die >1000 Clients nicht im AD. Ist eine Schule, daher nicht so einfach...
Einen Usernamen und Passwort sollte ja auch ein wenig technikaffiner Nutzer wohl gerade noch eintippen können.
