MikroTik WireGuard sitio a sitio: plantilla limpia para dos oficinas

Objetivos de diseño (para qué estamos optimizando)

Una VPN entre dos oficinas puede “funcionar” y aun así ser un desastre operativo. El objetivo aquí no es presumir ingenio.
El objetivo es poder responder, rápido y con evidencias, estas preguntas:

• ¿Está el túnel arriba? (handshake + bytes incrementando, no sensaciones)
• ¿Es correcta la ruta? (rutas y bypass de NAT, no enredos accidentales)
• ¿Es estable el rendimiento? (MTU/MSS, colas, interacciones con fasttrack)
• ¿Puede mantenerlo un administrador junior? (nombres claros, reglas mínimas)
• ¿Podemos ampliar a más sitios luego? (plan de direcciones y disposición de peers)

Esta plantilla usa un modelo enrutado (subredes LAN distintas por oficina). Sin bridge. Sin extensión L2.
El bridging es cómo importas tormentas de broadcast y elecciones misteriosas de Windows a tu vida. Ya tienes suficiente emoción.

También: mantén el espacio de IPs del túnel separado del espacio LAN. Si reutilizas una subred LAN dentro del túnel “porque está disponible”,
estás construyendo un fallo futuro. Es solo gratificación diferida, pero para dolor.

Algunos datos interesantes (contexto WireGuard + MikroTik)

Algunos puntos de contexto cortos que realmente te ayudan a tomar mejores decisiones:

1. WireGuard es intencionalmente pequeño. Fue diseñado con una base de código reducida comparada con pilas VPN heredadas, buscando reducir la superficie de ataque y la complejidad de auditoría.
2. Usa criptografía moderna por defecto. Sin el circo de negociación de suites de cifrado; el protocolo elige un conjunto estrecho (como ChaCha20-Poly1305) para evitar degradaciones.
3. “Handshake arriba” no significa “flujo de tráfico”. WireGuard puede establecer handshake incluso cuando enrutamiento/NAT/firewall impiden que los paquetes de carga útil vayan a algún lado útil.
4. WireGuard es sin estado de una manera específica. No construye una “sesión” tradicional como algunas VPN; los peers se identifican por claves públicas y los endpoints pueden desplazarse.
5. PersistentKeepalive existe por la realidad del NAT. Si un lado está detrás de NAT, paquetes periódicos mantienen la asociación viva para que el tráfico entrante no muera tras el tiempo de inactividad.
6. MikroTik añadió WireGuard relativamente tarde. El soporte en RouterOS llegó años después de que WireGuard fuera popular en Linux, por eso flotas antiguas de RouterOS a menudo muestran una mezcla de VPN heredadas y WG.
7. La simplicidad de WireGuard traslada complejidad al enrutamiento. Eso es una característica. Quieres que el enrutamiento sea explícito, inspeccionable y registrado.
8. Los problemas de MTU se hicieron más visibles con apps web modernas. Registros TLS más grandes, HTTP/2 y pilas “todo encapsulado” hacen que la fragmentación y MTU negro aparezcan como fallos extraños de aplicaciones.

Una cita, porque la gente de operaciones también merece poesía:
Todo falla, todo el tiempo. — Werner Vogels

No cínico. Práctico. Construimos sistemas que fallan de forma predecible y se recuperan limpiamente.

Plan de red: subredes, IPs del túnel y DNS

Distribución de las oficinas (ejemplo)

• LAN Oficina A: 10.10.10.0/24 (router: 10.10.10.1)
• LAN Oficina B: 10.20.20.0/24 (router: 10.20.20.1)
• Red del túnel WireGuard: 10.99.0.0/30
  • IP WG Oficina A: 10.99.0.1/30
  • IP WG Oficina B: 10.99.0.2/30
• Puerto UDP WG: 13231/udp (elige un puerto y documéntalo)

¿Por qué /30 para el túnel?

Porque es un enlace punto a punto. Necesitas dos IPs. Un /30 es aburrido, ajustado y evita que luego “amablemente” añadas hosts aleatorios a la red del túnel.
Si planeas 10+ sitios, usa /24 y asigna /32 por sitio—pero para dos oficinas, no sobreconstruyas.

Estrategia DNS (elige una, deliberadamente)

El enrutamiento sitio a sitio es la mitad de la batalla. El nombrado es la otra mitad. Tienes tres opciones sensatas:

1. Cada sitio resuelve nombres locales localmente. Si la Oficina A necesita recursos de la Oficina B, usa FQDNs que resuelvan a 10.20.20.0/24 y viceversa.
2. DNS central en un sitio. Apunta ambos sitios a un DNS autoritativo (alcanzable vía túnel). Esto es común en corporaciones pero hace que la disponibilidad DNS dependa del túnel.
3. DNS con visión dividida. Mejor para redes híbridas, más molesto de mantener. Vale la pena si tienes servicios solapados o separación nube/privado.

Mi sesgo operativo: mantén DNS local cuando sea posible y reenvía explícitamente solo lo necesario a través del túnel. Reduce las “la VPN está caída” que en realidad son “el DNS está caído”.

Plantilla de configuración limpia: Oficina A y Oficina B

La plantilla está diseñada para RouterOS v7+. Si estás en RouterOS más antiguo, actualiza. Si no puedes actualizar, no puedes tener cosas bonitas.
(No es broma. Es una política de mantenimiento.)

