WireGuard vs IPsec en oficinas: qué es más fácil de mantener y trampas comunes

Tomar la decisión como operador

Tanto WireGuard como IPsec pueden ofrecer conectividad oficina-a-oficina correctamente. La diferencia no es la “seguridad” en abstracto.
La diferencia es cuánto tiempo dedicarás a probar que un paquete existió alguna vez y con qué frecuencia una pequeña discordancia se convierte en un agujero negro.

Mi recomendación sesgada, orientada a producción

• Prefiere WireGuard por defecto para nuevas VPNs sitio-a-sitio cuando controlas ambos extremos (routers Linux, firewalls modernos o appliances que lo implementen limpiamente).
  Es más sencillo de razonar, más ligero de depurar y predecible bajo cambios.
• Usa IPsec/IKEv2 cuando debas interoperar con equipos empresariales existentes, listas de verificación impulsadas por cumplimiento o cuando “IPsec es lo único que el proveedor soporta sin apuntar con el dedo.”
  También: si necesitas un hub-and-spoke maduro a escala con herramientas IPsec ya internas, no pelees contra tu organización.
• No elijas por palabras de moda criptográficas. Elige por observabilidad, modos de fallo y quién estará de guardia a las 03:00.

Qué significa realmente “más fácil de mantener”

El mantenimiento no es la configuración inicial. Es la segunda oficina que añades, el cambio de ISP, la actualización del firewall y el “cambio rápido” de subred que no se documentó.
También son la rotación de credenciales, la monitorización y la recuperación de fallos parciales (el tráfico unidireccional es el rey del “parece arriba, actúa abajo”).

WireGuard tiende a ganar en claridad de configuración y depurabilidad.
IPsec suele ganar en compatibilidad institucional y amplitud de funciones—a costa de más piezas móviles y más superficies de fallo en la negociación.

Una verdad operativa: si tu VPN requiere una reunión para cambiar un conjunto de cifrados, no tienes una VPN—tienes un ritual semanal.

Cita (idea parafraseada) de Werner Vogels: Lo construyes, lo operas—lo que significa que el coste de operabilidad es parte del diseño, no un post scriptum.

Hechos interesantes y contexto histórico (lo que explica el lío actual)

1. IPsec comenzó en los años 90 como parte de la visión original de IPv6, y luego se llevó a la realidad de IPv4. El resultado: décadas de extensiones, perfiles e “interpretaciones” de los proveedores.
2. IKE (Internet Key Exchange) evolucionó porque las claves manuales eran un dolor. IKEv1 era flexible pero complicado; IKEv2 simplificó el protocolo y mejoró la fiabilidad bajo IPs cambiantes.
3. NAT rompió el modelo limpio de IPsec. ESP no le gusta ser atravesado por NAT; NAT-T (encapsulado en UDP) se volvió la cinta adhesiva que hizo a IPsec funcional en el Internet moderno.
4. WireGuard es intencionalmente pequeño. Su base de código es famosamente compacta en comparación con las pilas típicas de IPsec. Pequeño no significa perfecto automáticamente, pero reduce la superficie de “desconocidos desconocidos.”
5. WireGuard usa primitivas modernas (handshake basado en Noise). Hizo elecciones con opinión para evitar una matriz de negociación desbordada de algoritmos.
6. La adopción en el mainline de Linux cambió el juego de WireGuard. Cuando llegó al kernel de Linux, el rendimiento y el empaquetado se simplificaron, y dejó de sentirse como un proyecto lateral.
7. IPsec suele parecer “stateful” para los humanos porque lo es. Mantiene Security Associations (SAs) con tiempos de vida, rekeying y potencialmente múltiples child SAs.
8. WireGuard parece “stateless” hasta que aprendes que no lo es. Tiene handshakes y comportamiento de roaming, pero evita largas secuencias de negociación y la mayoría del drama de “desajuste de propuestas”.
9. Muchos proveedores de firewalls tratan IPsec como una característica de primera clase. Eso importa en oficinas porque los contratos de soporte y las operaciones guiadas por UI son restricciones reales.

Realidad del mantenimiento: lo que tu yo futuro odiará

WireGuard: menos perillas, menos formas de equivocarse

La configuración de WireGuard es básicamente: claves, endpoint, AllowedIPs y keepalive si estás detrás de NAT. Eso es todo.
El truco operativo es que AllowedIPs es a la vez enrutamiento y control de acceso. Es elegante, hasta que alguien piensa que es solo enrutamiento y accidentalmente concede alcance a un rango RFC1918 entero.

El trabajo de mantenimiento en WireGuard suele verse como:

• Rotación de claves sin romper peers.
• Mantener AllowedIPs limpias, no solapadas y documentadas.
• Prevenir “funciona desde el portátil de Bob pero no desde el router de la oficina” estandarizando NAT y reglas de firewall.
• Monitorizar handshakes y throughput para detectar fallos silenciosos temprano.

IPsec: la tierra de “debería funcionar” y “aún está negociando”

El mantenimiento de IPsec suele estar dominado por la interoperabilidad y las superficies de negociación:
propuestas IKE/ESP, grupos DH, tiempos de vida, temporizadores de rekey, identidades, PSKs vs certificados, túneles basados en políticas vs basados en rutas, DPD/keepalives, NAT-T, fragmentación y valores por defecto específicos del proveedor.

