L2TP/IPsec conectado pero sin Internet: por qué ocurre y cómo solucionarlo

Qué significa realmente “conectado” en L2TP/IPsec

L2TP/IPsec son dos protocolos bajo un mismo abrigo:

• IPsec proporciona cifrado y transporte de paquetes, habitualmente usando IKEv1 (a menudo “L2TP/IPsec PSK” en las UIs de cliente). Negocia claves y establece SAs (Security Associations). Si esto funciona, puedes decir con verdad “el túnel está arriba”.
• L2TP corre dentro de IPsec y establece una sesión PPP. En PPP obtienes una dirección IP, servidores DNS y a veces una ruta por defecto u otras rutas empujadas.

Así que “conectado” podría significar cualquiera de estos:

1. IKE tuvo éxito; existen SAs de IPsec; L2TP nunca subió. La interfaz puede aun así indicar éxito dependiendo del cliente.
2. L2TP subió; PPP autenticó; el cliente obtuvo una IP; pero las rutas no cambiaron como piensas.
3. Las rutas cambiaron; los paquetes fluyen; pero NAT/firewall en el servidor bloquea el tráfico de retorno.
4. Todo está “bien” excepto que el DNS apunta a un resolvedor al que no puedes alcanzar por la VPN.
5. Todo está “bien” hasta que el MTU/fragmentación mata paquetes grandes y la navegación web se vuelve un baile interpretativo.

Regla uno: trata “conectado” como una pista, no como un diagnóstico.

Broma #1: Una VPN que dice “conectado” pero no pasa tráfico es como una reunión que pudo haber sido un correo electrónico—técnicamente ocurrió, funcionalmente inútil.

Hechos y contexto interesantes (por qué este stack se comporta así)

Algo de contexto hace que la rareza sea menos misteriosa y las soluciones más previsibles. Aquí hay algunos hechos concretos y relevantes históricamente:

1. L2TP es básicamente ADN de L2F + PPTP. Se estandarizó a finales de los 90 como forma de tunelizar PPP sobre redes IP. Las suposiciones de PPP aún se filtran por todas partes.
2. L2TP no proporciona cifrado. Por eso “L2TP/IPsec” es el emparejamiento habitual. L2TP es la capa de sesión; IPsec es la capa de seguridad.
3. La mayoría de clientes usan IKEv1 para L2TP/IPsec. Los despliegues modernos de IPsec prefieren IKEv2, pero las pilas L2TP suelen quedarse en IKEv1 por compatibilidad.
4. NAT-Traversal se volvió la realidad por defecto. IPsec originalmente no amaba NAT. NAT-T encapsula ESP en UDP/4500 para que sobreviva en routers domésticos típicos.
5. L2TP utiliza UDP/1701. En L2TP/IPsec, UDP/1701 suele estar protegido por IPsec; si lo ves en claro en Internet, probablemente sea una mala configuración.
6. “Conectado” en Windows no garantiza cambio de ruta por defecto. Dependiendo de ajustes (split tunneling, métricas, “usar puerta de enlace remota por defecto”), tu ruta a Internet puede seguir siendo local.
7. Las opciones de PPP aún importan. Cosas como MRU/MTU, asignación de DNS y “defaultroute” pueden hacer o deshacer la usabilidad.
8. Muchos servidores L2TP se construyen con componentes antiguos. Stacks comunes en Linux implican strongSwan/Libreswan + xl2tpd + pppd—cada uno con sus logs, temporizadores y modos de fallo.
9. ESP es el protocolo IP 50, no TCP/UDP. Firewalls que “permiten IPsec” pero olvidan el protocolo 50 crean situaciones muy específicas de funcionamiento parcial (o forzan NAT-T inesperadamente).

Guion rápido de diagnóstico (comprueba 1, 2, 3)

Si estás de guardia, no tienes tiempo para redescubrir redes. Aquí está el camino más rápido hacia el cuello de botella.

1) ¿Es enrutamiento o DNS?

• Prueba la conectividad IP pura (haz ping a una IP pública como 1.1.1.1 o a tu endpoint público corporativo).
• Prueba DNS por separado (resuelve un nombre usando los servidores DNS que crees tener).

Si IP funciona y DNS no: deja de tocar IPsec. Arregla la asignación de DNS o la alcanzabilidad.

2) ¿Sale el tráfico del cliente por el túnel?

• Inspecciona la tabla de rutas en el cliente. Busca una ruta por defecto vía la interfaz PPP/túnel (túnel completo) o rutas específicas (split tunnel).
• Revisa las métricas de las interfaces: “ruta correcta, prioridad equivocada” es un clásico.

3) ¿Regresa el tráfico?

• En el servidor, captura paquetes en la interfaz VPN y en el uplink. Si ves paquetes saliendo de los clientes pero no hay traducción de retorno, es NAT/firewall.
• Comprueba el reenvío IP y las reglas NAT/MASQUERADE.

4) ¿Muere solo con algunos sitios o transferencias grandes?