Convenciones de nombres que te salvan después

• Nombre de interfaz: wg-s2s-officeB (dile al tú del futuro qué es)
• Nombres de listas de direcciones: lan-officeA, lan-officeB
• Prefijos en comentarios de firewall: S2S-WG: para filtrar rápido

Oficina A (IP pública, escucha)

Suposiciones:
El router de la Oficina A tiene una WAN pública o un reenvío de puerto estable hacia él. La Oficina B puede estar detrás de NAT.
Haremos que Oficina A escuche en UDP 13231 y que Oficina B inicie la conexión con keepalive.

cr0x@server:~$ cat office-a-routeros.rsc
# Office A: MikroTik RouterOS v7+ WireGuard site-to-site template

# Variables you must set:
# - Replace PUBLIC_WAN_INTERFACE if needed (example: ether1)
# - Set correct LAN interface/list and subnets
# - Paste actual keys (do not reuse this placeholder layout)

# 1) WireGuard interface
/interface/wireguard/add name=wg-s2s-officeB listen-port=13231 mtu=1420 comment="S2S-WG: OfficeA<->OfficeB"

# 2) WireGuard tunnel IP
/ip/address/add address=10.99.0.1/30 interface=wg-s2s-officeB comment="S2S-WG: tunnel IP OfficeA"

# 3) Peer (Office B)
/interface/wireguard/peers/add interface=wg-s2s-officeB public-key="OFFICE_B_PUBLIC_KEY" \
  allowed-address=10.99.0.2/32,10.20.20.0/24 \
  comment="S2S-WG: peer OfficeB"

# 4) Route to Office B LAN via WireGuard
/ip/route/add dst-address=10.20.20.0/24 gateway=wg-s2s-officeB comment="S2S-WG: route to OfficeB LAN"

# 5) Address lists for cleaner firewall rules
/ip/firewall/address-list/add list=lan-officeA address=10.10.10.0/24 comment="OfficeA LAN"
/ip/firewall/address-list/add list=lan-officeB address=10.20.20.0/24 comment="OfficeB LAN"

# 6) Firewall: allow WireGuard inbound on WAN
/ip/firewall/filter/add chain=input action=accept protocol=udp dst-port=13231 in-interface=ether1 \
  comment="S2S-WG: allow WireGuard UDP from WAN"

# 7) Firewall: allow WireGuard interface traffic to the router itself (optional but practical)
/ip/firewall/filter/add chain=input action=accept in-interface=wg-s2s-officeB \
  comment="S2S-WG: allow input from WireGuard (management/ping as needed)"

# 8) Firewall: allow forwarding between LANs over the tunnel
/ip/firewall/filter/add chain=forward action=accept in-interface=wg-s2s-officeB out-interface-list=LAN \
  comment="S2S-WG: allow WG to LAN forwarding"
/ip/firewall/filter/add chain=forward action=accept in-interface-list=LAN out-interface=wg-s2s-officeB \
  comment="S2S-WG: allow LAN to WG forwarding"

# 9) NAT bypass (no masquerade between sites)
# Place this BEFORE any general masquerade rule.
/ip/firewall/nat/add chain=srcnat action=accept src-address=10.10.10.0/24 dst-address=10.20.20.0/24 \
  comment="S2S-WG: no-NAT OfficeA->OfficeB"

# 10) Optional: log drops related to the tunnel during bring-up (disable after)
/ip/firewall/filter/add chain=forward action=log log-prefix="S2S-WG DROP " src-address=10.10.10.0/24 dst-address=10.20.20.0/24 \
  comment="S2S-WG: temporary debug log OfficeA->OfficeB"

Oficina B (detrás de NAT, inicia)

Oficina B establecerá un endpoint apuntando a la IP/DNS pública de Oficina A, y establecerá persistent-keepalive=25s.
No es magia; es simplemente enseñar a las cajas NAT a mantener viva la asociación.

cr0x@server:~$ cat office-b-routeros.rsc
# Office B: MikroTik RouterOS v7+ WireGuard site-to-site template

# 1) WireGuard interface
/interface/wireguard/add name=wg-s2s-officeA listen-port=13231 mtu=1420 comment="S2S-WG: OfficeB<->OfficeA"

# 2) WireGuard tunnel IP
/ip/address/add address=10.99.0.2/30 interface=wg-s2s-officeA comment="S2S-WG: tunnel IP OfficeB"

# 3) Peer (Office A)
/interface/wireguard/peers/add interface=wg-s2s-officeA public-key="OFFICE_A_PUBLIC_KEY" \
  endpoint-address=203.0.113.10 endpoint-port=13231 persistent-keepalive=25s \
  allowed-address=10.99.0.1/32,10.10.10.0/24 \
  comment="S2S-WG: peer OfficeA"

# 4) Route to Office A LAN via WireGuard
/ip/route/add dst-address=10.10.10.0/24 gateway=wg-s2s-officeA comment="S2S-WG: route to OfficeA LAN"

# 5) Address lists for cleaner firewall rules
/ip/firewall/address-list/add list=lan-officeA address=10.10.10.0/24 comment="OfficeA LAN"
/ip/firewall/address-list/add list=lan-officeB address=10.20.20.0/24 comment="OfficeB LAN"