Puedes operar IPsec sin problemas durante años, pero solo lo consigues siendo disciplinado:
estandariza perfiles, documenta las perillas exactas y monitoriza el comportamiento de rekeying. Si “solo haces clic hasta que se vuelva verde”, lo pagarás más tarde.

Qué realmente impulsa el trabajo operacional (independientemente del protocolo)

• NAT y enrutamiento asimétrico: la VPN recibe la culpa, la tabla de enrutamiento es la culpable.
• Problemas de MTU/PMTUD: pings pequeños funcionan; cargas grandes mueren; el helpdesk pierde una semana.
• Expectativas de DNS: la gente quiere que el “DNS de la oficina” funcione mágicamente a través de túneles sin planificación split-horizon.
• Deriva de identidad: cambia la IP o el hostname de un peer y la configuración no lo refleja.
• Ciclo de vida de claves: nadie lo programa, y se vuelve una interrupción cuando lo intentas.

Broma #1: Las VPNs son como las máquinas de café de la oficina—nadie sabe cómo funcionan, pero todo el mundo lo nota en el momento que no lo hacen.

WireGuard en oficinas: comportamiento operativo y trampas

Para qué es excelente WireGuard

• Enrutamiento sitio-a-sitio simple cuando cada oficina tiene subredes estables y quieres conectividad predecible.
• Roaming y enlaces inestables: si la IP pública de un endpoint cambia, WireGuard puede recuperarse rápido mientras el peer sea alcanzable y ocurran handshakes.
• Depuración de bajo coste: los comandos de “muéstrame el estado” suelen ser directos: último handshake, contadores de transferencia, endpoint.
• Rendimiento por CPU: a menudo excelente en hardware moderno, con menos overhead que muchas implementaciones de IPsec.

Las trampas que causan interrupciones reales

Trampa: solapamiento de AllowedIPs y secuestro de rutas

En WireGuard, AllowedIPs en el extremo receptor decide qué tráfico se acepta de un peer. En el extremo emisor, decide qué se enruta hacia el túnel.
Si se solapan, puedes crear una pesadilla de enrutamiento: el tráfico desaparece hacia el peer equivocado porque el kernel elige la ruta más específica, o peor, tu “temporal” 0.0.0.0/0 se vuelve permanente.

Regla práctica: trata AllowedIPs como reglas de firewall más entradas de la tabla de enrutamiento. Revísalas como política de seguridad, no como “algunas IP que necesitamos.”

Trampa: NAT y timeouts de inactividad sin keepalive persistente

Muchos enlaces de oficina están detrás de NAT—routers de ISP, respaldo LTE, “gateways empresariales” con firmware misterioso.
Si ninguno de los dos extremos envía tráfico por un tiempo, el estado expira y el siguiente paquete no llega. Esto parece un fallo intermitente, el peor tipo.
Para peers detrás de NAT, configura PersistentKeepalive (a menudo 25 segundos) en el lado NATeado.

Trampa: desajuste de MTU y agujero negro TCP

WireGuard añade overhead. Si lo ejecutas sobre PPPoE, etiquetas VLAN u otra encapsulación, la MTU efectiva puede reducirse rápidamente.
El síntoma: SSH funciona, HTTP pequeño funciona, pero “el CRM se agota” o las transferencias de archivos se quedan bloqueadas.
La solución suele ser ajustar la MTU de la interfaz WireGuard a un valor menor y/o hacer clamp de MSS en el firewall.

Trampa: olvidar que no es un firewall

WireGuard moverá paquetes con gusto. No diseñará tu segmentación.
Aún necesitas reglas de nftables/iptables, y debes pensar en el movimiento lateral entre redes de oficina.
Muchos equipos asumen erróneamente que “la VPN es el borde.” No lo es. Es un cable.

Trampa: gestión de claves con hojas de cálculo

Las claves de WireGuard son estáticas. Eso está bien, pero debes tratarlas como credenciales: propiedad, rotación y revocación.
El modo de fallo clásico es “¿quién tiene la clave privada del router de la sucursal vieja?” y la respuesta es “un MSP anterior.”
Almacena claves en un sistema de secretos, no en el directorio personal de alguien.

IPsec/IKEv2 en oficinas: comportamiento operativo y trampas

Para qué es excelente IPsec

• Interoperabilidad entre proveedores: todos los firewalls hablan alguna variante, y muchos tienen flujos de UI maduros para ello.
• Integración con certificados y PKI: gestión de identidades escalable cuando se hace correctamente.
• Túneles basados en rutas con VTI (en plataformas capaces): más cercanos al “enrutamiento normal”, que los operadores entienden.
• Compatibilidad con requisitos de cumplimiento: algunas organizaciones tienen políticas que nombran explícitamente IPsec.

Las trampas que causan interrupciones reales

Trampa: desajuste de propuestas y el “agujero negro de negociación”

La negociación de IPsec depende de acordar parámetros: cifrado, integridad, PRF, grupos DH, tiempos de vida y más.
Un desajuste puede hacer que el túnel fluctúe, no suba o suba pero falle al pasar tráfico por desajuste de child SA.
Los logs a menudo parecen una desacuerdo cortés. El impacto en el negocio no lo es.

