Registros VPN que importan: encontrar causas de «no conecta» en MikroTik/Linux

octubre 29, 2025 • febrero 3, 2026 • Lectura: 25 min • Views: 8

¿Te fue útil?

“La VPN no conecta” no es un síntoma. Es una queja. Y la diferencia importa, porque las quejas se escalan; los síntomas se diagnostican.

Cuando el portátil del CEO no conecta desde un Wi‑Fi de hotel que bloquea gran parte de Internet, no necesitas corazonadas. Necesitas los registros adecuados, los comandos correctos y una forma rápida de decidir si se trata de autenticación, enrutamiento, desajuste de criptografía, NAT, MTU o simplemente un bloqueo de firewall.

Tabla de contenidos

Qué registros importan realmente (y por qué la mayoría no lo hace)
Playbook de diagnóstico rápido (primeras/segundas/terceras comprobaciones)
Construir un modelo mental: dónde vive la verdad
MikroTik: registros que capturan fallos sin ahogarte
Linux: journalctl, kernel y registros de demonio VPN que valen
Tareas prácticas (comandos + salidas + decisiones)
Patrones de logs que mapean a causas raíz reales
Errores comunes: síntoma → causa raíz → arreglo
Listas de verificación / plan paso a paso (flujo de trabajo en producción)
Tres mini-historias del mundo corporativo (realistas, anonimizadas)
Datos interesantes & breve historia (cosas que explican los dolores actuales)
Preguntas frecuentes
Conclusión: próximos pasos que reducen las repeticiones

Qué registros importan realmente (y por qué la mayoría no lo hace)

El diagnóstico de VPN es un juego de latencia: cuanto más tiempo pases mirando ruido de registro irrelevante, más tiempo estarán tus usuarios desconectados. Tu objetivo es recopilar suficiente evidencia para elegir la rama correcta: auth vs crypto vs ruta de red vs política/enrutamiento.

Sólo hay unas pocas categorías de registros que consistentemente responden “¿por qué no conecta?”

Registros de handshake: negociaciones IKE/IPsec, handshakes TLS, handshakes de WireGuard. Te dicen “no pudimos ponernos de acuerdo” o “nunca alcanzamos al peer”.
Registros de autenticación/autorizar: fallos de usuario/contraseña, validación de certificados, decisiones EAP, respuestas RADIUS. Te dicen “llegamos, pero dijo que no”.
Registros de firewall/NAT: drops y traducciones alrededor de UDP 500/4500, ESP, TCP 443/1194, etc. Te dicen “los paquetes murieron aquí”.
Registros de enrutamiento y políticas: qué rutas se instalaron, qué selectores coincidieron, qué políticas se aplicaron. Te dicen “conectado, pero inútil”.
Registros del kernel/controlador: problemas de MTU, fragmentación, comportamientos extraños de offload, flaps de interfaz. Te dicen “la física no está de acuerdo con tu configuración”.

Lo que no importa tanto como la gente piensa: ruido aleatorio de PPP “conectado/desconectado” sin contexto, “peer no responde” genérico sin correlación de captura de paquetes, o mega-debug recogido después del hecho sin timestamps alineados entre sistemas. Tu primer movimiento debe ser sincronizar el tiempo y luego filtrar al minuto del fallo.

Una heurística confiable: cuando una VPN “no conecta”, la causa suele ser visible en uno de estos lugares:

registros del demonio VPN del cliente (qué intentó)
registros del demonio VPN del servidor (qué rechazó o nunca vio)
registros del borde de la red (qué fue bloqueado o deformado)

Consigue esas tres vistas, alinea las marcas de tiempo, y la historia se escribe sola.

Playbook de diagnóstico rápido (primeras/segundas/terceras comprobaciones)

Primero: confirmar la ruta (¿llega algo a algo?)

En MikroTik: busca drops de firewall en los puertos/protocolos VPN y por intentos de iniciación IKE.
En Linux: busca paquetes entrantes en la interfaz esperada, y luego comprueba si el demonio VPN registró un nuevo intento de handshake.

Decisión: si no ves tráfico en el servidor/router durante la ventana de intento, no estás depurando crypto. Estás depurando conectividad (enrutamiento, firewall, ISP, política del Wi‑Fi del hotel).

Segundo: clasificar la falla (auth vs negociación vs política)

Fallas de autenticación: “AUTH_FAILED”, “no shared key found”, “EAP failure”, “bad username or password”, “certificate verify failed”.
Fallas de negociación: “no proposal chosen”, “invalid KE payload”, “TS_UNACCEPTABLE”, “encryption algorithm not supported”.
Fallas de política/enrutamiento: túnel arriba pero sin rutas, selectores erróneos, tráfico que no coincide con la política, ajustes de split-tunnel incorrectos.

Decisión: elige la corrección más pequeña posible: una sola cadena de identidad, un solo conjunto de cifrado, un solo selector de subred, una regla de firewall.