# 6) Firewall: allow WireGuard traffic (input from WAN not needed if behind NAT, but allow from WG interface)
/ip/firewall/filter/add chain=input action=accept in-interface=wg-s2s-officeA \
  comment="S2S-WG: allow input from WireGuard (management/ping as needed)"

# 7) Firewall: allow forwarding between LANs over the tunnel
/ip/firewall/filter/add chain=forward action=accept in-interface=wg-s2s-officeA out-interface-list=LAN \
  comment="S2S-WG: allow WG to LAN forwarding"
/ip/firewall/filter/add chain=forward action=accept in-interface-list=LAN out-interface=wg-s2s-officeA \
  comment="S2S-WG: allow LAN to WG forwarding"

# 8) NAT bypass (no masquerade between sites)
# Place this BEFORE any general masquerade rule.
/ip/firewall/nat/add chain=srcnat action=accept src-address=10.20.20.0/24 dst-address=10.10.10.0/24 \
  comment="S2S-WG: no-NAT OfficeB->OfficeA"

# 9) Optional: log drops related to the tunnel during bring-up (disable after)
/ip/firewall/filter/add chain=forward action=log log-prefix="S2S-WG DROP " src-address=10.20.20.0/24 dst-address=10.10.10.0/24 \
  comment="S2S-WG: temporary debug log OfficeB->OfficeA"

Broma #1: WireGuard es tan simple que pasarás la mayor parte del tiempo depurando las partes que no configuraste, lo cual es sorprendentemente acorde con la red.

Manejo de claves (no improvises esto)

Genera claves en cada router e intercambia las claves públicas. Mantén privadas las claves privadas. Sí, la frase es obvia.
Aun así, es donde los equipos fallan bajo presión.

cr0x@server:~$ ssh admin@office-a 'wg genkey | tee /tmp/wg.key | wg pubkey > /tmp/wg.pub && ls -l /tmp/wg.* && cat /tmp/wg.pub'
-rw------- 1 admin admin 45 Dec 28 10:12 /tmp/wg.key
-rw-r--r-- 1 admin admin 45 Dec 28 10:12 /tmp/wg.pub
hF2m3dZyJf1q3oV6n8r2b1P9kY0aQk7mZxv6b2rNQXo=

Decisión: almacena la clave privada solo en la configuración de la interfaz WireGuard del router; no la envíes por correo, no la pegues en tickets, no la guardes “temporalmente” en chat compartido.
Si necesitas auditabilidad, guárdala en un gestor de secretos adecuado con controles de acceso estrictos.

Firewall y NAT: qué permitir, qué denegar

Tu política de firewall debe ser explícita. “Permitimos WireGuard” no es una política; es un estado de ánimo.
Para sitio a sitio, quieres:

• Input: permitir UDP puerto 13231 al router (solo en el lado que escucha en WAN pública)
• Forward: permitir tráfico LAN↔WG (lo más acotado posible)
• NAT: aceptar (bypass) tráfico entre sitios antes de la mascarada general

Sobre FastTrack (realidad específica de MikroTik)

FastTrack puede ser genial hasta que no lo sea. Dependiendo de tu versión de RouterOS y configuración, FastTrack puede evitar partes del tracking de conexiones y mangle,
y eso puede interferir con shaping de VPN, contabilidad de firewall o reglas de MSS clamping.

Mi regla: no FastTrackees tráfico que entre o salga de WireGuard hasta que hayas probado que se comporta. Luego, si lo habilitas, hazlo con excepciones y mide.

NAT bypass: la causa más común de “conecta pero no funciona”

Si haces masquerade del tráfico OficinaA→OficinaB, Oficina B verá paquetes provenientes de la IP del router en el túnel o la IP WAN del router, no de la IP original del cliente.
Eso rompe auditorías, puede romper ACLs y convierte la resolución de problemas en un juego de adivinanzas triste.

Añade reglas explícitas srcnat action=accept para las subredes intersitio y colócalas antes de cualquier masquerade genérico.
Luego deja un comentario corto en la regla de masquerade advirtiendo al tú del futuro que no la reordenes.

Diseño de enrutamiento: rutas estáticas que no te sorprenden

Para dos sitios, las rutas estáticas son la cantidad correcta de aburrimiento. El enrutamiento dinámico puede ser genial, pero también es un segundo sistema móvil
con sus propios modos de fallo, su propio modelo de seguridad y sus propios tickets de “alguien cambió una métrica”.

Usa una ruta por LAN remota, con el gateway establecido en la interfaz WireGuard. Eso es todo.
Si luego añades más sitios, aún puedes mantener rutas estáticas si la cantidad sigue siendo razonable.
Si crece, usa un protocolo de enrutamiento intencionalmente, no porque tu colega quiera practicar.

MTU, MSS clamping y por qué “pings pequeños funcionan” es una trampa

WireGuard encapsula paquetes dentro de UDP. La encapsulación añade overhead. El overhead reduce la MTU efectiva. Eso es normal.
El modo de fallo también es normal: algunas redes descartan mensajes ICMP “fragmentation needed”, así que el path MTU discovery falla.
Entonces paquetes TCP grandes desaparecen y los usuarios informan “algunos sitios cargan, otros no”.

Ajusta el MTU de WireGuard a algo conservador (1420 es un punto de partida común). Luego prueba con pings grandes y TCP real.
Si ves rarezas, aplica clamp de MSS en el tráfico que atraviesa el túnel.