Trampa: NAT-T y dolor por fragmentación de UDP

En un mundo NATeado, IPsec a menudo corre sobre UDP/4500. En algunos caminos, los paquetes UDP grandes se descartan.
Eso puede romper rekeying, romper los datos o crear un patrón de “funciona un tiempo y luego muere”.
Terminarás afinando MTU, habilitando soporte de fragmentación o aplicando clamp MSS de todos modos. Bienvenido al club.

Trampa: confusión entre policy-based y route-based

IPsec basado en políticas (selectores para subredes locales/remotas) parece simple hasta que necesitas subredes solapadas, múltiples redes o enrutamiento dinámico.
Route-based (VTI) suele ser más mantenible para oficinas porque se comporta como una interfaz normal y como un problema de enrutamiento.
Pero no todas las plataformas lo implementan consistentemente y algunas UIs ocultan la complejidad hasta que falla.

Trampa: temporizadores de rekey que no coinciden con la realidad

El rekeying es normal. Las tormentas de rekey no lo son.
Si los tiempos de vida son demasiado cortos, o si un lado rekeyea agresivamente y el otro no puede seguir el ritmo, obtienes pérdida periódica de paquetes que parece “jitters aleatorios del ISP.”
Monitoriza la frecuencia de rekey. Haz los tiempos de vida aburridos.

Trampa: configuración de identidad que falla tras cambios de ISP

Muchas implementaciones de IPsec en oficinas enlazan la identidad a direcciones IP, o asumen IPs públicas estáticas para siempre.
Luego el ISP cambia el CPE, o una sucursal salta a LTE, y la identidad IKE ya no coincide.
Usa identificadores estables: identidades FQDN y certificados, o al menos documenta la dependencia y planifica cambios.

Broma #2: IPsec es mucho como las convenciones de nombres diseñadas por comités—técnicamente completas, emocionalmente agotadoras.

Guion de diagnóstico rápido (encuentra el cuello de botella antes de “cambiar cosas”)

Cuando un túnel está “caído”, suele ser una de cuatro cosas: alcanzabilidad del transporte, negociación/handshake, enrutamiento o MTU/estado.
El truco es comprobar en el orden correcto para no perder una hora probando la capa equivocada.

Primero: ¿es alcanzable el underlay?

• Confirma la alcanzabilidad de IP/puerto públicos (UDP 51820 para WireGuard, UDP 500/4500 para IPsec).
• Verifica si cambiaron reglas de NAT o firewall.
• Valida que ambos extremos coincidan en la dirección del peer (o estén configurados para endpoints dinámicos apropiadamente).

Segundo: ¿la capa de control tiene éxito?

• WireGuard: comprueba la hora del último handshake, endpoint y contadores de transferencia.
• IPsec: comprueba el establecimiento del IKE SA, la instalación de child SA y la churn de rekey.

Tercero: ¿el plano de datos está enrutado correctamente?

• Verifica rutas en ambos lados (y que la vía de retorno coincida).
• Busca subredes solapadas y AllowedIPs o selectores de tráfico erróneos.
• Confirma que el reenvío y las políticas de firewall permitan el tráfico.

Cuarto: ¿MTU/fragmentación te está matando en silencio?

• Prueba con pings DF y tamaños crecientes.
• Haz clamp MSS para TCP si ves bloqueos.
• Observa fallos de rekey correlacionados con paquetes grandes.

Quinto: ¿es un problema de recursos?

• Saturación de CPU por criptografía.
• Descartes en colas de la interfaz WAN.
• Desequilibrio de IRQ en routers baratos con marketing de “aceleración VPN”.

Tareas prácticas con comandos (y qué significa la salida)

Estos no son comandos de laboratorio. Son los que ejecutas mientras alguien de Finanzas pregunta si “la VPN ya está arreglada.”
Cada tarea incluye: comando, salida de ejemplo, qué significa y la decisión que tomas.

1) WireGuard: comprobar estado del peer y último handshake

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

peer: 7bq1oYVxRjv0y9u8mS5o2k1m8K9p0t7x6w5v4u3y2x1=
  endpoint: 203.0.113.44:53122
  allowed ips: 10.20.0.0/16
  latest handshake: 1 minute, 12 seconds ago
  transfer: 1.21 GiB received, 980.33 MiB sent
  persistent keepalive: 25 seconds

Significado: “Latest handshake” es reciente; el endpoint es conocido; los contadores se mueven.
Decisión: Si el tráfico sigue fallando, deja de culpar al túnel y revisa enrutamiento/firewall/MTU interno. Si el handshake es “nunca” u horas, enfócate en la alcanzabilidad del underlay o en las claves.

2) WireGuard: comprobar las rutas del kernel creadas por AllowedIPs

cr0x@server:~$ ip route show table main | grep wg0
10.20.0.0/16 dev wg0 scope link

Significado: El sistema enruta 10.20.0.0/16 hacia wg0.
Decisión: Si esperabas solo 10.20.30.0/24 y ves /16, encontraste por qué el tráfico desaparece en el túnel. Arregla AllowedIPs y la política de rutas.

3) WireGuard: verificar la MTU de la interfaz y ajustarla si hace falta

cr0x@server:~$ ip link show dev wg0
7: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none

