En el mundo de las aplicaciones VPN para dispositivos iOS, la gestión eficaz y segura del tráfico de red es una prioridad absoluta. Una característica que ha generado muchas preguntas y expectación es includeAllNetworks, una bandera que, según Apple y diversas investigaciones, debería garantizar que todo el tráfico de datos sea enrutado exclusivamente a través del túnel VPN, minimizando fugas y mejorando la privacidad. Sin embargo, pese a sus aparentes beneficios y a la promesa de una configuración simplificada, nuestra aplicación de VPN para iOS todavía no utiliza esta función por razones técnicas y prácticas profundas que hoy exploraremos en detalle. El planteamiento de includeAllNetworks surge de un objetivo claro: evitar fugas de tráfico que podrían comprometer la privacidad y seguridad del usuario. La documentación oficial indica que activar este flag obligaría al sistema a tratar todo el tráfico como parte de la VPN, evitando que paquetes se desvíen fuera de ella.
En otros sistemas operativos, estrategias similares se logran mediante manipulación directa del firewall y tablas de enrutamiento, herramientas que a menudo complican la experiencia del desarrollador y usuario final. Apple propone una solución más elegante, con este solo parámetro configurado en el perfil VPN. A primera vista, activar includeAllNetworks parecería el avance ideal hacia una conectividad segura y robusta. Sin embargo, la realidad técnica en iOS es mucho más compleja y presenta problemas que han impedido su adopción en nuestra app. La configuración con esta bandera genera conflictos graves que afectan el funcionamiento interno del túnel VPN e incluso la conectividad general del dispositivo tras actualizaciones de la aplicación.
Uno de los principales retos técnicos es la interacción entre la aplicación y el proceso separado que maneja la VPN en iOS, conocido como paquete túnel o Packet Tunnel Provider. En nuestra arquitectura, el proceso que establece la conexión VPN y otra parte de la aplicación que interactúa con el usuario están desacoplados. El proceso de túnel maneja tanto paquetes ICMP para verificar la salud del túnel, como conexiones TCP para negociaciones necesarias en configuraciones avanzadas como DAITA o túneles resistentes a ataques cuánticos. Cuando includeAllNetworks se establece en verdadero, el tráfico generado desde ese mismo proceso de túnel no logra circular correctamente. Específicamente, intentos de enviar paquetes ICMP hacia el gateway interno o establecer conexiones TCP a través del túnel fallan sin generar errores explícitos, pero simplemente no avanzan.
Estos resultados sugieren una limitación o comportamiento no documentado y posiblemente no soportado por Apple, que impide simplemente utilizar sockets BSD tradicionales o NWTCPConnection para tráfico interno dentro del túnel cuando se activa la bandera. Una solución inicial consideró eliminar el uso de ICMP y TCP desde el proceso túnel, confiando en que el túnel funciona correctamente sin esas pruebas activas. Así, la navegación por internet y el envío de pings desde otras apps funcionaban, pero curiosamente la propia aplicación no podría realizar dichas comprobaciones internamente. Esto reveló una incoherencia importante: la app que establece el VPN no puede monitorizar el túnel a través de los métodos tradicionales cuando includeAllNetworks está activo. Para sortear estas limitaciones técnicas, se adoptó un enfoque innovador: implementar una pila de red en espacio de usuario, utilizando la librería gonet de gvisor, lo que permite establecer conexiones TCP y generar tráfico ICMP desde el propio proceso túnel sin depender de protocolos o sockets del sistema operativo que no funcionan con includeAllNetworks.
Esta solución ha logrado resultados positivos, y actualmente se usa en la versión liberada de la aplicación. Sin embargo, aún con esta ventaja técnica, hay un problema crítico relacionado con la experiencia del usuario y la estabilidad de la red durante actualizaciones de la aplicación. En pruebas realizadas, cuando includeAllNetworks está activo y la aplicación pasa por el proceso de actualización a través de la App Store, se produce una situación de bloqueo en la conectividad donde el dispositivo pierde acceso a internet. Este estado no se soluciona automáticamente y obliga al usuario a cancelar manualmente la descarga o incluso reiniciar el dispositivo para restaurar la conexión. Este bloqueo ocurre porque el sistema operativo mantiene el perfil VPN con includeAllNetworks activo mientras espera que la descarga y actualización finalicen.
Durante este proceso, el perfil impuesto por la VPN obliga a que todo el tráfico pase por el túnel activo, pero el viejo proceso ya terminó y el nuevo aún no se ha iniciado, lo que resulta en un limbo sin conexión. Además, ni desinstalar la aplicación ni eliminar el perfil VPN resuelve el problema mientras la actualización esté en curso, creando una experiencia frustrante y confusa para los usuarios. Por ahora, no existe una solución fácil para esta limitación. Hemos informado a Apple y seguimos esperando respuesta o una mejora que permita evitar este comportamiento. Mientras tanto, consideramos que implementar includeAllNetworks en nuestra app puede representar un riesgo mayor para la experiencia de nuestros usuarios que las fugas potenciales que esta función pretende evitar.
En términos de privacidad, includeAllNetworks es sin duda una promesa de mayor seguridad y control. Su correcta funcionalidad aseguraría que ningún paquete se escape fuera del túnel, bloqueando fugas que pueden comprometer la identidad, ubicación o actividades del usuario. Pero dicha promesa, si se implementa sin garantías técnicas y estabilidad, puede volverse un arma de doble filo, especialmente cuando bloqueos y pérdida de conectividad pueden afectar funcionalidades críticas como recibir notificaciones push, correos electrónicos o simplemente navegar. La realidad demuestra que el proceso de gestión de túneles en iOS es delicado y depende de interacciones complejas entre múltiples niveles del sistema y la aplicación. El manejo de sockets, la creación y señalización del estado de la conexión, la comunicación entre procesos separados y las limitaciones impuestas por la propia plataforma para evitar abusos o bloqueos no intencionados, hacen del desarrollo de VPN una tarea compleja y en constante evolución.
Aunque en iOS 18 existen indicios prometedores con el uso de NWConnection con parámetros especializados capaces de establecer conexiones dentro del túnel de forma confiable, la necesidad de mantener soporte para versiones anteriores, como iOS 15, mantiene nuestro enfoque en soluciones sorprendentes pero compatibles como el usuario espacio de red. Esta transición gradual nos permite explorar nuevas funciones sin descuidar a los usuarios que todavía no han actualizado sus equipos o cuyo hardware no soporta versiones recientes. Además, el estado actual refleja un equilibrio cuidadoso entre proteger la privacidad y no sacrificar la estabilidad del servicio. Optar por activar includeAllNetworks sin contar con soluciones robustas para problemas de conectividad y actualizaciones podría generar un daño mayor al erosionar la confianza del usuario debido a fallos persistentes o bloqueo del dispositivo. Es importante destacar que esta problemática no es exclusiva de nuestra solución, sino que refleja una limitación inherente al ecosistema iOS y al enfoque que Apple ha elegido para la gestión de conexiones VPN.