Regla de MSS clamping (ejemplo)

Esta es una solución práctica para problemas de MTU negro. No sustituye a entender tu path, pero mantiene la producción estable.

cr0x@server:~$ cat mss-clamp-routeros.rsc
# Apply on both sides if needed
/ip/firewall/mangle/add chain=forward action=change-mss new-mss=1360 protocol=tcp tcp-flags=syn \
  in-interface=wg-s2s-officeB out-interface-list=LAN comment="S2S-WG: clamp MSS WG->LAN"
/ip/firewall/mangle/add chain=forward action=change-mss new-mss=1360 protocol=tcp tcp-flags=syn \
  in-interface-list=LAN out-interface=wg-s2s-officeB comment="S2S-WG: clamp MSS LAN->WG"

Decisión: añade MSS clamping solo si observas fallos relacionados con MTU (o si sabes que atraviesas enlaces con MTU menor).
Aplicarlo a todo “por si acaso” puede reducir el rendimiento. No es catastrófico, pero no lo hagas por imitación.

Tareas operativas: comandos, salidas y decisiones (12+)

Estas son las tareas que ejecutas durante el bring-up y durante incidentes. Cada una incluye qué buscar y qué decisión tomar.
Úsalas como runbook, no como ritual.

Task 1: Verify WireGuard interface exists and is running (RouterOS)

cr0x@server:~$ ssh admin@office-a 'interface/wireguard/print detail where name="wg-s2s-officeB"'
 0 name="wg-s2s-officeB" mtu=1420 listen-port=13231 private-key="<hidden>" running=yes

Significado de la salida: running=yes confirma que la interfaz está operativa.
Decisión: si running=no, arregla la creación de la interfaz, la presencia de la clave o problemas de versión de RouterOS antes de tocar firewall/enrutamiento.

Task 2: Confirm the peer shows a recent handshake

cr0x@server:~$ ssh admin@office-a 'interface/wireguard/peers/print detail where comment~"OfficeB"'
 0 interface=wg-s2s-officeB public-key="OFFICE_B_PUBLIC_KEY" allowed-address=10.99.0.2/32,10.20.20.0/24
   last-handshake=1m12s rx=183204 tx=201889 endpoint-address=198.51.100.55 endpoint-port=51820

Significado de la salida: last-handshake es reciente y los contadores rx/tx aumentan.
Decisión: si el handshake está vacío/antiguo, verifica la accesibilidad UDP y la configuración del endpoint antes de depurar rutas.

Task 3: Validate tunnel IP addresses are present

cr0x@server:~$ ssh admin@office-a 'ip/address/print where interface="wg-s2s-officeB"'
 0   address=10.99.0.1/30 network=10.99.0.0 interface=wg-s2s-officeB

Significado de la salida: el router tiene la IP correcta del túnel.
Decisión: si falta, el tráfico puede aún hacer handshake pero el enrutamiento será incorrecto; añade la dirección antes de continuar.

Task 4: Check that the static route exists and is active

cr0x@server:~$ ssh admin@office-a 'ip/route/print detail where dst-address=10.20.20.0/24'
 0 dst-address=10.20.20.0/24 gateway=wg-s2s-officeB distance=1 scope=30 target-scope=10 active=yes

Significado de la salida: active=yes indica que el router considera la ruta usable.
Decisión: si está inactiva, puede que la interfaz esté caída, gateway incorrecto o conflicto de ruta (una ruta más específica en otra parte).

Task 5: Ping the remote tunnel IP from the router

cr0x@server:~$ ssh admin@office-a 'ping 10.99.0.2 count=5'
  SEQ HOST                                     SIZE TTL TIME       STATUS
    0 10.99.0.2                                   56  64 23ms       ok
    1 10.99.0.2                                   56  64 22ms       ok
    2 10.99.0.2                                   56  64 22ms       ok
    3 10.99.0.2                                   56  64 23ms       ok
    4 10.99.0.2                                   56  64 22ms       ok

Significado de la salida: la conectividad de la IP del túnel es buena.
Decisión: si esto falla pero el handshake existe, busca reglas input en el lado remoto y errores en allowed-address.

Task 6: Ping a remote LAN host from a local LAN host (end-to-end)

cr0x@server:~$ ping -c 4 10.20.20.50
PING 10.20.20.50 (10.20.20.50) 56(84) bytes of data.
64 bytes from 10.20.20.50: icmp_seq=1 ttl=62 time=25.1 ms
64 bytes from 10.20.20.50: icmp_seq=2 ttl=62 time=24.6 ms
64 bytes from 10.20.20.50: icmp_seq=3 ttl=62 time=24.9 ms
64 bytes from 10.20.20.50: icmp_seq=4 ttl=62 time=24.7 ms

--- 10.20.20.50 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms

Significado de la salida: la ruta de negocio real funciona.
Decisión: si router-a-router funciona pero host-a-host falla, probablemente falten reglas de firewall LAN, gateway por defecto incorrecto en los hosts o enrutamiento asimétrico.

Task 7: Trace the path to confirm routing is actually used

cr0x@server:~$ traceroute -n 10.20.20.50
traceroute to 10.20.20.50 (10.20.20.50), 30 hops max, 60 byte packets
 1  10.10.10.1  0.395 ms  0.324 ms  0.311 ms
 2  10.99.0.2   23.012 ms  22.911 ms  22.903 ms
 3  10.20.20.50 24.771 ms  24.701 ms  24.679 ms

