macOS Sequoia und VPN: So richtest du einen systemweiten Kill Switch ein und konfigurierst die Network Extension
Schritt-für-Schritt-Anleitung zur Einrichtung eines systemweiten Kill Switch für VPN auf macOS Sequoia sowie Grundlagen der Network Extension API. In 60–120 Minuten installierst du den Client, importierst die Konfiguration, richtest den PF-Filter und die Automatisierung ein und überprüfst, dass keine Datenlecks auftreten.
Inhalt des Artikels
- Einführung
- Vorbereitungen
- Grundbegriffe
- Schritt 1: protokoll- und clientauswahl
- Schritt 2: konfiguration importieren und erste verbindung
- Schritt 3: dns-leak-schutz und on-demand aktivieren
- Schritt 4: systemweiter kill switch durch pf: grundkonfiguration
- Schritt 5: automatisierung des kill switch: skript und launchagent
- Schritt 6: präzise regeln und unterschiedliche protokollszenarien
- Schritt 7: fortgeschrittener abschnitt – network extension api für kill switch
- Schritt 8: umfassende tests: traffic, dns, ausfallverhalten
- Ergebnisprüfung
- Typische fehler und lösungen
- Zusatzfunktionen
- Faq
- Fazit
Einführung
In dieser Schritt-für-Schritt-Anleitung richtest du einen zuverlässigen systemweiten Kill Switch für VPN auf macOS Sequoia ein und lernst, wie wichtige Elemente der Network Extension API funktionieren. Wir begleiten dich vom Protokoll- und Client-Auswahlprozess bis hin zum Erstellen von Systemregeln mit dem PF-Filter. Optional gehen wir auch auf die fortgeschrittene Integration via Network Extension ein. Am Ende profitierst du von einer sicheren VPN-Verbindung ohne Datenlecks selbst bei unerwarteten Verbindungsabbrüchen. Der Guide richtet sich an Einsteiger, enthält aber auch vertiefte Abschnitte für Nutzer, die tiefer in die Mechanik eintauchen wollen.
Nach Abschluss kannst du: den VPN-Client auf macOS Sequoia konfigurieren, eine fertige Konfigurationsdatei importieren, DNS-Leak-Schutz aktivieren, einen systemweiten Kill Switch per PF erstellen und testen, dessen Aktivierung automatisieren und bei Bedarf ein Minimalbeispiel mit der Network Extension API ausprobieren.
Der Guide ist ideal für: Mac-Besitzer mit macOS Sequoia (Stand 2026), Einsteiger im Bereich IT-Sicherheit, Entwickler, die die Grundlagen verstehen wollen, und alle, die einen garantierten VPN-Traffic-Schutz benötigen.
Vorwissen: Grundkenntnisse in Systemeinstellungen, Terminal-Befehle kopieren, Grundverständnis von IP-Adresse und Port reichen aus. API-Details erklären wir klar und praxisnah.
Dauer: Basis-Setup für VPN und Kill Switch dauert 60–90 Minuten, plus 30 Minuten für Automatisierung und Tests. Für den fortgeschrittenen Abschnitt mit Network Extension solltest du zusätzliche 60 Minuten einplanen – eine Apple Developer-Mitgliedschaft vorausgesetzt.
Vorbereitungen
Stelle vor dem Start sicher, dass alles Notwendige bereitsteht. Wir bereiten das System vor, wählen Client und Konfiguration, prüfen die macOS-Version und erstellen einen Wiederherstellungspunkt der Netzwerkeinstellungen.
Benötigte Tools und Zugänge
- Ein Mac mit macOS Sequoia (Version 15.x oder höher).
- Administratorenrechte auf dem Gerät (für PF-Konfiguration und Client-Installation).
- Konfigurationsdatei für dein VPN-Protokoll (WireGuard: .conf, OpenVPN: .ovpn oder IKEv2-Parameter).
- IP-Adresse und Port des VPN-Servers – idealerweise die IP, nicht nur der Domainname, um DNS-Abhängigkeiten beim Verbindungsaufbau auszuschließen.
- Aktive Internetverbindung während der Einrichtung.
Systemanforderungen
- macOS Sequoia 15.x (zu prüfen unter Apple-Menü → "Über diesen Mac" → Übersicht).
- Ca. 200 MB freier Speicher für Clients und Logs.
- Offene ausgehende Verbindungen zum VPN-Server (Ports je Protokoll: WireGuard meist UDP 51820; OpenVPN standardmäßig UDP 1194 oder TCP 443; IKEv2 UDP 500 und 4500).
Downloads und Installation
- WireGuard für macOS oder alternativ Tunnelblick/Viscosity für OpenVPN; für IKEv2 genügt der integrierte macOS-Client.
- Texteditor für die Konfigurationsdateien, z. B. der integrierte TextEdit.
Backup
Da Netzwerkanpassungen die Systemeinstellungen betreffen, sichere den aktuellen Zustand vorab ab. Notiere die aktiven DNS-Server, Interfaces und die Standardroute.
- Öffne das Terminal.
- Führe scutil --dns aus und speichere den Haupt-DNS-Abschnitt in einer Textdatei.
- Führe ifconfig und route -n get default aus, speichere die Ausgaben als Referenz.
- Erstelle, falls vorhanden, einen Wiederherstellungspunkt mit Time Machine.
Tipp: Halte IP-Adresse und Port deines VPN-Servers in einer Notiz bereit. Diese Daten brauchst du für PF-Regeln, um den ausgehenden Traffic ausschließlich dorthin zu erlauben, wenn sonst alles blockiert ist.
Grundbegriffe
Damit dir die Anleitung leichter fällt, erklären wir kurz die wichtigsten Begriffe in einfachen Worten, ohne unnötige Theorie.
- VPN – ein verschlüsselter Tunnel zwischen deinem Rechner und dem entfernten VPN-Server. Dein gesamter Traffic kann dadurch geleitet werden.
- Kill Switch – eine Funktion, die jeglichen Internetverkehr blockiert, wenn die VPN-Verbindung ausfällt. So schützt du dich vor Datenlecks.
- PF (Packet Filter) – der systemeigene Paketfilter von macOS. Damit definierst du, welche Verbindungen erlaubt sind und welche nicht – unabhängig von Einzelanwendungen.
- utun-Interface – ein virtueller Netzwerkadapter, den der VPN-Client schafft (z. B. utun0). Alle VPN-Daten werden hier verschlüsselt übertragen.
- Network Extension API – Apples Framework für VPN-Clients, Content-Filter und Proxies. Damit steuerst du die Tunnel- und Netzwerkeinstellungen programmatisch.
- On-Demand – Regeln, wann und wie sich VPN automatisch verbindet (z. B. bei unbekannten Netzwerken) und wie bei Verbindungsverlust reagiert wird.
- DNS-Leak – wenn DNS-Anfragen außerhalb des VPN-Tunnels ins Internet gehen und so dein Surfverhalten offenbaren können.
Tipp: Wenn in den folgenden Schritten Fachbegriffe auftauchen, kannst du jederzeit hierher zurückkehren. Zu wissen, was utun und PF bedeuten, macht die Einrichtung des Kill Switch um einiges leichter.
Schritt 1: Protokoll- und Clientauswahl
Ziel
Wähle dein VPN-Protokoll und den passenden Client für macOS Sequoia, um anschließend die Verbindung und den Kill Switch einzurichten.
Detaillierte Anleitung
- Bewerte deinen Anwendungsfall: Für maximale Geschwindigkeit und einfache Bedienung empfehlen wir WireGuard. Für maximale Kompatibilität mit älteren Netzwerken nutze OpenVPN. Für native Integration ohne zusätzlichen Client wähle IKEv2.
- Für WireGuard: Installiere die WireGuard-App für macOS von einer vertrauenswürdigen Quelle und bereite deine .conf-Datei vor.
- Für OpenVPN: Installiere Tunnelblick oder Viscosity und verwende die .ovpn-Datei.
- Für IKEv2: Nutze den eingebauten macOS-Client. Richte die folgenden Parameter ein: Server-Adresse (IP), Remote-ID, Lokale ID, Authentifizierung (Nutzername/Passwort oder Zertifikat) sowie die Option "Gesamten Traffic senden".
- Bereite IP und Port des Servers vor: WireGuard in der Regel UDP 51820; OpenVPN den Port aus der .ovpn-Datei; IKEv2 die UDP-Ports 500 und 4500.
⚠️ Achtung: Für einen funktionsfähigen systemweiten Kill Switch brauchst du die exakte IP des VPN-Servers, nicht nur den Domainnamen. Denn PF-Regeln erlauben den Verkehr nur zu dieser IP und dem Port. Falls nur ein Domainname vorliegt, kläre vorab die IP auf und notiere sie.
Tipp: Bei WireGuard sollte deine Konfig AllowedIPs = 0.0.0.0/0, ::/0 enthalten. Das sorgt dafür, dass der gesamte Traffic über den Tunnel geht, was die Logik vereinfacht und Datenlecks minimiert.
Erwartetes Ergebnis
Du hast ein Protokoll gewählt, den Client installiert oder den eingebauten ausgewählt und eine funktionierende Konfiguration mit bekanntem Server-IP und Port bereit.
Mögliche Probleme und Lösungen
- Unentschlossen bei der Protokollwahl? Für macOS Sequoia ist WireGuard ein hervorragender Start: einfach zu konfigurieren, schnell und ressourcenschonend.
- Nur Domain, keine IP? Im Terminal mit dig +short dein.domain oder nslookup dein.domain die IP herausfinden und notieren.
- UDP wird vom Internetanbieter blockiert? Nutze OpenVPN TCP 443 oder konfiguriere IKEv2. Falls unterstützt, aktiviere Obfuskation auf dem Server.
✅ Check: Du hast Protokoll, Client (oder eingebauten IKEv2) installiert, Konfiguration vorbereitet und IP mit Port notiert.
Schritt 2: Konfiguration importieren und erste Verbindung
Ziel
Importiere die Konfiguration in deinen Client und stelle sicher, dass du dich verbinden und Traffic senden kannst.
Detaillierte Anweisungen für WireGuard
- Starte die WireGuard-App auf deinem Mac.
- Klicke auf „Tunnel importieren“ oder „Add Tunnel“ und wähle deine .conf-Datei.
- Überprüfe, dass im Adressfeld die VPN-Subnetz-Adresse steht (z. B. 10.14.0.2/32), im PrivateKey dein Schlüssel und im Peer-Feld der Endpoint als IP:Port mit AllowedIPs = 0.0.0.0/0, ::/0 eingetragen ist.
- Schalte den Tunnel ein – der Indikator wird grün und Traffic-Zähler erscheinen.
Detaillierte Anleitung für OpenVPN (Tunnelblick)
- Starte Tunnelblick.
- Ziehe die .ovpn-Datei auf das Tunnelblick-Icon in der Menüleiste oder wähle „Konfiguration hinzufügen“ aus dem Anwendungmenü.
- Wähle Installation „nur für diesen Nutzer“ oder „für alle Nutzer“ nach Bedarf.
- Verbinde dich über den Button „Connect“ neben dem Profilnamen. Falls nötig, gib Zugangsdaten ein.
Detaillierte Anleitung für IKEv2 (integrierter Client)
- Öffne „Systemeinstellungen“ → „Netzwerk“ → „VPN“ → „VPN-Konfiguration hinzufügen“.
- Wähle als Typ „IKEv2“.
- Gib unter Server die IP-Adresse ein.
- Fülle „Remote-ID“ (meist Server-Domain) und „Lokale ID“ (falls erforderlich) aus.
- Wähle Authentifizierungsmethode (Benutzername/Passwort oder Zertifikat) und ergänze die Angaben.
- Aktiviere die Option „Gesamten Traffic senden“ (oder entsprechende Routing-Standardeinstellung).
- Speichere und klicke auf „Verbinden“.
Tipp: Hast du Zugang zum Kundenbereich deines VPN-Anbieters? Oft sind dort vorkonfigurierte Dateien erhältlich. Zum Beispiel auf vpn.how erhältst du fertige Konfigs für WireGuard, OpenVPN und IKEv2, die du schnell importieren kannst. Dieser Anbieter bietet dedizierte Server-IP, Unterstützung für WireGuard, OpenVPN, IKEv2 usw., Infrastruktur an zahlreichen Standorten, flexible Zahlungsmethoden und hohe Sicherheit ohne Logs – ein praktischer Start.
Erwartetes Ergebnis
Die VPN-Verbindung wird hergestellt, Internetzugang läuft über den Tunnel und die wichtigsten Parameter stimmen mit deiner Konfiguration überein.
Mögliche Probleme und Lösungen
- Verbindung schlägt fehl: Meist falscher Port oder IP. Prüfe Endpoint-Parameter und Port beim Anbieter nach.
- Internet wird zwar angezeigt, funktioniert aber nicht: Kontrolliere die Routen und DNS-Einstellungen. Bei WireGuard AllowedIPs auf 0.0.0.0/0 setzen oder bei IKEv2 „Gesamten Traffic senden“ aktivieren. DNS-Server im Tunnel ergänzen.
- Loginaufforderung bei jeder Verbindung: Aktiviere die Speicherung der Zugangsdaten, wenn deine Sicherheitsrichtlinie das zulässt.
✅ Check: Besuche eine Seite wie https://ifconfig.me und bestätige, dass die IP deines VPN-Servers angezeigt wird. Trenne VPN und kontrolliere, dass die IP sich ändert, um die richtige Tunnelung zu verifizieren.
Schritt 3: DNS-Leak-Schutz und On-Demand aktivieren
Ziel
Stelle sicher, dass DNS-Anfragen immer über VPN laufen und dass VPN bei Bedarf automatisch verbindet. So reduzierst du Leckrisiken bereits vor dem Kill Switch.
Detaillierte Anleitung
- Öffne dein WireGuard-Profil und überprüfe, ob ein DNS-Abschnitt existiert (z. B. DNS = 10.14.0.1 oder die Tunnel-DNS-Adresse). Falls nicht, füge die empfohlenen DNS-Server aus der Konfiguration hinzu.
- Bei OpenVPN (Tunnelblick) sollte deine .ovpn Datei DNS-Optionen vom Server pushen (z. B. dhcp-option DNS 10.14.0.1). Falls nicht, trag die DNS manuell in macOS-Netzwerkeinstellungen unter VPN-Adapter ein.
- In IKEv2 checke, ob der Server DNS-Einstellungen übermittelt. Wenn nötig, gib DNS manuell ein.
- Aktiviere On-Demand, falls der Client dies unterstützt: WireGuard bietet z. B. „Activate on demand“ mit SSID-Regeln, Tunnelblick kann „Connect when computer starts“, bei IKEv2 aktiviert man „automatisch verbinden“ in den macOS VPN-Einstellungen.
- Teste nach einem Neustart, ob der Tunnel automatisch aufgebaut wird, sobald du ins Internet gehst.
Tipp: Wenn dein Endpoint eine Domain ist, ersetze sie während der Kill Switch Einrichtung vorübergehend durch die IP, damit der Tunnel trotz ggf. nicht erreichbarem externen DNS aufgebaut wird. Nach Fertigstellung kannst du den Domainnamen zurücksetzen und nur für die nötigen DNS-Anfragen in PF gezielt erlauben. Für einfachen Start empfehlen wir eine feste IP.
Erwartetes Ergebnis
DNS-Anfragen gehen über den Tunnel, VPN verbindet sich automatisch und das Risiko von Lecks sinkt deutlich vor dem Aktivieren des Kill Switch.
Probleme & Lösungen
- DNS läuft immer noch außen vorbei: Ursache meist DNS-Priorität in macOS. Lösung: Deaktiviere alternative externe Resolver und nutze falls möglich matchDomains im Client.
- Automatische Verbindung funktioniert nicht: Eventuelle Konflikte bei On-Demand-Policy. Prüfe Client-Einstellungen und macOS-Autostartrechte.
✅ Check: Führe scutil --dns aus und kontrolliere, ob der aktive DNS-Resolver eine Adresse aus dem VPN-Tunnel zeigt. Trenne VPN, kontrolliere, dass DNS nicht mehr funktioniert. Verbinde VPN neu und teste Webseitenzugriff.
Schritt 4: Systemweiter Kill Switch durch PF: Grundkonfiguration
Ziel
Erstelle eine Grundkonfiguration für PF (Packet Filter), die ausgehenden Traffic komplett sperrt, außer dem, der zum Aufbau und Betrieb des VPN-Tunnels nötig ist.
Funktionsweise
Wir aktivieren PF mit Regeln, die standardmäßig alles blocken und nur den Verkehr durch das utun-Interface sowie ausgehende Pakete zu deinem VPN-Server-IP und Port erlauben. So wird sichergestellt, dass bei Tunnel-Ausfall keine unverschlüsselten Verbindungen ins Netz zugelassen werden.
Daten vorbereiten
- Notiere die IP deines VPN-Servers, z. B. 203.0.113.10.
- Notiere den Port: WireGuard: 51820 UDP; OpenVPN z. B. 1194 UDP; IKEv2: 500 UDP und 4500 UDP.
- Bestimme deinen Haupt-physikalischen Netzwerkadapter: Führe route -n get default aus, suche nach "interface: en0" oder "en1" und notiere ihn (z. B. en0).
Anchor-Datei für PF anlegen
- Terminal öffnen.
- Erstelle Datei mit: sudo nano /etc/pf.anchors/vpn-killswitch.
- Füge die folgenden Regeln ein, jeweils eine pro Zeile, mit deinen individuellen Werten ersetzt:
- set block-policy drop
- set skip on lo0
- block all
- pass quick on utun0 all keep state
- pass quick on utun1 all keep state (für den Fall, dass ein anderer utun verfügbar ist; bei Bedarf utun2, utun3 ergänzen)
- pass out quick on en0 proto udp to 203.0.113.10 port 51820 keep state (für WireGuard)
- pass in quick on en0 proto udp from 203.0.113.10 port 51820 keep state (optional für eingehende Antworten, wird meist vom stateful Tracking abgedeckt)
- pass out quick on en0 proto udp to 203.0.113.10 port 500 keep state (für IKEv2)
- pass out quick on en0 proto udp to 203.0.113.10 port 4500 keep state (für IKEv2)
- pass out quick on en0 proto udp to 203.0.113.10 port 1194 keep state (für OpenVPN UDP)
- pass out quick on en0 proto tcp to 203.0.113.10 port 443 keep state (für OpenVPN TCP 443, falls verwendet)
Speichere und beende den Editor. Entferne alle Ports und Protokolle, die du nicht benutzt, um die Regeln schlank zu halten.
Anchor in Haupt-PF-Konfiguration einbinden
- Öffne Hauptdatei mit sudo nano /etc/pf.conf.
- Füge am Ende folgende Zeilen hinzu:
anchor "vpn-killswitch"
load anchor "vpn-killswitch" from "/etc/pf.anchors/vpn-killswitch" - Speichere und schließe die Datei.
PF aktivieren und prüfen
- Syntax überprüfen mit sudo pfctl -nf /etc/pf.conf – keine Fehler sollten erscheinen.
- Konfiguration laden: sudo pfctl -f /etc/pf.conf.
- PF aktivieren, falls noch nicht aktiv: sudo pfctl -e.
- Regeln anzeigen: sudo pfctl -sr – deine Einträge sollten sichtbar sein.
Tipp: Falls du dir unsicher bist, welcher utun genutzt wird, füge Regeln für utun0 bis utun3 hinzu. Das ist sicher und erleichtert die Nutzung, wenn sich beim Neuverbinden unterschiedliche utun-Interfaces bilden.
⚠️ Achtung: Während dieser Einrichtung kann das Internet ausfallen, wenn VPN nicht verbunden ist und keine Ausnahmen für Server-IP und Ports in PF angelegt sind. Das ist normal. Verbinde den VPN-Client, damit die Verbindung über den Tunnel läuft.
Erwartetes Ergebnis
PF erlaubt Internet nur bei aktivem VPN. Wenn VPN getrennt ist, blockiert die Firewall jeglichen Traffic außer Verbindungsversuche zum VPN-Server.
Probleme & Lösungen
- Keine Verbindung trotz aktivem VPN: Wahrscheinlich falscher oder fehlender utun in PF-Regeln. Mit ifconfig prüfen, welcher utun aktiv ist und in den Regeln ergänzen, danach PF neu laden.
- VPN-Verbindung schlägt fehl: Kein pass-out für den Server-IP und Port definiert. Ergänze entsprechende Regeln.
- Domain-Name im Endpoint wird nicht aufgelöst: DNS ist vor VPN-Verbindung blockiert. Temporär IP anstelle Domain nutzen oder punktuelles DNS-Zulassungsregel in PF hinzufügen – aber Achtung, das kann Lecks verursachen.
✅ Check: VPN trennen – Internetausfall. VPN starten – Internet funktioniert wieder. curl https://ifconfig.me zeigt VPN-IP. Trenne VPN, Befehl bricht ab oder meldet Fehler.
Schritt 5: Automatisierung des Kill Switch: Skript und LaunchAgent
Ziel
Sicherstellen, dass PF-Regeln bei Systemneustart und VPN-Reconnect automatisch geladen werden und leicht per Hand umschaltbar sind.
Anleitung
- Erstelle ein Hilfsskript, das PF neu lädt und VPN-Interface prüft: sudo nano /usr/local/bin/vpn-ks-reload.sh.
- Füge diese Zeilen ein (bitte eigene Werte ergänzen danach):
- #!/bin/sh
- /sbin/pfctl -nf /etc/pf.conf || exit 1
- /sbin/pfctl -f /etc/pf.conf
- /sbin/pfctl -e
- exit 0
- Datei speichern und schließen.
- Mach die Datei ausführbar: sudo chmod +x /usr/local/bin/vpn-ks-reload.sh.
- Lege einen LaunchAgent an, der bei Login das Skript ausführt: nano ~/Library/LaunchAgents/com.local.vpnks.reload.plist.
- Füge folgenden Inhalt ein (ohne Formatierungsfehler):
- <plist version="1.0"><dict><key>Label</key><string>com.local.vpnks.reload</string><key>ProgramArguments</key><array><string>/usr/local/bin/vpn-ks-reload.sh</string></array><key>RunAtLoad</key><true/></dict></plist>
- Datei speichern.
- Agent laden: launchctl load ~/Library/LaunchAgents/com.local.vpnks.reload.plist.
- Teste durch erneutes Anmelden oder manuelle Ausführung von /usr/local/bin/vpn-ks-reload.sh. Fehlerfrei sollte laufen.
Tipp: Möchtest du den Kill Switch temporär deaktivieren, führe sudo pfctl -d aus. Achtung: Dann entfällt der Systemschutz. Um PF wieder zu aktivieren: sudo pfctl -e und sudo pfctl -f /etc/pf.conf.
Erwartetes Ergebnis
Beim Systemstart werden PF-Regeln automatisch aktiviert. Bei VPN-Verbindungsänderungen bleibt die Firewall konsistent aktiv. PF kann bei Bedarf per Skript manuell neu geladen werden.
Probleme & Lösungen
- LaunchAgent startet nicht: Meist Syntaxfehler in plist. Prüfe, lade neu, kontrolliere mit launchctl list und den Logs der Konsole.
- PF deaktiviert sich nach System-Update: Lade PF und Konfiguration erneut manuell oder automatisiert.
✅ Check: Nach Neustart und Login erscheint PF-Regelwerk aktiv (sudo pfctl -sr). VPN-Verbindung und Trennung verhält sich erwartungsgemäß mit Internetzugriff nur bei aktivem Tunnel.
Schritt 6: Präzise Regeln und unterschiedliche Protokollszenarien
Ziel
Kill Switch soll je Protokoll (WireGuard, OpenVPN, IKEv2) zuverlässig funktionieren, inklusive spezieller Ports und erforderlicher Ausnahmen.
WireGuard
- Beschränke Erlaubnis auf UDP-Verkehr zu IP und Port 51820 auf dem physischen Interface (z. B. en0). Das ist das Minimum für Tunnelaufbau.
- Stelle sicher, dass AllowedIPs auf 0.0.0.0/0, ::/0 gesetzt ist, damit kompletter Traffic durch das utun läuft.
- Stelle sicher, dass DNS-Server im Tunnel konfiguriert sind, um DNS-Leaks zu vermeiden.
OpenVPN
- Bei UDP: Erlaube proto udp to IP port 1194 (oder deinen Port) auf dem physischen Interface.
- Bei TCP 443: Erlaube proto tcp to IP port 443.
- Kontrolliere DNS-Push vom Server oder konfiguriere DNS manuell im VPN-Adapter.
IKEv2
- Erlaube proto udp to IP port 500 und proto udp to IP port 4500 für ausgehenden Traffic.
- Aktiviere in den IKEv2-Einstellungen die Option „Gesamten Traffic senden“, um Split-Tunneling zu verhindern.
- Stelle sicher, dass DNS durch den Tunnel geleitet wird.
Tipp: Wenn du häufig zwischen unterschiedlichen Netzwerken wechselst (z.B. zu Hause, Büro, mobiles Hotspot), prüfe, ob sich das physische Interface ändert (en0, en1). Falls ja, erweitere deine Regeln um alle genutzten Interfaces oder verwende "group egress" für generelle Erlaubnis an die Server-IP.
Erwartetes Ergebnis
Die PF-Regeln sind schlank und präzise: Sie erlauben nur Tunnelaufbau und gesamten Traffic über den Tunnel – keine unerwünschten Ausnahmen.
Probleme & Lösungen
- Verbindung bricht beim Netzwerkwechsel ab: Wahrscheinlich neues physisches Interface oder geänderte öffentliche IP. Ergänze Regeln für das Interface oder nutze TCP 443 als Fallback bei OpenVPN.
- Keine Antwort von internen Ressourcen: Korrigiere die Routen oder erweitere AllowedIPs um interne Subnetze oder konfiguriere Routing serverseitig.
✅ Check: Starte VPN, führe ping und traceroute zu externer Adresse aus. Trenne VPN und überprüfe, dass neue Verbindungen blockiert werden und bestehende Streams enden.
Schritt 7: Fortgeschrittener Abschnitt – Network Extension API für Kill Switch
Ziel
Verstehe, wie du mit der Network Extension API VPN-Traffic steuerst und eine strikte Tunnelung erzielst. Optional und Entwickler-Account erforderlich.
Wichtige Hinweise
Für Network Extension unter macOS wird eine Apple Developer-Mitgliedschaft mit entsprechenden Berechtigungen benötigt. Einige Provider-Typen – vor allem Content-Filter (NEFilter) – brauchen spezielle Genehmigung durch Apple. Du kannst ein Packet Tunnel Provider-Projekt für den Eigengebrauch bauen, wenn du die Basis-Entitlements hast. Dieser Abschnitt dient zur Einführung und Praxis im Testumfeld.
Zentrale Klassen und Flags
- NEPacketTunnelProvider – Einstiegspunkt für deinen eigenen VPN-Client, Verwaltung des Tunnels und Netzwerkeinstellungen.
- NEPacketTunnelNetworkSettings – Hier definierst du IPv4/IPv6 Einstellungen, DNS und Routen. Wichtige Flags sind includeAllNetworks = true und excludeLocalNetworks = true für das Erzwingen von vollem Tunnelverkehr.
- NEVPNManager – Steuerung der On-Demand-Policy und des VPN-Lebenszyklus (IKEv2, Packet Tunnel).
- NEDNSSettings – Gibt DNS-Server an und setzt matchDomains = [""] zum Abfangen aller DNS-Anfragen.
Minimaler Ablauf in Xcode
- Erstelle in Xcode ein neues macOS-App-Projekt. Füge ein Network Extension Target des Typs Packet Tunnel Provider hinzu.
- Setze die Entitlements: aktiviere „Personal VPN“. Prüfe, dass Signing & Capabilities den Network Extensions Provider enthalten.
- Erstelle in deinem Packet Tunnel Provider Code mittels NEPacketTunnelNetworkSettings eine Tunnel-Konfiguration. Gib ipv4Settings mit Tunnel-IP (z. B. 10.14.0.2/32) und Default Route (0.0.0.0/0) an, setze includeAllNetworks = true und excludeLocalNetworks = true.
- Füge NEDNSSettings mit Tunnel-DNS und matchDomains = [""] ein, um alle DNS-Anfragen zu tunneln.
- Speichere On-Demand-Policy über NEVPNManager mit Verbindungsregeln für alle Netzwerke, außer ggf. vertrauenswürdige SSIDs. Für Kill Switch keine Ausnahmen lassen.
- Baue die App und starte lokal, installiere und aktiviere das VPN-Profil in den macOS Netzwerkeinstellungen. Akzeptiere angefragte Profile und Berechtigungen.
Tipp: Für private Nutzung ohne App Store veröffentlichen, nutze deinen eigenen Apple ID Account im Projekt. Das erleichtert Installation und Verwaltung auf deinem Mac.
Erwartetes Ergebnis
Du erhältst eine minimal funktionale Custom-Client-Konfiguration, die per Standard sämtlichen Traffic inklusive DNS über den Tunnel führt. Der systemweite Kill Switch läuft zusätzlich weiter über den zuvor eingerichteten PF, was eine doppelte Sicherheitslinie schafft.
Probleme & Lösungsvorschläge
- Fehlendes Entitlement: Prüfe deine Apple Developer Mitgliedschaft und ergänze erforderliche Rechte unter Signing & Capabilities.
- Profilinstallation schlägt fehl: Kontrolliere Console Logs und Signaturen, stelle sicher, dass die App VPN verwalten darf.
- Konflikt mit bestehendem Client: Starte nicht gleichzeitig mehrere Clients, wenn sie dieselben Tunnel-Interfaces verwenden.
✅ Check: Im macOS Netzwerk erscheint dein VPN-Profil. Nach Verbindung fließt Traffic und DNS komplett durch Tunnel. Sobald der Client stoppt, sorgt PF weiterhin für Blockade ungesicherten Verkehrs.
Schritt 8: Umfassende Tests: Traffic, DNS, Ausfallverhalten
Ziel
Dies stellt sicher, dass Kill Switch robust ist: Kein Traffic entkommt dem VPN, DNS-Leaks bleiben aus, und bei plötzlichem Tunnelabbruch blockiert das System sofort den Internetzugang.
Testplan
- Routing-Test: Bei aktivem VPN führe curl https://ifconfig.me aus und notiere die IP. Trenne VPN, teste erneut – Anfrage darf nicht durchkommen (PF blockiert).
- DNS-Test: Mit VPN aktiv prüfe scutil --dns, der Resolver muss Tunnel-IP sein. Nutze nslookup example.com, um antwortenden DNS-Server zu sehen. Trenne VPN: DNS-Anfragen sollten blockieren.
- Ausfalltest: Beende VPN-Client-Prozess manuell oder wechsle das WLAN. Überprüfe, dass keine Internetverbindung auftaucht, bevor die VPN-Verbindung neu aufgebaut ist.
- Recovery-Test: Messe die Zeitdauer bis zur Wiederverbindung und stelle sicher, dass PF den Block bis dahin hält.
- Anwendungstest: Nutze Browser, Messenger und Player – sie sollten nur bei aktivem VPN funktionieren.
Tipp: Für genaue Diagnose hilft das Tool tcpdump auf deinem physischen Interface: sudo tcpdump -i en0 not port 51820 (beispielhaft für WireGuard). Bei korrekter PF-Konfiguration siehst du keine Pakete, die außerhalb des VPN laufen.
Erwartetes Ergebnis
Kein Traffic oder DNS läuft ohne aktiven VPN durch. Anwendungen funktionieren umgehend nach Wiederherstellung des Tunnels.
Probleme & Lösungen
- Einige Systemdienste senden Traffic außen herum: Prüfe Regeln mit sudo pfctl -vvsr und stelle sicher, dass keine unerwarteten Pass-Regeln vorliegen, vor allem nicht von Drittanwendungen hinzugefügte.
- Verzögerung bei Wiederverbindung: Aktiviere On-Demand im Client für schnellere Netzwerkerkennung und minimiere PF-Regeln auf das Wesentliche.
✅ Check: Zusammenfassung: Ohne VPN blockiert PF alle Verbindungen, mit VPN funktioniert alles; DNS läuft ausschließlich durch den Tunnel, Verbindungsabbrüche führen nicht zu Lecks.
Ergebnisprüfung
Checkliste
- VPN-Client (WireGuard, OpenVPN oder IKEv2) installiert und eingerichtet.
- Korrekter Import der Konfiguration mit bekanntem Server-IP und Port.
- DNS über Tunnel aktiviert und On-Demand für automatische Verbindung eingerichtet.
- PF-Anchor-Datei erstellt und im Hauptpf.conf eingebunden.
- PF aktiviert, Regeln aktiv nach Neustart und Login.
- Internetzugang nur mit aktivem VPN möglich.
- Durchgeführte Tests zu Ausfallverhalten und DNS-Leak-Schutz bestanden.
Testmethodik
- Mehrfach-Testzyklus: VPN aktiv (IP + DNS überprüfen), VPN deaktiviert (keine Verbindungen), VPN neu verbinden (Zugang wiederhergestellt).
- Teste unterschiedliche Netzwerke (WLAN, Ethernet).
- Untersuche PF-Logausgaben mit sudo pfctl -vvsr und sudo pfctl -vvss für Status.
Erfolgskriterien
- Keine Netzwerkverbindungen ohne aktives VPN außer definiertem Serververkehr.
- DNS nur über Tunnel, keine Antworten ohne VPN.
- Apps starten und funktionieren schnell nach VPN-Wiederverbindung.
Typische Fehler und Lösungen
- Problem: Kein Internet trotz aktivem VPN. Ursache: Falsches utun in PF-Regeln. Lösung: Ermittle aktiven utun mit ifconfig und ergänze Regel pass quick on utunX.
- Problem: VPN verbindet nicht. Ursache: PF blockiert Serverzugang. Lösung: Füge Regel pass out quick on enX proto udp/tcp to IP port NNNN ein.
- Problem: DNS-Leak. Ursache: DNS wird nicht durch Tunnel geführt. Lösung: Bei WireGuard DNS in Konfig festlegen, bei OpenVPN Server-Push oder statische DNS-Einstellungen nutzen.
- Problem: PF deaktiviert nach Update. Ursache: System startet Dienste neu. Lösung: Aktiviere PF manuell neu mit sudo pfctl -e und lade Konfiguration, überprüfe LaunchAgent.
- Problem: Einige Apps umgehen VPN. Ursache: Split-Tunneling in Routen erlaubt. Lösung: Prüfe AllowedIPs und setze auf 0.0.0.0/0, ::/0.
- Problem: Beispiel mit Network Extension lässt sich nicht bauen. Ursache: Fehlende Entitlements. Lösung: Apple Developer Mitgliedschaft aktivieren und entsprechende Rechte setzen.
- Problem: Verbindungsabbruch beim WLAN-Wechsel. Ursache: Port oder Protokoll blockiert. Lösung: Nutze OpenVPN TCP 443 oder setze eine Reservekonfiguration ein.
Zusatzfunktionen
Erweiterte PF-Konfiguration
- Tabellen-Variablen nutzen: IP in Tabelle speichern, Regeln referenzieren diese. Bei IP-Wechsel nur Tabelle anpassen.
- Logging aktivieren: Blockierte Pakete per Console.app oder tcpdump -n -e -ttt -i pflog0 analysieren.
- Feinjustierung: Mehrere Protokolle getrennt in unterschiedlichen Anchors verwalten und dynamisch laden.
Client-Optimierungen
- WireGuard MTU-Anpassung (z. B. 1420–1440) einrichten, um Fragmentierung zu verhindern.
- OpenVPN mit tls-crypt und modernen Verschlüsselungen absichern.
- IKEv2 mit aktuellem Kryptosatz und Perfect Forward Secrecy verwenden, sofern Server es unterstützt.
Weitere Tipps
- MDM und Profile: Im Unternehmen verwaltete Geräte können On-Demand Richtlinien für Skalierbarkeit nutzen.
- Backup-Szenarien: Fallback Profile mit anderem Port oder Protokoll sichern für Netzwerke mit restriktiver Filterung.
- Monitoring: Systembenachrichtigungen bei Tunnel-Abbruch einrichten oder Skripte, die Interface-Zustand prüfen und lokal protokollieren.
Tipp: Wenn du viel unterwegs bist und häufig unterschiedliche Netzwerke nutzt, verwalte mehrere Profile mit verschiedenen Ports und Protokollen, um den VPN-Zugang auch bei Einschränkungen sicherzustellen.
FAQ
- Geht ein Kill Switch ohne PF? Ja, einige VPN-Clients bringen einen eigenen Kill Switch mit. PF bietet aber eine systemweite, clientunabhängige Sicherheit.
- Muss ich eine Domain oder besser eine IP nutzen? Für PF ist eine IP zuverlässiger. Domain kann für Lastverteilung gut sein, erfordert aber sorgsames DNS-Handling.
- Woher weiß ich, welchen utun ich nehme? Verbinde VPN, nutze ifconfig – aktiver utun zeigt Traffic mit Daten.
- Kann ich IPv6 verwenden? Ja. Füge ::/0 in die Routen ein und achte darauf, dass Server IPv6 unterstützt. PF-Regeln für IPv6 sind ähnlich, müssen aber angepasst werden.
- Was, wenn ich kein Apple Developer Konto habe? Kein Problem. Der primäre Kill Switch per PF funktioniert ohne Network Extension. Erweiterte Funktionen sind optional.
- Muss PF immer aktiv sein? Für dauerhaften Kill Switch ja. Schalte PF nur bei begründetem Bedarf temporär ab.
- Wie aktualisiere ich die Konfiguration sicher? VPN trennen, Konfig anpassen, PF-Syntax testen, VPN neu verbinden und PF-Regeln erneut laden. IP und Port immer griffbereit halten.
- Funktionieren lokale Netzwerke (z. B. Drucker, NAS)? Standardmäßig nein, wenn kompletter Traffic getunnelt wird. Dafür Exceptions in VPN-Routen oder Split-Tunneling mit Bedacht einstellen.
- Wie teste ich WebRTC-Leaks? Im Browser WebRTC deaktivieren oder Erweiterungen nutzen. Kern ist aber ein stabiler systemweiter Kill Switch und umfassende Routen.
- Kann ich Profile automatisch wechseln? Ja. Nutze Skripte oder Client-Funktionalitäten (WireGuard CLI) dazu. PF-Regeln solltest du für alle Server-IPs passend halten.
Fazit
Du hast den kompletten Weg durchlaufen: Protokoll und Client gewählt, Konfiguration importiert, DNS-Leak-Schutz und On-Demand aktiviert, den systemweiten Kill Switch via PF eingerichtet, automatisiert und in unterschiedlichen Szenarien geprüft. Das Ergebnis ist eine zuverlässige Lösung, die sicherstellt, dass dein Traffic ausschließlich über VPN läuft und bei Verbindungsabbrüchen auf Systemebene blockiert wird.
Außerdem kannst du mehrere Server und Protokolle einrichten, PF-Regeln tabellieren, tiefer in die Network Extension API einsteigen und bei Bedarf verwaltete Profile im Unternehmensumfeld einsetzen. So erreichst du hohe Stabilität, Vorhersehbarkeit und Sicherheit mit klarer Fehlerdiagnose über PF-Logs.
Tipp: Überprüfe deine Regeln regelmäßig, besonders nach macOS-Updates. Nutze das PF-Neustart-Skript und die Checkliste aus dem Abschnitt „Ergebnisprüfung“, um schnell sicherzugehen, dass alles wie gewünscht funktioniert.
⚠️ Achtung: Vermeide unnötige Ausnahmen in PF. Je kürzer und präziser die erlaubten Verbindungen, desto zuverlässiger der Kill Switch und desto weniger Überraschungen bei Netzwerkwechseln.