Significado: MTU 1420 es común para WireGuard sobre Ethernet típica. Sobre PPPoE u otra encapsulación, podría seguir siendo demasiado alta.
Decisión: Si ves agujero negro TCP, baja la MTU (p. ej., 1380) y/o haz clamp MSS en el borde.

4) Prueba de Path MTU con ping DF (encuentra agujeros)

cr0x@server:~$ ping -M do -s 1372 -c 3 10.20.30.10
PING 10.20.30.10 (10.20.30.10) 1372(1400) bytes of data.
1372 bytes from 10.20.30.10: icmp_seq=1 ttl=63 time=18.7 ms
1372 bytes from 10.20.30.10: icmp_seq=2 ttl=63 time=18.5 ms
1372 bytes from 10.20.30.10: icmp_seq=3 ttl=63 time=18.6 ms

--- 10.20.30.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms

Significado: Payload 1372 con DF tiene éxito, así que al menos paquetes ~1400 pasan por ese camino.
Decisión: Si esto falla con “Frag needed”, ajusta MTU/MSS. Si simplemente agota, sospecha filtrado de ICMP o un agujero real—haz clamp MSS y reduce MTU proactivamente.

5) WireGuard: confirmar que el proceso escucha en el puerto esperado

cr0x@server:~$ sudo ss -lunp | grep 51820
UNCONN 0      0          0.0.0.0:51820      0.0.0.0:*    users:(("wg-quick",pid=1324,fd=6))

Significado: UDP/51820 está abierto localmente.
Decisión: Si no está escuchando, tu servicio no arrancó o enlazó incorrectamente. Arregla systemd/wg-quick y luego verifica firewall/NAT.

6) WireGuard: capturar intentos de handshake (demostrar que los paquetes existen)

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 51820 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:10:01.123456 IP 198.51.100.22.51820 > 203.0.113.44.53122: UDP, length 148
12:10:01.223901 IP 203.0.113.44.53122 > 198.51.100.22.51820: UDP, length 92

Significado: UDP bidireccional está fluyendo; el underlay y el firewall probablemente están bien.
Decisión: Si ves solo salidas y ninguna respuesta, es firewall/NAT/ISP. Si ves bidireccional pero no handshake en wg show, sospecha desajuste de claves o configuración de peer incorrecta.

7) IPsec (strongSwan): mostrar estado de IKE y child SA

cr0x@server:~$ sudo swanctl --list-sas
vpn-office: #12, ESTABLISHED, IKEv2, 3c2f2e8d1d0a9c1f_i* 9a8b7c6d5e4f3210_r
  local  'office-a' @ 198.51.100.10[4500]
  remote 'office-b' @ 203.0.113.44[4500]
  AES_GCM_16-256/PRF_HMAC_SHA2_256/ECP_256
  established 42 minutes ago, rekeying in 2 hours
  office-a-office-b: #14, INSTALLED, TUNNEL, reqid 1
    local  10.10.0.0/16
    remote 10.20.0.0/16
    AES_GCM_16-256, 51023 bytes_i, 48890 bytes_o, rekeying in 46 minutes

Significado: IKE SA establecida, child SA instalada, los selectores coinciden con las subredes de oficina.
Decisión: Si IKE está arriba pero falta child SA, tienes desajuste de selectores/propuestas. Si ambos están arriba pero el tráfico falla, revisa enrutamiento, firewall y MTU/fragmentación.

8) IPsec: comprobar logs de charon por errores de negociación

cr0x@server:~$ sudo journalctl -u strongswan --since "10 min ago" | tail -n 12
Dec 28 12:02:11 gw-a charon-systemd[998]: 14[IKE] received NO_PROPOSAL_CHOSEN notify error
Dec 28 12:02:11 gw-a charon-systemd[998]: 14[IKE] failed to establish CHILD_SA, keeping IKE_SA
Dec 28 12:02:11 gw-a charon-systemd[998]: 14[IKE] peer supports MOBIKE

Significado: El peer rechazó la propuesta para el child SA (transformaciones ESP, grupo DH, etc.).
Decisión: Alinea suites de cifrado/propuestas en ambos lados. No “abra todo.” Estandariza un perfil conocido y aplícalo por todas partes.

9) IPsec: verificar listeners UDP 500/4500

cr0x@server:~$ sudo ss -lunp | egrep ':500|:4500'
UNCONN 0      0          0.0.0.0:500        0.0.0.0:*    users:(("charon",pid=998,fd=12))
UNCONN 0      0          0.0.0.0:4500       0.0.0.0:*    users:(("charon",pid=998,fd=13))

Significado: El daemon está escuchando en los puertos requeridos IKE/NAT-T.
Decisión: Si falta, tu servicio está caído o enlazado incorrectamente. Arregla eso primero; no toques propuestas todavía.

10) IPsec: confirmar que NAT-T está en uso (o no)

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 4500 -c 3
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:06:44.001122 IP 198.51.100.10.4500 > 203.0.113.44.4500: UDP, length 244
12:06:44.101455 IP 203.0.113.44.4500 > 198.51.100.10.4500: UDP, length 276