Significado de la salida: el salto 2 es el endpoint remoto del túnel; el enrutamiento es correcto.
Decisión: si el salto 2 muestra un salto del ISP, tu tráfico se está filtrando a Internet porque tu ruta/NAT está mal.

Task 8: Validate NAT bypass rule ordering

cr0x@server:~$ ssh admin@office-a 'ip/firewall/nat/print where chain="srcnat"'
 0 chain=srcnat action=accept src-address=10.10.10.0/24 dst-address=10.20.20.0/24 comment="S2S-WG: no-NAT OfficeA->OfficeB"
 1 chain=srcnat action=masquerade out-interface=ether1 comment="MASQ: internet"

Significado de la salida: la regla accept está por encima de la masquerade. Bien.
Decisión: si la masquerade está por encima del accept, corrige el orden. Esto no es negociable si te importa preservar IP de origen.

Task 9: Confirm firewall counters increment on the intended rules

cr0x@server:~$ ssh admin@office-a 'ip/firewall/filter/print stats where comment~"S2S-WG: allow"'
 0 chain=input action=accept packets=921 bytes=87244 comment="S2S-WG: allow WireGuard UDP from WAN"
 1 chain=input action=accept packets=110 bytes=9320 comment="S2S-WG: allow input from WireGuard (management/ping as needed)"
 2 chain=forward action=accept packets=12844 bytes=11833492 comment="S2S-WG: allow WG to LAN forwarding"
 3 chain=forward action=accept packets=12192 bytes=11011220 comment="S2S-WG: allow LAN to WG forwarding"

Significado de la salida: el tráfico coincide con tus reglas allow previstas, no cae en un drop por defecto.
Decisión: si los contadores se quedan en cero mientras los usuarios se quejan, no estás en el camino que crees—revisa rutas y listas de interfaces.

Task 10: Capture packets on the WireGuard interface (RouterOS sniffer)

cr0x@server:~$ ssh admin@office-a 'tool/sniffer/quick interface=wg-s2s-officeB ip-address=10.20.20.50'
  TIME   NUM  DIR  SRC-ADDRESS        DST-ADDRESS        PROTOCOL  SIZE
  1.234   12  <->  10.10.10.25        10.20.20.50        icmp      98
  1.456   13  <->  10.20.20.50        10.10.10.25        icmp      98

Significado de la salida: los paquetes atraviesan la interfaz WG en ambas direcciones.
Decisión: si ves solo una dirección, sospecha drops de firewall en el otro lado o problemas de ruta/puerta de enlace en el host destino.

Task 11: Check for route conflicts (more specific routes winning)

cr0x@server:~$ ssh admin@office-a 'ip/route/print where dst-address~"10.20.20."'
 0 dst-address=10.20.20.0/24 gateway=wg-s2s-officeB distance=1 active=yes
 1 dst-address=10.20.20.0/24 gateway=10.10.10.254 distance=1 active=no

Significado de la salida: hay otra ruta para el mismo prefijo, actualmente inactiva.
Decisión: elimina o corrige rutas en conflicto; de lo contrario, futuros cambios de estado pueden volcar tu tráfico inesperadamente.

Task 12: MTU test with “do not fragment” ping

cr0x@server:~$ ping -M do -s 1380 -c 3 10.20.20.50
PING 10.20.20.50 (10.20.20.50) 1380(1408) bytes of data.
1388 bytes from 10.20.20.50: icmp_seq=1 ttl=62 time=25.9 ms
1388 bytes from 10.20.20.50: icmp_seq=2 ttl=62 time=25.4 ms
1388 bytes from 10.20.20.50: icmp_seq=3 ttl=62 time=25.5 ms

--- 10.20.20.50 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms

Significado de la salida: tamaño de payload 1380 funciona sin fragmentación; es una buena señal para el rendimiento TCP.
Decisión: si falla en tamaños moderados (por ejemplo 1360–1380), implementa MSS clamping y/o baja MTU de WG.

Task 13: Confirm WireGuard UDP port is reachable from the internet (from a test host)

