El punto clave en una VPN L2TP no es solo “abrir un puerto”, sino entender qué tráfico viaja por cada capa y por qué algunas conexiones funcionan en casa pero fallan en una WiFi pública o detrás de un router con NAT. Aquí voy a explicarte qué usa realmente L2TP, qué cambia cuando entra IPsec, cómo comprobarlo en router y firewall, y qué errores veo una y otra vez en entornos domésticos y de pequeña oficina.
Lo más importante del puerto de L2TP en una VPN
- L2TP usa UDP 1701; ese es su puerto base.
- Si va sobre IPsec, también entran UDP 500, UDP 4500 y ESP protocolo 50.
- Abrir solo 1701 suele ser insuficiente para una VPN L2TP/IPsec real.
- El doble NAT y el CGNAT son dos de los bloqueos más molestos cuando el túnel no levanta.
- En redes con filtrado agresivo, L2TP/IPsec puede fallar aunque la navegación normal siga funcionando.
Lo esencial del puerto de L2TP en una VPN
El RFC 2661 de IETF deja claro que L2TP usa UDP 1701: el iniciador manda el primer control hacia ese puerto y, a partir de ahí, el túnel mantiene sus extremos de forma estable. Dicho de forma simple, el puerto L2TP que debes tener en la cabeza es 1701/UDP, no TCP y no un rango raro de números para “probar suerte”.
Esto importa porque muchas configuraciones fallan por una lectura incompleta del protocolo. Se abre algo en el router, pero el tráfico real se corta por usar el puerto equivocado, por confundir L2TP con PPTP o por un firewall que inspecciona más de la cuenta. Yo siempre empiezo por la misma pregunta: ¿estamos hablando de L2TP puro o de L2TP con IPsec? La respuesta cambia todo el mapa, y si además usas IPsec, el escenario técnico cambia bastante.
Qué cambia cuando L2TP va protegido con IPsec
Cuando L2TP viaja sobre IPsec, ya no basta con mirar 1701. Microsoft Learn resume el caso práctico de forma bastante clara: hay que permitir ESP, que usa el protocolo IP 50, además de UDP 500 para IKE o ISAKMP y UDP 4500 para NAT-T, junto con el propio UDP 1701 de L2TP. Eso no significa que todo deba quedar expuesto sin control; significa que el tráfico correcto tiene que poder atravesar el firewall o el router sin ser cortado a mitad de camino.
| Elemento | Puerto o protocolo | Qué hace en la conexión |
|---|---|---|
| L2TP | UDP 1701 | Transporta el túnel y su señalización base. |
| IKEA/ISAKMP | UDP 500 | Negocia la asociación de seguridad de IPsec. |
| NAT-T | UDP 4500 | Permite que IPsec sobreviva cuando hay NAT en el camino. |
| ESP | IP protocolo 50 | Aporta el encapsulado de seguridad de IPsec. |
La trampa habitual está en NAT. Si el cliente o el servidor están detrás de una traducción de direcciones, IPsec encapsula parte del tráfico en UDP 4500 para que el túnel siga vivo; si además hay CGNAT del operador, reenviar puertos deja de ser una solución real. En una WiFi de hotel, en una red pública o en algunos routers domésticos con doble NAT, ahí es donde la conexión se cae sin un error demasiado explícito. Con ese mapa claro, lo útil es saber qué abrir y cómo comprobarlo sin adivinar.
Cómo comprobarlo en router, firewall y cliente
Yo lo reviso en este orden, porque acelera mucho el diagnóstico y evita tocar media red para no resolver nada:
- Confirmo el modo exacto: L2TP solo o L2TP/IPsec. No es lo mismo abrir 1701 que permitir todo el flujo de IPsec.
- Verifico el lado correcto: si el servidor está detrás de un router, el reenvío debe apuntar a su IP interna real, no a otro equipo de la LAN.
- Autorizo los puertos y protocolos necesarios: UDP 1701 para L2TP; si hay IPsec, también UDP 500, UDP 4500 y ESP 50.
- Pruebo desde otra red: datos móviles o una WiFi distinta sirven para separar un problema local de un bloqueo del operador o del firewall.
- Compruebo el tráfico: si el túnel no sube, mirar logs o una captura ayuda más que seguir cambiando reglas a ciegas.
Un detalle práctico: no me fiaría solo de un escaneo UDP desde fuera. En VPN y en firewalls modernos, un puerto puede parecer cerrado aunque el problema real esté en la negociación IPsec, en la autenticación o en una política de seguridad intermedia. Cuando ya sabes dónde mirar, los fallos repetidos empiezan a parecer más obvios que misteriosos.
Errores que más rompen una conexión L2TP
- Abrir solo 1701: suficiente para L2TP puro, insuficiente para L2TP/IPsec.
- Reenviar al equipo equivocado: el router entrega el tráfico a otra máquina y la VPN nunca ve la petición.
- Olvidar ESP: el túnel parece negociar, pero no termina de establecerse.
- Confundir L2TP con PPTP: PPTP usa 1723/TCP y GRE 47; tocar eso no arregla una VPN L2TP.
- Dar por hecho que la WiFi permite VPN: hay redes que dejan navegar, pero bloquean justo el tráfico que necesita el túnel.
- Ignorar usuario, PSK o certificados: a veces el problema se presenta como red, pero en realidad es autenticación.
En redes corporativas y en equipos del operador, los filtros de estado, la inspección profunda y un NAT mal colocado hacen más daño que el propio puerto. Ese contexto también ayuda a decidir si merece la pena seguir con L2TP o mirar otra opción.
Cuándo sigue teniendo sentido frente a otras VPN
No defiendo L2TP por nostalgia. Lo mantengo sobre la mesa cuando necesito compatibilidad nativa con dispositivos ya desplegados y quiero evitar instalar clientes extra. Fuera de ese escenario, otras VPN suelen dar menos fricción operativa y menos reglas especiales en el firewall.
| Opción | Exposición de red | Cuándo la veo útil |
|---|---|---|
| L2TP | UDP 1701 | Entornos heredados o pruebas controladas dentro de una red muy cerrada. |
| L2TP/IPsec | UDP 1701, UDP 500, UDP 4500 y ESP 50 | Compatibilidad nativa con equipos variados cuando puedes gestionar bien el firewall. |
| PPTP | TCP 1723 y GRE 47 | Solo para migraciones o compatibilidad temporal; hoy no lo elegiría para algo serio. |
Mi criterio es bastante directo: si la prioridad es seguridad y simplicidad operativa, yo prefiero una solución más moderna; si la prioridad es compatibilidad inmediata con móviles, routers y sistemas antiguos, L2TP/IPsec todavía cumple. Eso sí, cuanto más grande es la red, más se nota el coste de mantener reglas extra y excepciones heredadas. Antes de cerrar, yo haría una última comprobación sencilla para evitar pruebas a ciegas.
La comprobación final que yo haría antes de tocar más la red
Cuando una VPN L2TP no levanta, yo no sigo moviendo reglas al azar. Primero confirmo si el equipo está detrás de una IP pública real o de CGNAT, porque en ese caso el reenvío de puertos deja de servir de forma práctica. Después pruebo desde una red distinta, idealmente con datos móviles, para separar el problema local del problema del proveedor, del router o de la política de la WiFi.
Si en ese segundo intento la conexión cambia de comportamiento, ya no estoy persiguiendo un “fallo del puerto”: estoy persiguiendo un bloqueo de red, un NAT intermedio o una política de seguridad demasiado agresiva. Esa distinción ahorra tiempo y evita abrir más superficie de la necesaria; en seguridad, abrir menos y entender mejor suele ser la combinación que más rinde. Si tuviera que dejar una sola idea clara, sería esta: L2TP vive en UDP 1701, pero en Internet casi siempre depende de IPsec para funcionar de verdad, y eso cambia por completo la lista de puertos y de problemas posibles.