Significado: IPsec está encapsulado en UDP/4500. Eso es típico cuando se detecta NAT o se fuerza.
Decisión: Si UDP/4500 está bloqueado en algún punto, tendrás fallo intermitente o total. Ábrelo y vigila problemas de fragmentación UDP.

11) Sanidad de enrutamiento: verificar la vía de retorno (la asimetría mata VPNs)

cr0x@server:~$ ip route get 10.20.30.10
10.20.30.10 dev wg0 src 10.10.0.1 uid 0
    cache

Significado: El kernel cree que 10.20.30.10 es alcanzable vía wg0.
Decisión: Ejecuta la misma comprobación en el lado remoto para tu subred de origen. Si un lado enruta correctamente y el otro no, tienes enrutamiento asimétrico o rutas faltantes.

12) Sanidad del firewall: confirmar que la política de forwarding no está descartando en silencio

cr0x@server:~$ sudo nft list ruleset | sed -n '1,80p'
table inet filter {
  chain forward {
    type filter hook forward priority filter; policy drop;
    iifname "wg0" oifname "lan0" accept
    iifname "lan0" oifname "wg0" accept
    ct state established,related accept
  }
}

Significado: La política de forward es drop por defecto; existen aceptaciones explícitas entre wg0 y lan0.
Decisión: Si faltan estas reglas, el túnel puede estar arriba pero el tráfico no pasará. Añade reglas de forwarding mínimas y explícitas y registra los descartes durante el despliegue.

13) Ver drops y errores en vivo en interfaces (detecta congestión/MTU)

cr0x@server:~$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    RX:  bytes packets errors dropped  missed   mcast
    9876543210  8123456      0    1203       0  12345
    TX:  bytes packets errors dropped carrier collsns
    8765432109  7345678      0     987       0       0

Significado: Los drops son no nulos. Puede ser presión de colas, policing o un fallo del driver.
Decisión: Si los drops aumentan durante el uso de la VPN, investiga shaping/QoS en WAN, CPU y MTU. No toques la criptografía al azar primero.

14) Confirmar que el reenvío IP está habilitado (el clásico “túnel arriba, sin tráfico”)

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

Significado: El host enrutará paquetes.
Decisión: Si es 0 en un router Linux, encontraste la causa de la caída. Habilítalo persistentemente y confirma reglas de forward del firewall.

15) Probar que DNS es el problema, no la VPN

cr0x@server:~$ dig +short app.internal.example @10.20.0.53
10.20.30.45

Significado: La resolución de nombres funciona sobre el túnel hacia el DNS remoto.
Decisión: Si la IP resuelve pero la app sigue fallando, mira enrutamiento/ACLs de la app. Si no resuelve, tu informe de “VPN caída” es en realidad alcanzabilidad DNS o diseño split-horizon.

16) Trazar la ruta a una subred remota (encuentra una ruta por defecto rogue)

cr0x@server:~$ traceroute -n 10.20.30.10
traceroute to 10.20.30.10 (10.20.30.10), 30 hops max, 60 byte packets
 1  10.10.0.1  0.334 ms  0.291 ms  0.271 ms
 2  10.20.30.10  18.821 ms  18.654 ms  18.590 ms

Significado: El tráfico alcanza el host remoto en dos saltos—probablemente enrutamiento correcto a través del gateway del túnel.
Decisión: Si ves saltos saliendo hacia el ISP, estás filtrando rutas. Arregla el enrutamiento y considera routing policy o prefijos más específicos.

17) Para IPsec, comprobar xfrm state/policy (vista del kernel Linux)

cr0x@server:~$ sudo ip xfrm state | sed -n '1,60p'
src 198.51.100.10 dst 203.0.113.44
  proto esp spi 0xc0ffee12 reqid 1 mode tunnel
  replay-window 32 flag af-unspec
  auth-trunc hmac(sha256) 0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 128
  enc cbc(aes) 0xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
  lifetime config: soft 0 hard 0
  lifetime current: soft 0 hard 0

Significado: El kernel tiene un ESP SA instalado. Si faltan políticas, el tráfico no coincidirá y saldrá en claro (o será descartado por el firewall).
Decisión: Si el daemon dice “arriba” pero xfrm está vacío, el plano de control no instaló estado—verifica privilegios, soporte kernel o errores del daemon.

18) Medir throughput y pérdida de paquetes a través del túnel

cr0x@server:~$ iperf3 -c 10.20.30.10 -t 10
Connecting to host 10.20.30.10, port 5201
[  5] local 10.10.0.50 port 58312 connected to 10.20.30.10 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-10.00  sec   412 MBytes   346 Mbits/sec   92   1.12 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   0.00-10.00  sec   412 MBytes   346 Mbits/sec   92             sender
[  5]   0.00-10.00  sec   409 MBytes   343 Mbits/sec                  receiver

Significado: Hay retransmisiones pero el throughput es decente. Si las retransmisiones son muchas o el throughput colapsa, sospecha MTU, pérdida o saturación de CPU.
Decisión: Correlaciona con drops en interfaz y CPU. Si la CPU está alta, considera una mejora de hardware, opciones de offload (con cuidado) o reducir overhead de cifrado solo si la política lo permite.

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

1) “El túnel está arriba, pero nada puede comunicarse”

Síntomas: Handshake/SA establecido, pings al endpoint del túnel funcionan, pero tráfico subnet-a-subnet falla.