Tercero: eliminar los asesinos silenciosos (tiempo, MTU, NAT-T)

Tiempo: la validación de certificados y las lifetimes de IKE se desmoronan cuando los relojes divergen.
MTU: “conecta” pero se queda; la web puede funcionar pero SMB falla; los paquetes grandes desaparecen.
Traversal NAT: UDP 500 funciona hasta que aparece el NAT; UDP 4500 bloqueado; ESP dañado.

Decisión: si los síntomas son inconsistentes entre redes (en casa funciona, en hotel falla), sospecha MTU/NAT/puertos bloqueados antes de reescribir la VPN.

Idea parafraseada (atribuida): “La esperanza no es una estrategia.” — Edsger W. Dijkstra (idea parafraseada)

Construir un modelo mental: dónde vive la verdad

El diagnóstico de VPN falla cuando tratas los registros como un álbum de recortes. Trátalos como un rastro de transacción distribuido: cada componente registra una vista parcial, y la superposición es donde emerge la causalidad.

Para una configuración típica de acceso remoto (cliente ↔ internet ↔ MikroTik ↔ endpoint VPN Linux o servicios), tus fuentes de datos son:

Registros del cliente: te dicen qué ofreció el cliente, qué esperaba y qué consideró fatal.
Registros de MikroTik: te dicen sobre IKE, L2TP/PPP, decisiones de firewall y comportamiento de NAT en el borde.
Registros del demonio VPN en Linux: strongSwan, OpenVPN, herramientas de WireGuard; te dicen razones a nivel de protocolo.
Kernel de Linux + netfilter: paquetes descartados, rarezas de conntrack/NAT, pistas de MTU/fragmentación.
Registros AAA: decisiones de RADIUS/LDAP o base de usuarios local.

La alineación de relojes importa más de lo que crees. Si MikroTik tiene 90 segundos de diferencia y tu host Linux está disciplinado por NTP, “probarás” la cosa equivocada. Arregla el tiempo primero y luego persigue fantasmas.

MikroTik: registros que capturan fallos sin ahogarte

MikroTik puede ser maravillosamente directo. Te dirá “no proposal chosen” y puedes irte a casa temprano. O dirá “peer not responding” y perderás dos horas a menos que correlaciones con contadores de firewall y flujo de paquetes.

Qué habilitar (y qué mantener apagado)

Habilita registros que capturen:

ipsec detalles de negociación al nivel info (y temporalmente en debug para una sola fuente)
l2tp, ppp para autenticación y establecimiento de sesión (si usas piezas L2TP/PPTP/PPPoE)
firewall para drops en las cadenas relevantes (limitado, con rate-limit y dirigido)

Evita dejar debug completo encendido permanentemente. Los logs de debug son como la cafeína: útiles en un apuro, luego te preguntas por qué el corazón te late y el almacenamiento está lleno.

Cómo se ve “bien” en los registros de MikroTik

Para IPsec/IKEv2, “bien” suele incluir:

peer inicia
propuesta aceptada
SA establecida
políticas instaladas

Para L2TP/IPsec, quieres ver:

IPsec establecido primero
luego el canal de control L2TP se levanta
luego la autenticación PPP tiene éxito

Si solo ves la primera mitad, sabes dónde apuntar.

Linux: journalctl, kernel, y registros de demonio VPN que valen

Linux te da más visibilidad de la que mereces. El truco no es recolectar registros; es hacer preguntas estrechas.

Fuentes de registro que importan

systemd journal vía journalctl (la mayoría de distros)
/var/log/auth.log o /var/log/secure (PAM, SSH, algunos hooks de autenticación VPN)
Registros strongSwan (demonio charon)
Registros OpenVPN (salida de la unidad del servicio o archivo de log)
Kernel para xfrm/IPsec, WireGuard, drops de netfilter

Cuando sea posible, enruta los logs de servicio a journald y usa filtrado estructurado por unidad. Hacer grep en archivos planos funciona, pero es 2025; podemos hacerlo mejor.

Tareas prácticas (comandos + salidas + decisiones)

Estas son las tareas que realmente ejecuto cuando una VPN no conecta. Cada una incluye un comando, cómo suele verse la salida y la decisión que tomas a partir de ella.

Tarea 1: Confirmar alineación de tiempo del sistema (Linux)

cr0x@server:~$ timedatectl
               Local time: Sun 2025-12-28 15:40:11 UTC
           Universal time: Sun 2025-12-28 15:40:11 UTC
                 RTC time: Sun 2025-12-28 15:40:11
                Time zone: UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Significado: “System clock synchronized: yes” es lo que quieres. Las VPN basadas en certificados fallarán de formas tontas si el tiempo está mal.

Decisión: Si no está sincronizado, arregla NTP antes de depurar la VPN. De lo contrario, malinterpretarás errores de certificado y ventanas de replay.

