WireGuard: Authentifizierung

[jochen02]

Hallo,

ich habe heute WireGuard auf einer FritzBox und einem Android-Telefon in Betrieb genommen. Bevor ich das auch auf den mobilen Debian-PCs mache, würde ich gern eine Unklarheit beseitigen.
Mir ist aufgefallen, dass die einzige Sicherheit im Schlüsselpaar besteht. Der "Client"-Schlüssel lässt sich anscheinend nicht mit einer Passphrase sichern.
Verliere ich also mein mobiles Gerät, haben die Fieslinge nicht nur mein Notebook, sondern auch den Zugriff auf mein Heim-Netzwerk. Das scheint mir, vorsichtig ausgedrückt, nicht zuende gedacht. IPSec und OpenVPN machen das anders und meiner Auffassung nach besser.

Wo ist hier mein Denkfehler?

[mat6937]

Mir ist aufgefallen, dass die einzige Sicherheit im Schlüsselpaar besteht.

Es gibt bei WireGuard noch einen psk-Schlüssel und die AllowedIPs (in der config). Was AVM bzw. die FritzBox aus/mit WireGuard gemacht hat, weiß ich nicht, weil ich WG mit der FB nicht benutze.
Ja, wenn Du den Verlust des Notebooks erst spät merkst, hast Du evtl. ein Problem.

[bluestar]

Wo ist hier mein Denkfehler?

Sowohl OpenVPN als auch IPSEC bringen, wenn du sie als permanenten Tunnel im Hintergrund aktivieren willst, die gleichen Probleme mit sich.

Ich möchte auf dem Handy - aus Komfortgründen - nicht jedes Mal beim VPN starten unständlich ein kompliziertes 15stelliges Passwort eingeben müssen.

Ob du bei Verlust deinen User auf dem Server sperrst oder dein Wireguard-Peer deaktivierst, das kommt letztlich auf‘s selbe.

[jochen02]

Sowohl OpenVPN als auch IPSEC bringen, wenn du sie als permanenten Tunnel im Hintergrund aktivieren willst, die gleichen Probleme mit sich.

Ach so, das ist nicht mein use case. Ich baue eine VPN-Verbindung immer nur nach Bedarf auf.

Ich möchte auf dem Handy - aus Komfortgründen - nicht jedes Mal beim VPN starten unständlich ein kompliziertes 15stelliges Passwort eingeben müssen.

Ich kann damit leben. Außerdem fiel mir auf, dass bei der Android-"App" nicht mal sichtbar ist, ob eine Verbindung steht, oder nicht. Nachdem ich die Verbindung auf der FritzBox deaktiviert hatte, war es weiterhin möglich, sie auf dem Client zu aktivieren -- keine Fehlermeldung.
Für mich sieht es so aus, als würde man hier eine längere Entwicklungszeit von OpenVPN durchaus merken.

[mat6937]

... auf der FritzBox ...
Für mich sieht es so aus, als würde man hier eine längere Entwicklungszeit von OpenVPN durchaus merken.

Benutzt Du OpenVPN auf deiner FritzBox?

[bluestar]

Nachdem ich die Verbindung auf der FritzBox deaktiviert hatte, war es weiterhin möglich, sie auf dem Client zu aktivieren -- keine Fehlermeldung.

Das scheint ein Android Problem zu sein, auf meinen iOS Geräten kommt eine Fehlermeldung.

Wireguard und OpenVPN bzw. IPSEC sind nur schwer vergleichbar. Die Konzepte dahinter unterscheiden sich halt grundlegend, Wireguard kann ja auch keinen IP Pool serverseitig an Clients verteilen.

[reox]

Ich kann damit leben. Außerdem fiel mir auf, dass bei der Android-"App" nicht mal sichtbar ist, ob eine Verbindung steht, oder nicht. Nachdem ich die Verbindung auf der FritzBox deaktiviert hatte, war es weiterhin möglich, sie auf dem Client zu aktivieren -- keine Fehlermeldung.
Für mich sieht es so aus, als würde man hier eine längere Entwicklungszeit von OpenVPN durchaus merken.

Mit sichtbar meinst du ob der Server erreichbar ist oder ob überhaupt WG gestartet ist? Neuere Androids sollten ein Schlüsselsymbol bei aktivem VPN anzeigen.
Ersteres ist ein grundsätzliches "Problem" des Protokolls. Solange die Server IP erreichbar ist - also die Pakete zumindest theoretisch ankommen könnten, kann der Client nicht wissen, ob der Server (noch) nicht geantwortet hat oder ob die Verbindung tot ist.
Du kannst einen heartbeat setzen, dann siehst du zumindest ob der Server geantwortet hat - ist aber auch nicht immer die sinnvollste Lösung.

