Du betrachtest gerade Cisco VPN unter Fedora: Warum die DNS-Auflösung nach dem Disconnect streikt.
VPN Fedora Logo. Created with Stable Diffusion and Gimp.

Cisco VPN unter Fedora: Warum die DNS-Auflösung nach dem Disconnect streikt.

Ich nutze Fedora seit Jahren als zuverlässige und moderne Linux-Distribution, sowohl für private Projekte als auch für meine Arbeit. Umso irritierender war es, als ich plötzlich nach dem Trennen einer Cisco-VPN-Verbindung keine neue Verbindung mehr aufbauen konnte. Der VPN-Server war nicht erreichbar, obwohl nichts an der Konfiguration geändert wurde. Bei meiner Recherche habe ich ebenfalls schon festgestellt, das dies nicht nur den CISCO AnyConnect Client betrifft, sondern diverse Firmen VPN Clients.

Nach einer kleinen Analyse stellte sich heraus: Das Problem liegt weder am VPN-Gateway noch an der Firewall, sondern an der DNS-Konfiguration von Fedora selbst.

Und genau darum geht es in diesem Artikel:
Was passiert hier eigentlich und wie lässt sich der Fehler dauerhaft „beheben“?

Inhaltsverzeichnis

Was genau passiert nach einem VPN-Disconnect unter Fedora?

Kurz gesagt:

Der VPN-Client setzt beim Verbindungsaufbau neue DNS-Server, entfernt sie beim Disconnect aber unter Fedora nicht vollständig.

Dadurch bleibt das System nach dem Trennen des VPNs in einem Zustand, in dem es weiterhin versucht, interne Firmen-DNS-Server zu verwenden. Diese sind außerhalb des VPN-Tunnels naturgemäß nicht erreichbar.

Eine Fehlermeldung des Cisco AnyConnect VPN-Clients verweist auf ein IPv6 Problem:
DIe VPN-Verbindung zum ausgewählten sicheren Gateway erfordert eine routbare physische IPv6-Adapteradresse. Wechseln Sie zu einem IPv6-Netzwerk und versuchen Sie erneut, die Verbindung herzustellen, oder wählen Sie ein anderes sicheres Gateway aus.

Der AnyConnect Client für das Firmen VPN verweist in seiner Fehlermeldung auf ein IPv6 Routing Problem. Das ist hier in meinem Fall aber nicht die Ursache gewesen. Andere IPv6 Adressen waren erreichbar. Auffällig war das vor allem Domains meiner Firma nicht pingbar oder im Browser aufrufbar waren. Somit war erst mal vom VPN ausgeschlossen 🙁

Mit einer weitere Rechereche habe ich die DNS Einstlelungen meines Systems überprüft.

resolvectl status

Es ergaben sich. nach obigen Befehl, dann folgender Eintrag:

Global
         Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: foreign
Current DNS Server: 192.168.X.X
       DNS Servers: 192.168.X.X 192.168.X.X
        DNS Domain: klasseFirma.de tollerRouter

Und siehe da, es gibt einen globalen Eintrag der für Domains meines Routers und für die Domain meiner Firma die DNS Server überschreibt. Und es bleibt nach dem Trennen der VPN Verbindung erhalten. Das sollte eigentlich zurückgesetzt werden.

Wie ich das Problem reproduzierbar gelöst habe

Sobald klar war, dass DNS schlicht nicht sauber zurückgesetzt wird, war die Lösung tatsächlich einfach. Es genügt, systemd-resolved neu zu starten.

sudo systemctl restart systemd-resolved

Damit wird:

  • der DNS-Cache geleert
  • die globale DNS-Konfiguration neu erzeugt
  • die Auflösung wieder korrekt an den lokalen Router oder DHCP übernimmt

Danach funktioniert der VPN-Reconnect ohne jegliche Probleme.


Automatische Lösung: DNS nach VPN-Disconnect selbst zurücksetzen

Damit ich nicht nach jedem VPN-Tunnel manuell eingreifen muss, habe ich eine kleine NetworkManager-Dispatcher-Regel hinterlegt, die DNS automatisch zurücksetzt, sobald der VPN-Tunnel getrennt wird.

Datei erstellte ich folgende Datei:

sudo nano /etc/NetworkManager/dispatcher.d/99-reset-dns.sh

Und habe dieses Skript eingebaut:

#!/bin/bash
if [ "$2" = "down" ]; then
    systemctl restart systemd-resolved
fi

Anschließend habe ich die Datei noch ausführbar gemacht:

sudo chmod +x /etc/NetworkManager/dispatcher.d/99-reset-dns.sh

Seitdem läuft das VPN auch nach einem Disconnect.

Schreibe einen Kommentar