Tarea 2: Comprobar si los paquetes llegan al servidor Linux durante un intento

cr0x@server:~$ sudo tcpdump -ni eth0 'udp port 500 or udp port 4500 or proto 50' -c 10
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
15:41:02.101234 IP 198.51.100.23.55231 > 203.0.113.10.500: isakmp: phase 1 I ident
15:41:02.105991 IP 203.0.113.10.500 > 198.51.100.23.55231: isakmp: phase 1 R ident
15:41:03.220110 IP 198.51.100.23.55231 > 203.0.113.10.4500: UDP-encap: ESP(spi=0xcafebabe,seq=0x1)

Significado: Tienes alcanzabilidad y actividad NAT-T. Si esto está silencioso, el problema está corriente arriba: firewall, enrutamiento, ISP, o el cliente nunca envió.

Decisión: Si no llegan paquetes, deja de ajustar cifrados. Empieza a revisar ACLs, NAT y si el cliente está apuntando a la IP correcta.

Tarea 3: Registros strongSwan IKEv2 para clasificar fallos de handshake

cr0x@server:~$ sudo journalctl -u strongswan --since "15:40" --no-pager
Dec 28 15:41:02 server charon[1123]: 09[IKE] received IKE_SA_INIT request from 198.51.100.23[55231]
Dec 28 15:41:02 server charon[1123]: 09[IKE] no proposal chosen
Dec 28 15:41:02 server charon[1123]: 09[IKE] sending NO_PROPOSAL_CHOSEN notify to 198.51.100.23[55231]

Significado: Desajuste criptográfico. El peer ofreció algoritmos que no aceptaste (o viceversa).

Decisión: Alinea las propuestas. No “abras todo” permanentemente; añade el conjunto mínimo compatible y programa una limpieza.

Tarea 4: strongSwan “authentication failed” vs “not found”

cr0x@server:~$ sudo journalctl -u strongswan --since "15:40" --no-pager | tail -n 6
Dec 28 15:41:22 server charon[1123]: 11[IKE] authentication of 'vpnuser' with EAP failed
Dec 28 15:41:22 server charon[1123]: 11[IKE] sending AUTHENTICATION_FAILED notify
Dec 28 15:41:22 server charon[1123]: 11[IKE] IKE_SA closed

Significado: La ruta de red está bien; las credenciales o la integración AAA no lo están.

Decisión: Deja de mirar reglas de firewall. Revisa RADIUS/LDAP, secretos de usuario y compatibilidad del método EAP.

Tarea 5: Estado de handshake de WireGuard (Linux)

cr0x@server:~$ sudo wg show
interface: wg0
  public key: 7E8sN8ZQk0yqJfYHk2m2pX1G4vQn4w2XhQ0v0n0n0n0=
  listening port: 51820

peer: GkYp9q3yR1l4tD0Nw7xqzK9uJm9c0q0H0e0o0r0e0r0=
  endpoint: 198.51.100.23:60211
  allowed ips: 10.66.66.2/32
  latest handshake: 2 minutes, 11 seconds ago
  transfer: 18.32 MiB received, 22.10 MiB sent
  persistent keepalive: every 25 seconds

Significado: Si “latest handshake” es “never”, estás tratando con alcanzabilidad, bloqueos de puerto o claves incompatibles.

Decisión: Si existe handshake pero no fluye tráfico, céntrate en AllowedIPs, enrutamiento y firewall. Si no hay handshake, céntrate en la alcanzabilidad UDP y las claves correctas.

Tarea 6: Pistas del kernel de WireGuard (Linux)

cr0x@server:~$ sudo journalctl -k --since "15:00" --no-pager | grep -i wireguard | tail
Dec 28 15:12:01 server kernel: wireguard: wg0: Handshake for peer 1 (198.51.100.23:60211) did not complete after 5 seconds, retrying (try 2)
Dec 28 15:12:06 server kernel: wireguard: wg0: No response from peer 1 (198.51.100.23:60211), retrying (try 3)

Significado: Los paquetes salientes salen; las respuestas no regresan. Clásico fallo por NAT/firewall/port-forward.

Decisión: Revisa filtrado ascendente, mapeos NAT y si la IP/puerto de endpoint es correcta.

Tarea 7: Registros del servicio OpenVPN (Linux)

cr0x@server:~$ sudo journalctl -u openvpn-server@server --since "15:40" --no-pager
Dec 28 15:41:10 server openvpn[2210]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Dec 28 15:41:10 server openvpn[2210]: TLS Error: TLS handshake failed

Significado: Usualmente no es un problema de certificado; es alcanzabilidad (puerto TCP/UDP bloqueado) o enrutamiento asimétrico. A veces es MTU.