• Eso es MTU/fragmentación hasta que se demuestre lo contrario. Prueba con pings con “no fragmentar” y ajusta MSS.

5) ¿Es intermitente?

• Busca timeout de UDP/estado NAT, problemas de rekey, o múltiples clientes detrás del mismo NAT con IDs idénticos.

Los modos reales de fallo: enrutamiento, NAT, DNS, MTU, firewall y políticas

Modo de fallo A: El cliente nunca envía tráfico de internet al túnel (enrutamiento/métricas)

L2TP/IPsec se despliega a menudo como “túnel completo” (todo el tráfico va por la VPN), pero los clientes con frecuencia se configuran como split tunnel por accidente—o por una vieja “optimización” que nadie documentó.

Patrones comunes:

• La ruta por defecto aún apunta a la puerta de enlace local, no a PPP.
• Existe una ruta por defecto vía la VPN, pero tiene una métrica más alta que la local.
• Sólo subredes corporativas se enrutan al túnel; Internet se queda local. Los usuarios interpretan esto como “sin internet” porque el DNS corporativo fuerza resoluciones internas.

Decisión: determina si quieres split tunnel o túnel completo. Luego haz que la tabla de enrutamiento refleje esa intención.

Modo de fallo B: El tráfico entra al túnel pero muere en el servidor (faltan forwarding, NAT o firewall)

Esta es la causa más común de “conectado pero sin internet” en concentradores L2TP de Linux. La sesión PPP está arriba. El cliente tiene una IP. Los paquetes llegan. Luego el servidor se encoge de hombros y los descarta porque:

• net.ipv4.ip_forward está desactivado.
• No hay masquerade NAT para el pool de clientes VPN hacia el uplink.
• Reglas de firewall permiten IKE/ESP/L2TP pero bloquean tráfico reenviado.
• El filtrado de ruta inversa (rp_filter) descarta flujos asimétricos.

Decisión: decide si esta VPN es una ruta de salida a Internet. Si sí, debes reenviar y NATear. Si no, no finjas que lo es—empuja rutas de split-tunnel y corrige el DNS.

Modo de fallo C: DNS incorrecto (y todo “parece caído”)

La “internet” de la VPN a menudo es sólo DNS. El navegador necesita DNS para convertir nombres en IPs. Si PPP empuja servidores DNS que sólo son accesibles en una red interna que no enrutaste, obtendrás:

• Ping a 1.1.1.1 funciona.
• Ping a ejemplo.com falla.
• Apps que usan IPs codificadas funcionan; todo lo demás no.

Decisión: alinea el DNS con el enrutamiento. El túnel completo puede usar resolvers internos; el split tunnel debe usar resolvedores alcanzables (públicos o un reenviador DNS accesible vía las rutas del split).

Modo de fallo D: MTU y fragmentación (el clásico “algunos sitios cargan, otros no”)

L2TP + IPsec añade overhead. Luego NAT-T añade más. Luego PPP añade el suyo. Si tu path MTU es ajustado (común con PPPoE, LTE, Wi‑Fi de hotel, o middleboxes “útiles”), los paquetes grandes se quedan en un agujero negro.

Síntomas incluyen:

• SSH funciona, páginas web se cargan a medias, los handshakes TLS fallan intermitentemente.
• Pings pequeños tienen éxito; los más grandes fallan cuando DF está activado.
• Las pruebas de velocidad empiezan y luego se desploman.

Solución: ajusta (clamp) el TCP MSS en el servidor (y a veces en clientes) y/o establece MTU/MRU de PPP a un valor conservador (a menudo alrededor de 1400, pero verifica).

Modo de fallo E: Firewall y casos límite de NAT-T (UDP 4500, ESP y “estado”)

IPsec es sensible a firewalls que están “casi” configurados. Permitir UDP/500 y UDP/4500 pero no ESP (protocolo 50) puede forzar NAT-T o romper caminos sin NAT. Algunos entornos bloquean UDP/4500 completamente. Otros lo permiten pero eliminan mappings UDP inactivos a corto plazo, lo que provoca “se conecta, luego sin tráfico al cabo de unos minutos”.

Decisión: decide si requieres NAT-T y asegura keepalives/tiempos de rekey compatibles con los timeouts reales de NAT.

Modo de fallo F: Subredes solapadas (te enrutaste a un paradoja)

Si la LAN local del cliente usa la misma subred que la corporativa (ejemplo: ambas 192.168.1.0/24), el cliente enviará tráfico a la LAN local en vez del túnel. La VPN puede estar perfecta; la decisión de enrutamiento no.

Solución: evita rangos RFC1918 comunes para redes corporativas si puedes. Si no puedes, usa enrutamiento basado en políticas, asigna pools no solapados, o NATea el lado cliente de la VPN (último recurso, pero a veces lo único que funciona a escala).

Broma #2: Las subredes solapadas son como nombrar a dos compañeros “Chris” y luego culpar al sistema de correo cuando responde el equivocado.

Tareas prácticas con comandos: qué ejecutas, qué significa, qué decides