cr0x@server:~$ sudo nmap -sU -p 13231 203.0.113.10
Starting Nmap 7.94 ( https://nmap.org ) at 2025-12-28 10:40 UTC
Nmap scan report for 203.0.113.10
Host is up (0.021s latency).

PORT      STATE         SERVICE
13231/udp open|filtered unknown

Nmap done: 1 IP address (1 host up) scanned in 1.23 seconds

Significado de la salida: UDP suele mostrar open|filtered porque no hay handshake como TCP.
Decisión: si muestra closed, probablemente tengas bloqueo en ISP/edge o reenvío de puertos/firewall incorrecto. Arregla la alcanzabilidad antes de tocar peers.

Task 14: Watch WireGuard transfer counters during a test

cr0x@server:~$ ssh admin@office-b 'interface/wireguard/peers/print detail where comment~"OfficeA"'
 0 interface=wg-s2s-officeA public-key="OFFICE_A_PUBLIC_KEY" allowed-address=10.99.0.1/32,10.10.10.0/24
   last-handshake=14s rx=901233 tx=884120 endpoint-address=203.0.113.10 endpoint-port=13231

Significado de la salida: los contadores cambian al generar tráfico. Si no lo hacen, tu prueba puede no estar pasando por el túnel.
Decisión: si rx aumenta pero tx no (o viceversa), revisa firewall y rutas en la dirección que falta.

Guion de diagnóstico rápido

Cuando está roto y alguien está mirando, necesitas un orden de operaciones despiadado. No reinicies el túnel.
No “simplemente reinicies el router”. Así borras evidencia y prolongas la interrupción.

Primero: ¿el peer está realmente vivo?

1. Revisa last-handshake en ambos lados.
2. Revisa contadores rx/tx mientras generas tráfico.
3. Si el handshake está obsoleto: valida la alcanzabilidad UDP (ISP, reenvío de puertos, firewall WAN).

Llamada de cuello de botella: si el handshake está muerto, tu cuello de botella es la alcanzabilidad de subcapa (underlay) (ruta WAN, NAT, firewall).

Segundo: ¿el enrutamiento apunta al túnel?

1. Verifica que existan rutas estáticas y estén activas.
2. Desde un host LAN, haz traceroute a la IP LAN remota.
3. En el router, captura en la interfaz WG para ese flujo.

Llamada de cuello de botella: si el handshake está bien pero el traceroute muestra saltos del ISP, tu cuello de botella es la política de enrutamiento/NAT.

Tercero: ¿firewall/NAT reescribe o descarta?

1. Verifica el orden de NAT: el accept bypass debe estar por encima de mascarade.
2. Revisa contadores del firewall en las reglas allow.
3. Habilita temporalmente logs dirigidos para las dos subredes LAN.

Llamada de cuello de botella: si los paquetes golpean logs de drop o contadores de masquerade inesperadamente, tu cuello de botella es la política (filter/NAT).

Cuarto: ¿es raro por MTU/rendimiento?

1. Haz pings con DF y cargas grandes.
2. Prueba un flujo TCP único (copia de archivos o iperf si lo tienes).
3. Si fallan apps intermitentes: aplica clamp MSS y vuelve a probar.

Llamada de cuello de botella: si pings pequeños funcionan pero los grandes fallan, tu cuello de botella es el MTU blackholing.

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

1) El handshake está arriba, pero nadie puede alcanzar el otro sitio

Síntoma: last-handshake es reciente, pero ping/traceroute a la LAN remota falla.

Causa raíz: ruta estática faltante, allowed-address erróneo o masquerade NAT afectando el tráfico intersitio.

Solución: añade/activa la ruta a la LAN remota vía WG; asegura que allowed-address del peer incluya la LAN remota; añade regla de bypass NAT accept por encima de la masquerade.

2) Solo funciona una dirección (A→B funciona, B→A falla)

Síntoma: puedes alcanzar B desde A, pero no A desde B.

Causa raíz: enrutamiento asimétrico o camino de retorno bloqueado; gateway por defecto erróneo en el host remoto; faltan reglas de forward en un lado.

Solución: confirma gateways por defecto en los hosts destino apunten al router del sitio; verifica reglas forward accept en ambos sentidos; captura en la interfaz WG para ver si existe tráfico de retorno.

3) Algunas aplicaciones funcionan, otras se cuelgan (especialmente HTTPS, SMB, RDP)

Síntoma: DNS resuelve, pings pequeños funcionan, pero apps web agotan o SMB se queda atascado.

Causa raíz: MTU/PMTUD blackhole; mensajes de fragmentación bloqueados aguas arriba.

Solución: baja MTU de WireGuard (comienza en 1420 y ajusta) y/o aplica MSS clamping en paquetes TCP SYN reenviados.

4) El túnel cae después de unos minutos de inactividad

Síntoma: el handshake envejece; el tráfico se reanuda solo cuando alguien “lo intenta de nuevo”.

Causa raíz: expiración de la asociación NAT en el lado detrás de NAT; no hay keepalive.

Solución: establece persistent-keepalive=25s en el peer NATeado; verifica que UDP saliente esté permitido.

5) El tráfico entre sitios está NATeado y las ACL fallan

Síntoma: los servidores remotos ven tráfico desde el router remoto, no desde la IP real del cliente; fallan reglas de acceso o la auditoría es inútil.

Causa raíz: una regla masquerade genérica coincide antes de tu bypass.

Solución: añade srcnat action=accept para el tráfico LAN-a-LAN y colócalo por encima de la masquerade; verifica contadores.

6) Puedes hacer ping a las IPs del túnel pero no a las LAN remotas

Síntoma: 10.99.0.1↔10.99.0.2 ping funcionan, pero 10.10.10.0/24↔10.20.20.0/24 falla.

Causa raíz: allowed-address incluye solo /32s del túnel, no los prefijos LAN; o la cadena forward no permite forwarding LAN.

Solución: incluye subredes LAN remotas en allowed-address; añade reglas forward accept LAN↔WG en ambos sentidos.

7) Pico de CPU y colapso de throughput durante transferencias

Síntoma: copias grandes de archivos saturan la CPU en un router; la latencia sube; quejas de lentitud general.

Causa raíz: modelo de router insuficiente, colas/fasttrack mal configuradas o logging excesivo en firewall.

Solución: deshabilita reglas de logging de debug; asegúrate de no estar registrando cada paquete forward; considera actualización de hardware o shaping intencional (no al tanteo).