Decisión: Verifica la exposición del puerto y si los paquetes llegan al demonio. Si lo hacen, busca desajuste de cifrado y ajustes TLS cliente/servidor a continuación.

Tarea 8: Confirmar que Linux escucha en los puertos esperados

cr0x@server:~$ sudo ss -lunpt | egrep ':(500|4500|1194|51820)\b'
udp   UNCONN 0      0            0.0.0.0:4500      0.0.0.0:*    users:(("charon",pid=1123,fd=14))
udp   UNCONN 0      0            0.0.0.0:500       0.0.0.0:*    users:(("charon",pid=1123,fd=13))
udp   UNCONN 0      0            0.0.0.0:51820     0.0.0.0:*    users:(("wg-quick",pid=1300,fd=6))
udp   UNCONN 0      0            0.0.0.0:1194      0.0.0.0:*    users:(("openvpn",pid=2210,fd=5))

Significado: Si el servicio no está escuchando, tu firewall puede ser perfecto y nada funcionará.

Decisión: Si falta, arregla la configuración/arranque del servicio antes de tocar dispositivos de red.

Tarea 9: Comprobar la política netfilter (Linux) sin adivinar

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    udp dport { 500, 4500, 51820, 1194 } accept
    ip protocol icmp accept
    counter drop
  }
}

Significado: Policy drop está bien si permites explícitamente puertos/protocolos VPN. Si olvidas UDP/4500, IKEv2 detrás de NAT fallará de la forma más molesta.

Decisión: Si faltan aceptaciones, añádelas; si están, deja de culpar al firewall de Linux y muévete hacia afuera.

Tarea 10: Confirmar el reenvío IP y salud de políticas XFRM para IPsec

cr0x@server:~$ sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 0

Significado: Para site-to-site o acceso remoto enrutable, el reenvío importa. Algunas configuraciones aún “conectan” pero no pasan tráfico si el reenvío está apagado.

Decisión: Si el reenvío está apagado y esperas tráfico enrutable, actívalo y verifica reglas de la cadena forward del firewall.

Tarea 11: Inspeccionar SAs IPsec en Linux (strongSwan)

cr0x@server:~$ sudo swanctl --list-sas
vpn-ikev2: #12, ESTABLISHED, IKEv2, 3c1f0b1f2d3e4a5b_i* 2a1b3c4d5e6f7a8b_r
  local  '203.0.113.10' @ 203.0.113.10[4500]
  remote '198.51.100.23' @ 198.51.100.23[60211]
  AES_GCM_16_256/PRF_HMAC_SHA2_256/ECP_256
  established 98s ago
  vpn-ikev2{21}:  INSTALLED, TUNNEL, reqid 7, ESP in UDP SPIs: c1234567_i c89abcde_o
  vpn-ikev2{21}:   10.10.10.0/24 === 10.66.66.2/32

Significado: “ESTABLISHED” más “INSTALLED” te dice que Fase 1 y Fase 2 están arriba. Si el tráfico aún falla, estás viendo enrutamiento, firewall o desajuste de selectores.

Decisión: Si no hay CHILD_SA instalada, arregla selectores/propuestas. Si está instalada, traza el flujo de paquetes después de la desencriptación.

Tarea 12: MikroTik: ver peers IPsec y SAs activas

cr0x@server:~$ ssh admin@mtk-edge 'ip ipsec active-peers print; ip ipsec installed-sa print'
 0  address=198.51.100.23 port=60211 state=established phase1-established=yes
 0  spi=0xcafebabe src-address=203.0.113.1 dst-address=198.51.100.23 state=mature
    auth-algorithm=sha256 enc-algorithm=aes-gcm enc-key-size=256

Significado: Peer establecido + SA instalada significa que el borde ve un túnel real, no sólo ilusión.

Decisión: Si el peer no está establecido, trabaja en negociación/autenticación. Si está establecido pero no hay tráfico, inspecciona rutas, exenciones de NAT y reglas de forward del firewall.

Tarea 13: MikroTik: activar logging dirigido para IPsec y PPP (temporalmente)

cr0x@server:~$ ssh admin@mtk-edge '/system logging add topics=ipsec,debug action=memory; /system logging add topics=ppp,info action=memory; /log print where topics~"ipsec|ppp"'
15:44:01 ipsec,debug initiate new phase 1 (Identity_Protection): 198.51.100.23[60211]<=>203.0.113.1[500]
15:44:02 ipsec,error no proposal chosen
15:44:03 ppp,info <l2tp-user> disconnected

Significado: “no proposal chosen” es desajuste criptográfico inmediato. Las desconexiones PPP son colaterales después.

Decisión: Arregla la alineación de propuestas IPsec primero. No persigas PPP hasta que la capa IPsec esté estable.

Tarea 14: MikroTik: comprobar contadores de firewall para puertos VPN