[mat6937]

Solange die Server IP erreichbar ist - also die Pakete zumindest theoretisch ankommen könnten, kann der Client nicht wissen, ob der Server (noch) nicht geantwortet hat oder ob die Verbindung tot ist.

Der WG-Client sollte doch mit Hilfe des handshakes wissen/mitbekommen, ob der WG-Server antwortet:

Code: Alles auswählen

latest handshake: 1 minute ago

Code: Alles auswählen

Jul 26 08:29:59 xxxxxx user.debug kernel: [ 5258.716349] wireguard: wg2: Sending handshake initiation to peer 3 (109.###.###.###:*****)
Jul 26 08:29:59 xxxxxx user.debug kernel: [ 5258.729526] wireguard: wg2: Receiving handshake response from peer 3 (109.###.###.###:*****)

[reox]

Der WG-Client sollte doch mit Hilfe des handshakes wissen/mitbekommen, ob der WG-Server antwortet:

ah ja natürlich. Das stimmt.
na dann zeigt einem die App das eh auch an ob man verbunden ist. Kann natürlich sein, dass man vor kurzem einen Handshake empfangen hat aber dann der Server aus geht - man hat also keine direkte Anzeige ob der Server noch da ist.

[jochen02]

Der WG-Client sollte doch mit Hilfe des handshakes wissen/mitbekommen, ob der WG-Server antwortet:

Code: Alles auswählen

latest handshake: 1 minute ago

Code: Alles auswählen

Jul 26 08:29:59 xxxxxx user.debug kernel: [ 5258.716349] wireguard: wg2: Sending handshake initiation to peer 3 (109.###.###.###:*****)
Jul 26 08:29:59 xxxxxx user.debug kernel: [ 5258.729526] wireguard: wg2: Receiving handshake response from peer 3 (109.###.###.###:*****)

Ah ja, danke. Das hilft.

[jochen02]

(...) Wireguard kann ja auch keinen IP Pool serverseitig an Clients verteilen.

Das würde mich im Unternehmens-Umfeld schon sehr gestört haben. Aber da bin ich inzwischen 'raus.

[mat6937]

... aber dann der Server aus geht - man hat also keine direkte Anzeige ob der Server noch da ist.

Der handshake ist unabhängig von der Konfiguration des WG-Clienten. Was man aber im WG-Client konfigurieren kann, ist "persistent keepalive" und wenn der WG-Server (peer) nicht antwortet ist er i. d. R. nicht mehr erreichbar:

Code: Alles auswählen

Jul 26 08:29:59 xxxxxx user.debug kernel: [ 5258.729555] wireguard: wg2: Sending keepalive packet to peer 3 (109.###.###.###:*****)
Jul 26 08:29:59 xxxxxx user.debug kernel: [ 5258.732770] wireguard: wg2: Receiving keepalive packet from peer 3 (109.###.###.###:*****)

Es kann auch sein, dass der WG-Server seine externe/öffentliche IP-Adresse (inzwischen) geändert hat und dann stimmt der "Endpoint"-Eintrag in der config des WG-Clienten nicht mehr. Für Linux und BSD's gibt es dafür das Sript "reresolve-dns.sh", das man mit einem cronjob oder timer-unit (Linux) benutzen kann.
Android und iOS sollen das mit dem Endpoint (permanente Erreichbarkeit des WG-Servers/Peer bei Änderung der externen IP-Adresse), aber angeblich schon viel "eleganter" gelöst haben.

[reox]

Android und iOS sollen das mit dem Endpoint (permanente Erreichbarkeit des WG-Servers/Peer bei Änderung der externen IP-Adresse), aber angeblich schon viel "eleganter" gelöst haben.

Achso? Seit wann? Mein Client hängt einfach immer wenn sich die IP des Servers ändert und die einzige Lösung ist dann den Client neu zu starten.
Mein letzter Stand ist, dass man sich das selber basteln kann aber das es (zumindest in Android) noch nicht eingebaut wurde.

[mat6937]

Achso? Seit wann?

"angeblich", ... ich weiß nicht mehr wo ich das gelesen habe, weil ich benutze diese OSs nicht. Mich haben nur Linux und die BSD's (bzgl. Endpoint) interessiert.