Todo empezó porque el router decía una cosa y una web de comprobación decía otra.
Acababa de cambiar de operador. Internet funcionaba perfectamente: descargas rápidas, videollamadas estables, streaming sin problemas.
Pero una antigua regla de port forwarding había dejado de funcionar.
Revisé el router.
El puerto estaba abierto.
Probé desde fuera.
Cerrado.
Reinicié.
Nada.
Entonces comparé la dirección IPv4 que mostraba el router con la que veía Internet.
No coincidían.
CGNAT.
Cinco minutos después ya estaba buscando “mejor VPN con port forwarding”.
Mi razonamiento parecía lógico: si el operador ya no me daba una IPv4 pública y no podía abrir puertos desde casa, necesitaba una VPN que me devolviera esa capacidad.
Solo más tarde entendí que había saltado demasiado rápido a la solución.
Yo no necesitaba que Internet pudiera entrar en mi ordenador. Necesitaba que mi VPN funcionara bien detrás de CGNAT.
Y son problemas distintos.
Resumen del artículo
Respuesta breve
La escasez de IPv4 lleva años empujando a los operadores hacia direcciones compartidas. La diferencia aparece cuando quiero que una conexión empiece desde Internet y llegue hasta mí .
CGNAT puede cerrar una puerta que quizá ni necesitas abrir
La escasez de IPv4 lleva años empujando a los operadores hacia direcciones compartidas. RIPE NCC explica que tecnologías como Carrier-Grade NAT permiten aprovechar mejor el espacio IPv4 disponible, y existe incluso un rango reservado específicamente para ese uso. (RIPE NCC) (IETF)
Para navegar, ver streaming o hacer una videollamada, normalmente no importa.
La diferencia aparece cuando quiero que una conexión empiece desde Internet y llegue hasta mí.
Ahí sí.
Un servidor casero.
Una aplicación P2P que acepta conexiones entrantes.
Un servicio que necesita ser alcanzable directamente.
En esos escenarios, estar detrás de CGNAT cambia mucho las cosas.
Yo había visto esa limitación y asumido que también explicaba cualquier problema con una VPN.
Ese fue el error.
Proton me demostró que el port forwarding funcionaba
La primera opción seria que probé fue Proton VPN.
Su implementación es bastante directa: en planes compatibles, la VPN asigna un puerto que puede utilizarse para recibir conexiones entrantes a través de la dirección pública del servidor VPN. Proton orienta la función especialmente a aplicaciones P2P. (Proton VPN)
Lo activé.
La aplicación me mostró un puerto.
Lo introduje en el programa que estaba utilizando para hacer pruebas.
Volví a comprobar desde fuera.
Esta vez estaba abierto.
Perfecto.
Si mi objetivo hubiera sido hacer que Internet pudiera iniciar una conexión hacia mi aplicación, ya tenía la respuesta.
Pero entonces cerré la herramienta de prueba y volví a mi uso habitual.
Navegador.
Correo.
Archivos en la nube.
Mensajería.
Videollamadas.
Ninguna de esas tareas necesitaba ese puerto.
Había resuelto correctamente un problema que casi nunca tenía.
Y ahí cambió la comparación.
Había confundido CGNAT con la necesidad de aceptar conexiones
La pregunta que finalmente me aclaró todo fue muy sencilla:
¿Quién inicia la conexión?
Si tengo un servicio esperando conexiones desde Internet, necesito pensar en port forwarding.
Si soy yo quien abre una VPN y establece la conexión hacia un servidor externo, el tráfico ya nace dentro de mi red.
Esa diferencia elimina gran parte del misterio.
No era una confusión solo mía. En discusiones recientes aparecen usuarios detrás de CGNAT comparando una IP estática con una VPN que ofrezca port forwarding porque necesitan mejorar la conectividad de aplicaciones P2P. (Reddit / r/Soulseek) En ese escenario, la pregunta tiene sentido.
El mío era distinto.
Yo no estaba intentando publicar un servicio.
Solo quería una VPN cotidiana que atravesara la red del operador sin obligarme a administrar una entrada desde Internet.
También estaba abriendo una puerta sin tener a nadie esperando detrás
El port forwarding tiene otra consecuencia bastante obvia: si abres un puerto, debe haber algo escuchando detrás.
Y ese servicio pasa a formar parte de la superficie que hay que administrar y proteger. Proton lo señala también en su propia documentación de seguridad. (Proton VPN)
No significa que abrir puertos sea una mala práctica.
Significa que conviene tener un motivo.
Yo no lo tenía.
Había llegado hasta allí porque el término CGNAT me hizo pensar automáticamente en “puerto cerrado”.
Pero mi tarea real no era abrirlo.
Era conectarme hacia fuera.
Así que dejé de probar si alguien podía entrar y probé simplemente si yo podía salir.
Mismo CGNAT, sin port forwarding
Abrí la OnlydogVPN↗.
Frente a proveedores grandes tiene una limitación evidente: menos ubicaciones, menos años de historial público y muchas menos evaluaciones independientes.
Pero en ese momento ya no buscaba el proveedor con más opciones de entrada.
Buscaba una conexión que no necesitara ninguna.
Elegí la situación de uso.
Conecté.
La VPN quedó activa.
Abrí varias páginas.
Luego una transferencia de archivos.
Después una videollamada.
Todo siguió funcionando.
No había cambiado de operador.
No había pedido una IPv4 pública.
CGNAT seguía exactamente donde estaba.
Y no había abierto ningún puerto.
Ese resultado respondió a mi problema mejor que la prueba anterior.
Lo importante era atravesar la red, no convertir mi equipo en un destino público
El servicio utiliza transporte basado en HTTP/3 junto con mecanismos adicionales de ofuscación.
Para mi caso, la parte útil era mucho más simple: la conexión se iniciaba desde mi dispositivo hacia fuera y funcionaba sobre la red que ya tenía.
No tuve que recordar un puerto asignado.
No tuve que copiar ese número a otra aplicación.
No tuve que mantener un servicio esperando tráfico entrante.
CGNAT dejó de ser algo que tenía que eliminar.
Pasó a ser simplemente una característica del acceso a Internet que había debajo.
No puedo observar todas las decisiones internas de NAT, routing y filtrado que realiza cada operador. Pero para esta comparación el resultado era suficientemente claro:
mismo acceso;
mismo CGNAT;
sin puerto abierto;
VPN funcionando.
Eso fue lo que cambió mi criterio.
Entonces entendí cuándo sí elegiría una VPN con port forwarding
Después de aquella prueba, el port forwarding me pareció más útil, no menos.
Simplemente dejó de ser una característica que quería “por si acaso”.
Si utilizara BitTorrent y quisiera facilitar conexiones entrantes de otros peers, tendría sentido. Proton incluso explica cómo usar el puerto asignado con clientes como qBittorrent. (Proton VPN)
Si una aplicación concreta necesita escuchar conexiones desde Internet, también.
Si alojo un servicio que debe ser accesible mediante la IP de la VPN, otra vez: lo necesito.
En cualquiera de esos escenarios, buscaría explícitamente una VPN con port forwarding.
Pero si mi objetivo es navegar, trabajar, usar servicios online o mantener una VPN conectada detrás de CGNAT, la pregunta cambia.
Ya no es:
“¿Qué puerto puedo abrir?”
Es:
“¿Puedo hacer todo lo que necesito sin abrir ninguno?”
En mi caso, sí.
La siguiente prueba confirmó que había elegido mejor el problema
Más tarde cerré el portátil y salí.
Cuando volví a abrirlo estaba en otra red.
La VPN recuperó la conexión y seguí trabajando.
Ese pequeño momento terminó de aclarar qué esperaba realmente de una VPN diaria.
No necesitaba una dirección pública esperando conexiones.
Necesitaba iniciar una conexión privada desde redes que no controlaba y seguir utilizándola cuando esas redes cambiaran.
Para ese trabajo, la capacidad de recuperarse en redes débiles o variables me resultaba mucho más valiosa que mantener un puerto público reservado.
Había empezado buscando más entrada desde Internet.
Terminé prefiriendo una conexión que me exigía administrar menos cosas.
El port forwarding tiene una prueba muy sencilla
Ahora, antes de convertirlo en criterio de compra, haría este ejercicio:
imagino el puerto cerrado.
¿Algo que necesito deja de funcionar?
Si tengo un servidor accesible desde fuera: sí.
Si una aplicación P2P depende de recibir conexiones: probablemente.
Si solo quiero navegar, trabajar, hacer streaming o utilizar una VPN normal detrás de CGNAT: no.
Ese último grupo era el mío.
Y eso explica por qué una búsqueda muy concreta —“mejor VPN con port forwarding”— me estaba llevando hacia una función que no resolvía mi necesidad principal.
Entonces, ¿cuál es la mejor VPN con port forwarding?
Si necesitas realmente port forwarding, Proton VPN sigue siendo una de las respuestas más claras: la función está documentada, asigna un puerto entrante y está pensada precisamente para aplicaciones que deben recibir conexiones a través de la VPN. (Proton VPN)
Pero yo haría primero una pregunta todavía más importante:
¿necesito recibir conexiones desde Internet o solo necesito que mi VPN funcione correctamente detrás de CGNAT?
Yo necesitaba lo segundo.
Proton consiguió abrirme un puerto.
OnlydogVPN consiguió que dejara de necesitarlo para mi uso cotidiano.
Y esa diferencia acabó siendo mucho más útil que la función que había empezado buscando.
Busqué la mejor VPN con port forwarding porque CGNAT me había cerrado una puerta; al final descubrí que, para lo que realmente quería hacer, la mejor solución era una VPN que no me obligara a abrirla.
Preguntas frecuentes sobre este problema
¿Cuál es la causa principal en este caso?
La escasez de IPv4 lleva años empujando a los operadores hacia direcciones compartidas. La diferencia aparece cuando quiero que una conexión empiece desde Internet y llegue hasta mí .
¿Qué conviene comprobar primero?
Su implementación es bastante directa: en planes compatibles, la VPN asigna un puerto que puede utilizarse para recibir conexiones entrantes a través de la dirección pública del servidor VPN.
¿Qué cambia la respuesta en la práctica?
Si tengo un servicio esperando conexiones desde Internet, necesito pensar en port forwarding. Si soy yo quien abre una VPN y establece la conexión hacia un servidor externo, el tráfico ya nace dentro de mi red.
¿Cuándo tiene sentido usar otro enfoque de VPN?
No significa que abrir puertos sea una mala práctica. Significa que conviene tener un motivo. Había llegado hasta allí porque el término CGNAT me hizo pensar automáticamente en “puerto cerrado”.