cr0x@server:~$ ssh admin@mtk-edge '/ip firewall filter print stats where chain=input and (protocol=udp and (dst-port=500 or dst-port=4500))'
 0    chain=input action=accept protocol=udp dst-port=500,4500 in-interface=WAN packets=1823 bytes=219120
 1    chain=input action=drop in-interface=WAN packets=44 bytes=3520

Significado: Tienes accepts y algunos drops. La pregunta es: ¿los drops son tu VPN o ruido de fondo?

Decisión: Si los accepts son cero durante un intento, el tráfico no llega o no coincide con tu regla. Si los drops suben durante intentos, añade un accept específico antes del drop.

Tarea 15: Confirmar síntomas de MTU de ruta con ping DF (Linux)

cr0x@server:~$ ping -M do -s 1372 -c 3 10.66.66.2
PING 10.66.66.2 (10.66.66.2) 1372(1400) bytes of data.
From 10.10.10.1 icmp_seq=1 Frag needed and DF set (mtu = 1420)
From 10.10.10.1 icmp_seq=2 Frag needed and DF set (mtu = 1420)
From 10.10.10.1 icmp_seq=3 Frag needed and DF set (mtu = 1420)

--- 10.66.66.2 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss

Significado: Estás superando un MTU de ruta. La encapsulación de VPN añade overhead y esto es común; puede parecer “conecta pero nada funciona”.

Decisión: Reduce MTU del túnel, clamp al MSS de TCP o arregla bloqueos de PMTUD. No simplemente “desactives DF en todas partes” y lo llames un día.

Broma #1: Los problemas de MTU son el único bug de red que puede hacer que una VPN “funcione” y aun así arruinarte el fin de semana.

Patrones de logs que mapean a causas raíz reales

Patrón: “no proposal chosen” (IKE/IPsec)

Usualmente significa: desajuste en encriptación/integridad/PRF/grupo DH, o estás mezclando suposiciones IKEv1 en una configuración IKEv2.

Qué hacer: Compara las propuestas ofrecidas por el cliente con el conjunto aceptado por el servidor. En MikroTik, revisa la configuración de propuestas IPsec; en strongSwan, revisa ike= y esp=. Haz un lado más permisivo temporalmente, luego ajusta.

Patrón: “AUTHENTICATION_FAILED”

Usualmente significa: credenciales incorrectas, cadena de identidad equivocada, desajuste de certificado o política RADIUS rechazando al usuario.

Qué hacer: Verifica la ID que presenta el cliente (FQDN/email/DN) y lo que el servidor espera. En configuraciones con certificados, revisa EKU, SAN y la cadena de confianza. En EAP, confirma compatibilidad de método (EAP-MSCHAPv2 vs EAP-TLS).

Patrón: “peer not responding” / timeouts

Usualmente significa: los paquetes no regresan. Bloqueos de firewall, NAT rota, IP de destino equivocada, ruta asimétrica o UDP 4500 bloqueado.

Qué hacer: Captura de paquetes en ambos extremos. Si ves salientes pero no entrantes, ve a la red. Si ves entrantes y el demonio está en silencio, estás golpeando el host/puerto incorrecto o el firewall/SELinux local lo está consumiendo.

Patrón: túnel arriba, pero “sin tráfico”

Usualmente significa: enrutamiento/AllowedIPs/selectores incorrectos, falta de exención de NAT o forward chain del firewall bloqueando tráfico post-desencriptación.

Qué hacer: Para IPsec, inspecciona políticas/selectores instalados. Para WireGuard, inspecciona AllowedIPs en ambos extremos y confirma que existen rutas. Luego traza con tcpdump en la interfaz interna, no solo en el WAN.

Patrón: conectividad intermitente según la red

Usualmente significa: casos límite de NAT-T, MTU/PMTUD, o portales cautivos que bloquean UDP.

Qué hacer: Forzar NAT-T (cuando corresponda), probar puertos/protocolos alternativos (por ejemplo, OpenVPN en TCP 443) y clavar MSS. Los logs te mostrarán timeouts y retransmisiones; tu trabajo es conectarlos al entorno de red.

Errores comunes: síntoma → causa raíz → arreglo

1) Síntoma: “funciona en casa, falla en el Wi‑Fi del hotel”

Causa raíz: UDP bloqueado o dañado; NAT-T UDP 4500 bloqueado; portal cautivo; o políticas de firewall estrictas.

Arreglo: Ofrece una alternativa basada en TCP (a menudo TCP 443), asegúrate de que NAT-T esté habilitado para IPsec y registra los drops de firewall en input WAN para los puertos VPN.

2) Síntoma: “IKE_SA se establece, pero no hay acceso interno”

Causa raíz: rutas faltantes, selectores de tráfico erróneos, falta de exención NAT o drop en forward chain.

Arreglo: Verifica los selectors CHILD_SA instalados, añade rutas, añade una regla de allow explícita post-desencriptación y asegúrate de no NATear tráfico que deba estar protegido.