Abajo hay tareas probadas en campo que puedes ejecutar mientras ocurre el incidente. Los comandos son centrados en Linux en el lado servidor (strongSwan/xl2tpd/pppd), pero la lógica se traslada a otras plataformas.

Cada tarea incluye: comando, salida realista, qué significa y qué decisión tomas.

Task 1: Confirmar que existen SAs de IPsec (servidor)

cr0x@server:~$ sudo ipsec statusall
Status of IKE charon daemon (strongSwan 5.9.8, Linux 6.5.0, x86_64):
  uptime: 2 hours, since Dec 27 08:12:41 2025
  worker threads: 16 of 16 idle
Connections:
    l2tp-psk:  %any...%any  IKEv1
Security Associations (1 up, 0 connecting):
    l2tp-psk[3]: ESTABLISHED 6 minutes ago, 203.0.113.44[203.0.113.44]...198.51.100.10[198.51.100.10]
    l2tp-psk{7}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c2a3d8c4_i c8a1aa9b_o

Significado: IPsec está arriba. Si los usuarios aún no tienen internet, el problema probablemente sea PPP/enrutamiento/NAT/DNS/MTU, no la negociación IKE.

Decisión: Pasa a la verificación de la sesión PPP y al reenvío. No pierdas tiempo rotando PSKs “por si acaso”.

Task 2: Verificar que xl2tpd acepta sesiones (servidor)

cr0x@server:~$ sudo journalctl -u xl2tpd -n 30 --no-pager
Dec 27 10:01:12 server xl2tpd[1290]: Connection established to 203.0.113.44, 1701, LNS session 4087
Dec 27 10:01:12 server xl2tpd[1290]: Call established with 203.0.113.44, Local: 53291, Remote: 22714, Serial: 1
Dec 27 10:01:13 server pppd[24410]: pppd 2.4.9 started by root, uid 0
Dec 27 10:01:13 server pppd[24410]: peer from calling number 203.0.113.44 authorized
Dec 27 10:01:13 server pppd[24410]: local  IP address 10.10.50.1
Dec 27 10:01:13 server pppd[24410]: remote IP address 10.10.50.101
Dec 27 10:01:13 server pppd[24410]: primary   DNS address 10.10.0.53

Significado: PPP está arriba y un cliente obtuvo 10.10.50.101 con DNS 10.10.0.53. Bien. Ahora verifica rutas y alcanzabilidad hacia 10.10.0.53 (y hacia Internet) desde el servidor.

Decisión: Si el DNS es interno (10.10.0.53), asegúrate de que el cliente pueda enrutar hacia 10.10.0.0/16 vía la VPN o un túnel completo.

Task 3: Confirmar que existe la interfaz PPP y tiene direcciones (servidor)

cr0x@server:~$ ip -br addr show | egrep 'ppp|eth0|ens'
ens3             UP             198.51.100.10/24
ppp0             UP             10.10.50.1/32

Significado: ppp0 está arriba con /32 local. Eso es normal para PPP. Los clientes están en el otro lado con sus propios /32.

Decisión: Asegúrate de tener una ruta al pool de clientes vía interfaces ppp o que tus reglas de firewall coincidan con ppp+. Mucha gente escribe reglas para “10.10.50.0/24 vía ppp0” y luego se pregunta por qué es un caos.

Task 4: Comprobar el reenvío IP (servidor)

cr0x@server:~$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 0

Significado: El servidor no reenviará paquetes entre interfaces. Los clientes VPN se conectarán, pero no alcanzarán nada más allá del servidor.

Decisión: Actívalo de inmediato y de forma persistente si este host está pensado para enrutar.

Task 5: Habilitar el reenvío IP (servidor)

cr0x@server:~$ sudo sysctl -w net.ipv4.ip_forward=1
net.ipv4.ip_forward = 1

Significado: Reenvío activado ahora. Aún necesitas la corrección de firewall/NAT.