Tres microhistorias corporativas (cómo sale mal)

Incidente por una suposición errónea: “Handshake significa que está bien”

Una empresa mediana conectó dos oficinas con WireGuard en MikroTik. El admin hizo la validación clásica:
handshake es reciente, por lo tanto la VPN está arriba. Anunciaron éxito. La gente empezó a mapear unidades de red.

En una hora, comenzaron los tickets: algunas PCs podían acceder a un servidor de archivos remoto, otras no. Las PCs “funcionantes” estaban en una VLAN
que casualmente tenía una política de firewall permisiva. El resto estaba en una VLAN restringida cuyas reglas forward no incluían la interfaz WireGuard.

El admin siguió tocando ajustes de WireGuard. Nada cambió, porque el túnel no era el problema. La prueba estaba ahí:
los contadores del peer aumentaban durante pings, pero los contadores de la cadena forward no se movían para tráfico real de usuarios.
Depuraban la capa equivocada porque asumieron que el handshake equivalía a conectividad extremo a extremo.

La solución fue mundana: añadir reglas forward explícitas para las subredes LAN específicas hacia y desde la interfaz WG, y acotarlas a los puertos necesarios.
Tras eso, la conectividad fue consistente y el equipo de seguridad dejó de observar.

Optimización que salió mal: “FastTrack para todo”

Otra organización tenía una queja de rendimiento: transferencias grandes entre oficinas eran más lentas de lo esperable. Alguien sugirió habilitar FastTrack ampliamente
para reducir la carga CPU y aumentar throughput. Lo hicieron en la cadena forward con una regla amplia que coincidía con conexiones establecidas.

Por un día, todo lució bien. La CPU bajó. Los gráficos se calmaron. Luego comenzaron los informes extraños:
algunas sesiones HTTPS se atascaban, especialmente apps con conexiones largas. Las copias SMB empezaban rápido y luego degradaban.
Soporte lo clasificó como “internet intermitente”, que en corporativo significa “no sabemos qué pasa”.

Causa raíz: la regla FastTrack evitaba partes del pipeline de firewall/mangle que usaban para MSS clamping y contabilidad.
Algunos flujos pasaban clamped y otros no, según estado de conexión y orden de reglas. El rendimiento se volvió no determinista.

Revirtieron FastTrack para el tráfico relacionado con WireGuard y lo mantuvieron solo para flujos NAT a internet simples.
El throughput se estabilizó. La lección no fue “FastTrack es malo”. Fue “sabe qué estás evitando” y sé disciplinado con las excepciones.

Práctica sencilla y correcta que salvó el día: “Comentar, baseline y medir”

Un tercer equipo tenía la costumbre ordenada: cada cambio a firewall/NAT para la VPN tenía un prefijo de comentario y mantenían una captura base de
cómo luce “saludable”—tiempos de handshake, estado de rutas y contadores de reglas durante una prueba estándar de ping.

Una mañana, la Oficina B perdió acceso al ERP de Oficina A. El túnel estaba arriba. El enrutamiento parecía correcto a simple vista.
En lugar de probar arreglos aleatorios, el ingeniero de guardia comparó los contadores con la baseline: la regla de bypass NAT ya no coincidía.

Resultó que una “limpieza” rutinaria la noche anterior reordenó las reglas NAT. La regla de masquerade se movió por encima del accept bypass.
Todo aún “funcionaba” para algún tráfico, pero los servidores ERP tenían ACLs esperando las IPs de cliente reales y empezaron a rechazar sesiones.

Porque el equipo tenía comentarios y baselines, el diagnóstico llevó minutos. Restauraron el orden NAT, añadieron un comentario guardián en la regla de masquerade
e implementaron una pequeña política de revisión por pares para cambios de orden de reglas. No fue glamuroso. También evitó una clase recurrente de fallos.

Broma #2: El dispositivo de red más peligroso es el etiquetado “temporal”, porque sobrevivirá a tu organigrama.

Listas de verificación / plan paso a paso

Puesta en marcha paso a paso (dos oficinas)

1. Elige subredes: confirma que las LANs no se solapan (10.10.10.0/24 y 10.20.20.0/24) y elige un túnel /30 (10.99.0.0/30).
2. Actualiza RouterOS: ambos routers en v7+ con la misma release mayor si es posible.
3. Genera claves en cada router; intercambia claves públicas fuera de banda.
4. Crea interfaces WG con nombres explícitos y MTU 1420.
5. Asigna IPs de túnel a las interfaces WG.
6. Configura peers:
   • El allowed-address del peer en Oficina A incluye /32 del túnel de Oficina B y la LAN /24 de Oficina B.
   • El allowed-address del peer en Oficina B incluye /32 del túnel de Oficina A y la LAN /24 de Oficina A.
   • Oficina B configura endpoint hacia Oficina A y persistent keepalive si está detrás de NAT.
7. Añade rutas estáticas a la LAN remota vía la interfaz WG.
8. Añade reglas de firewall:
   • Permite puerto UDP en la WAN de Oficina A.
   • Permite forward LAN↔WG en ambos sentidos.
9. Añade bypass NAT reglas accept antes de masquerade.
10. Prueba por capas:
    • Handshake
    • Ping a IPs del túnel
    • Ping a LAN remota desde el router
    • Ping a host remoto desde host LAN
    • Prueba MTU con ping DF