3) Síntoma: “autenticación fallida” justo después de la negociación

Causa raíz: identidad errónea (IDi/IDr), método EAP equivocado, RADIUS rechaza, cadena de confianza de certificados incompleta.

Arreglo: Registra la identidad presentada, alinea ajustes de ID, valida la cadena de certificados en el servidor y revisa logs AAA para razones de rechazo.

4) Síntoma: OpenVPN “TLS handshake failed” pero el puerto está abierto

Causa raíz: desajuste TLS cliente/servidor (tls-crypt/tls-auth), desajuste de cifrado o MTU causando fragmentación y pérdida del handshake.

Arreglo: Compara configuraciones; simplifica temporalmente a un cifrado/TLS conocido bueno y luego vuelve a endurecer. Revisa MTU y configuraciones de fragmentación.

5) Síntoma: WireGuard “latest handshake: never”

Causa raíz: endpoint equivocado, UDP bloqueado, clave pública errónea o NAT que necesita keepalive persistente.

Arreglo: Verifica claves y endpoint; añade keepalive para clientes detrás de NAT; confirma alcanzabilidad UDP con tcpdump.

6) Síntoma: VPN conecta, navegación web funciona, compartición de archivos expira

Causa raíz: problemas de MTU/MSS. Los paquetes pequeños pasan; los grandes mueren.

Arreglo: Clampa MSS de TCP en la interfaz/túnel del borde, reduce MTU y asegúrate de que ICMP “frag needed” no esté bloqueado.

7) Síntoma: L2TP/IPsec conecta para algunos usuarios, otros fallan

Causa raíz: secretos PPP por usuario, desajustes de perfil, diferencias en atributos RADIUS o agotamiento del pool de direcciones.

Arreglo: Revisa logs de auth PPP, verifica disponibilidad del pool IP, estandariza perfiles y compara respuestas AAA.

8) Síntoma: IPsec site-to-site se cae cada pocos minutos

Causa raíz: desajuste DPD, desajuste de rekey timing, timeouts de mapeo NAT o enlace WAN inestable.

Arreglo: Alinea lifetimes y ajustes DPD; revisa errores en el WAN; considera keepalives; registra eventos de rekey y correlaciónalos con cambios de estado de interfaz.

Listas de verificación / plan paso a paso (flujo de trabajo en producción)

Checklist A: el triage de 10 minutos (no seas ingenioso aún)

Obtén la ventana exacta de fallo y el tipo de red del cliente (casa/celular/hotel).
Confirma que DNS resuelve a la IP pública esperada (evita los agujeros de conejo “destino equivocado”).
Verifica que el tiempo del servidor/router y Linux estén sincronizados.
En Linux, ejecuta tcpdump para UDP 500/4500 (o el puerto relevante) durante un intento fresco.
En MikroTik, comprueba contadores de firewall y logs IPsec/PPP para el mismo minuto.
Clasifica: sin tráfico, fallo de negociación, fallo de auth, o “arriba pero sin datos”.
Elige una hipótesis y pruébala con un cambio o comando.

Checklist B: profundización negociación/auth (cuando llegan paquetes)

Extrae la cadena de error exacta de los logs del demonio VPN (NO_PROPOSAL_CHOSEN, AUTHENTICATION_FAILED, TS_UNACCEPTABLE).
Lista las propuestas configuradas en el servidor y compáralas con la suite soportada por el cliente.
Valida la cadena de certificados, expiración y campos de identidad (SAN, CN según corresponda).
Revisa logs AAA (RADIUS/LDAP) por razones de rechazo; no adivines.
Vuelve a probar. Si el error cambia, avanzaste. Si no, no lo hiciste.

Checklist C: “conectado pero nada funciona” (el sigiloso)

Confirma que SA está establecida y los selectores coinciden con las subredes esperadas.
Confirma que existen rutas en ambos extremos (y en el cliente para split tunnel).
Confirma que el firewall permite tráfico post-desencriptación (cadena forward, no sólo input).
Confirma exención NAT para subredes VPN (no NATees dentro-a-dentro salvo que quieras).
Prueba MTU con ping DF o clampa MSS y repite la prueba.

Broma #2: La VPN no está “caída”. Sólo practica chaos engineering sin avisarte.

Tres mini-historias del mundo corporativo (realistas, anonimizadas)

Mini-historia 1: El incidente causado por una suposición equivocada

El helpdesk escaló una “caída de VPN” a las 8:17 AM. El síntoma era claro: un grupo de usuarios remotos no podía conectar, y los que podían estaban mayormente en broadband doméstico. Los usuarios celulares estaban bien. Todos culparon certificados porque alguien había renovado “algo” la semana pasada.