Causa raíz: Falta de IP forwarding, reglas de forward de firewall faltantes o falta de ruta a subredes remotas.

Solución: Habilitar forwarding (sysctl net.ipv4.ip_forward=1), añadir reglas explícitas de forward, verificar rutas con ip route get en ambos lados.

2) “Funciona unos minutos, luego muere hasta que ‘reiniciamos la VPN’”

Síntomas: Conectividad intermitente, a menudo tras periodos de inactividad.

Causa raíz: Timeout de NAT. WireGuard sin keepalive, o estado NAT-T de IPsec expirando.

Solución: WireGuard: fijar PersistentKeepalive = 25 en peers NATeados. IPsec: asegurar que DPD/keepalive esté configurado apropiadamente; validar estabilidad de UDP/4500.

3) “Pings pequeños funcionan, las apps se bloquean, transferencias de archivos cuelgan”

Síntomas: SSH ok, UI web carga a medias, SMB/HTTPS se cuelga, subidas grandes time out.

Causa raíz: Fallo de MTU/PMTUD o pérdida por fragmentación UDP.

Solución: Reducir MTU del túnel, hacer clamp TCP MSS y ejecutar pings DF para encontrar tamaños seguros de paquete.

4) “Después de añadir una nueva oficina, otra oficina se rompió”

Síntomas: Añadir el peer C hace que el peer B sea inaccesible; las rutas se flipan.

Causa raíz: Solapamiento de AllowedIPs (WireGuard) o selectores de tráfico solapados (IPsec basado en políticas). Cambios de preferencia de ruta.

Solución: Usa prefijos no solapados por sitio. Prefiere IPsec basado en rutas (VTI) y un protocolo de enrutamiento si estás creciendo.

5) “IPsec no sube, pero ambos lados juran que está configurado bien”

Síntomas: Intentos repetidos de negociación, NO_PROPOSAL_CHOSEN, AUTH failed o ausencia de CHILD_SA coincidente.

Causa raíz: Desajuste de propuestas, desajuste de identidad (IDs/certs), PSK mismatched o skew de reloj afectando validación de certificados.

Solución: Estandariza propuestas; verifica identidades; confirma sincronización horaria; inspecciona logs en ambos extremos y alinea transformaciones y selectores exactos.

6) “Handshakes de WireGuard ocurren, pero los contadores no se mueven”

Síntomas: wg show muestra handshake reciente pero transfer sigue en 0; o sólo una dirección incrementa.

Causa raíz: AllowedIPs erróneos en un extremo, firewall bloqueando el reenvío o enrutamiento asimétrico en la LAN.

Solución: Valida AllowedIPs en ambos peers; revisa tablas de enrutamiento; confirma reglas de forward; ejecuta tcpdump en wg0 y la interfaz LAN.

7) “Todo se rompió después de que el ISP cambió la IP pública de la sucursal”

Síntomas: El túnel no vuelve; los logs muestran desajuste de identidad o peer inalcanzable.

Causa raíz: Endpoint/identidad hardcodeada ligada a la IP antigua; NAT upstream cambió; agujeros de firewall faltantes.

Solución: Usa identidades estables (certs/FQDN para IPsec), DNS dinámico con controles de seguridad, o un modelo hub donde las sucursales inicien outbound.

8) “El rendimiento VPN es terrible en horas laborales”

Síntomas: Alta latencia, throughput bajo, picos de pérdida de paquetes, problemas de voz.

Causa raíz: Saturación de CPU por criptografía, congestión WAN, bufferbloat o QoS mal configurado.

Solución: Mide con iperf3, revisa drops en interfaz y CPU; aplica shaping/QoS adecuados; actualiza hardware si es necesario.

Tres microhistorias corporativas (anonimizadas, plausibles y dolorosamente familiares)

Incidente causado por una suposición errónea: “La VPN es la red”

Una empresa mediana abrió una nueva oficina. Ya usaban WireGuard para usuarios remotos, así que reutilizaron la misma hoja de ruta para sitio-a-sitio.
El despliegue fue rápido: túnel arriba, rutas añadidas, pings básicos exitosos. Todos chocaron manos y volvieron a sus tareas.

Dos semanas después, alguien notó que la nueva oficina podía alcanzar una subred legacy que debía estar aislada. No “ups, un servidor.” Toda la subred.
La suposición había sido: “Si está en el túnel, es de confianza como la LAN interna.” Esa suposición nunca había sido verdadera—pero ahora estaba codificada en AllowedIPs y reglas de forwarding permisivas.

La causa raíz fue sutil: AllowedIPs incluía un amplio 10.0.0.0/8 porque “podríamos añadir más subredes después.”
En el firewall, el forwarding entre wg0 y lan0 se permitía con un accept global.
Nadie documentó requisitos de segmentación porque “es solo un túnel de oficina.”

La solución no fue heroica. Acotaron AllowedIPs a prefijos exactos por sitio, implementaron ACLs explícitas entre redes de oficina y añadieron logs para flujos entre sitios.
La corrección real fue cultural: dejaron de tratar la VPN como un límite de confianza mágico y empezaron a verla como un transporte.

La lección: la forma más rápida de crear alcance sorpresa es “planear para crecer” enroutando todo el universo desde el día uno.