11. Deshabilita reglas de logging de debug tras la validación.
12. Anota el estado conocido bueno: rutas, contadores, cadencia de handshake y dónde se configuró keepalive.

Checklist de cambios (cada vez que lo toques)

• ¿Este cambio afecta el orden de reglas en NAT o filter? Si sí, valida que el bypass NAT siga coincidiendo.
• ¿Cambiamos definiciones de subred? Si sí, actualiza allowed-address y rutas estáticas en ambos lados.
• ¿Introdujiste subredes solapadas vía una nueva VLAN? Si sí, detente y rediseña antes de desplegar.
• ¿Habilitaste FastTrack o nuevos mangle? Si sí, vuelve a probar MTU/MSS y mide throughput.
• ¿Cambiamos ISP o direccionamiento WAN? Si sí, valida endpoint y alcanzabilidad UDP de inmediato.

Checklist de seguridad (higiene mínima viable)

• Restringe input al puerto UDP 13231 en WAN (Oficina A) y mantiene otros inputs cerrados.
• Acota reglas forward por subredes (e incluso puertos/servicios si puedes).
• Mantén claves WireGuard fuera de tickets y logs de chat.
• Registra solo lo necesario y solo cuando sea necesario. “Loguear todo” permanentemente es un DoS autoinfligido.

Preguntas frecuentes

1) ¿Debo hacer bridge entre las dos oficinas para que sea “una LAN”?

No, a menos que tengas un requisito muy específico y estés listo para asumir las consecuencias de broadcast y spanning-tree.
Enrutado es más limpio, depurable y escala mejor operacionalmente.

2) ¿Por qué añadimos subredes LAN remotas a allowed-address?

En WireGuard, allowed-address actúa como política de enrutamiento/selector: qué prefijos de destino se consideran válidos para ese peer.
Si omites la LAN, obtendrás handshake y quizá pings del túnel, pero no enrutamiento intersitio real.

3) ¿Necesito persistent-keepalive en ambos lados?

Usualmente solo en el lado detrás de NAT (o detrás de firewalls estatales agresivos). Si ambos lados tienen IPs públicas y UDP estable,
a menudo puedes omitirlo. Si dudas, configúralo solo en el lado NATeado a 25 segundos.

4) ¿Qué puerto debo usar para WireGuard?

Cualquier puerto UDP que puedas permitir de forma fiable en tu borde WAN. Elige uno, documéntalo y no reutilices puertos al azar entre diferentes VPNs.
Claridad operativa supera ocultamiento ingenioso.

5) ¿Puedo ejecutar múltiples túneles sitio a sitio en un router?

Sí. Usa interfaces separadas o configura peers con cuidado en una interfaz. Mantén nombres estrictos y planificación de direcciones consistente.
En el momento en que pierdas qué peer posee qué subredes, encaminarás tráfico al lugar equivocado.

6) El handshake es reciente pero rx aumenta y tx no (o viceversa). ¿Qué significa?

Tienes tráfico unidireccional. O el camino de retorno está roto (enrutamiento/gateway por defecto), o el firewall está descartando una dirección.
Captura en la interfaz WG y verifica los contadores de forward para ver dónde muere.

7) ¿Cómo evito subredes solapadas cuando la empresa adquiere otra oficina?

Planéalo: mantén un registro IPAM interno y reserva rangos por sitio. Si heredas solapamiento, debes renumerar un lado
o implementar NAT entre sitios (deuda operativa). Renumerar duele una vez; NAT duele para siempre.

8) ¿Debo NATear tráfico entre sitios para hacerlo “más simple”?

Evítalo. NAT oculta IPs de origen, rompe expectativas de ACL y complica la resolución de problemas.
Usa NAT intersitio solo como medida temporal de compatibilidad (por ejemplo, subredes solapadas que no puedes renumerar de inmediato) y escribe un plan de retirada.

9) ¿Necesito QoS especial para WireGuard sitio a sitio?

No por defecto. Mide primero. Si voz/video o apps críticas sufren durante transferencias grandes, entonces introduce shaping con clases y límites claros.
No conviertas tus colas en un nuevo cuello de botella sin datos base.

10) ¿Cuál es la mejor métrica de “salud”?

Handshake reciente más contadores de transferencia incrementándose durante una prueba sintética programada (como un ping más una sonda TCP pequeña).
El handshake solo no es suficiente; los contadores solos pueden estar obsoletos. Quieres ambos, observados en el tiempo.

Conclusión: próximos pasos que puedes hacer hoy

Si solo haces tres cosas después de leer esto, haz estas:

1. Fija un plan de IP limpio (LANs distintas, túnel /30 separado) y escríbelo donde no desaparezca.
2. Implementa correctamente el bypass NAT (reglas accept por encima de masquerade) y verifica mediante contadores, no por esperanza.
3. Adopta el orden de diagnóstico rápido: handshake → enrutamiento → firewall/NAT → MTU. Te evita depurar la capa equivocada.

Luego programa una pequeña ventana de mantenimiento para ejecutar la sección de tareas operativas como ensayo: captura salidas conocidas buenas, confirma contadores
y prueba MTU. El momento para aprender las peculiaridades de tu red no es durante una llamada de incidente con cinco gerentes respirando en silencio en el puente de conferencia.