La primera suposición equivocada: “Si algunos usuarios pueden conectar, el servidor VPN está sano.” Eso reconforta emocionalmente y a veces es cierto, pero también es la forma de perder fallos dependientes de ruta como filtrado UDP y rarezas de NAT-T. La segunda suposición equivocada: “Si es IPsec, debe ser crypto.” No. IPsec suele ser política de red con traje de crypto.

Pusimos tcpdump en el endpoint Linux: no llegó nada por UDP 4500 durante los intentos fallidos. Los contadores de firewall de MikroTik para UDP 4500 también estaban planos, mientras UDP 500 se disparaba. Esa fue la pista: clientes detrás de NAT empiezan en UDP 500 y luego pasan a UDP 4500 para NAT traversal. Se quedaban atascados en la puerta.

La causa fue aburrida: un firewall ascendente recién desplegado permitía UDP 500 pero no UDP 4500. La plantilla tenía “IPsec” en el nombre, así que todos asumieron que estaba completa. Añadimos UDP 4500, vimos cómo los logs de strongSwan pasaban de timeouts a SAs establecidas, y el incidente se cerró.

La lección del postmortem no fue “recuerda UDP 4500”. Fue: nunca diagnostiques “no conecta” sin antes probar que el tráfico alcanza el dispositivo en el puerto que realmente necesita.

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

Un equipo de red decidió “reducir ruido de logs” en un borde MikroTik desactivando la mayoría de logs relacionados con VPN y confiar en un syslog central Linux desde la capa de aplicaciones. La motivación era comprensible: presupuesto de almacenamiento, fatiga de alertas y un dashboard que parecía un sismógrafo.

Dos semanas después, un despliegue de IKEv2 empezó a fallar para una población específica de clientes. El endpoint Linux mostraba esporádicos “received packet with unknown SPI” y fallos de AUTH ocasionales. Pero no había patrón consistente, y no teníamos logs del borde para decir si el tráfico estaba siendo NATeado, descartado o traducido de forma extraña.

Volvimos a habilitar logs IPsec dirigidos en MikroTik y añadimos una sola regla de firewall con contadores para UDP 500/4500. En minutos apareció la historia: una regla NAT hacía hairpin con ciertos rangos de origen de forma distinta, causando que el endpoint viera puertos origen cambiantes a mitad del handshake. strongSwan trató los cambios como sospechosos y los handshakes morían intermitentemente.

La “optimización” fue apagar los mismos logs que te dicen qué hace el borde con los paquetes. La solución no fue “habilitar todos los logs”. La solución fue logging disciplinado: debug pequeño, dirigido y limitado en el tiempo más contadores persistentes.

Después, el equipo mantuvo el ruido bajo pero preservó la capacidad de reconstruir un fallo. Esa es la diferencia entre observabilidad y acaparamiento.

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

Otra organización hizo algo poco moderno: estandarizó el triage de fallos VPN en un pequeño runbook. Cada incidente empezaba con las mismas tres capturas: timestamp del cliente, contadores del borde y logs del demonio del servidor. También forzaron NTP en cada MikroTik y en cada host Linux, y lo probaban mensualmente como adultos.

Cuando una “VPN no conecta” afectó durante una demostración de un proveedor, no discutieron culpas. Alinearon las marcas de tiempo y miraron la ventana de solapamiento. El borde mostró paquetes UDP 500 entrantes aceptados, luego nada en UDP 4500. Tcpdump del servidor mostró lo mismo. Eso lo acotó a filtrado ascendente o política de la red del cliente.

El usuario estaba en una Wi‑Fi de invitados que bloqueaba UDP 4500. El siguiente paso del runbook fue un fallback documentado: OpenVPN sobre TCP 443, con un filtro de logs explícito para confirmar handshake TLS. Cambiaron de perfil, vieron “TLS negotiation succeeded” y la demo continuó con sólo un poco de sudor.

La práctica salvadora no fue sofisticada. Fue tener un camino alternativo y el hábito de confirmar alcanzabilidad de paquetes antes de reescribir configuraciones. Lo aburrido gana. Puedes enmarcar eso y colgarlo en la oficina, preferiblemente sobre la máquina de espresso.

Datos interesantes & breve historia (cosas que explican los dolores actuales)