Optimización que salió mal: ajuste de criptografía en lugar de planificación de capacidad

Otra organización ejecutaba IPsec entre HQ y varias sucursales, mayormente en appliances de firewall de gama media.
El negocio se quejó de sincronización lenta de archivos y llamadas entrecortadas. El equipo de redes hizo lo que hacen bajo presión: buscaron una perilla.

Cambiaron propuestas IPsec a ajustes “más ligeros” y acortaron tiempos de vida, esperando mejorar rendimiento y estabilidad.
El cambio redujo un poco la carga de CPU—pero también aumentó la frecuencia de rekey y provocó ráfagas de pérdida de paquetes cada vez que los túneles rotaban claves.
La experiencia de usuario empeoró, y ahora lo hacía de forma periódica, difícil de explicar.

Depurar llevó tiempo porque cada sucursal se comportaba distinto. Algunas estaban detrás de NAT agresivo; otras con PPPoE; otras con ISP que detestan UDP fragmentado.
Los tiempos de vida cortos significaron intercambios de control más frecuentes. Esos eran exactamente los paquetes que la ruta odiaba.

La solución final fue aburrida: revertir a tiempos de vida sensatos, clamp MSS y aplicar shaping en el borde WAN.
Luego actualizaron dos appliances sobrecargados que simplemente no tenían CPU para las horas pico.
La “optimización” no era errónea en teoría; era errónea en contexto.

La lección: si tu WAN está saturado o tu router no tiene potencia, tocar suites de cifrado es sólo reorganizar sillas durante un incendio.

Práctica correcta y aburrida que salvó el día: perfiles estándar + validación pre-cambio

Una empresa con 15 oficinas ejecutaba una mezcla de WireGuard e IPsec debido a adquisiciones. Su equipo SRE odiaba más las caídas que el papeleo, así que construyeron un hábito:
cada cambio tenía una lista de verificación pre-flight, y cada túnel tenía un perfil “conocido-bueno”.

Un viernes por la tarde (siempre viernes), un ISP de sucursal hizo mantenimiento no anunciado y cambió la IP pública.
El túnel cayó. Pero en vez de adivinar, el on-call ejecutó los mismos tres comandos que siempre: comprobar alcanzabilidad del underlay, comprobar estado del plano de control, comprobar rutas.
La monitorización ya tenía alertas para “handshake mayor que N minutos” y “SA flapping.”

Ya tenían un modelo hub donde las sucursales iniciaban hacia afuera, más un procedimiento documentado para actualizar endpoints de sucursal.
Actualizaron el endpoint, vieron reanudarse los handshakes y verificaron aplicaciones clave con una pequeña suite de pings y chequeos TCP.
Impacto total: notable, pero contenido.

Lo que los salvó no fue un protocolo sofisticado. Fue consistencia:
configuraciones estándar, buena observabilidad y una cultura de “validar antes y después.”

Listas de verificación / plan paso a paso (lánzalo sin odiarte)

Elige el modelo primero: malla vs hub-and-spoke

• Malla (cada oficina con cada oficina): concepto simple, operativamente desordenado a medida que creces. Claves/perfiles se multiplican; la depuración se vuelve combinatoria.
• Hub-and-spoke (oficinas al hub HQ/nube): normalmente lo mejor para oficinas. Monitorización centralizada, menos túneles, control de políticas más fácil.

Regla de decisión: si tienes más que un puñado de sitios y no un equipo de red dedicado, construye un hub.
Si necesitas malla completa por razones de latencia, hazlo con automatización y convenciones fuertes o no lo hagas en absoluto.

Plan de despliegue WireGuard (oficina-a-oficina)

1. Define direccionamiento: asigna prefijos no solapados por sitio; documéntalos.
2. Elige un puerto de escucha y estandarízalo (no te pongas “creativo” por sitio).
3. Genera claves por router de sitio; almacena claves privadas en tu sistema de secretos.
4. Escribe AllowedIPs estrictamente: solo los prefijos remotos del sitio; evita rangos catch-all.
5. Configura PersistentKeepalive para sitios detrás de NAT.
6. Implementa política de firewall: listas blancas explícitas entre subredes; deny por defecto para movimiento lateral entre sitios.
7. Fija MTU y/o clamp MSS según tu realidad WAN (PPPoE/LTE casi siempre necesita atención).
8. Monitorización: alerta por edad de handshake, contadores de transferencia que se estanquen y pérdida/latencia hacia servicios clave.
9. Ejecuta pruebas post-cambio: ping, TCP connect a puertos clave, consulta DNS y una pequeña prueba de throughput.

Plan de despliegue IPsec (IKEv2, oficina-a-oficina)

1. Elige basado en rutas si es posible (VTI). Si te quedas con basado en políticas, mantén selectores simples y explícitos.
2. Estandariza un único conjunto de propuestas en la organización. Uno. No cinco. Evita modos “auto” del proveedor a menos que disfrutes arqueología.
3. Decide PSK vs certificados: PSK es rápido pero no escala bien; certificados requieren higiene PKI pero rinden a largo plazo.
4. Fija tiempos de vida a valores sensatos y consistentes para evitar churn.
5. Habilita NAT-T (según necesidad) y valida alcanzabilidad UDP/4500.
6. Planifica MTU: haz clamp MSS temprano; confirma que PMTUD funciona o asume que no.
7. Logging y monitorización: rastrea eventos SA up/down, frecuencia de rekey y notificaciones de error como NO_PROPOSAL_CHOSEN.
8. Documenta identidades: qué ID usa cada lado; qué cambia cuando la IP del ISP cambia; dónde viven los certificados.
9. Validación post-cambio: igual que WireGuard, además de asegurar que los selectores de child SA coinciden con las redes previstas.