Decisión: Si esto lo arregla, hazlo persistente vía /etc/sysctl.d/*.conf y sigue leyendo: reenvío sin reglas de firewall es cómo se generan sorpresas.

Task 6: Comprobar NAT (MASQUERADE) para el pool de clientes VPN (servidor)

cr0x@server:~$ sudo iptables -t nat -S | egrep 'MASQUERADE|10\.10\.50'
-A POSTROUTING -s 10.10.50.0/24 -o ens3 -j MASQUERADE

Significado: Existe NAT de salida para el pool 10.10.50.0/24 hacia ens3 (uplink a Internet). Esa es la necesidad habitual para “la VPN da internet”.

Decisión: Si falta esa línea, añádela. Si está presente pero el tráfico sigue fallando, revisa las reglas de filtrado y rp_filter.

Task 7: Comprobar la política y contadores de FORWARD (servidor)

cr0x@server:~$ sudo iptables -S FORWARD
-P FORWARD DROP
-A FORWARD -i ppp+ -o ens3 -j ACCEPT
-A FORWARD -i ens3 -o ppp+ -m state --state ESTABLISHED,RELATED -j ACCEPT

Significado: Política por defecto FORWARD DROP (buena práctica). Se permite ppp-to-internet y tráfico de retorno. También bueno.

Decisión: Si tienes DROP sin estos accept, añádelos. Si existen pero aún no hay tráfico, verifica que los nombres de interfaz coincidan con la realidad (ppp+ ayuda) y que nftables no esté realmente en control.

Task 8: Identificar si nftables es el firewall real (servidor)

cr0x@server:~$ sudo nft list ruleset | head -n 25
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    iif "lo" accept
    ct state established,related accept
    udp dport {500, 4500, 1701} accept
  }
  chain forward {
    type filter hook forward priority 0; policy drop;
    iifname "ppp0" oifname "ens3" accept
    iifname "ens3" oifname "ppp0" ct state established,related accept
  }
}

Significado: nftables está activo y tiene reglas específicas para ppp0 sólo. Si los clientes caen en ppp1/ppp2, el reenvío podría fallar.

Decisión: Reemplaza las coincidencias ppp0 por un estilo comodín (iifname «ppp+») o usa sets. Si no, el primer cliente funciona y el segundo te llama a las 2 a.m.

Task 9: Validar que el servidor puede alcanzar Internet (servidor)

cr0x@server:~$ ping -c 2 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=12.4 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=12.1 ms

--- 1.1.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms

Significado: El concentrador tiene conectividad básica. Si los clientes no la tienen, no es “Internet caído”.

Decisión: Centra el foco en reenvío/NAT/selección de rutas para el tráfico de clientes.

Task 10: Observar si los paquetes del cliente atraviesan el servidor (tcpdump)

cr0x@server:~$ sudo tcpdump -ni ppp0 icmp or udp port 53
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ppp0, link-type PPP, snapshot length 262144 bytes
10:04:21.112233 IP 10.10.50.101 > 1.1.1.1: ICMP echo request, id 4112, seq 1, length 64
10:04:22.114455 IP 10.10.50.101 > 1.1.1.1: ICMP echo request, id 4112, seq 2, length 64

Significado: El cliente envía tráfico a través del túnel hacia el servidor. Si no ves respuestas, el problema es la ruta de retorno: NAT, firewall o enrutamiento ascendente.

Decisión: Captura en ens3 para ver si las solicitudes salen y si las respuestas regresan.

Task 11: Confirmar que ocurre la traducción NAT (servidor, captura en uplink)

cr0x@server:~$ sudo tcpdump -ni ens3 icmp and host 1.1.1.1
listening on ens3, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:04:21.112900 IP 198.51.100.10 > 1.1.1.1: ICMP echo request, id 4112, seq 1, length 64
10:04:21.125001 IP 1.1.1.1 > 198.51.100.10: ICMP echo reply, id 4112, seq 1, length 64

Significado: NAT funciona: la fuente del paquete es la IP pública del servidor (198.51.100.10), y las respuestas regresan. Si los clientes aún no las reciben, tu cadena FORWARD de retorno hacia PPP puede estar bloqueando, o rp_filter está eliminando paquetes.

Decisión: Revisa reglas de FORWARD y rp_filter, luego comprueba si las respuestas llegan a ppp0.

Task 12: Comprobar el filtrado de ruta inversa (rp_filter) (servidor)

cr0x@server:~$ sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.ens3.rp_filter net.ipv4.conf.ppp0.rp_filter
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.ens3.rp_filter = 1
net.ipv4.conf.ppp0.rp_filter = 1

Significado: rp_filter estricto puede eliminar paquetes cuando el kernel considera que la ruta de retorno es “incorrecta”, lo que sucede con túneles, NAT, enrutamiento por políticas o enrutamiento asimétrico.

Decisión: Ajusta rp_filter a 0 (off) o 2 (loose) en las interfaces relevantes. Para concentradores VPN, el modo loose suele ser el compromiso sensato.

Task 13: Probar resolución DNS vía el servidor DNS empujado (comprobación servidor)

cr0x@server:~$ dig @10.10.0.53 example.com +short
93.184.216.34

Significado: El resolvedor interno responde. Eso no prueba que el cliente pueda alcanzarlo, pero elimina una variable.

Decisión: Si DNS resuelve aquí pero no para clientes, es enrutamiento/firewall entre el pool VPN y la red DNS, o el cliente no está usando realmente ese DNS.

Task 14: Comprobar que PPP empuja el DNS y rutas planeadas (configuración servidor)

cr0x@server:~$ sudo sed -n '1,120p' /etc/ppp/options.xl2tpd
ipcp-accept-local
ipcp-accept-remote
ms-dns 10.10.0.53
ms-dns 10.10.0.54
noccp
auth
mtu 1400
mru 1400
proxyarp

Significado: Se empuja DNS y se establece MTU. Si los usuarios reportan “algunos sitios cargan”, el MTU aquí es una buena señal. Si MTU está por defecto (a menudo 1500), puede que necesites ajustarlo.

Decisión: Si no controlas MTU/MRU aquí, planea añadirlo y clamp MSS en el firewall.

Task 15: Detectar agujero MTU con ping DF (desde el servidor hacia la ruta del cliente)

cr0x@server:~$ ping -M do -s 1472 -c 2 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1472(1500) bytes of data.
ping: local error: message too long, mtu=1476
ping: local error: message too long, mtu=1476

--- 1.1.1.1 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1024ms

Significado: Path MTU está por debajo de 1500 (aquí sugiere ~1476 en este salto), y si mensajes ICMP de fragmentación necesarios están bloqueados en algún punto, los clientes experimentarán fallos “aleatorios”.

Decisión: Ajusta MSS (por ejemplo, a un rango 1360–1410 dependiendo del overhead) y/o reduce MTU/MRU de PPP. Verifica con pruebas iterativas.

Task 16: Aplicar clamp de TCP MSS para tráfico VPN reenviado (servidor)

cr0x@server:~$ sudo iptables -t mangle -A FORWARD -i ppp+ -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
cr0x@server:~$ sudo iptables -t mangle -S FORWARD | tail -n 2
-A FORWARD -i ppp+ -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Significado: Los paquetes SYN negociarán un MSS que quepa en el path MTU real, reduciendo los problemas de fragmentación.

Decisión: Si esto mejora la fiabilidad web/TLS de inmediato, mantenlo y hazlo persistente. Aún valida que PMTUD (ICMP) no esté siendo bloqueado aguas arriba.

Task 17: Verificar que existen rutas del pool de clientes (enrutamiento servidor)

cr0x@server:~$ ip route show | egrep '10\.10\.50|default'
default via 198.51.100.1 dev ens3
10.10.50.101 dev ppp0 scope link

Significado: Para PPP, las rutas suelen ser rutas /32 por cliente. Si esperabas un /24, esa expectativa es el bug, no el kernel.

Decisión: Asegura que las reglas de firewall y monitorización entiendan esto. Usa coincidencias ppp+ en lugar de confiar en una ruta de subred ordenada.

Task 18: Confirmar que UDP/4500 y ESP están permitidos en el perímetro (servidor)

cr0x@server:~$ sudo iptables -S INPUT | egrep 'udp.*(500|4500|1701)|esp'
-A INPUT -p udp -m udp --dport 500 -j ACCEPT
-A INPUT -p udp -m udp --dport 4500 -j ACCEPT
-A INPUT -p udp -m udp --dport 1701 -j ACCEPT
-A INPUT -p esp -j ACCEPT

Significado: Los puertos comunes y ESP están permitidos. Si falta ESP y no se usa NAT-T, tendrás “conexiones intermitentes” dependiendo de condiciones NAT del cliente.

Decisión: Permite ESP cuando sea factible. Si no puedes, aplica NAT-T y asegura que 4500 sea fiable end-to-end.

Tres micro-historias corporativas desde el campo

Micro-historia 1: El incidente causado por una suposición errónea

La empresa tenía un concentrador L2TP/IPsec legado que “siempre funcionaba”. Una pequeña migración lo movió de un host VM a otro. Misma IP. Mismas reglas de firewall. Mismos archivos de configuración. La solicitud de cambio fue aburrida, lo cual suele ser buena señal.

El lunes por la mañana, el helpdesk vio una avalancha: la VPN se conecta, pero “internet está muerto”. Gente podía alcanzar algunos servicios internos pero no otros, y la mayoría de sitios externos eran inalcanzables. El equipo de redes culpó de inmediato al ISP ascendente porque eso es lo que todo el mundo culpa cuando el navegador gira.

La suposición equivocada: “Si el túnel está arriba, el enrutamiento es correcto.” En realidad, la red del nuevo hypervisor usaba un nombre de interfaz diferente (ens192 en vez de ens3). Las reglas NAT aún referenciaban el dispositivo antiguo. Los paquetes entraban por ppp0, llegaban a POSTROUTING y… nada coincidía. Sin masquerade. Sin internet.

Se puso peor: unos cuantos ingenieros podían alcanzar servicios internos porque las rutas de split tunnel seguían funcionando para subredes internas, así que los síntomas parecían inconsistentes. Esa inconsistencia hizo perder horas. Buscaron una red inestable cuando el problema era una descoincidencia determinista.

La solución fue brutalmente simple: cambiar la regla NAT para que coincida con el nombre real del uplink (o, mejor, matchear por tabla de enrutamiento / usar sets en nftables). Luego añadieron una verificación en el arranque que afirma “si ppp+ existe, la regla NAT debe existir.” La lección quedó: nunca bases comportamiento crítico de enrutamiento/NAT en un nombre de interfaz que no controlas.

Micro-historia 2: La optimización que salió mal

Una revisión de seguridad señaló que los usuarios VPN estaban haciendo hairpin del tráfico de internet por el centro de datos. Alguien propuso split tunneling como optimización: “Solo enrutar subredes corporativas por la VPN; dejar todo lo demás local. Menos carga, mejor rendimiento.” En teoría, correcto. En producción, comedia.

Empujaron rutas de split tunnel sin alinear el DNS. PPP siguió empujando resolvers DNS internos porque “siempre lo hicimos así”. Ahora laptops remotas resolvían dominios públicos vía resolvers internos alcanzables solo por la VPN, pero las consultas iban por el túnel mientras las respuestas volvían por la interfaz local—o no volvían por completo debido a firewalls stateful y enrutamiento asimétrico en el lado del cliente.

El síntoma fue ruidoso: “La VPN se conecta, no hay internet.” La realidad era más estrecha: fallo de resolución de nombres, acceso interno intermitente y algunas apps (IPs fijas) seguían funcionando. Los usuarios no reportan “fallo de DNS”; reportan “nada funciona”. Justo.

Lo “arreglaron” temporalmente pidiendo a los usuarios que pongan DNS públicos. Eso creó otro problema: nombres internos dejaron de resolverse y seguridad no estuvo contenta por filtrar consultas internas. Finalmente hicieron lo correcto y aburrido: proveer un forwarder DNS accesible por la VPN que responda zonas internas y recurra para externo, y asegurar que las consultas DNS sigan la misma política de enrutamiento que el resto del tráfico.

La optimización está bien. Pero el split tunneling es un cambio de política de enrutamiento, no una mejora de CPU. Trátalo con la misma precaución que cambiar niveles de aislamiento de bases de datos: descubrirás los casos límite de la peor manera.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Otra organización ejecutaba L2TP/IPsec para una flota de laptops industriales. No glamoroso. Pero el equipo SRE tenía la costumbre: cada cambio en la VPN requería una prueba de humo automatizada desde un runner externo. Esta prueba hacía: conectar, verificar IP asignada, ping a IP pública, resolver un nombre, obtener una pequeña página HTTPS y descargar un archivo más grande para probar MTU/MSS.

Un viernes rutinario, una limpieza de política de firewall eliminó “reglas heredadas raras”. La siguiente pipeline de despliegue ejecutó la prueba de humo y falló en “obtener página HTTPS”. El ping funcionaba. DNS funcionaba. HTTP a veces funcionaba. HTTPS fallaba. Aquí es donde la mayoría de equipos empiezan a reiniciar cosas al azar. Ellos no.

El script incluía una sonda MTU y marcó fallo de fragmentación. La limpieza del firewall también había eliminado el permiso ICMP “fragmentation-needed” y una regla de clamp de MSS. Sin clamp MSS, paquetes TLS quedaban en agujeros negros en ciertos caminos. La prueba lo detectó antes que los humanos.

Rollback inmediato. Reintrodujeron una regla controlada de MSS clamp, documentaron por qué existía y añadieron una prueba de firewall: “los clientes VPN deben completar handshake TLS a un endpoint público.” Aburrido. Correcto. Salvó el fin de semana.

Errores comunes: síntoma → causa raíz → solución

Esta sección es opinada porque la producción necesita opiniones. Estos son los patrones que generan tickets de “conectado pero sin internet”.

1) Síntoma: “Conectado” pero no puedo hacer ping a ninguna IP (ni siquiera 1.1.1.1)

• Causa raíz: El tráfico del cliente no se enruta al túnel; o la sesión PPP no está realmente pasando datos; o el servidor descarta el reenvío.
• Solución: En el cliente, verifica la ruta por defecto y las métricas de interfaz. En el servidor, habilita IP forwarding y permite tráfico FORWARD de ppp+ hacia el uplink, con NAT si se pretende salida a Internet.

2) Síntoma: Puedo hacer ping a IPs públicas pero las webs no cargan

• Causa raíz: Mala configuración de DNS (resolvedores inalcanzables o cliente sin usar el DNS empujado).
• Solución: Empuja DNS alcanzables vía opciones PPP (ms-dns). Asegura que el enrutamiento permita acceso a esos resolvers. Para split tunnel, usa un forwarder DNS accesible por el túnel.

3) Síntoma: Solo algunos sitios cargan; HTTPS es inestable; descargas grandes fallan

• Causa raíz: Agujero MTU o problemas de fragmentación por overhead de L2TP/IPsec y bloqueo de ICMP.
• Solución: Clamp del MSS TCP en el servidor para tráfico VPN reenviado. Ajusta PPP MTU/MRU (p. ej. 1400) y retesta. Permite los tipos ICMP necesarios si controlas los firewalls.

4) Síntoma: Recursos internos funcionan; internet no

• Causa raíz: Split tunnel por diseño o por accidente; falta NAT para salida a Internet; o la política prohíbe Internet por la VPN.
• Solución: Decide la política. Si se requiere túnel completo, empuja la ruta por defecto (ajuste en el cliente) y configura NAT/reenvío. Si se desea split tunnel, empuja sólo rutas internas y provee DNS sensato.

5) Síntoma: Internet funciona, pero sólo para el primer cliente conectado

• Causa raíz: Reglas de firewall que coinciden con una única interfaz (ppp0) en lugar de todas las interfaces PPP (ppp+), o NAT atado a una interfaz específica que cambia.
• Solución: Usa comodines ppp+ (iptables) o patrones iifname/oifname / sets (nftables). Evita suposiciones frágiles sobre nombres de interfaz.

6) Síntoma: Conexión exitosa en algunas redes pero no en otras (Wi‑Fi de hotel, LTE)

• Causa raíz: UDP 4500 bloqueado o con timeouts agresivos; problemas NAT-T; dispositivos intermedios que manglean ESP/UDP.
• Solución: Asegura que NAT-T esté habilitado y configura keepalives. Si UDP es poco fiable, considera migrar de L2TP/IPsec a IKEv2 o VPNs basadas en TLS cuando sea posible.

7) Síntoma: “Conectado” pero no puedo acceder a subred corporativa que se solapa con la subred doméstica

• Causa raíz: Espacio de direcciones RFC1918 solapado; las rutas del cliente prefieren la LAN local.
• Solución: Cambia el direccionamiento corporativo (mejor), o NATea subredes clientes en el concentrador VPN, o usa enrutamiento por políticas por cliente. Como mínimo, evita usar 192.168.0.0/24 o 192.168.1.0/24 para recursos que esperas que clientes remotos accedan.

8) Síntoma: Ayer funcionó; hoy se conecta pero sin tráfico después de un cambio en el firewall

• Causa raíz: Se permitieron puertos IKE/L2TP pero se bloqueó reenvío, DNS, ICMP fragmentation-needed o tráfico de retorno estado.
• Solución: Audita reglas para: UDP/500, UDP/4500, UDP/1701 (según necesidad), ESP, además de FORWARD y NAT. Restaura clamp MSS y ICMP requerido si aparecen problemas MTU.

Listas de verificación / plan paso a paso

Checklist 1: Decide la política (túnel completo vs split tunnel)

• Túnel completo: La ruta por defecto del cliente va por la VPN. Debes NATear y reenviar en el servidor. DNS puede ser interno.
• Split tunnel: Solo prefijos corporativos van por la VPN. Debes empujar esas rutas. El DNS no debe crear dependencia en resolvers internos inalcanzables (usa un forwarder accesible por el túnel).

Si no tomas esta decisión explícitamente, tu sistema la tomará implícitamente, y elegirá el caos.

Checklist 2: Esenciales del lado servidor (concentrador Linux L2TP/IPsec)

1. IPsec SAs establecidas (strongSwan/libreswan muestra INSTALLED).
2. xl2tpd ve sesiones; pppd autentica; asigna IPs a clientes; empuja DNS si se desea.
3. net.ipv4.ip_forward=1.
4. NAT masquerade para el pool de clientes hacia el uplink (si túnel completo/salida a Internet).
5. Firewall FORWARD permite ppp+ hacia uplink y retorno ESTABLISHED.
6. Clamp MSS para SYN TCP reenviados, o MTU/MRU conservador en PPP.
7. rp_filter en modo loose/off donde sea necesario.
8. Logs: strongSwan, xl2tpd, pppd todos recogidos y buscables.

Checklist 3: Esenciales del lado cliente (genérico)

1. Confirma que obtuviste una IP en la interfaz VPN y una configuración DNS que entiendes.
2. Revisa la tabla de rutas: ¿tienes ruta por defecto vía VPN (túnel completo) o rutas específicas (split tunnel)?
3. Prueba: ping a IP pública, resuelve un nombre, curl a endpoint HTTPS.
4. Si solo falla HTTPS: sospecha MTU/MSS y agujeros de fragmentación.
5. Si los recursos corporativos fallan desde casa: sospecha subredes solapadas.

Plan de recuperación paso a paso durante un outage

1. Confirma alcance. Un usuario vs todos; redes específicas vs todas; OS de cliente específico vs todos.
2. Demuestra que IPsec está arriba. Si IPsec no está arriba, arregla IKE/PSK/certs/puertos primero. Si está arriba, deja de culpar IKE.
3. Demuestra que PPP está arriba. Busca IP asignada y DNS en logs de pppd.
4. Demuestra intención de enrutamiento. ¿Túnel completo o split tunnel? Verifica que rutas del cliente coincidan con la política.
5. Demuestra reenvío/NAT en el servidor. tcpdump en ppp+ y uplink; verifica MASQUERADE y reglas FORWARD.
6. Demuestra DNS. Resuelve vía el servidor DNS que empujas; confirma alcanzabilidad a través de las rutas.
7. Demuestra MTU. Si los síntomas son “algunos sitios”, habilita clamp MSS y ajusta MTU/MRU de PPP.
8. Estabiliza. Haz persistentes los cambios, añade monitorización y documenta lo que cambiaste y por qué.

Principio operativo (una cita)

“La esperanza no es una estrategia.” — idea parafraseada atribuida a líderes de operaciones y fiabilidad

Traducción: si tu VPN funciona solo cuando “la red está amable”, no funciona. Hazla determinista.

Preguntas frecuentes

1) ¿Por qué L2TP/IPsec dice “conectado” cuando nada funciona?

Porque “conectado” a menudo significa que IKE tuvo éxito y las SAs están instaladas. La usabilidad real depende de PPP, enrutamiento, NAT, firewall, DNS y MTU. Capas diferentes pueden tener éxito independientemente.

2) ¿Suele ser un problema del cliente o del servidor?

La mayoría de las veces es del lado servidor: reenvío/NAT/firewall, o un desfase de políticas (split vs túnel completo). Los siguientes más comunes son métricas de enrutamiento del cliente y selección de DNS.

3) Si recursos internos funcionan pero Internet no, ¿cuál es la causa más probable?

O bien el split tunnel está activo (por diseño o accidente), o falta masquerade NAT para el pool de clientes VPN. Decide si la VPN debe proporcionar salida a Internet. Luego impleméntalo explícitamente.

4) Si ping a 1.1.1.1 funciona pero las webs no, ¿qué hago primero?

Revisa DNS. Verifica qué resolvers usa el cliente y si esos resolvers son alcanzables vía las rutas VPN. Los problemas de DNS son la ilusión de “está caído” más rápida en el negocio.

5) ¿Qué MTU debo usar para L2TP/IPsec?

No hay un valor universal, pero 1400 es un punto de partida común para MTU/MRU de PPP en L2TP/IPsec con NAT-T. Mejor: clamp MSS al PMTU y valida con pings DF y transferencias HTTPS reales.

6) ¿Necesito permitir UDP/1701 por el firewall?

Para L2TP/IPsec, UDP/1701 se usa para control/datos L2TP y normalmente está protegido por IPsec. Prácticamente, a menudo se permite UDP/1701 al servidor VPN, además de UDP/500, UDP/4500 y ESP. Tu conjunto exacto de reglas depende del modo IPsec y si se usa NAT-T.

7) ¿Y los clientes detrás del mismo NAT? ¿Puede eso romper cosas?

Sí. Múltiples clientes detrás de un mismo NAT pueden provocar casos límite de NAT-T, especialmente con IKEv1 e identificadores idénticos. Asegura que tu configuración IPsec soporte múltiples peers y use IDs/usuarios únicos, y ajusta keepalives para que los mappings UDP no caduquen.

8) ¿Pueden las subredes solapadas realmente causar “sin internet”?

Sí, indirectamente. Si DNS o proxies enrutan a través de una subred corporativa que se solapa con una LAN doméstica, el cliente envía tráfico localmente y falla. Los usuarios interpretan eso como “internet caído” porque navegadores y apps dependen de esos servicios internos.

9) ¿Deberíamos seguir usando L2TP/IPsec?

Si necesitas máxima compatibilidad con clientes integrados, lo seguirás viendo. Si puedes elegir, prefiere IKEv2 o una VPN moderna basada en TLS que se comporte mejor a través de NAT y tenga herramientas cliente más limpias. Pero si estás atascado con L2TP/IPsec, aún puedes volverla fiable—siendo explícito sobre enrutamiento, DNS y MTU.

10) ¿Cuál es la comprobación de monitorización más efectiva para esto?

Ejecuta una prueba sintética externa que establezca una sesión VPN y luego haga: ping a IP pública, lookup DNS y GET HTTPS de una página pequeña más una descarga mayor. Eso detecta regresiones de enrutamiento, DNS y MTU rápidamente.

Siguientes pasos (qué cambiar para no seguir reviviendo esto)

Arreglar el incidente de hoy está bien. Prevenir el próximo es mejor y, sinceramente, menos agotador.

1. Escribe tu intención. Túnel completo o split tunnel. Qué DNS. Qué pool de clientes. Qué subredes. Hazlo un runbook de una página que refleje la realidad.
2. Haz el reenvío/NAT determinista. Habilita ip_forward persistentemente, usa comodines de interfaz o coincidencia basada en enrutamiento, y guarda reglas de firewall en control de versiones.
3. Estandariza el manejo de MTU. Añade clamp MSS para tráfico reenviado y fija MTU/MRU de PPP intencionalmente. Trata el fallo de PMTUD como riesgo conocido.
4. Deja de depurar por el estado de la UI. Monitoriza SAs de IPsec, sesiones PPP y pruebas de plano de datos end-to-end por separado.
5. Añade una prueba de humo. Un script desde fuera de tu red que valide la conectividad como la experimentan los usuarios. Ejecútalo después de cada cambio.
6. Planifica una migración. Si L2TP/IPsec es un ancla heredada, define un camino hacia IKEv2 u otra solución moderna. No porque sea tendencia, sino porque la simplicidad operativa es una característica.

Si haces solo una cosa: añade capturas de paquetes y una prueba sintética VPN a tu flujo de trabajo de incidentes. “Conectado pero sin internet” deja de ser un misterio y se vuelve un elemento de la lista.