El empuje empresarial original de IPsec fue en los años 90, cuando “seguridad en la capa de red” sonaba a que simplificaría todo. No lo logró, pero estandarizó mucho vocabulario VPN.
IKEv2 (mediados de 2000) fue diseñado para arreglar la complejidad de IKEv1 y mejorar movilidad y NAT traversal, pero aún depende mucho de propuestas e identidades correctas.
NAT no fue diseñado pensando en IPsec. ESP (protocolo 50) no tiene puertos, lo que hace incómodos a los dispositivos NAT clásicos; NAT-T envolvió ESP en UDP 4500 como parche pragmático.
Las VPN de la era PPP (L2TP/PPTP) perduraron porque eran fáciles de desplegar, no porque fueran excelentes. Los logs aún muestran fallos de auth PPP que no tienen nada que ver con crypto.
WireGuard se hizo mainstream por ser intencionalmente pequeño: menos opciones, menos modos heredados y, por ende, menos errores de negociación “misteriosos”—cuando falla, suele fallar de forma clara.
OpenVPN popularizó “VPN sobre TCP/443” como táctica de supervivencia para redes restrictivas, aunque TCP sobre TCP puede ser una trampa de rendimiento.
El dolor de MTU empeoró conforme el cifrado se volvió por defecto: cada capa de encapsulación roba bytes, y las redes modernas a menudo bloquean ICMP necesario para PMTUD.
Las prácticas de logging cambiaron con systemd: journald facilitó filtrar por unidad y ventana de tiempo, que es exactamente lo que necesita el diagnóstico VPN.

Preguntas frecuentes

1) Si la VPN “no conecta”, ¿dónde miro primero: cliente, MikroTik o Linux?

Empieza donde puedas probar llegada de paquetes. Si controlas el servidor, ejecuta tcpdump y revisa logs del demonio. Si no ves paquetes, pivota al borde MikroTik y a la ruta ascendente.

2) ¿Por qué veo paquetes UDP 500 pero no UDP 4500?

Muchos clientes empiezan IKE en UDP 500 y cambian a UDP 4500 cuando detectan NAT. No ver UDP 4500 suele significar política de firewall o filtrado ascendente, no crypto.

3) ¿Qué significa realmente “no proposal chosen”?

Los peers no pudieron ponerse de acuerdo en algoritmos (encriptación/integridad/PRF/grupo DH) para IKE o ESP. Arregla alineando los conjuntos de propuestas; no habilites suites heredadas al azar sin entender el riesgo.

4) El túnel se establece, pero las subredes internas son inalcanzables. ¿Sigue siendo un problema de VPN?

Sí, pero no es un problema de handshake. Es enrutamiento, reglas forward del firewall, exenciones NAT o selectores/AllowedIPs. Revisa SAs y rutas, luego traza tráfico después de la desencriptación.

5) ¿Por qué WireGuard muestra handshakes pero aun así no hay tráfico?

Usualmente AllowedIPs o enrutamiento. Un handshake sólo prueba claves y alcanzabilidad; no prueba que estés enroutando las subredes correctas por el túnel o permitiéndolas en el firewall.

6) ¿Cuál es la forma más rápida de confirmar que un firewall Linux no está bloqueando la VPN?

Inspecciona el ruleset (nft list ruleset) y confirma accepts explícitos para puertos/protocolos VPN, además de contadores si puedes. No “flushees iptables” en producción a menos que te gusten los incidentes.

7) ¿Debo habilitar debug permanentemente en MikroTik y strongSwan?

No. Habilita debug dirigido brevemente, idealmente acotado por ventana de tiempo y IP de origen si es posible, luego apágalo. Mantén logs info ligeros y contadores siempre.

8) ¿Cómo sé que es MTU?

Señal clásica: peticiones pequeñas funcionan, transferencias grandes se quedan; algunas apps conectan, otras cuelgan. Confírmalo con pings DF y clamp al MSS. Los logs suelen mostrar retransmisiones/timeouts, no “MTU” en neón.

9) Si OpenVPN sobre TCP 443 funciona en todas partes, ¿debería usar sólo eso?

Es un fallback útil, no siempre una primaria. TCP sobre TCP puede empeorar rendimiento bajo pérdida. Úsalo cuando necesites atravesar redes restrictivas y mide antes de estandarizar.

10) ¿Qué hábito único reduce más los incidentes VPN?

Disciplina de timestamps: NTP en todos lados y el hábito de recopilar tiempo del intento del cliente, contadores del borde y logs del demonio del servidor para el mismo minuto.

Conclusión: próximos pasos que reducen las repeticiones

Deja de tratar “VPN no conecta” como un acertijo. Trátalo como una investigación corta con recolección de evidencia y lógica de bifurcación.

Estandariza el playbook rápido (llegada de tráfico → clasificar error → comprobar tiempo/MTU/NAT-T) y hazlo la respuesta por defecto.
Mantén logging dirigido siempre activo: logs info IPsec en MikroTik, contadores de firewall para puertos VPN y logs de demonios Linux en journald.
Practica un camino de fallback para redes restrictivas (a menudo TCP 443) y pruébalo periódicamente.
Haz de MTU/MSS una verificación de primera clase para incidentes “conectado pero inutilizable”—porque sigue ocurriendo y fingir lo contrario no ayuda.

Cuando puedas responder “¿llegaron paquetes?” y “¿qué error exacto se disparó?” en menos de cinco minutos, los incidentes VPN pasan de drama a mantenimiento rutinario. Ese es el objetivo: menos heroísmos, más uptime.