macOS Sequoia y VPN: cómo crear un kill switch del sistema y configurar Network Extension
Guía paso a paso para configurar un kill switch del sistema para VPN en macOS Sequoia y los fundamentos del Network Extension API. En 60–120 minutos instalarás el cliente, importarás la configuración, ajustarás el filtro PF, automatizarás el proceso y confirmarás que no hay fugas de datos.
Contenido del artículo
- Introducción
- Preparación previa
- Conceptos básicos
- Paso 1: elección del protocolo y cliente
- Paso 2: importar configuración y primera conexión
- Paso 3: activar protección contra fugas dns y on-demand
- Paso 4: kill switch del sistema con pf: configuración básica
- Paso 5: automatizar kill switch: script y launchagent
- Paso 6: ajuste fino de reglas y protocolos
- Paso 7: bloque avanzado: fundamentos del network extension api para kill switch
- Paso 8: pruebas integrales: tráfico, dns, fallos
- Verificación final
- Errores comunes y soluciones
- Funciones adicionales
- Preguntas frecuentes (faq)
- Conclusión
Introducción
En esta guía paso a paso configurarás un kill switch del sistema fiable para VPN en macOS Sequoia y entenderás cómo funcionan los elementos clave del Network Extension API. Cubriremos desde la elección del protocolo y el cliente hasta la creación de reglas a nivel del sistema mediante el filtro PF y, si quieres, exploraremos la integración avanzada con Network Extension. Al final tendrás una conexión segura sin fugas de tráfico fuera de la VPN incluso ante desconexiones inesperadas. Esta guía está diseñada para usuarios principiantes, pero incluye apartados avanzados para quienes quieran comprender los mecanismos en profundidad.
Al completar todos los pasos podrás: configurar un cliente VPN en macOS Sequoia, importar un archivo de configuración listo, activar protección contra fugas DNS, crear y probar un kill switch del sistema usando PF, automatizar la activación y desactivación del filtro, y, si lo deseas, probar un ejemplo mínimo con Network Extension API.
La guía es adecuada para: propietarios de Mac con macOS Sequoia (vigente en 2026), profesionales de seguridad principiantes, desarrolladores interesados en entender los principios, y todos quienes necesitan garantizar que el tráfico fuera de la VPN esté bloqueado.
Qué debes saber antes: uso básico de Configuración del Sistema, habilidad para copiar comandos en Terminal, y nociones de qué es una dirección IP y un puerto. Eso es suficiente. Los detalles sobre el API se explican de forma clara y práctica.
Tiempo estimado: configuración básica de VPN y kill switch toma de 60 a 90 minutos, más 30 minutos para automatización y pruebas. Para la parte avanzada con Network Extension, reserva 60 minutos si tienes cuenta de desarrollador.
Preparación previa
Antes de empezar asegúrate de tener todo lo necesario. Prepararemos el sistema, elegiremos el cliente y la configuración, verificaremos la versión de macOS y haremos un punto de restauración con los ajustes de red importantes.
Herramientas y accesos necesarios
- Mac con macOS Sequoia (15.x o superior).
- Permisos de administrador en el dispositivo (para configurar PF e instalar clientes).
- Archivo de configuración para el protocolo elegido (WireGuard, OpenVPN, IKEv2). Puede ser un archivo .conf para WireGuard, .ovpn para OpenVPN o parámetros para IKEv2.
- Dirección IP y puerto del servidor VPN. Ideal contar con IP y no solo nombre de dominio para evitar dependencia del DNS externo al establecer la conexión.
- Conexión activa a internet durante la configuración.
Requisitos del sistema
- macOS Sequoia 15.x (verifica: menú Apple → Acerca de este Mac → Resumen).
- 200 MB libres en disco para clientes y logs.
- Conexiones salientes abiertas hacia tu servidor VPN (los puertos dependen del protocolo: WireGuard usualmente UDP 51820; OpenVPN por defecto UDP 1194 o TCP 443; IKEv2 UDP 500 y UDP 4500).
Qué descargar e instalar
- WireGuard para macOS o alternativamente Tunnelblick/Viscosity para OpenVPN; si usas IKEv2, el cliente integrado de macOS es suficiente.
- Editor de texto para editar configuraciones (por ejemplo, TextEdit integrado o cualquier otro).
Respaldo
Los cambios en red afectan la configuración del sistema. Antes guarda el estado actual. Copia los servidores DNS actuales, interfaces activas y ruta por defecto.
- Abre Terminal.
- Ejecuta scutil --dns. Copia la sección principal de DNS en un archivo de texto.
- Ejecuta ifconfig y route -n get default. Guarda los resultados para referencia.
- Crea un punto de restauración con Time Machine si lo usas.
Consejo: Guarda la IP y puerto del servidor VPN en una nota. Los necesitarás para las reglas PF para permitir tráfico saliente solo hacia ese servidor cuando todo lo demás esté bloqueado.
Conceptos básicos
Para facilitar la comprensión, repasemos brevemente términos clave con explicaciones simples, sin teoría innecesaria.
- VPN — túnel cifrado entre tu computador y el servidor VPN remoto. Todo el tráfico puede pasar por este túnel.
- Kill switch — mecanismo que bloquea cualquier tráfico de red si por alguna razón la VPN se desconecta. Protege contra fugas.
- PF (Packet Filter) — filtro de paquetes del sistema en macOS. Permite definir qué conexiones están permitidas o bloqueadas, independientemente de las aplicaciones.
- Interfaz utun — interfaz de red virtual creada por el cliente VPN. Ejemplo: utun0. Todo el tráfico VPN cifrado pasa por esa interfaz.
- Network Extension API — framework de Apple para desarrollar clientes VPN, filtros de contenido y proxies. Permite controlar programáticamente túneles y configuraciones de red.
- On-Demand — conjunto de reglas para cuándo y cómo la VPN se conecta automáticamente (por ejemplo, en redes no confiables) y su comportamiento ante pérdidas de conexión.
- Fuga DNS — cuando las solicitudes DNS salen fuera de la VPN directamente a internet, exponiendo dominios e IP.
Consejo: Si encuentras términos desconocidos más adelante, regresa a esta sección. Entender qué es utun y PF hace mucho más sencillo configurar el kill switch.
Paso 1: Elección del protocolo y cliente
Objetivo
Decidir el protocolo y cliente para macOS Sequoia para luego configurar la conexión y el kill switch a nivel del sistema.
Instrucciones detalladas
- Evalúa tu caso: si buscas rapidez y sencillez, elige WireGuard. Para compatibilidad con redes antiguas, considera OpenVPN. Si quieres integración nativa sin clientes externos, opta por IKEv2.
- Si eliges WireGuard: instala la app WireGuard para macOS desde fuente confiable y prepara el archivo .conf.
- Si optas por OpenVPN: instala Tunnelblick o Viscosity y prepara el archivo .ovpn.
- Si optas por IKEv2: usa el cliente integrado de macOS. Configura: dirección del servidor (IP), identificador remoto, local, autenticación (usuario/contraseña o certificado) y marca la opción “Enviar todo el tráfico”.
- Prepara la IP y puerto: para WireGuard usualmente UDP 51820; para OpenVPN consulta puerto en .ovpn; para IKEv2 usa UDP 500 y 4500.
⚠️ Atención: Para un kill switch del sistema correcto, necesitas conocer la IP exacta del servidor, no solo el dominio. En las reglas PF permitiremos conexiones solo a esa IP y puerto. Si solo tienes dominio, resuélvelo a IP antes y anota esa dirección.
Consejo: Para WireGuard, procura que en el config AllowedIPs sea 0.0.0.0/0, ::/0. Así el cliente enviará todo el tráfico por el túnel, facilitando la lógica y reduciendo riesgos de fuga.
Resultado esperado
Has elegido protocolo, instalado cliente (o decidido usar el integrado) y tienes una configuración funcional con IP y puerto conocidos.
Problemas comunes y soluciones
- No sabes qué elegir. Solución: para macOS Sequoia, WireGuard es la mejor opción inicial: fácil de configurar, rápido y con bajo consumo.
- Solo tienes dominio, no IP. Solución: usa dig +short tu.dominio o nslookup tu.dominio en Terminal y anota la IP.
- Proveedor bloquea UDP. Solución: usa OpenVPN sobre TCP 443 o IKEv2, o activa ofuscación si el servidor la soporta.
✅ Verificación: Tienes el protocolo elegido, cliente instalado (o listo para IKEv2 integrado), configuración y la IP con puertos del servidor.
Paso 2: Importar configuración y primera conexión
Objetivo
Importar configuración en el cliente seleccionado y verificar que la VPN se conecta y enruta tráfico.
Instrucciones para WireGuard
- Abre la app WireGuard en Mac.
- Haz clic en «Importar túnel» o «Add Tunnel» y selecciona el archivo .conf.
- Comprueba que en Address están las direcciones de la subred VPN (ejemplo, 10.14.0.2/32), en PrivateKey la clave privada y en Peer que el Endpoint indique IP:puerto y que AllowedIPs = 0.0.0.0/0, ::/0.
- Activa el interruptor para conectar el túnel. El indicador debe volverse verde y verás tráfico «actual/total».
Instrucciones para OpenVPN (Tunnelblick)
- Inicia Tunnelblick.
- Arrastra el archivo .ovpn al ícono de Tunnelblick en la barra de menú o elige «Agregar configuración» desde el menú de la app.
- Selecciona si la instalación será «Solo para este usuario» o «Para todos los usuarios» según convenga.
- Conéctate haciendo clic en «Connect» junto al nombre del perfil. Ingresa usuario y contraseña si se requieren.
Instrucciones para IKEv2 (cliente integrado)
- Abre «Preferencias del Sistema» → «Red» → «VPN» → «Agregar configuración VPN».
- Selecciona tipo «IKEv2».
- Introduce en «Servidor» la dirección IP del servidor.
- Completa «Identificador remoto» (normalmente dominio del servidor) y «Identificador local» (tu identificador si es necesario).
- Selecciona método de autenticación: «Usuario y contraseña» o «Certificado» y rellena campos.
- Activa la opción «Enviar todo el tráfico» (o configuración similar de ruta predeterminada).
- Guarda y pulsa «Conectar».
Consejo: Si tienes acceso al panel de tu servicio VPN, es más cómodo usar configuraciones predefinidas. Por ejemplo, vpn.how ofrece archivos listos para WireGuard, OpenVPN e IKEv2 que puedes descargar e importar directamente al cliente macOS. Este servicio dispone de servidores dedicados (no compartidos), asigna IP exclusiva a cada cliente, soporta WireGuard, OpenVPN, IKEv2, L2TP, SSTP, con infraestructura en diversas ciudades y múltiples opciones de pago. Es ideal para obtener configuraciones funcionales y IP garantizada rápidamente. Lo mencionamos para facilitar tu experiencia sin sobrecargar esta guía.
Resultado esperado
La VPN se conecta, tienes acceso a internet a través del túnel, y los parámetros básicos coinciden con la configuración.
Problemas comunes y soluciones
- No se conecta. Causa: puerto o IP incorrectos. Solución: revisa el Endpoint en la configuración y confirma el puerto con el proveedor.
- Conexión establecida pero sin internet. Causa: rutas o DNS mal configurados. Solución: verifica AllowedIPs en WireGuard o la opción «Enviar todo el tráfico» en IKEv2, añade servidores DNS del túnel.
- Solicita usuario y contraseña cada vez. Solución: activa guardar credenciales si la política de seguridad lo permite.
✅ Verificación: Visita una web que muestre tu IP y comprueba que muestra la IP de la VPN. Desconecta la VPN y confirma que la IP cambia a la original. Esto confirma el enrutamiento básico.
Paso 3: Activar protección contra fugas DNS y On-Demand
Objetivo
Asegurar que las solicitudes DNS siempre pasan por la VPN y que ésta se conecta automáticamente en las redes adecuadas. Esto reduce el riesgo de fugas antes de aplicar el kill switch del sistema.
Instrucciones
- En WireGuard abre el perfil y comprueba que incluye la sección DNS (por ejemplo, DNS = 10.14.0.1 o la IP de tu DNS en el túnel). Si no está, agrégala con los servidores recomendados para que el cliente configure el DNS al conectar.
- En OpenVPN (Tunnelblick) confirma que el archivo .ovpn tenga la directiva para configurar DNS enviada por el servidor (ejemplo, dhcp-option DNS 10.14.0.1). Si no es así, agrega manualmente en macOS tras conectar en la configuración de red del adaptador VPN → DNS.
- En IKEv2 verifica que el servidor provea DNS en la configuración. Si es necesario, añade DNS manualmente en los parámetros VPN.
- Activa On-Demand (si el cliente lo tiene). En WireGuard hay opciones para «Activar bajo demanda» y reglas por SSID/red. En Tunnelblick usa «Conectar al iniciar» o similar en Viscosity. En IKEv2 habilita «Conectar automáticamente» si está disponible en la interfaz de macOS Sequoia.
- Comprueba que tras reiniciar el Mac el cliente levanta el túnel automáticamente al conectarte a internet.
Consejo: Si usas un Endpoint con dominio, para configurar el kill switch especifica temporalmente la IP en el Endpoint para evitar problemas si el DNS externo no está disponible al iniciar la conexión. Una vez establecida la conexión, puedes volver a usar el dominio y agregar reglas PF para permitir solo consultas DNS específicas. Por simplicidad, esta guía usa IP fija del servidor.
Resultado esperado
El DNS se enruta por el túnel y la VPN se conecta automáticamente. Esto no es el kill switch definitivo, pero reduce significativamente riesgos de fugas.
Problemas comunes y soluciones
- DNS sigue saliendo fuera del túnel. Causa: prioridades DNS del sistema. Solución: deshabilita resolutores externos en la interfaz activa o usa matchDomains en el cliente si lo soporta.
- La conexión automática no funciona. Causa: conflictos en políticas. Solución: revisa configuración On-Demand en el cliente y permisos de inicio automático en macOS.
✅ Verificación: Ejecuta scutil --dns y confirma que el resolver activo muestra las direcciones del túnel VPN. Desconexión y reconexión de la VPN debería mostrar cambios correspondientes. Navega sitios para comprobar.
Paso 4: Kill switch del sistema con PF: configuración básica
Objetivo
Crear una configuración básica de PF que bloquee todo el tráfico saliente salvo el permitido: hacia el servidor VPN mientras se establece el túnel y a través de la interfaz VPN una vez activo.
Cómo funciona
Activaremos PF y definiremos reglas: bloquear todo por defecto, permitir solo tráfico por utun y permitir paquetes salientes al IP y puerto del servidor VPN en la interfaz física para establecer el túnel. Así si el túnel cae, tu tráfico directo a internet queda bloqueado porque no hay excepciones fuera del servidor y la interfaz utun.
Preparar datos
- Confirma la IP del servidor VPN, por ejemplo, 203.0.113.10.
- Confirma el puerto: WireGuard — 51820/UDP; OpenVPN — 1194/UDP (o tu puerto), IKEv2 — 500 y 4500 UDP.
- Identifica la interfaz física principal: ejecuta route -n get default y busca «interface: en0» o «en1». Anota el nombre (ejemplo: en0).
Crear ancla de reglas PF
- Abre Terminal.
- Crea archivo ancla: sudo nano /etc/pf.anchors/vpn-killswitch.
- Pega las reglas línea por línea, reemplazando valores según corresponda. Cada regla es un punto aparte para claridad:
- set block-policy drop
- set skip on lo0
- block all
- pass quick on utun0 all keep state
- pass quick on utun1 all keep state (en caso de otro utun; añade utun2, utun3 si necesitas)
- pass out quick on en0 proto udp to 203.0.113.10 port 51820 keep state (para WireGuard)
- pass in quick on en0 proto udp from 203.0.113.10 port 51820 keep state (opcional para paquetes de respuesta, el estado ya cubre esto)
- pass out quick on en0 proto udp to 203.0.113.10 port 500 keep state (para IKEv2)
- pass out quick on en0 proto udp to 203.0.113.10 port 4500 keep state (para IKEv2)
- pass out quick on en0 proto udp to 203.0.113.10 port 1194 keep state (para OpenVPN UDP)
- pass out quick on en0 proto tcp to 203.0.113.10 port 443 keep state (para OpenVPN TCP 443 si lo usas)
Guarda y cierra el editor. Usa solo los puertos y protocolos de tu configuración para limitar la superficie de riesgo.
Conectar ancla desde pf.conf principal
- Abre config principal: sudo nano /etc/pf.conf.
- Al final agrega: anchor "vpn-killswitch" y en una línea debajo load anchor "vpn-killswitch" from "/etc/pf.anchors/vpn-killswitch".
- Guarda y cierra.
Activar PF y comprobar
- Verifica sintaxis: sudo pfctl -nf /etc/pf.conf. No debe mostrar errores.
- Carga configuración: sudo pfctl -f /etc/pf.conf.
- Activa PF si está desactivado: sudo pfctl -e.
- Revisa reglas activas: sudo pfctl -sr. Debes ver tus líneas.
Consejo: Si dudas qué utun usará, añade reglas para utun0 a utun3. Es seguro y facilita manejar cambios de interfaz tras reconexiones.
⚠️ Atención: Al activar esta configuración puede que pierdas internet si la VPN no está conectada y no permitiste el tráfico hacia el servidor IP y puerto. Esto es normal. Simplemente conecta el cliente VPN y la red funcionará nuevamente vía túnel.
Resultado esperado
Con PF activo el internet funciona solo con VPN conectada. Si desconectas VPN, el tráfico queda bloqueado salvo intentos hacia IP y puertos del servidor.
Problemas comunes y soluciones
- Pérdida total de conexión aún con VPN activo. Causa: utun incorrecto o ausencia de reglas. Solución: revisa ifconfig para encontrar utun activo tras conectar; agrégalo y recarga PF.
- No se conecta la VPN. Causa: no permitiste tráfico saliente a IP y puerto. Solución: añade regla pass out en la interfaz física con protocolo, IP y puerto correctos.
- Dominio del endpoint no resuelve. Causa: DNS bloqueado antes de conectar. Solución: usa IP en vez de dominio temporalmente o añade regla específica para DNS, teniendo cuidado con fugas.
✅ Verificación: Desconecta VPN y el internet debe desaparecer. Conéctala y debe volver. Con curl https://ifconfig.me comprueba que la IP es la del VPN. Al desconectar, el comando debe fallar o colgar evidenciando bloqueo.
Paso 5: Automatizar kill switch: script y LaunchAgent
Objetivo
Garantizar que reglas PF se cargan y mantienen consistentes tras reinicios y reconexiones, y permitir cambiar modos rápido si es necesario.
Instrucciones
- Crea un script que recargue PF y verifique estado de interfaces VPN: sudo nano /usr/local/bin/vpn-ks-reload.sh.
- Pega estas líneas una a una, adaptando valores si necesitas:
- #!/bin/sh
- /sbin/pfctl -nf /etc/pf.conf || exit 1
- /sbin/pfctl -f /etc/pf.conf
- /sbin/pfctl -e
- exit 0
- Guarda y cierra el editor.
- Haz el script ejecutable: sudo chmod +x /usr/local/bin/vpn-ks-reload.sh.
- Crea LaunchAgent que recargue PF al iniciar sesión: nano ~/Library/LaunchAgents/com.local.vpnks.reload.plist.
- Pega el siguiente XML sin indentaciones para evitar errores:
- <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>
- Guarda el archivo. Carga el agente: launchctl load ~/Library/LaunchAgents/com.local.vpnks.reload.plist.
- Prueba reiniciando sesión o ejecutando manualmente /usr/local/bin/vpn-ks-reload.sh y verifica que no arroje errores.
Consejo: Para desactivar kill switch temporalmente corre sudo pfctl -d. Pero recuerda que deshabilita la protección del sistema. Para activarlo de nuevo usa sudo pfctl -e y sudo pfctl -f /etc/pf.conf.
Resultado esperado
Tras reiniciar el Mac las reglas PF se activan automáticamente. Cuando la VPN se reconecte, siguen funcionando correctamente. Puedes recargar PF manualmente con un comando.
Problemas comunes y soluciones
- LaunchAgent no funciona. Causa: error en plist. Solución: revisa sintaxis, recarga el agente y revisa launchctl list y logs en Console.app.
- PF se desactiva tras actualización del sistema. Solución: ejecuta sudo pfctl -e y recarga configuración. Repite configuración del ancla si hace falta.
✅ Comprobación: Reinicia Mac y al iniciar sesión ejecuta sudo pfctl -sr. Confirma que tus reglas están activas. Prueba conectar y desconectar VPN — el acceso a internet debe comportarse como antes.
Paso 6: Ajuste fino de reglas y protocolos
Objetivo
Asegurar que el kill switch funciona bien con WireGuard, OpenVPN e IKEv2, considerando detalles de puertos y permisos necesarios para cada caso.
WireGuard
- Solo permite UDP al IP del servidor en puerto 51820 por la interfaz física (ejemplo en0). Es la mínima configuración para el túnel.
- Verifica que en AllowedIPs esté 0.0.0.0/0, ::/0 para enrutar todo por utun.
- Confirma que el config tenga DNS dentro del túnel para evitar fugas.
OpenVPN
- Si usas UDP, permite proto udp to IP port 1194 (o tu puerto) en la interfaz física.
- Si usas TCP 443, permite proto tcp to IP port 443.
- Verifica directivas push DNS del servidor o configura DNS manualmente en el adaptador VPN.
IKEv2
- Permite proto udp to IP port 500 y proto udp to IP port 4500 para tráfico saliente en la interfaz física.
- Activa «Enviar todo el tráfico» en configuraciones IKEv2 para evitar fugas.
- Confirma que DNS va por el túnel.
Consejo: Si cambias de red con frecuencia (casa, oficina, hotspot), verifica si cambia la interfaz física (en0, en1). Si es así, agrega reglas pass para cada interfaz usada o usa «group egress» para permitir siempre salida al IP del servidor sin importar interfaz.
Resultado esperado
Reglas PF son mínimas y precisas: solo permiten establecer túnel y todo el tráfico dentro del túnel, sin excepciones imprevistas.
Problemas comunes y soluciones
- Se pierde conexión al cambiar a una red nueva. Causa: interfaz física cambió o IP pública bloquea puerto. Solución: añade reglas para nueva interfaz o usa OpenVPN TCP 443 como alternativa.
- No responden pings a recursos internos. Causa: rutas y AllowedIPs. Solución: incluye subredes internas en AllowedIPs o configura rutas en el servidor.
✅ Verificación: Prueba conectando VPN y haciendo ping y traceroute a direcciones externas. Luego desconecta y confirma que intentos nuevos se bloquean, mientras flujos existentes no se mantienen.
Paso 7: Bloque avanzado: fundamentos del Network Extension API para kill switch
Objetivo
Entender cómo el Network Extension API configura parámetros que afectan el tráfico y cómo implementar enrutamiento estricto por túnel. Opcional y requiere cuenta de desarrollador Apple.
Notas importantes
Para usar Network Extension en macOS puede ser necesario suscribirse a Apple Developer y activar entitlements. Algunos proveedores como filtros de contenido (NEFilter) requieren aprobación especial. Para uso personal y pruebas puedes compilar una app con Packet Tunnel Provider si cuentas con entitlements básicos. Esta sección es para familiarizarte y practicar en ambiente de desarrollo.
Clases y flags clave
- NEPacketTunnelProvider — punto de entrada para cliente VPN personalizado. Aquí levantas túnel y configuras red.
- NEPacketTunnelNetworkSettings — objeto donde defines ajustes IPv4/IPv6, DNS, rutas. Flags importantes: includeAllNetworks = true y excludeLocalNetworks = true para forzar todo el tráfico por túnel.
- NEVPNManager — controla política On-Demand y ciclo de vida VPN en sistema (para IKEv2 y Packet Tunnel).
- NEDNSSettings — permite definir DNS a través del túnel y matchDomains = [""] para capturar todas las consultas DNS.
Pasos básicos en Xcode
- Crea en Xcode un nuevo proyecto App para macOS. Añade target Network Extension de tipo Packet Tunnel Provider.
- Entitlements posibles: activa «Personal VPN». Asegúrate de que en Signing & Capabilities esté agregado Network Extensions con el proveedor requerido.
- En el código de Packet Tunnel Provider crea NEPacketTunnelNetworkSettings. Define ipv4Settings con la IP del túnel (ejemplo 10.14.0.2/32) y rutas por defecto (0.0.0.0/0). Establece includeAllNetworks = true y excludeLocalNetworks = true.
- Agrega NEDNSSettings con la IP DNS dentro del túnel y matchDomains = [""] para que todo DNS pase por la VPN.
- Guarda política On-Demand con NEVPNManager, estableciendo conexión en cualquier red salvo las confiables que quieras excluir. Para kill switch es mejor no excluir ninguna.
- Compila y ejecuta la app localmente, instalando la configuración VPN en el sistema. Autoriza la instalación si pide.
Consejo: Para uso personal y no publicar en App Store, mantiene proyecto y bundle ID con tu Apple ID personal. Facilita instalación y gestión del perfil en tu Mac.
Resultado esperado
Obtienes una configuración mínima funcional de cliente personalizado que enruta todo tráfico y DNS por el túnel. El kill switch del sistema sigue siendo PF configurado antes. Juntos ofrecen doble capa de protección.
Problemas comunes y soluciones
- No tienes el entitlement necesario. Solución: revisa tu suscripción Apple Developer y agrega capacidades en Signing & Capabilities.
- No se instala el perfil. Solución: consulta logs de consola, verifica firma y permisos de la app para manejar VPN.
- Conflicto con cliente existente. Solución: no ejecutes clientes simultáneos usando el mismo túnel.
✅ Verificación: En ajustes de red macOS deberá aparecer tu perfil VPN. Al conectar todo el tráfico debe ir por el túnel y DNS también. Al detener tu cliente, PF mantiene el bloqueo.
Paso 8: Pruebas integrales: tráfico, DNS, fallos
Objetivo
Confirmar que el kill switch funciona bien: no hay conexiones fuera del VPN, no hay fugas DNS y ante caída repentina del túnel el acceso a internet se bloquea inmediatamente.
Plan de pruebas
- Prueba de enrutamiento: con VPN activa ejecuta curl https://ifconfig.me y anota IP. Desconecta VPN y confirma que la solicitud falla (por PF).
- Prueba DNS: con VPN activa ejecuta scutil --dns y verifica que el resolver es la IP del túnel. Haz nslookup example.com y checa qué servidor responde. Desconecta y confirma que el DNS falla.
- Prueba de interrupción: con VPN activa mata el proceso cliente o cambia la red Wi‑Fi. Verifica que internet no aparece hasta reconectar VPN.
- Prueba de tiempo de recuperación: mide segundos que tarda VPN en reconectarse tras cambio de red. Confirma que PF bloquea durante ese tiempo.
- Prueba con apps: abre navegador, mensajería y reproductor. Comprueba que funcionan solo con VPN activa.
Consejo: Para diagnóstico detallado usa tcpdump en interfaz física: sudo tcpdump -i en0 not port 51820 (para WireGuard). Con configuración correcta no verás fugas bajo PF.
Resultado esperado
No hay fugas de tráfico ni DNS sin VPN activa. Al restablecer túnel, todas las apps recuperan acceso inmediatamente.
Problemas comunes y soluciones
- Algunos servicios del sistema conectan fuera del túnel. Causa: excepción no contemplada en PF. Solución: revisa sudo pfctl -vvsr y elimina reglas inesperadas, sobre todo creadas por apps externas.
- Retrasos en reconexión. Solución: habilita On-Demand en cliente para que responda rápido a cambios y simplifica reglas PF al mínimo.
✅ Verificación: En resumen: sin VPN — tráfico bloqueado; con VPN — todo funciona; DNS siempre via túnel; cortes no generan fugas.
Verificación final
Checklist
- Cliente VPN instalado y configurado (WireGuard, OpenVPN o IKEv2).
- Configuración importada correctamente, IP y puerto del servidor conocidos.
- DNS activado por túnel, On-Demand configurado.
- Creada ancla PF y conectada a /etc/pf.conf.
- PF habilitado, reglas activas tras reinicio.
- Internet funciona solo con VPN activo.
- Pasadas pruebas de desconexión y fugas DNS.
Cómo probar
- Realiza tres ciclos: VPN activo — verifica IP y DNS; VPN desactivado — sin conexiones; VPN reconectado — acceso retornado.
- Prueba en redes Wi‑Fi y Ethernet diversas.
- Consulta logs PF con sudo pfctl -vvsr y sudo pfctl -vvss para estado.
Criterios de éxito
- Cero conexiones de red sin VPN activo (excepto las permitidas a IP y puertos del servidor).
- Sin respuestas DNS fuera de VPN y resolución estable dentro del túnel.
- Rápida recuperación de apps tras reconexión VPN.
Errores comunes y soluciones
- Problema: Internet no funciona con VPN activo. Causa: utun equivocado en reglas PF. Solución: identifica utun activo con ifconfig y añade pass quick on utunX en ancla.
- Problema: VPN no se conecta. Causa: PF bloquea conexión al servidor. Solución: añade regla pass out quick on enX proto udp/tcp to IP port NNNN para tu protocolo.
- Problema: Fugas DNS. Causa: DNS no configurado para ir por túnel. Solución: añade DNS en WireGuard config, usa push DNS en OpenVPN o asigna DNS en interfaz VPN.
- Problema: PF se desactiva tras actualización. Causa: el sistema reinicia servicios. Solución: ejecuta sudo pfctl -e y recarga con -f /etc/pf.conf, asegúrate que LaunchAgent esté activo.
- Problema: Apps se conectan fuera del VPN. Causa: enrutamiento con exclusiones. Solución: revisa AllowedIPs y evita split-tunneling; usa 0.0.0.0/0 y ::/0.
- Problema: No puedes compilar ejemplo con Network Extension. Causa: falta de entitlements. Solución: suscríbete a Apple Developer y añade capacidades en Xcode.
- Problema: Corte al cambiar entre redes Wi‑Fi. Causa: puerto o protocolo bloqueados. Solución: usa OpenVPN TCP 443 o perfil alternativo.
Funciones adicionales
Configuraciones avanzadas PF
- Usar tablas para IPs: crea tabla con IP del servidor y aplica una regla para actualizar solo la tabla si cambia la IP.
- Logging: activa registro de bloqueos para análisis en Console.app o con tcpdump -n -e -ttt -i pflog0.
- Granularidad: si usas varios protocolos, sepáralos en anclas diferentes y maneja su activación dinamicamente.
Optimización del cliente
- En WireGuard ajusta MTU (1420–1440) para evitar fragmentación.
- En OpenVPN usa tls-crypt y cifrado moderno para mayor seguridad.
- En IKEv2 utiliza cifrados modernos y PFS si el servidor lo soporta.
Qué más puedes hacer
- MDM y perfiles: si es dispositivo corporativo, despliega perfiles gestionados con política On-Demand para escalar en varios equipos.
- Perfiles de respaldo: prepara configuración VPN alternativa con otro puerto o protocolo para redes con filtro estricto.
- Monitoreo: configura alertas ante caída del túnel vía eventos del sistema o scripts que vigilen interfaces y escriban logs locales.
Consejo: Si te desplazas y usas redes de invitados, ten a mano varios perfiles con diferentes puertos y protocolos. Así mantienes acceso a la VPN ante diversas restricciones.
Preguntas frecuentes (FAQ)
- ¿Se puede hacer kill switch sin PF? Sí, algunos clientes tienen kill switch propio, pero PF ofrece garantía a nivel sistema, independiente del cliente.
- ¿Es necesario usar dominio en vez de IP? No siempre. Para seguridad y facilidad en PF es mejor usar IP fija. El dominio es útil para balanceo y cambio de servidores, pero requiere manejar exclusiones DNS.
- ¿Cómo saber qué utun usar? Conecta VPN y corre ifconfig. El utun activo con datos de tráfico es tu interfaz túnel.
- ¿Se puede usar IPv6? Sí. Añade ::/0 en rutas y confirma soporte del servidor. Reglas PF para IPv6 se configuran similar, cuidando protocolos y direcciones.
- ¿Qué pasa si no soy Apple Developer? No importa. El kill switch principal con PF funciona sin Network Extension. La parte avanzada es opcional.
- ¿Hay que tener PF siempre activado? Sí, si quieres kill switch permanente. Deshabilítalo temporalmente solo con plena conciencia.
- ¿Cómo actualizar la configuración seguro? Desconecta VPN, actualiza config, revisa sintaxis PF, conecta VPN y recarga PF. Siempre ten a mano IP y puertos.
- ¿Funcionan las redes locales (impresoras, NAS)? Por defecto no si todo va por túnel. Añade exclusiones en rutas o considera tunel dividido para subredes específicas, asumiendo riesgos.
- ¿Cómo evitar fugas WebRTC? Desactiva WebRTC en el navegador o usa extensiones. La base es mantener kill switch activo con rutas completas.
- ¿Se puede automatizar cambio de perfiles? Sí. Usa scripts o funciones del cliente (WireGuard tiene CLI). Mantén PF estable con las IPs en tablas autorizadas.
Conclusión
Has recorrido el proceso completo: elegido protocolo y cliente, importado config, configurado DNS y On-Demand, activado kill switch del sistema con PF, automatizado y testeado en múltiples escenarios. El resultado es un esquema fiable donde tu tráfico solo sale por VPN y se bloquea totalmente si la conexión cae.
A futuro puedes personalizar configuraciones para varios servidores y protocolos, usar reglas PF con tablas, profundizar en Network Extension API para clientes personalizados, y emplear perfiles gestionados en ambientes corporativos. Con buena configuración consigues alta resiliencia, previsibilidad y seguridad, además de diagnósticos claros mediante logs PF.
Consejo: Revisa reglas periódicamente, especialmente después de actualizaciones de macOS, y verifica que el comportamiento no cambie. El script de recarga PF y el checklist en «Verificación final» te ayudarán a asegurarte de que todo funcione como esperado.
⚠️ Atención: No agregues excepciones innecesarias en PF “por si acaso”. A menor y más precisa sea la lista de permisos, más seguro y estable será tu kill switch, y menos sorpresas ante cambios de red.