Checklist de higiene operacional (aplica a ambos)

• Cada sitio tiene: propietario, propósito, subredes, endpoints de peers y un plan de rollback.
• Existe monitorización para: salud del plano de control del túnel y alcanzabilidad de aplicaciones.
• Estrategia de MTU escrita (incluyendo excepciones PPPoE/LTE).
• Las ventanas de cambio incluyen comprobaciones pre/post con salidas guardadas.
• Claves/PSKs/certs tienen procedimientos de rotación y revocación.
• Las reglas de firewall se revisan como código, no editadas por “quien tuviera acceso”.

FAQ

1) ¿Es WireGuard “más seguro” que IPsec?

No en un sentido que importe para la mayoría de despliegues de oficina. Ambos pueden ser seguros cuando están configurados correctamente.
WireGuard reduce la complejidad de configuración (menos formas de equivocarse), mientras que IPsec puede ser extremadamente robusto pero tiene una superficie de negociación y política mayor.

2) ¿Cuál es más fácil de depurar en guardia?

WireGuard, típicamente. wg show te dice la edad del handshake, el endpoint y los contadores en un solo vistazo.
La depuración de IPsec suele requerir leer logs de negociación y entender qué SA falló y por qué.

3) ¿Cuál es el error más común de WireGuard en oficinas?

AllowedIPs demasiado amplios o solapados. Causa secuestro de rutas, acceso no intencionado o tráfico que desaparece en el túnel equivocado.
Trata AllowedIPs como enrutamiento y autorización a la vez.

4) ¿Cuál es el error más común de IPsec en oficinas?

Valores “auto” en propuestas y perfiles desajustados entre proveedores. Funciona hasta que no, y entonces nadie puede explicar por qué.
Estandariza un único perfil IKEv2/ESP y aplícalo por todas partes.

5) ¿Necesito enrutamiento dinámico (OSPF/BGP) sobre la VPN?

Si tienes más que unos pocos sitios o esperas cambios, el enrutamiento dinámico reduce trabajo—especialmente con túneles basados en rutas.
Si eres pequeño y estable, rutas estáticas pueden estar bien, pero documéntalas y prueba caminos de failover.

6) ¿Cómo evito problemas de MTU sin convertirme en un mago de paquetes?

Sé conservador: baja la MTU del túnel y haz clamp MSS en el borde.
Valida con pings DF y una transferencia TCP real. Asume que PMTUD fallará en al menos un camino ISP.

7) ¿Deben iniciar las sucursales el túnel, o debe iniciarlo HQ?

Prefiere que las sucursales inicien hacia afuera a un hub estable. Evita agujeros de firewall entrantes en sucursales y tolera mejor IPs cambiantes de sucursal.
También simplifica la respuesta a incidentes: un hub que vigilar.

8) ¿Puedo mezclar WireGuard e IPsec en una organización?

Sí, y muchos lo hacen por adquisiciones o limitaciones de proveedores. El riesgo es inconsistencia operacional.
Mitígalo con runbooks estándar, monitorización que hable en resultados (latencia, alcanzabilidad) y un plan para converger con el tiempo.

9) ¿Necesito certificados para IPsec, o PSK está bien?

PSK está bien para pocos sitios y manejo disciplinado. Los certificados escalan mejor, especialmente cuando cambia el personal y necesitas revocación.
Si haces PKI, hazlo bien: sincronización de tiempo, automatización de renovación y mapeo claro de identidades.

10) ¿Qué suele significar “túnel arriba pero tráfico unidireccional”?

Enrutamiento asimétrico, rarezas de estado NAT o reglas de firewall que permiten una dirección.
Demuéstralo con contadores (wg show o bytes de SA) y capturas en ambos extremos; luego arregla simetría de rutas y políticas de reenvío.

Siguientes pasos que realmente puedes entregar

Si comienzas desde cero y controlas ambos extremos, despliega WireGuard en un layout hub-and-spoke.
Mantén AllowedIPs estrechos, configura keepalive para sitios NATeados y aplica clamp MSS temprano. Añade monitorización para edad de handshake y cheques de aplicación, no solo “túnel arriba.”

Si ya estás en IPsec, no lo arranques porque sea molesto. Hazlo aburrido:
estandariza un perfil IKEv2, mueve a túneles basados en rutas cuando puedas, alinea tiempos de vida e instrumenta rekeys y errores.
La mayoría de misterios de IPsec desaparecen cuando dejas de permitir que todos inventen su propio conjunto de propuestas.

Finalmente: escribe el runbook que desearías que existiera. Usa el orden de diagnóstico rápido, guarda los comandos a mano y almacena salidas pre/post con cada cambio.
Tu yo futuro seguirá recibiendo paginaciones, pero al menos tendrá recibos.