El poder de 01100011 Unix-FreeBSD

sábado, 31 de octubre de 2026

Mejorar Compatibilidad y Conexión MikroTik ax3

Para mejorar la compatibilidad y conexión entre tu MikroTik hAP ax3 y los clientes , el enfoque debe centrarse en ajustar la seguridad y el roaming del router, así como en corregir posibles configuracines del dispositivo cliente. Dado que el ax3 es un router Wi-Fi 6 potente, los problemas suelen derivar de portocolos de seguridad mixtos o funciones de traspaso de red (roaming) que el dispositivo gestiona de forma particular.

1. Si tienes RouterOS 7.13 o superior, usa el menú WiFi (no el antiguo "Wireless") para las interfaces AX.

2. Actualiza RouterOS

3. Configura la Seguridad Híbrida (WPA2/WPA3) mejora la compatibilidad y el roaming en dispositivos.

4. Desactiva "ft-over-ds" (Fast Transition) En la configuración roaming del router (WiFi Interface wifi1 FT), busca la opción FT Over DS y desactiva. (WiFi Interface wifi2 FT), busca la opción FT Over DS y desactiva. Usuarios de MikroTik reportan que esto soluciona problemas de conexión y desconexiones extrañas con dispositivos Samsung y Apple.

FreeBSD es genial!.

domingo, 25 de octubre de 2026

Proyecto ax3 (4/4) - Doble túnel WireGuard con Address Lists

Proyecto ax³ (4/4) — Doble túnel WireGuard: España y Marsella
Serie completa: Índice · Parte 1 · Parte 2 · Parte 3 · Parte 4

Referencia de comandos: Cheatsheet RouterOS — Proyecto ax³

Introducción

En la Parte 3 dejamos el hAP ax³ funcionando con un túnel WireGuard apuntando a un servidor de ProtonVPN en Barcelona. En esta cuarta y última parte, vamos a levantar un segundo túnel simultáneo hacia Marsella y usaremos Address Lists para enrutar el tráfico por dispositivo.

Este enfoque no solo nos permite organizar la red de forma granular, sino que separa una configuración doméstica de una infraestructura profesional: podremos añadir decenas de dispositivos y cambiar su país de salida con un solo clic, sin tocar el firewall.

Requisito previo: Esta parte asume que el túnel principal Barcelona de la Parte 3 funciona correctamente. Haz un backup antes de empezar.

Copia de seguridad

/system backup save name=ax3-dual-20261024-vpn-marsella-barcelona-OK 
/export compact file=ax3-dual-20261024-vpn-marsella-barcelona-OK

Fase 8 — El desafío del doble túnel

Configurar dos túneles VPN simultáneos hacia el mismo proveedor (ProtonVPN) nos obligará a sortear tres problemas que, si no se controlan, romperán la red:

Conflicto de IP interna: ProtonVPN asigna la misma IP interna a todos los perfiles (ej. 10.2.0.2/32).
Conflicto de puerto: Dos interfaces WireGuard no pueden usar el mismo puerto de escucha local.
El bucle del retorno: El tráfico de vuelta del nuevo túnel viene desde una subred interna (10.3.0.0/24) que debe ser excluida del enrutamiento.

Paso 1 — Preparar el perfil de Marsella

Descarga el archivo WireGuard de ProtonVPN para Marsella y edítalo con un editor de texto:

# Original
Address = 10.2.0.2/32

# Modificado
Address = 10.3.0.2/32

Paso 2 — Importar y ajustar la interfaz

En WinBox, ve a WireGuard → Interface → + → Import from file y selecciona el archivo de Marsella.

Name: proton-vpn-marsella
Listen Port: 13232 (distinto al 13231 de Barcelona).
MTU: 1380 (ajustado para evitar fragmentación).

Paso 3 - Tabla de enrutamiento personalizada con FIB activado

El parámetro fib es fundamental para que las rutas de esa tabla se instalen en el Forwarding Information Table y el tráfico realmente se enrute.

/routing table add name=via-vpn-marsella fib

Paso 4 - Crear la tabla de rutas y el Kill Switch

/ip route add dst-address=0.0.0.0/0 gateway=proton-vpn-marsella routing-table=via-vpn-marsella distance=1 comment="Salida por Marsella"
/ip route add dst-address=0.0.0.0/0 blackhole=yes routing-table=via-vpn-marsella distance=2 comment="Kill switch Marsella"

Paso 5 - El detalle de oro: Excluir la red interna del túnel

Este es el paso que evita que la red se rompa. Cuando el tráfico vuelve del túnel, llega a través de la IP interna del mismo. Si no le decimos al router que esa red es "tráfico local", intentará enrutarla por el túnel otra vez, creando un bucle.

/ip firewall address-list add list=lan-directa address=10.3.0.0/24 comment="Red interna Marsella"

Paso 6 - Reglas de Firewall y NAT

# NAT (Masquerade para Marsella)
/ip firewall nat add chain=srcnat action=masquerade src-address=192.168.88.0/24 out-interface=proton-vpn-marsella comment="NAT para Marsella"

# Filter (Permitir LAN a Marsella)
/ip firewall filter add chain=forward in-interface-list=LAN out-interface=proton-vpn-marsella action=accept comment="Permitir LAN a VPN Marsella" place-before=[find comment="Drop todo lo dems"]

Paso 7 - Address Lists y Mangle (La magia)

En lugar de reglas individuales, agrupamos los dispositivos en listas:

# Lista para Marsella
/ip firewall address-list
add list=vpn-marsella address=192.168.88.100 comment="pc100"
add list=vpn-marsella address=192.168.88.101 comment="movil101"
add list=vpn-marsella address=192.168.88.102 comment="tablet102"
add list=vpn-marsella address=192.168.88.103 comment="portatil103"

# Lista para Barcelona
/ip firewall address-list
add list=vpn-barcelona address=192.168.88.201 comment="portatil201"
add list=vpn-barcelona address=192.168.88.202 comment="movil202"
add list=vpn-barcelona address=192.168.88.203 comment="movil203"

Y creamos las reglas genéricas de Mangle (Marcar primero, Enrutar después):

# --- MARSELLA ---
/ip firewall mangle add chain=prerouting src-address-list=vpn-marsella in-interface=bridge action=mark-connection new-connection-mark=conn-marsella passthrough=yes comment="Mangle: Marcar lista Marsella"
/ip firewall mangle add chain=prerouting connection-mark=conn-marsella action=mark-routing new-routing-mark=via-vpn-marsella passthrough=no comment="Mangle: Enrutar lista Marsella"

# --- BARCELONA (ESPAÑA) ---
/ip firewall mangle add chain=prerouting src-address-list=vpn-barcelona in-interface=bridge action=mark-connection new-connection-mark=conn-barcelona passthrough=yes comment="Mangle: Marcar lista Barcelona"
/ip firewall mangle add chain=prerouting connection-mark=conn-barcelona action=mark-routing new-routing-mark=via-vpn passthrough=no comment="Mangle: Enrutar lista Barcelona"

¡Atención con las IPs dinámicas! Las Address Lists funcionan buscando la IP del dispositivo. Si el servidor DHCP de tu router le asigna mañana una IP diferente al dispositivo (ej. pasa de la .100 a la .105), las reglas de Mangle no lo reconocerán y se saltará la VPN.

Obligatorio: Ve a IP → DHCP Server → Leases, busca los dispositivos de tus listas, haz clic derecho y selecciona "Make Static" (o usa el comando /ip dhcp-server lease make-static [find]). Así te aseguras de que su IP nunca cambie y el enrutamiento sea siempre perfecto.

Paso 8 - Ajustar el MSS (Crucial para el rendimiento)

El cálculo del MSS es crítico. Debe ser siempre 40 bytes menor que el MTU de la interfaz. Si el MTU de Marsella es 1380, el MSS debe ser 1340. Un MSS incorrecto provocará que las webs se queden a medio cargar.

/ip firewall mangle add chain=forward protocol=tcp tcp-flags=syn out-interface=proton-vpn-marsella action=change-mss new-mss=1340 passthrough=yes comment="MSS para tunel Marsella (MTU 1380)"

Paso 9 - Limpiar conexiones y probar

/ip firewall connection remove [find src-address~"192.168.88.10"]
/ip firewall connection remove [find src-address~"192.168.88.20"]

Comandos de verificación (El "Checklist" del Administrador)

Para asegurarte de que todo está fluyendo correctamente, ejecuta estas comprobaciones en el MikroTik:

# 1. ¿Los túneles están vivos y con handshake reciente?
/interface wireguard peers print detail

# 2. ¿Puede el router hacer ping a través de Marsella? (Debe ser 0% packet-loss)
/ping 1.1.1.1 interface=proton-vpn-marsella count=3

# 3. ¿Está la tabla de rutas de Marsella activa y con su Kill Switch?
/ip route print where routing-table=via-vpn-marsella

# 4. ¿Están los dispositivos generando tráfico y con la marca correcta?
/ip firewall connection print where src-address~"192.168.88.10"
# (Fíjate en la columna CONNECTION-MARK: debería decir conn-marsella)

# 5. ¿Están subiendo los contadores de las reglas de Mangle?
/ip firewall mangle print stats

Resolución de problemas (Lo que aprendimos a golpes)

Si el túnel se levanta pero los dispositivos no tienen Internet, revisa estos cinco puntos:

El "Peer Fantasma": Si al importar el archivo se creó una interfaz con un asterisco (ej. *D) o un peer duplicado con la misma clave pública, el túnel se volverá loco y perderá paquetes. Elimina cualquier peer que no corresponda con su interfaz.
```
/interface wireguard peers remove [find name="peerX"]
```
El conflicto de IP: Comprueba en /ip address print que no existe ninguna interfaz llamada unknown. Si existe, bórrala: /ip address remove [find interface=unknown].
El firewall bloquea el retorno: Asegúrate de que tienes la regla de accept para out-interface=proton-vpn-marsella antes del Drop general en la cadena forward.
El DNS: Si el ping por IP funciona pero las webs no cargan, es un problema de DNS. Asegúrate de que el dispositivo usa Pi-Hole (192.168.88.244) y que el tráfico hacia esa IP no está siendo enrutado por error hacia la VPN (la regla lan-directa lo evita).
Las IPs han cambiado: Si de repente un dispositivo deja de ir por la VPN, comprueba en IP → DHCP Server → Leases que sigue teniendo la misma IP que pusiste en la Address List. Si no lo hiciste en su momento, haz clic derecho y selecciona "Make Static".

El flujo de trabajo para alternar países

La ventaja de las Address Lists es que el cambio es instantáneo. Para pasar un dispositivo de Marsella a Barcelona:

Ve a IP → Firewall → Address Lists.
Busca su IP y cambia la columna List de vpn-marsella a vpn-barcelona.

Borra su sesión en el router para forzar el cambio:

/ip firewall connection remove [find src-address~"192.168.88.100"]

Muy importante: Orden de las reglas

/ip firewall mangle print
Flags: D - DYNAMIC
 0 D ;;; special dummy rule to show fasttrack counters
     chain=prerouting action=passthrough
 
 1 D ;;; special dummy rule to show fasttrack counters
     chain=forward action=passthrough
 
 2 D ;;; special dummy rule to show fasttrack counters
     chain=postrouting action=passthrough
 
 3   ;;; evita problemas de fragmentacion de paquetes
     chain=forward action=change-mss new-mss=1452 passthrough=yes tcp-flags=syn protocol=tcp out-interface=pppoe-o2 log=no
     log-prefix=""
 
 4   ;;; No marcar Trafico LAN
     chain=prerouting action=return dst-address-list=lan-directa log=no log-prefix=""
 
 5   ;;; Mangle: Marcar lista Barcelona
     chain=prerouting action=mark-connection new-connection-mark=conn-barcelona passthrough=yes src-address-list=vpn-barcelona
     in-interface=bridge
 
 6   ;;; Mangle: Marcar lista Marsella
     chain=prerouting action=mark-connection new-connection-mark=conn-marsella passthrough=yes src-address-list=vpn-marsella
     in-interface=bridge
 
 7   ;;; Mangle: Enrutar lista Marsella
     chain=prerouting action=mark-routing new-routing-mark=via-vpn-marsella passthrough=no connection-mark=conn-marsella
 
 8   ;;; Mangle: Enrutar lista Barcelona
     chain=prerouting action=mark-routing new-routing-mark=via-vpn passthrough=no connection-mark=conn-barcelona
 
 9   ;;; MSS para tunel WireGuard (MTU 1420)
     chain=forward action=change-mss new-mss=1380 passthrough=yes tcp-flags=syn protocol=tcp out-interface=proton-vpn
 
10   ;;; MSS para tunel Marsella (MTU 1380)
     chain=forward action=change-mss new-mss=1340 passthrough=yes tcp-flags=syn protocol=tcp out-interface=proton-vpn-marsella

Consejo de administración: A partir de ahora, añadir un dispositivo nuevo es tan simple como añadirlo a la lista correspondiente. Las reglas de Mangle ya no se tocan nunca. Esto reduce el consumo de CPU del router al evaluar una sola regla por lista.

Conclusión de la serie: Con esta cuarta parte, el hAP ax³ deja de ser un simple router doméstico y se convierte en un verdadero concentrador de enrutamiento avanzado. Hemos eliminado el doble NAT, montado un sistema de VPN multi-región por dispositivo con Address Lists, asegurado el DNS con Pi-Hole y Unbound, y añadido failover (Kill Switch) a cada túnel. Una infraestructura de red de nivel profesional, documentada paso a paso y con un plan de reversión en cada fase.

Serie: este artículo es la Parte 4 de Proyecto ax³. Viene de la Parte 3 — Monopuesto, VPN y corte final.

Volver al índice de la serie · Cheatsheet RouterOS

FreeBSD es genial!.

viernes, 16 de octubre de 2026

Restaurar red tras resume ACPI en FreeBSD

Objetivo

Ejecutar automáticamente un script al despertar el equipo de suspensión (S3) para restaurar:

Ethernet con IP fija
Reglas de pf
Ratón USB
Cliente NFS

Piezas necesarias

Pieza	Ruta
Script de restauración	/usr/local/sbin/resume-network.sh
Regla de devd	/etc/devd/resume-network.conf
Log del script	/var/log/resume-network.log
Syslog (logger)	/var/log/messages

1️⃣ Crear el script

doas vim /usr/local/sbin/resume-network.sh

Puntos clave:

Shebang: #!/bin/sh
PATH completo al inicio (devd lo ejecuta con PATH mínimo):

PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
export PATH

Redirigir toda la salida a un log para depurar:

exec >> /var/log/resume-network.log 2>&1

Función log() que escribe a archivo y a syslog

log() {
    echo "[$(date '+%F %T')] $*"
    logger -t resume-network "$*"
}

Usar rutas absolutas en comandos críticos (/sbin/pfctl, /usr/local/bin/wg-quick, etc.).
Esperar a que el enlace esté active antes de reasignar IP.
Al reasignar IP fija: borrar primero la IP previa y borrar la ruta por defecto antes de volver a añadirla.

Dar permisos:

doas chmod +x /usr/local/sbin/resume-network.sh

2️⃣ Script completo

#!/bin/sh
# =========================================================
# /usr/local/sbin/resume-network.sh
# Restaura Ethernet (em0, IP fija), ratón USB y NFS
# tras un resume ACPI.
# (WireGuard y qBittorrent excluidos)
# =========================================================

# PATH completo: devd ejecuta los scripts con un PATH mínimo
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
export PATH

LOG="/var/log/resume-network.log"
exec >> "$LOG" 2>&1

# Función para loguear en archivo y en syslog
log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $*"
    logger -t resume-network "$*"
}

log "=== $(date) - Resume detectado ==="

# ---------------------------------------------------------
# 1. Ethernet: reactivar em0 y aplicar IP fija
# ---------------------------------------------------------
sleep 3

ifconfig em0 down
sleep 1
ifconfig em0 up

# Esperar a que el enlace esté activo (hasta 15s)
i=0
status=""
while [ $i -lt 15 ]; do
    status=$(ifconfig em0 | awk '/status:/ {print $2}')
    [ "$status" = "active" ] && break
    sleep 1
    i=$((i + 1))
done

log "em0 status=$status tras ${i}s"

if [ "$status" != "active" ]; then
    log "ERROR - em0 sin enlace tras ${i}s"
    exit 1
fi

# Eliminar IP previa (si existe) y reaplicar IP fija y ruta
ifconfig em0 inet 192.168.88.50 delete 2>/dev/null
ifconfig em0 inet 192.168.88.50 netmask 255.255.255.0
route delete default 2>/dev/null
route add default 192.168.88.1

log "Ethernet OK (IP fija y ruta activas)"

# ---------------------------------------------------------
# 2. Recargar pf para limpiar estados obsoletos
# ---------------------------------------------------------
/sbin/pfctl -f /etc/pf.conf 2>/dev/null
log "pf recargado"

# ---------------------------------------------------------
# 3. Verificar conectividad con reintentos
# ---------------------------------------------------------
connected=0
for attempt in 1 2 3; do
    if ping -c 1 -t 3 192.168.88.1 >/dev/null 2>&1; then
        connected=1
        break
    fi
    sleep 2
done

if [ "$connected" != "1" ]; then
    log "ERROR - sin conectividad a la puerta de enlace"
    exit 1
fi
log "Conectividad verificada tras ${attempt} intento(s)"

# ---------------------------------------------------------
# 4. Reactivar ratón USB
# ---------------------------------------------------------
if kldstat -q -m ums 2>/dev/null; then
    kldunload ums 2>/dev/null
    sleep 1
    kldload ums
    log "módulo ums recargado"
elif kldstat -q -m uhid 2>/dev/null; then
    kldunload uhid 2>/dev/null
    sleep 1
    kldload uhid
    log "módulo uhid recargado"
else
    log "ni ums ni uhid cargados, ratón sin cambios"
fi

# Reiniciar moused si está corriendo
if pgrep -q moused; then
    service moused restart 2>/dev/null || {
        pkill -f moused 2>/dev/null
        sleep 1
        service moused start 2>/dev/null
    }
    log "moused reiniciado"
fi

# ---------------------------------------------------------
# 5. Reiniciar el cliente NFS
# ---------------------------------------------------------
service nfsclient restart
log "nfsclient reiniciado"

# Opcional: remontar sistemas NFS si se quedan colgados
# mount -a -t nfs
# log "sistemas NFS remontados"

log "=== $(date) - Resume completado ==="
exit 0

3️⃣ Crear la regla de devd

# cat /etc/devd/resume-network.conf 
notify 100 {
    match "system"      "ACPI";
    match "subsystem"   "Resume";
    action "/usr/local/sbin/resume-network.sh";
};

Aplicar cambios

doas service devd restart

Comprobar que devd ve el evento

Verifica que el subsystem sea exactamente el correcto. Algunos equipos emiten Resume y otros resume. Para ver qué llega:

doas devd -d

Suspende y despierta el equipo. Si no aparece el evento ACPI/Resume, ajusta la regla con el subsystem que realmente emita tu hardware (puedes verlo también en /var/log/messages).

4️⃣ Probar sin suspender

Ejecuta el script manualmente como root:

doas sh -x /usr/local/sbin/resume-network.sh

Y revisa el log:

tail -f /var/log/resume-network.log

5️⃣ Depurar tras un resume real

Log propio del script:

tail -n 50 /var/log/resume-network.log

add net default: gateway 192.168.88.1
[2026-10-16 15:02:49] Ethernet OK (IP fija y ruta activas)
[2026-10-16 15:02:49] pf recargado
[2026-10-16 15:02:51] Conectividad verificada tras 1 intento(s)
[2026-10-16 15:02:51] ni ums ni uhid cargados, ratón sin cambios
Starting default moused.
[2026-10-16 15:02:51] moused reiniciado
NFS access cache time=60
[2026-10-16 15:02:51] nfsclient reiniciado
[2026-10-16 15:02:51] === Fri Oct 16 15:02:51 CEST 2026 - Resume completado ===
[2026-10-16 15:03:28] === Fri Oct 16 15:03:28 CEST 2026 - Resume detectado ===
[2026-10-16 15:03:36] em0 status=active tras 2s

add net default: gateway 192.168.88.1
[2026-10-16 15:03:37] Ethernet OK (IP fija y ruta activas)
[2026-10-16 15:03:37] pf recargado
[2026-10-16 15:03:42] Conectividad verificada tras 2 intento(s)
[2026-10-16 15:03:42] ni ums ni uhid cargados, ratón sin cambios
Starting default moused.
[2026-10-16 15:03:42] moused reiniciado
NFS access cache time=60
[2026-10-16 15:03:42] nfsclient reiniciado
[2026-10-16 15:03:42] === Fri Oct 16 15:03:42 CEST 2026 - Resume completado ===
[2026-10-16 18:34:14] === Fri Oct 16 18:34:14 CEST 2026 - Resume detectado ===
[2026-10-16 18:34:23] em0 status=active tras 2s

add net default: gateway 192.168.88.1
[2026-10-16 18:34:23] Ethernet OK (IP fija y ruta activas)
[2026-10-16 18:34:23] pf recargado
[2026-10-16 18:34:26] Conectividad verificada tras 1 intento(s)
[2026-10-16 18:34:26] ni ums ni uhid cargados, ratón sin cambios
Starting default moused.
[2026-10-16 18:34:26] moused reiniciado
NFS access cache time=60
[2026-10-16 18:34:26] nfsclient reiniciado
[2026-10-16 18:34:26] === Fri Oct 16 18:34:26 CEST 2026 - Resume completado ===
[2026-10-16 21:58:08] === Fri Oct 16 21:58:08 CEST 2026 - Resume detectado ===
[2026-10-16 21:58:16] em0 status=active tras 2s

add net default: gateway 192.168.88.1
[2026-10-16 21:58:17] Ethernet OK (IP fija y ruta activas)
[2026-10-16 21:58:17] pf recargado
[2026-10-16 21:58:22] Conectividad verificada tras 2 intento(s)
[2026-10-16 21:58:22] ni ums ni uhid cargados, ratón sin cambios
Starting default moused.
[2026-10-16 21:58:22] moused reiniciado
NFS access cache time=60
[2026-10-16 21:58:22] nfsclient reiniciado
[2026-10-16 21:58:22] === Fri Oct 16 21:58:22 CEST 2026 - Resume completado ===

Mensajes que ha escrito devd y el script vía logger:

grep resume /var/log/messages

Oct 16 21:58:08 solaris resume-network[18841]: === Fri Oct 16 21:58:08 CEST 2026 - Resume detectado ===
Oct 16 21:58:16 solaris resume-network[18862]: em0 status=active tras 2s
Oct 16 21:58:17 solaris resume-network[18871]: Ethernet OK (IP fija y ruta activas)
Oct 16 21:58:17 solaris resume-network[18877]: pf recargado
Oct 16 21:58:22 solaris resume-network[18891]: Conectividad verificada tras 2 intento(s)
Oct 16 21:58:22 solaris resume-network[18898]: ni ums ni uhid cargados, ratón sin cambios
Oct 16 21:58:22 solaris resume-network[18929]: moused reiniciado
Oct 16 21:58:22 solaris resume-network[18945]: nfsclient reiniciado
Oct 16 21:58:22 solaris resume-network[18951]: === Fri Oct 16 21:58:22 CEST 2026 - Resume completado ===

Errores frecuentes

Síntoma	Causa	Solución
Nada ocurre al despertar	`&` al final del action	Quitarlo
Nada ocurre al despertar	subsystem distinto (`resume` vs `Resume`)	Ajustar en el .conf
Script falla silenciosamente	Comando no encontrado (logger, route, …)	Añadir PATH completo
IP fija no se aplica	La IP ya estaba asignada	`ifconfig em0 inet X delete` antes
Ratón no vuelve	Módulo incorrecto cargado	Probar ums, uhid, usbhid
NFS colgado	`service nfsclient restart` no remonta	Añadir `umount -f` + `mount -a`

Comandos útiles de referencia

service devd restart            # recargar reglas
devd -d                         # ver eventos en directo
ifconfig em0                    # ver estado del enlace
netstat -rn                     # ver rutas
pfctl -s info                   # estado de pf
kldstat                         # módulos cargados
mount | grep nfs                # montajes NFS activos

Todo el flujo en un solo vistazo: script → regla devd → restart → log → depuración.

FreeBSD es genial!.

jueves, 15 de octubre de 2026

Cheatsheet RouterOS — Proyecto ax³

Qué es esta entrada

Resumen de comandos útiles de RouterOS y del cliente SSH, agrupados por tema y con comentarios. Todo lo que aparece aquí es lo que se usó realmente durante el Proyecto ax³: la migración del hAP ac² al hAP ax³ con monopuesto de O2, policy routing multi-región con ProtonVPN y Address Lists, DNS con Pi-Hole y Unbound, y backups.

Cómo usar esta entrada: usa el índice para saltar al bloque que necesites. Cada bloque de código tiene un botón Copiar en la esquina superior derecha. Los comandos están pensados para pegarse en la terminal de RouterOS (New Terminal en WinBox o SSH) o en el cliente (FreeBSD/Linux/Windows).

Índice

SSH y acceso remoto
Usuarios
Backups
Firewall — Filter
Firewall — Mangle (Policy Routing)
Firewall — NAT
Listas de direcciones (Address Lists)
Rutas y Tablas de Enrutamiento
DHCP y PPPoE
DNS
WireGuard
Diagnóstico y Rescate
Cliente — comandos útiles
~/.ssh/config (cliente)
Buenas prácticas aplicadas
Arquitectura de referencia

SSH y acceso remoto

# Ver la configuración SSH actual
/ip ssh print

# Permitir autenticación por contraseña
/ip ssh set password-authentication=yes

# Solo permitir contraseña a usuarios SIN clave (recomendado tras importar claves)
/ip ssh set password-authentication=yes-if-no-key

# Forzar algoritmos criptográficos modernos (AES-GCM, ChaCha20, Ed25519)
/ip ssh set strong-crypto=yes

# Ver las claves SSH importadas de los usuarios
/user ssh-keys print

# Ver detalle (incluye fingerprint)
/user ssh-keys print detail

# Importar una clave pública a un usuario
/user ssh-keys import public-key-file=mikrotik_axe.pub user=carlos

# Eliminar una clave por índice
/user ssh-keys remove 1

# Eliminar una clave por fingerprint (más seguro)
/user ssh-keys remove [find fingerprint="SHA256:..."]

Valores de password-authentication:

yes — Login por contraseña siempre permitido.
no — Nunca permitido, solo clave SSH.
yes-if-no-key — Solo si el usuario no tiene clave asociada. Recomendado tras importar las claves.

Usuarios

# Listar todos los usuarios
/user print

# Habilitar un usuario y asignarle contraseña
/user set admin disabled=no password="TuContraseñaSegura"

# Asignar grupo (full = control total)
/user set admin disabled=no group=full password="TuContraseñaSegura"

# Dejar un usuario sin contraseña (solo entrará con clave SSH)
/user set carlos password=""

# Deshabilitar un usuario temporalmente
/user set carlos disabled=yes

Backups

# Backup binario (restaurable, incluye todo)
/system backup save name=ax3-2026-10-25-dual-vpn-OK

# Backup con contraseña (recomendado si sale del router)
/system backup save name=ax3-2026-10-25-dual-vpn-OK password="clave"

# Export legible (.rsc, sin contraseñas)
/export compact file=ax3-2026-10-25-dual-vpn-OK

# Export con datos sensibles (¡cuidado con dónde se guarda!)
/export file=ax3-2026-10-25-dual-vpn-OK show-sensitive

# Listar archivos existentes
/file print

# Restaurar un backup binario
/system backup load name=ax3-2026-10-25-dual-vpn-OK.backup

# Reiniciar el router
/system reboot

Nomenclatura recomendada: ax3-AAAA-MM-DD-HHMM-<estado>.ext. Guardar siempre una copia fuera del router (en tormenta, por ejemplo, con ZFS y snapshots).

Firewall — Filter

# Ver reglas
/ip firewall filter print
/ip firewall filter print stats

# Permitir LAN → WAN (con prioridad antes del drop final)
/ip firewall filter add chain=forward in-interface-list=LAN out-interface-list=WAN \
    action=accept comment="Permitir LAN a WAN"

# Permitir LAN → VPN España
/ip firewall filter add chain=forward in-interface-list=LAN out-interface=proton-vpn \
    action=accept comment="Permitir LAN a VPN España"

# Permitir LAN → VPN Marsella
/ip firewall filter add chain=forward in-interface-list=LAN out-interface=proton-vpn-marsella \
    action=accept comment="Permitir LAN a VPN Marsella"

# Colocar una regla antes de otra (ej. antes del Drop final)
/ip firewall filter add ... place-before=[find comment="Drop todo lo dems"]

# Mover una regla después de crearla
/ip firewall filter move [find comment~"Permitir LAN a VPN"] \
    destination=[find comment~"Drop todo lo dems"]

# Resetear contadores
/ip firewall filter reset-counters [find]

Firewall — Mangle (Policy Routing)

# Ver reglas y contadores
/ip firewall mangle print
/ip firewall mangle print stats

# 1. Excluir tráfico LAN del marcado (DEBE IR PRIMERO)
/ip firewall mangle add chain=prerouting dst-address-list=lan-directa \
    action=return comment="No marcar tráfico LAN"

# 2. Marcar la conexión (usando Address Lists en lugar de IPs sueltas)
/ip firewall mangle add chain=prerouting src-address-list=vpn-marsella in-interface=bridge \
    action=mark-connection new-connection-mark=conn-marsella passthrough=yes \
    comment="Mangle: Marcar lista Marsella"

# 3. Enrutar por la tabla correspondiente
/ip firewall mangle add chain=prerouting connection-mark=conn-marsella \
    action=mark-routing new-routing-mark=via-vpn-marsella passthrough=no \
    comment="Mangle: Enrutar lista Marsella"

# --- MSS (Cálculo correcto = MTU - 40) ---
# PPPoE: MTU 1492 -> MSS 1452
/ip firewall mangle add chain=forward protocol=tcp tcp-flags=syn \
    out-interface=pppoe-o2 action=change-mss new-mss=1452 passthrough=yes \
    comment="MSS para PPPoE"

# WireGuard España: MTU 1420 -> MSS 1380
/ip firewall mangle add chain=forward protocol=tcp tcp-flags=syn \
    out-interface=proton-vpn action=change-mss new-mss=1380 passthrough=yes \
    comment="MSS para túnel España"

# WireGuard Marsella: MTU 1380 -> MSS 1340
/ip firewall mangle add chain=forward protocol=tcp tcp-flags=syn \
    out-interface=proton-vpn-marsella action=change-mss new-mss=1340 passthrough=yes \
    comment="MSS para túnel Marsella"

Orden crítico: la regla "No marcar tráfico LAN" debe ir antes de cualquier mark-connection o mark-routing. Además, es vital excluir las redes internas de los túneles (ej. 10.3.0.0/24) en la lista lan-directa para evitar bucles.

Firewall — NAT

# Ver reglas
/ip firewall nat print
/ip firewall nat print stats

# Masquerade general (salida por PPPoE)
/ip firewall nat add chain=srcnat action=masquerade src-address=192.168.88.0/24 \
    out-interface=pppoe-o2 comment="NAT general por PPPoE"

# Masquerade para el túnel España (debe ir ANTES que la general)
/ip firewall nat add chain=srcnat action=masquerade src-address=192.168.88.0/24 \
    out-interface=proton-vpn comment="NAT para ProtonVPN España"

# Masquerade para el túnel Marsella
/ip firewall nat add chain=srcnat action=masquerade src-address=192.168.88.0/24 \
    out-interface=proton-vpn-marsella comment="NAT para ProtonVPN Marsella"

# Masquerade para acceder al HGU (activar solo cuando se necesite)
/ip firewall nat add chain=srcnat action=masquerade src-address=192.168.88.0/24 \
    out-interface=ether1 disabled=yes comment="NAT para entrar al HGU O2"

Listas de direcciones (Address Lists)

# Ver todas las listas
/ip firewall address-list print

# Añadir red a la lista "lan-directa" (Para evitar que vaya por la VPN)
/ip firewall address-list add list=lan-directa address=192.168.88.0/24 \
    comment="LAN principal"
/ip firewall address-list add list=lan-directa address=10.2.0.0/24 \
    comment="Red interna VPN España"
/ip firewall address-list add list=lan-directa address=10.3.0.0/24 \
    comment="Red interna VPN Marsella"

# Añadir dispositivos a las listas de VPN
/ip firewall address-list add list=vpn-marsella address=192.168.88.100 comment="Dispositivo 1"
/ip firewall address-list add list=vpn-barcelona address=192.168.88.201 comment="Dispositivo 2"

Rutas y Tablas de Enrutamiento

# Ver todas las rutas
/ip route print

# Crear una tabla de enrutamiento personalizada (RouterOS v7 requiere FIB)
/routing table add name=via-vpn-marsella fib

# Salida por ProtonVPN Marsella
/ip route add dst-address=0.0.0.0/0 gateway=proton-vpn-marsella routing-table=via-vpn-marsella \
    distance=1 comment="Salida por Marsella"

# Kill switch: blackhole si el túnel cae (Sintaxis correcta en v7)
/ip route add dst-address=0.0.0.0/0 blackhole=yes routing-table=via-vpn-marsella \
    distance=2 comment="Kill switch Marsella"

Kill switch por blackhole: si el túnel está arriba, la ruta 1 (distance=1) está activa y la 2 nunca se usa. Si el túnel cae, la ruta 1 se vuelve inactiva y entra la 2 (blackhole), descartando el tráfico marcado. No hay fuga posible hacia la WAN normal. (Nota: en RouterOS v6 se usaba type=blackhole, en v7 es blackhole=yes).

DHCP y PPPoE

# Ver red DHCP configurada
/ip dhcp-server network print

# Forzar DNS a Pi-Hole
/ip dhcp-server network set [find] dns-server=192.168.88.244

# Fijar las IPs de los dispositivos (CRUCIAL para que las Address Lists no fallen)
/ip dhcp-server lease make-static [find]

# Ver cliente PPPoE
/interface pppoe-client print detail

# Asegurar que PPPoE añade ruta por defecto
/interface pppoe-client set [find name=pppoe-o2] add-default-route=yes

# DHCP client de ether1 sin añadir ruta (evita doble NAT)
/ip dhcp-client set [find interface=ether1] add-default-route=no

Doble NAT y VPNs: el DHCP client de ether1 debe tener siempre add-default-route=no. Además, si usas Address Lists para enrutar por VPN, las IPs deben ser estáticas (reservas DHCP) para que el router siempre reconozca al dispositivo.

DNS

# Ver configuración DNS del router
/ip dns print

# Desactivar el resolver del router (los clientes usan Pi-Hole)
/ip dns set allow-remote-requests=no

Cadena DNS: clientes → Pi-Hole (192.168.88.244) → Unbound (192.168.88.160) → resolución recursiva. El router no participa. Por eso allow-remote-requests debe estar en no.

WireGuard

# Ver interfaces WireGuard
/interface wireguard print

# Ver peers (comprobar que el Last-Handshake es reciente)
/interface wireguard peers print detail

# Ping por el túnel (desde el propio router)
/ping 10.2.0.1 count=3 interface=proton-vpn

# Ping a Internet usando la interfaz del túnel
/ping 1.1.1.1 interface=proton-vpn-marsella count=3

Diagnóstico, Monitorización y Rescate

# Ver interfaces activas y sus MTU
/interface print

# Ver direcciones IP asignadas (¡comprueba que no haya ninguna 'unknown'!)
/ip address print

# Ver conexiones activas con marca VPN
/ip firewall connection print where connection-mark~"vpn"

# Ver conexiones de un dispositivo concreto
/ip firewall connection print where src-address~"192.168.88.100"

# Ver logs de PPPoE o Firewall
/log print where topics~"pppoe"
/log print where message~"DROP"

# Ver contadores de mangle (las reglas de Arriba deben sumar paquetes)
/ip firewall mangle print stats

# --- RESOLUCIÓN DE PROBLEMAS ---
# Eliminar un peer WireGuard fantasma que rompe el túnel
/interface wireguard peers remove [find name="peerX"]

# Limpiar la interfaz 'unknown' si falla una importación de WireGuard
/ip address remove [find interface=unknown]

# Resetear las conexiones de una IP tras cambiar de VPN
/ip firewall connection remove [find src-address~"192.168.88.100"]

# Activar Safe Mode (revierte cambios si se pierde la sesión)
/system safe-mode

Cliente — comandos útiles

# Generar par de claves ed25519
ssh-keygen -t ed25519 -f ~/.ssh/mikrotik_axe -C "carlos@mikrotik-ax3"

# Ver fingerprint de una clave pública
ssh-keygen -lf ~/.ssh/mikrotik_axe.pub

# Limpiar entrada antigua de known_hosts
ssh-keygen -R 192.168.88.1

# Subir clave pública al router
scp ~/.ssh/mikrotik_axe.pub carlos@192.168.88.1:/mikrotik_axe.pub

# Conectar con clave específica
ssh -i ~/.ssh/mikrotik_axe carlos@192.168.88.1

# Descargar backups
scp carlos@192.168.88.1:/ax3-2026-10-25-dual-vpn-OK.backup .
scp carlos@192.168.88.1:/ax3-2026-10-25-dual-vpn-OK.rsc .

# Ver IP pública actual y ubicación geográfica
curl -s ifconfig.me
curl -s ipinfo.io/city

# Probar fugas DNS
nslookup whoami.akamai.net
nslookup dnsleaktest.com

~/.ssh/config (cliente)

Host mikrotik-ax3
    HostName 192.168.88.1
    User carlos
    IdentityFile ~/.ssh/mikrotik_axe
    IdentitiesOnly yes

Host mikrotik-admin
    HostName 192.168.88.1
    User admin

Con eso:

ssh mikrotik-ax3
scp archivo.bin mikrotik-ax3:/

Buenas prácticas aplicadas

Elemento	Valor correcto
`strong-crypto`	`yes`
`password-authentication`	`yes-if-no-key` (tras importar claves)
Fasttrack	Deshabilitado (rompe policy routing)
`allow-remote-requests` (DNS)	`no`
DHCP client de `ether1`	`add-default-route=no`
PPPoE client	`add-default-route=yes`
Kill switch VPN	Ruta blackhole en tabla `via-vpn`
Regla de exclusión LAN	Primera en `prerouting`
MSS	MTU - 40 (Ej: 1452 PPPoE, 1380 España, 1340 Marsella)
Backups	`.backup` + `.rsc`, copia externa en `tormenta`
DHCP Leases	Hacer estáticas (`make-static`) para que no cambien de IP

Arquitectura de referencia

O2 / Internet
   │
Fibra óptica
   │
┌──────────────────────────┐
│ MitraStar GPT-2541GNAC   │
│ MONOPUESTO               │
│ VoIP: teléfono fijo      │
└────────────┬─────────────┘
             │ Ethernet / PPPoE
             ▼
┌──────────────────────────┐
│ hAP ax³                  │
│ PPPoE + NAT + Firewall   │
│ WireGuard + ProtonVPN    │
│ Policy routing           │
└────────────┬─────────────┘
             │
       192.168.88.0/24
             │
   ├── tormenta   .160  FreeBSD 14.5 (Unbound, NFSv4, Kerberos, ZFS, Samba)
   ├── solaris    .50   FreeBSD 14.5
   ├── raspberry  .244  Raspberry Pi 3B + Pi-Hole
   └── demás dispositivos

Cadena DNS: clientes → Pi-Hole (.244) → Unbound (.160) → recursivo

Cheatsheet de Proyecto ax³. Última actualización: 2026-10-25.

FreeBSD es genial!.

martes, 13 de octubre de 2026

Proyecto ax³ — Índice de la serie

Proyecto ax³

Durante los próximos tres artículos documento la sustitución del router principal de casa —un MikroTik hAP ac²— por un MikroTik hAP ax³, aprovechando la ocasión para reorganizar por completo la red: eliminar el doble NAT, montar WireGuard con ProtonVPN, montar policy routing por dispositivo y dejar el DNS en manos de Pi-Hole y Unbound.

La serie está pensada como una guía reproducible. El hilo conductor es sencillo: nada se toca hasta que lo nuevo está probado. El hAP ac² sigue funcionando exactamente igual durante todo el proceso y solo se apaga cuando el ax³ ya está listo para entrar en producción.

Serie completa:

Parte 1 — Qué cambia y por qué.
Objetivo, comparativa hAP ac² vs hAP ax³, arquitectura final y distribución de servicios.
Leer Parte 1 →
Parte 2 — Preparar el ax³ sin tocar la red.
RouterOS y firmware, red de laboratorio aislada 192.168.50.0/24, configuración base, firewall y backups.
Leer Parte 2 →
Parte 3 — Monopuesto, VPN y corte final.
PPPoE de O2, MitraStar en monopuesto, WireGuard + ProtonVPN, policy routing, kill switch, DNS con Pi-Hole y Unbound, migración final y plan de reversión.
Leer Parte 3 →
Parte 4 — Doble túnel WireGuard: España y Marsella.
Segundo túnel simultáneo, Address Lists para enrutamiento por dispositivo, reglas Mangle genéricas, ajuste de MSS y diagnóstico de problemas.
Leer Parte 4 →

Arquitectura final

O2 / Internet
   │
Fibra óptica
   │
┌──────────────────────────────────┐
│ MitraStar GPT-2541GNAC           │
│ MONOPUESTO                       │
│ SIN NAT                          │
│ Teléfono ─── VoIP                │
└────────────┬─────────────────────┘
             │ Ethernet / PPPoE
             ▼
┌──────────────────────────────────┐
│ hAP ax³                          │
│ PPPoE + NAT + Firewall           │
│ WireGuard + ProtonVPN            │
│ Policy routing                   │
└────────────┬─────────────────────┘
             │
       192.168.88.0/24
             │
   ├── tormenta      192.168.88.160   FreeBSD 14.5 (Unbound, NFSv4, Kerberos, ZFS, Samba)
   ├── solaris       192.168.88.51    FreeBSD 14.5
   ├── raspberry     192.168.88.244   Raspberry Pi 3B + Pi-Hole
   └── demás dispositivos

Puntos clave del proyecto

Sin doble NAT: el MitraStar pasa a monopuesto y el ax³ recibe la IP pública por PPPoE.
Sin cortes: el hAP ac² sigue en producción hasta el corte final.
DNS propio: clientes → Pi-Hole (raspberry.casa.lan) → Unbound (tormenta.casa.lan).
VPN por dispositivo: policy routing con mark-connection + mark-routing y kill switch por blackhole.
Reversión ensayada: vuelta al hAP ac² en menos de 10 minutos si algo falla.

Filosofía de la serie: el objetivo no es solo migrar, sino poder volver atrás si algo falla. Esa garantía es lo que convierte un cambio de router en un proyecto controlado y no en una tarde de emergencia.

Empezar a leer

Material complementario: Cheatsheet RouterOS — Proyecto ax³
Todos los comandos usados en la serie, agrupados por tema y listos para copiar.

FreeBSD es genial!.

Proyecto ax³ (3/3) — Monopuesto, VPN y corte final

Proyecto ax³ (3/4) — Monopuesto, VPN y corte final
Serie completa: Índice · Parte 1 · Parte 2 · Parte 3 · Parte 4

Referencia de comandos: Cheatsheet RouterOS — Proyecto ax³

Introducción

En la Parte 1 definimos el objetivo, la comparativa y la arquitectura. En la Parte 2 dejamos el hAP ax³ completamente preparado en la red aislada 192.168.50.0/24, con RouterOS y firmware actualizados, DHCP funcionando, Wi-Fi 6 configurado, firewall básico y backups en orden.

En esta tercera y última parte se hace el corte real: configurar el PPPoE de O2, poner el MitraStar en monopuesto, integrar WireGuard con ProtonVPN, montar el policy routing, cerrar el DNS con Pi-Hole y Unbound, migrar a 192.168.88.0/24 y apagar el hAP ac².

Esta es la parte con riesgo real. Hasta aquí todo eran pruebas aisladas. A partir de este punto, un error puede dejar la red sin Internet. Antes de empezar, ten a mano el bloque de reversión que está al final de este artículo y asegúrate de haberlo leído entero.

Fase 5 — Internet O2 y monopuesto

El objetivo de esta fase es que el hAP ax³ reciba directamente la IP pública por PPPoE, eliminando el doble NAT que hoy existe entre el MitraStar y el router. Para ello, el MitraStar pasa a modo monopuesto.

Arquitectura final

O2 / Internet
   │
Fibra óptica
   │
┌──────────────────────────────────┐
│ MitraStar GPT-2541GNAC           │
│ MONOPUESTO                       │
│ SIN NAT                          │
│ Teléfono ─── VoIP                │
└────────────┬─────────────────────┘
             │ Ethernet / PPPoE
             ▼
┌──────────────────────────────────┐
│ hAP ax³                          │
│ PPPoE + NAT + Firewall           │
│ WireGuard + ProtonVPN            │
│ Policy routing                   │
└────────────┬─────────────────────┘
             │
       192.168.88.0/24
             │
   ├── tormenta      192.168.88.160   FreeBSD 14.5 (Unbound, NFSv4, Kerberos, ZFS, Samba)
   ├── solaris       192.168.88.51    FreeBSD 14.5
   ├── raspberry     192.168.88.244   Raspberry Pi 3B + Pi-Hole
   └── demás dispositivos

Datos PPPoE de O2

Usuario:    adslppp@telefonicanetpa
Contraseña: adslppp

Notas sobre el MitraStar GPT-2541GNAC

Este HGU tiene un comportamiento específico que conviene documentar antes de tocarlo. En monopuesto, delega la conexión de Internet al router neutro mediante PPPoE, pero sigue gestionando la VoIP del teléfono fijo. Es exactamente lo que queremos.

Modelo / Board ID	`GPT-2541GNAC`
Firmware	`ES_g7.12_100VNJ0b73`
Build	`230705_2059` → 5 de julio de 2023
Bootloader	`1.0.41-117.134`
Wireless driver	`6.37.14.4803.cpe4.14L04Apatch1.0`

Recomendaciones críticas para el monopuesto:

Usar la opción «Monopuesto» de la interfaz básica del MitraStar.
No intentar construir el bridge manualmente desde la interfaz avanzada.
Hay reportes de bugs si se manipulan VLAN desde el menú avanzado.
En monopuesto, el HGU entrega el PPPoE sin etiquetar.
Por tanto, no configurar VLAN 6 en el MikroTik.

Atención con la VoIP: existen casos documentados con este firmware en los que el teléfono deja de funcionar a los pocos minutos de activar monopuesto. Si ocurre, la solución reportada es acceder a la configuración avanzada del HGU, editar la interfaz WAN de VoIP y habilitar las opciones Enable IGMP Multicast Proxy y Enable IGMP Multicast Source. No dar el cambio por bueno hasta que hayan pasado al menos 48 horas sin incidencias.

Configurar el cliente PPPoE en el ax³

Conectar el cable del MitraStar al puerto ether1 del ax³.
WinBox → PPP → Interface → + → PPPoE Client.
Configurar:
- Name: pppoe-o2
- Interface: ether1
- User: adslppp@telefonicanetpa
- Password: adslppp
- Add Default Route: sí
- Use Peer DNS: no
Apply → OK.

Comprobar que la sesión levanta:

/interface pppoe-client monitor [find] once
/log print where topics~"pppoe"

Activar el monopuesto en el MitraStar

Acceder al MitraStar por su interfaz web.
Ir a la sección básica de configuración WAN.
Activar la opción «Monopuesto».
Guardar y esperar el reinicio del HGU.
Comprobar en el ax³ que la sesión PPPoE obtiene una IP pública.
Verificar que el teléfono fijo sigue registrando correctamente.

Decisión clave sobre el DHCP client de ether1: el ax³ mantiene un DHCP client activo en ether1 para obtener una IP en la LAN del HGU (192.168.1.0/24), lo que permite acceder a la interfaz web del MitraStar si hace falta. Pero ese cliente debe tener add-default-route=no. Si lo activamos, RouterOS añade una ruta 0.0.0.0/0 via 192.168.1.1 que reintroduce el doble NAT que acabamos de eliminar.

/ip dhcp-client set [find interface=ether1] add-default-route=no
/interface pppoe-client set [find name=pppoe-o2] add-default-route=yes

Verificar que la única ruta por defecto es la del PPPoE:

/ip route print where dst-address=0.0.0.0/0

Debe aparecer una sola ruta por defecto en la tabla main:

DAv 0.0.0.0/0  gateway=pppoe-o2  distance=1

Fase 6 — VPN, DNS y policy routing

Con Internet funcionando en el ax³, ya se puede montar el resto de la infraestructura: WireGuard, ProtonVPN, policy routing, kill switch y DNS definitivo. Esta fase es la más delicada del proyecto, porque cualquier error aquí no rompe la red entera, pero sí deja dispositivos sin Internet de forma difícil de diagnosticar.

WireGuard y ProtonVPN

ProtonVPN ofrece configuración WireGuard lista para importar. Desde el panel de ProtonVPN se genera un archivo con clave privada, clave pública del servidor, endpoint y AllowedIPs. Se importa directamente en RouterOS:

WireGuard → Interface → + → Import from file

Comprobar que el túnel levanta:

/interface wireguard print
/interface wireguard peers print
/ping 10.2.0.1 count=3 interface=proton-vpn

Detalle importante: verificar que el campo AllowedIPs del peer incluye 0.0.0.0/0. Si solo incluye rangos parciales, algunos destinos no pasarán por la VPN aunque los marques con routing-mark.

Policy routing: el patrón correcto

El objetivo es que cada dispositivo pueda salir por WAN normal o por ProtonVPN según una política definida. En RouterOS esto se hace combinando tres piezas:

Marcar la conexión al primer paquete (chain prerouting).
Marcar el routing de todos los paquetes de esa conexión.
Una tabla de rutas alternativa que envía lo marcado por el túnel.

Error común: marcar directamente routing-mark en prerouting sin marcar antes la conexión. Funciona en el 90% de los casos, pero falla con NAT, con retorno asimétrico y cuando una conexión se reutiliza. El patrón robusto es siempre primero marcar conexión, después marcar routing.

Estructura final de las reglas de mangle

0     No marcar tráfico LAN          dst-address-list=lan-directa
1-2   Dummy (dinámicas)
3     change-mss 1452                out-interface=pppoe-o2
4     Marcar conexión de xiaomi      src-address=192.168.88.252
5     Marcar conexión de solaris     src-address=192.168.88.51
6     Enrutar xiaomi por VPN         connection-mark=xiaomi-vpn
7     Enrutar solaris por VPN        connection-mark=solaris-vpn
8     change-mss 1380                out-interface=proton-vpn

Paso 1 — Address-list con las redes que NO se marcan

Antes de cualquier regla de marcado, hay que excluir el tráfico destinado a la propia LAN. Si no, el tráfico hacia Pi-Hole, Unbound o cualquier host local se marca con via-vpn, y como la tabla via-vpn no tiene ruta a 192.168.88.0/24, esas consultas se van por el túnel en lugar de entregarse localmente. El síntoma es desconcertante: parece que "no hay Internet", pero el ping por IP funciona.

/ip firewall address-list
add list=lan-directa address=192.168.88.0/24 comment="LAN principal"
add list=lan-directa address=192.168.1.0/24  comment="LAN del HGU O2"
add list=lan-directa address=10.2.0.0/24     comment="Red interna ProtonVPN"

Y la regla de exclusión, al principio de prerouting:

/ip firewall mangle
add chain=prerouting dst-address-list=lan-directa action=return \
    comment="No marcar tráfico LAN"

Si place-before=0 falla (RouterOS no acepta referencias a reglas dinámicas), añade la regla al final y muévela después con move [find comment~"No marcar"] destination=[find comment~"Marcar conexin de xiaomi"]. Lo importante es que esté antes de cualquier mark-connection o mark-routing.

Paso 2 — Marcar conexión por dispositivo

/ip firewall mangle
add chain=prerouting src-address=192.168.88.252 in-interface=bridge \
    action=mark-connection new-connection-mark=xiaomi-vpn passthrough=yes \
    comment="Marcar conexión de xiaomi"

add chain=prerouting src-address=192.168.88.51 in-interface=bridge \
    action=mark-connection new-connection-mark=solaris-vpn passthrough=yes \
    comment="Marcar conexión de solaris"

El passthrough=yes es importante: después de marcar la conexión, el paquete sigue evaluándose contra las reglas siguientes, que serán las que lean esa marca.

Paso 3 — Enrutar por VPN según la marca de conexión

/ip firewall mangle
add chain=prerouting connection-mark=xiaomi-vpn \
    action=mark-routing new-routing-mark=via-vpn passthrough=no \
    comment="Enrutar xiaomi por VPN"

add chain=prerouting connection-mark=solaris-vpn \
    action=mark-routing new-routing-mark=via-vpn passthrough=no \
    comment="Enrutar solaris por VPN"

El passthrough=no ahorra ciclos de CPU: una vez marcado el routing, no hace falta seguir evaluando más reglas de mangle.

Paso 4 — Tabla de rutas con kill switch por blackhole

La tabla via-vpn debe tener dos rutas: una activa por el túnel y otra blackhole de respaldo. Si el túnel cae, la activa desaparece y entra la blackhole, que descarta el tráfico marcado. Es un kill switch a nivel de routing, sin necesidad de reglas de firewall adicionales.

/ip route
add dst-address=0.0.0.0/0 gateway=proton-vpn routing-table=via-vpn distance=1 \
    comment="Salida por ProtonVPN"
add dst-address=0.0.0.0/0 type=blackhole routing-table=via-vpn distance=2 \
    comment="Kill switch: descartar si el túnel cae"

Por qué funciona: si el túnel está arriba, la ruta 1 está activa y la 2 nunca se usa. Si el túnel cae, la ruta 1 se vuelve inactiva y la 2 entra en juego, descartando el tráfico marcado. No hay fuga posible hacia la WAN normal.

Paso 5 — MSS por interfaz

El MSS (Maximum Segment Size) es el tamaño máximo de payload TCP. Si se configura mal, se produce fragmentación o drops silenciosos: algunas webs cargan, otras se quedan colgadas, y parece que "no hay Internet" cuando en realidad es un problema de MTU.

/ip firewall mangle
add chain=forward protocol=tcp tcp-flags=syn out-interface=pppoe-o2 \
    action=change-mss new-mss=1452 passthrough=yes \
    comment="MSS para PPPoE (MTU 1492)"

add chain=forward protocol=tcp tcp-flags=syn out-interface=proton-vpn \
    action=change-mss new-mss=1380 passthrough=yes \
    comment="MSS para túnel WireGuard (MTU 1420)"

Interfaz	MTU	MSS	Fórmula
`pppoe-o2`	1492	1452	1492 − 40 (IP+TCP)
`proton-vpn`	1420	1380	1420 − 40 (IP+TCP)
`bridge` (LAN)	1500	1460	1500 − 40 (IP+TCP)

Error frecuente: usar un único MSS de 1452 para todo el tráfico. Para el tráfico que sale por PPPoE es correcto, pero para el que sale por el túnel es demasiado alto. Los paquetes grandes se fragmentan o se descartan silenciosamente, y el síntoma es exactamente el de "webs a medio cargar".

Paso 6 — Regla de forward para el tráfico del túnel

El firewall del ax³ tiene una regla que acepta el tráfico de LAN hacia WAN, pero el túnel proton-vpn normalmente no está en la lista WAN. Sin una regla específica, el tráfico que sale por el túnel cae en el Drop todo lo demás y se descarta.

/ip firewall filter
add chain=forward in-interface-list=LAN out-interface=proton-vpn \
    action=accept comment="Permitir LAN a VPN" \
    place-before=[find comment="Drop todo lo dems"]

Paso 7 — DNS con Pi-Hole y Unbound

Clientes de la LAN
   │
   ▼
Pi-Hole (raspberry.casa.lan / 192.168.88.244)
   │
   ▼
Unbound (tormenta.casa.lan / 192.168.88.160)
   │
   ▼
Resolución recursiva directa (sin DNS externos)

En el ax³, dos ajustes complementarios:

# 1. El DHCP entrega solo Pi-Hole como DNS
/ip dhcp-server network
set [find] dns-server=192.168.88.244

# 2. El router no actúa como resolver DNS
/ip dns
set allow-remote-requests=no

Allow Remote Requests debe estar desactivado. Si se activa, el router abre un resolver en 192.168.88.1:53 que se salta Pi-Hole y Unbound. Eso rompe el filtrado y puede filtrar metadatos al ISP si el router reenvía al DNS del operador.

Verificación final del policy routing

/ip firewall mangle print stats

Regla	Debe tener paquetes	Comentario
No marcar tráfico LAN	✅	Ping a Pi-Hole, Unbound, etc.
Marcar conexión de xiaomi	✅	Primer paquete de cada conexión
Marcar conexión de solaris	✅	Primer paquete de cada conexión
Enrutar xiaomi por VPN	✅	Todos los paquetes de la conexión
Enrutar solaris por VPN	✅	Todos los paquetes de la conexión
MSS túnel WireGuard	✅	Solo paquetes SYN que salen por el túnel

Diferencia esperada entre marca y enrutamiento: la regla "Marcar conexión" solo actúa sobre el primer paquete de cada conexión, la "Enrutar por VPN" sobre todos. Por eso la segunda siempre tiene más paquetes. Si ves lo contrario, algo va mal.

Prueba real desde un cliente VPN

# Desde solaris
ping -c 3 192.168.88.244   # Pi-Hole (debe funcionar)
ping -c 3 1.1.1.1          # Internet por IP (por el túnel)
ping -c 3 google.com       # DNS (por Pi-Hole)
curl -s ifconfig.me        # IP pública (debe ser de ProtonVPN)

Resultado esperado: curl ifconfig.me devuelve una IP distinta a la de O2 (que es la que devolverá desde cualquier dispositivo que NO esté en la lista de clientes VPN).

Kill switch: prueba real

Deshabilitar la interfaz WireGuard:
```
/interface wireguard disable proton-vpn
```
Desde solaris, comprobar que no tiene Internet:
```
ping -c 3 1.1.1.1
```
Comprobar que sigue teniendo acceso a la LAN:
```
ping -c 3 192.168.88.244
```
Volver a habilitar la interfaz:
```
/interface wireguard enable proton-vpn
```
Comprobar que recupera Internet por el túnel:
```
curl -s ifconfig.me
```

Fase 7 — Corte final

Llegados a este punto, el ax³ funciona en 192.168.50.0/24 con Internet, PPPoE, VPN, policy routing y DNS completo. Solo falta el cambio final: apagar el ac² y migrar el ax³ a 192.168.88.0/24.

O2 monopuesto
      │
      ▼
   hAP ax³
      │
192.168.88.0/24
      │
tormenta + solaris + raspberry + resto de LAN

Preparativos antes del corte

Backup completo del hAP ac² exportado y descargado.
Backup completo del hAP ax³ exportado y descargado.
Capturas de la configuración actual del MitraStar.
Confirmar que el hAP ac² está apagado pero accesible físicamente.
Ventana de mantenimiento acordada con quien use la red.

Pasos del corte

Apagar el hAP ac² y desconectarlo de la red.
En el ax³, cambiar la IP LAN de 192.168.50.1/24 a 192.168.88.1/24.
Actualizar el DHCP Network a 192.168.88.0/24.
Actualizar el pool DHCP a 192.168.88.10-192.168.88.254.
Conectar el ax³ al switch de la LAN.
Comprobar desde un cliente:
- IP recibida por DHCP.
- Puerta de enlace 192.168.88.1.
- Acceso a Internet.
- Resolución DNS vía Pi-Hole.

Comprobaciones post-corte

# Desde un cliente de la LAN
curl -s ifconfig.me           # Debe devolver la IP pública de O2

# Desde el ax³
/ip route print where dst-address=0.0.0.0/0
/interface pppoe-client monitor [find] once
/ip firewall mangle print stats

Internet normal funcionando.
Internet por ProtonVPN funcionando en los clientes marcados.
Policy routing por dispositivo correcto.
Kill switch bloqueando fugas.
DNS sin fugas: clientes → Pi-Hole → Unbound.
NFSv4, Kerberos, ZFS y Samba accesibles desde clientes.
VoIP del MitraStar operativa.
Rendimiento Wi-Fi 6 correcto.

Estado final alcanzado: el hAP ax³ es el router de producción, sale directamente por la IP pública de O2 vía PPPoE (sin doble NAT), el MitraStar está en monopuesto gestionando la VoIP, y el hAP ac² queda apagado con su configuración intacta, listo para volver a entrar en servicio si algo falla.

Plan de reversión

Regla de oro: nunca se desmonta nada antes de tener confirmado que el nuevo estado funciona. El hAP ac² no se apaga, no se resetea y no se reconfigura hasta que el ax³ lleve al menos 48 horas funcionando en producción sin incidencias.

Puntos de retorno

Punto de no retorno	Síntoma	Acción de reversión
Antes de monopuesto	Todo funciona con doble NAT	Nada que revertir. Seguir probando.
Tras activar monopuesto	VoIP deja de funcionar	Volver a modo router en el MitraStar
Tras activar monopuesto	El ax³ no levanta PPPoE	Volver a modo router en el MitraStar
Tras el corte final	Fallo grave en el ax³	Reenchufar el ac² tal cual estaba
Tras el corte final	Fugas DNS o kill switch roto	Volver al ac² y revisar reglas

Caso 1 — La VoIP deja de funcionar tras monopuesto

Síntoma: el teléfono fijo registra correctamente al principio y deja de funcionar a los pocos minutos. Es un bug conocido de determinadas versiones de firmware MitraStar, entre ellas la ES_g7.12_100VNJ0b73.

Acceder al MitraStar por su interfaz web.
Ir a la opción de Monopuesto en la interfaz básica.
Desactivarla y volver a modo router.
Confirmar que el teléfono vuelve a registrar.
El hAP ax³ seguirá funcionando detrás del MitraStar, pero volveremos a tener doble NAT.

Alternativa si se quiere insistir en monopuesto:

Acceder a la configuración avanzada del HGU.
Editar la interfaz WAN de VoIP.
Habilitar Enable IGMP Multicast Proxy y Enable IGMP Multicast Source.
Guardar y comprobar que el teléfono vuelve a registrar.

Caso 2 — El ax³ no levanta PPPoE

Diagnóstico rápido:

/interface pppoe-client monitor [find] once
/log print where topics~"pppoe"

Comprobaciones:

Usuario y contraseña exactos:

Usuario:    adslppp@telefonicanetpa
Contraseña: adslppp

Que el MitraStar esté realmente en monopuesto.
Que el cable salga del puerto correcto del MitraStar hacia ether1.
Que no haya VLAN configurada en ether1.
Que ether1 no esté dentro del bridge.

Caso 3 — Corte final: hay que volver al hAP ac²

Requisito previo: el hAP ac² debe estar apagado pero físicamente accesible y con su configuración intacta.

Apagar el hAP ax³.
Desconectar el cable que va del MitraStar al ether1 del ax³.
Reconectar el hAP ac² exactamente como estaba.
Encender el hAP ac².
Esperar 60–90 segundos.
Comprobar desde un cliente: IP, puerta de enlace, Internet, DNS.
Si el MitraStar sigue en monopuesto, volverlo a modo router.

Caso 4 — Fugas DNS o kill switch roto

# Fuga DNS
nslookup whoami.akamai.net
nslookup dnsleaktest.com

# Kill switch (con el túnel caído)
ping 1.1.1.1
curl ifconfig.me

Reversión inmediata:

Desactivar temporalmente el policy routing en el ax³.
Dejar todo el tráfico saliendo por la WAN normal.
Confirmar que Internet vuelve a funcionar.
Revisar reglas de firewall, marcas de routing y DNS antes de reactivar.

Caso 5 — El ax³ se queda inaccesible

Reglas preventivas:

WinBox por MAC siempre disponible.
Safe Mode activado antes de tocar firewall o interfaces:
```
/system safe-mode
```

Si aun así queda inaccesible:

Conectar el portátil a un puerto LAN del ax³.
WinBox → Neighbors → entrar por MAC.
Si tampoco aparece, resetear el ax³ y restaurar el último backup.

Checklist de reversión

☐ Capturas de la configuración del MitraStar guardadas.
☐ Backup del hAP ac² exportado y descargado.
☐ Backup del hAP ax³ exportado y descargado.
☐ Cable del MitraStar etiquetado (WAN, LAN).
☐ Procedimiento de reversión impreso o accesible desde el móvil.
☐ hAP ac² accesible físicamente, apagado pero listo para reconectar.
☐ Ventana de mantenimiento acordada.
☐ Ensayo previo del corte y de la reversión hecho antes del día real.

Filosofía del plan: el objetivo no es que no falle nada, sino que si falla algo, en menos de 10 minutos todo el mundo esté navegando como antes. La migración se hace cuando se puede permitir el lujo de fallar; no cuando no hay margen.

Pendientes por aclarar

Confirmar que la VoIP del MitraStar se mantiene operativa durante 48 horas.
Definir política final de DNS: Pi-Hole como único DNS para clientes, Unbound como resolver recursivo aguas arriba.
Definir reservas DHCP fijas en 192.168.88.0/24 para tormenta, solaris y raspberry.
Documentar qué dispositivos van por ProtonVPN y cuáles por WAN normal.
Valorar migrar de reglas por IP a address-list=vpn-clients cuando la lista de dispositivos VPN crezca.

Checklist final del proyecto

☐ hAP ac² sigue funcionando hasta el corte final.
☐ hAP ax³ actualizado: RouterOS y firmware al mismo nivel.
☐ Backup inicial del ax³.
☐ IP LAN temporal: 192.168.50.1/24.
☐ DHCP Network temporal: 192.168.50.0/24.
☐ Pool temporal: 192.168.50.10-192.168.50.254.
☐ Portátil en 192.168.50.254.
☐ WinBox por MAC funcionando.
☐ Configuración base: bridge, DHCP, Wi-Fi 6, firewall, NAT.
☐ PPPoE O2: adslppp@telefonicanetpa / adslppp.
☐ MitraStar en monopuesto.
☐ VoIP operativa tras monopuesto.
☐ WireGuard + ProtonVPN funcionando.
☐ Policy routing por dispositivo con mark-connection + mark-routing.
☐ Exclusión LAN (lan-directa) al principio del mangle.
☐ MSS por interfaz: 1452 para PPPoE, 1380 para túnel.
☐ Regla de forward LAN → VPN.
☐ Kill switch por blackhole probado con túnel caído.
☐ DNS sin fugas: clientes → Pi-Hole → Unbound.
☐ allow-remote-requests=no en /ip dns.
☐ DHCP entrega solo 192.168.88.244 como DNS.
☐ NFSv4, Kerberos, ZFS y Samba accesibles.
☐ Corte final a 192.168.88.0/24.
☐ IP pública confirmada desde cliente (curl ifconfig.me).
☐ 48 horas de observación antes de retirar el ac² definitivamente.

Serie: este artículo cierra Proyecto ax³. Viene de la Parte 1 — Qué cambia y por qué y de la Parte 2 — Preparar el ax³ sin tocar la red.

Volver al índice de la serie · Cheatsheet RouterOS

FreeBSD es genial!.

Proyecto ax³ (2/3) — Preparar el ax³ sin tocar la red

Proyecto ax³ (2/4) — Preparar el ax³ sin tocar la red
Serie completa: Índice · Parte 1 · Parte 2 · Parte 3 · Parte 4

Referencia de comandos: Cheatsheet RouterOS — Proyecto ax³

Introducción

En la Parte 1 vimos el objetivo, la comparativa entre el hAP ac² y el hAP ax³ y la arquitectura final del proyecto. En esta segunda parte entramos en materia: cómo preparar el hAP ax³ completamente aislado de la red de producción, sobre una red temporal 192.168.50.0/24, sin tocar en ningún momento el hAP ac² ni el MitraStar.

La idea es sencilla: durante toda esta fase, el ax³ no tiene salida a Internet y no conoce la red 192.168.88.0/24. Es un laboratorio cerrado, con un único portátil conectado por cable, donde se construye el router desde cero.

Fase 0 — Estado de seguridad

Antes de tocar nada del ax³, hay que garantizar que la red de producción queda intacta. Esto implica tres reglas que no se negocian.

No tocar la red actual 192.168.88.0/24.
El hAP ac² sigue funcionando exactamente como hasta ahora.
El hAP ax³ se prepara aislado: no se conecta al hAP ac² ni al MitraStar.

hAP ac² ─── RED ACTUAL 192.168.88.0/24 ─── TODO NORMAL

hAP ax³ ─── portátil ─── SIN WAN

Precaución crítica: no conectar el ax³ al hAP ac² ni al MitraStar durante toda esta fase. Si ambos routers tienen la misma red (192.168.88.0/24) en el mismo segmento, se producirán conflictos de DHCP y de puerta de enlace difíciles de diagnosticar.

Ventana de trabajo: esta fase se puede hacer en cualquier momento, sin prisa y sin afectar a nadie. No hay ventana de mantenimiento porque nada de la red real se toca.

Fase 1 — Primer contacto con el hAP ax³

Sacamos el ax³ de la caja, lo conectamos a un portátil por cable y comprobamos su estado de fábrica. Nada más. Sin configuración, sin cambios.

Conexión física

Conectar la alimentación.
Conectar un cable Ethernet del portátil a un puerto LAN del ax³ (no al puerto WAN/Internet).
No conectar nada al puerto WAN del ax³.
Encender el equipo y esperar a que arranque.

Primer acceso

Comprobar la IP que ha recibido el portátil:

# Windows
ipconfig

# FreeBSD / Linux
ifconfig
route -n get default

Entrar por WinBox o WebFig:

WebFig:  http://192.168.88.1
WinBox:  Neighbors → seleccionar el ax³ → Connect

Acceso por MAC: si el ax³ no responde por IP, WinBox permite conectarse por dirección MAC desde la pestaña Neighbors, siempre que el portátil esté en el mismo segmento L2. Es la vía recomendada cuando se cambia la IP LAN y no queremos perder la sesión.

Revisión inicial

Versión de RouterOS.
Firmware del RouterBOARD.
Interfaces detectadas.
Configuración de fábrica (bridge, DHCP, Wi-Fi por defecto).
Conectividad local (ping al gateway).
Primer backup.

Hacer el primer backup desde WinBox:

Files → Backup → nombre: ax3-inicial.backup

Y descargarlo al portátil antes de continuar:

Files → seleccionar el .backup → Download

Fase 2 — RouterOS y firmware

En este proyecto, RouterOS ya estaba actualizado a 7.21.5, pero el firmware del RouterBOARD seguía en 7.20.8. Hay que igualarlos: RouterOS y firmware deben coincidir para evitar comportamientos extraños.

Actualizar RouterOS (si hiciera falta)

System → Packages → Check For Updates → Download & Install
System → Reboot

Actualizar firmware del RouterBOARD

System → RouterBOARD → Upgrade → Confirmar
System → Reboot

Tras el reinicio, volver a System → RouterBOARD y comprobar:

Current Firmware:  7.21.5
Upgrade Firmware:  7.21.5

No saltes este paso. Un desajuste entre RouterOS y firmware es una fuente silenciosa de bugs. Si ambos no coinciden, no continúes con la Fase 3.

Segundo backup

Después de actualizar, hacer un nuevo backup y descargarlo:

Files → Backup → nombre: ax3-post-upgrade.backup

Fase 3 — Red de laboratorio aislada

El ax³ sale de fábrica con 192.168.88.1/24, exactamente la misma red que la red de producción. Para evitar cualquier confusión, lo movemos temporalmente a 192.168.50.0/24.

LAN laboratorio:  192.168.50.0/24
hAP ax³:          192.168.50.1
PC:               192.168.50.254

Truco clave: antes de cambiar la IP, conectar WinBox por MAC. Así, aunque se pierda la conectividad IP al cambiar la dirección, la sesión no se cae.

MAC del ax³ en este equipo:

D0:EA:11:DF:9B:80

Cambiar la IP LAN del ax³

WinBox → IP → Addresses.
Buscar 192.168.88.1/24.
Editar.
Cambiar a 192.168.50.1/24.
Mantener la interfaz exactamente igual (probablemente bridge).
Apply → OK.

WinBox puede perder momentáneamente la conexión IP. No cerrar la ventana.

Configurar el portátil

En Windows 10, configurar manualmente:

IP:             192.168.50.254
Máscara:        255.255.255.0
Puerta enlace:  (vacía)
DNS:            (vacío)

Reconectar WinBox por MAC y comprobar que el router sigue accesible.

Corregir el DHCP heredado de fábrica

El ax³ trae de fábrica una red DHCP en 192.168.88.0/24 que ya no tiene sentido. Hay que moverla a la nueva red del laboratorio.

IP → DHCP Server → Networks:

Address:  192.168.50.0/24
Gateway:  192.168.50.1
DNS:      192.168.50.1

IP → Pool, editar default-dhcp:

192.168.50.10-192.168.50.254

Comprobar en IP → DHCP Server → DHCP que el servidor DHCP está asociado al bridge y activo.

Estado al terminar la Fase 3: el ax³ vive en 192.168.50.0/24, el portátil tiene IP fija 192.168.50.254, y WinBox se conecta por MAC. Todavía no hay Internet, no hay firewall, no hay Wi-Fi configurado.

Fase 4 — Configuración base del hAP ax³

Con el laboratorio en marcha, ya se puede construir el router pieza a pieza. Todo esto se hace sin WAN, sin Internet, sin conexión al MitraStar. Es preparación pura.

Elementos a configurar

Contraseña del router (usuario admin o usuario nuevo).
Bridge LAN y asignación de puertos.
Servidor DHCP en 192.168.50.0/24.
Wi-Fi 6 (SSID, contraseña, canales, bandas 2.4 / 5 GHz).
Firewall básico (input, forward, NAT).
Estructura de interfaces: ether1 como WAN, resto en bridge LAN.
Listas de direcciones LAN y WAN para reglas de firewall.
Reglas de seguridad iniciales.
Backups periódicos.

Estructura recomendada de interfaces

ether1          → WAN  (sin bridge)
ether2..ether5  → LAN  (dentro del bridge)
wlan1 / wlan2   → LAN  (dentro del bridge)

No configurar todavía:

PPPoE en ether1.
VLAN 6 (el MitraStar en monopuesto entrega PPPoE sin etiquetar).
WireGuard / ProtonVPN.
Policy routing.
DNS definitivo (Pi-Hole / Unbound).

Todo eso es Parte 3.

Firewall básico

Reglas mínimas que deben quedar activas antes de la Parte 3:

input:
  - accept established,related
  - accept ICMP desde LAN
  - accept WinBox desde LAN
  - drop all from WAN
  - drop all invalid

forward:
  - accept established,related
  - accept LAN → WAN
  - drop all invalid

nat:
  - masquerade out-interface=ether1

Antes de tocar el firewall, activar Safe Mode:

/system safe-mode

Si se pierde la sesión por una regla mal puesta, RouterOS revierte los cambios automáticamente al reiniciar.

Backup tras la configuración base

Files → Backup → nombre: ax3-base-192.168.50.backup

Descargarlo al portátil. Guardarlo junto al resto de backups de la serie.

Reversión: el ax³ se queda inaccesible

Durante la Parte 2, la red de producción no corre ningún riesgo: el ax³ está aislado. El único escenario de reversión posible es perder el acceso al ax³ mientras se configura.

Buena noticia: RouterOS es muy difícil de dejar inaccesible si se siguen dos reglas: WinBox por MAC siempre disponible, y Safe Mode activado antes de tocar firewall o interfaces.

Si se pierde la sesión

Conectar el portátil a un puerto LAN del ax³.
WinBox → pestaña Neighbors.
Conectar por MAC (D0:EA:11:DF:9B:80).
Si la sesión se perdió por un cambio en firewall, RouterOS habrá revertido automáticamente al reiniciar (Safe Mode).
Si no aparece por MAC, mantener pulsado el botón Reset durante el arranque para volver a configuración de fábrica y restaurar el último backup.

Restaurar un backup:

Files → seleccionar el .backup → Restore → Reboot

Y volver a aplicar la IP 192.168.50.1/24 si hiciera falta.

Qué viene en la Parte 3

Con el ax³ actualizado, en 192.168.50.1/24, con DHCP funcionando, Wi-Fi 6 configurado, firewall básico y backups en orden, la Parte 3 entra en el terreno delicado.

Fase 5 — Internet o2 y monopuesto: PPPoE, datos de conexión y notas del MitraStar GPT-2541GNAC.
Fase 6 — WireGuard con ProtonVPN, policy routing, kill switch y DNS con Pi-Hole + Unbound.
Fase 7 — Corte final: apagar el ac², migrar a 192.168.88.0/24 y pruebas de producción.
Bloque de reversión completo con los 5 casos, checklist y filosofía del proyecto.

Idea clave: al terminar la Parte 2, el ax³ está listo para entrar en producción, pero todavía no ha visto Internet. El único riesgo real empieza en la Parte 3, y es ahí donde el plan de reversión deja de ser teoría.

Serie: este artículo es la Parte 2 de Proyecto ax³. Viene de la Parte 1 — Qué cambia y por qué y continúa en la Parte 3 — Monopuesto, VPN y corte final.

Volver al índice de la serie · Cheatsheet RouterOS

FreeBSD es genial!.

Proyecto ax³ (1/3) — Qué cambia y por qué

Proyecto ax³ (1/4) — Qué cambia y por qué
Serie completa: Índice · Parte 1 · Parte 2 · Parte 3 · Parte 4

Referencia de comandos: Cheatsheet RouterOS — Proyecto ax³

Introducción

Este es el primero de una serie de tres artículos en los que documento la sustitución del router principal de casa —un MikroTik hAP ac²— por un MikroTik hAP ax³, aprovechando la ocasión para reorganizar por completo la red: separar servicios, eliminar el doble NAT, integrar VPN por WireGuard con ProtonVPN y dejar el DNS en manos de Pi-Hole y Unbound.

La serie está pensada como una guía reproducible, no como un simple “cambio de router”. El hilo conductor es sencillo: nada se toca hasta que lo nuevo está probado. El hAP ac² permanece funcionando exactamente igual durante todo el proceso y solo se desconecta cuando el ax³ ya está listo para entrar en producción.

Objetivo

Sustituir el MikroTik hAP ac² por un hAP ax³.
Mantener el hAP ac² funcionando exactamente como ahora durante todo el proceso.
Preparar y probar el hAP ax³ aislado, inicialmente en 192.168.50.0/24.
Al final del proyecto:
- o2/MitraStar en monopuesto.
- El hAP ax³ establece PPPoE y recibe la IP pública.
- LAN final: 192.168.88.0/24.
- Sin doble NAT.
Redistribuir los servicios clave:
- Router, NAT, firewall, DHCP y policy routing en el hAP ax³.
- WireGuard + ProtonVPN en el hAP ax³.
- DNS con Pi-Hole en Raspberry Pi y Unbound en FreeBSD.
- NFSv4, Kerberos, ZFS y Samba en tormenta.

Estrategia general: el hAP ac² permanece intacto. El hAP ax³ se construye desde cero, en paralelo, sobre una red temporal aislada (192.168.50.0/24). Solo se produce el corte cuando todo está probado y hay un plan de reversión ensayado.

Comparativa hAP ac² vs hAP ax³

Antes de justificar la migración, conviene ver qué cambia realmente entre los dos equipos. La diferencia no es solo Wi-Fi 6: hay un salto generacional claro en CPU, RAM, almacenamiento y en la licencia de RouterOS.

Característica	MikroTik hAP ac²	MikroTik hAP ax³
Estándar Wi-Fi	Wi-Fi 5 (802.11a/b/g/n/ac)	Wi-Fi 6 (802.11a/b/g/n/ac/ax)
Velocidad inalámbrica	AC1200 (300 + 867 Mbps)	AX1800 (574 + 1200 Mbps)
Antenas	Internas (2.5 dBi)	Externas alta ganancia (3.3 / 5.5 dBi)
CPU	IPQ-4018, 4 núcleos 716 MHz, 32-bit	IPQ-6010, 4 núcleos hasta 1.8 GHz, 64-bit
RAM	128 MB	1 GB
Almacenamiento	16 MB Flash	128 MB NAND
Ethernet	5 × Gigabit	4 × Gigabit + 1 × 2.5 Gigabit
USB	1 × USB 2.0 tipo A	1 × USB 3.0 tipo A
PoE-out	No	Sí, en Ether1, Passive PoE
Licencia RouterOS	Nivel 4	Nivel 6 (completa)
Diseño	Compacto vertical / horizontal	Sobremesa con antenas externas

Los puntos decisivos para este proyecto son tres: la CPU de 64 bits (necesaria para WireGuard y policy routing sin ahogos), la RAM de 1 GB (imprescindible si se manejan muchas reglas y listas) y la licencia RouterOS Nivel 6, que desbloquea funciones avanzadas que el ac² no tiene.

Arquitectura

Situación actual

Hoy todo depende del hAP ac², que hace de router, firewall, DHCP y punto de acceso. Detrás, en la misma red 192.168.88.0/24, conviven los equipos de casa: tormenta (FreeBSD 14.5, con Unbound, NFSv4, Kerberos, ZFS y Samba), solaris (también FreeBSD 14.5) y la Raspberry Pi con Pi-Hole.

INTERNET
   │
Router o2 (MitraStar GPT-2541GNAC)
   │
hAP ac²
   │
192.168.88.0/24
   │
   ├── tormenta        192.168.88.160   FreeBSD 14.5 (Unbound, NFSv4, Kerberos, ZFS, Samba)
   ├── solaris         192.168.88.51    FreeBSD 14.5
   ├── raspberry       192.168.88.244   Raspberry Pi 3B + Pi-Hole
   └── demás dispositivos

Situación final deseada

El MitraStar pasa a modo monopuesto: delega la conexión de Internet al router neutro mediante PPPoE y se queda únicamente gestionando la VoIP del teléfono fijo. El hAP ax³ pasa a ser el router real de la casa, con IP pública, firewall, NAT, WireGuard, ProtonVPN y policy routing. El DNS se delega en Pi-Hole y Unbound.

o2 / Internet
   │
Fibra óptica
   │
┌─────────────────────────┐
│ MitraStar GPT-2541GNAC  │
│ MONOPUESTO              │
│ SIN NAT                 │
│ Teléfono ─── VoIP       │
└────────────┬────────────┘
             │ Ethernet / PPPoE
             ▼
┌─────────────────────────┐
│ hAP ax³                 │
│ PPPoE + NAT + Firewall  │
│ WireGuard + ProtonVPN   │
│ Policy routing          │
└────────────┬────────────┘
             │
       192.168.88.0/24
             │
   ├── tormenta      192.168.88.160   FreeBSD 14.5 (Unbound, NFSv4, Kerberos, ZFS, Samba)
   ├── solaris       192.168.88.51    FreeBSD 14.5
   ├── raspberry     192.168.88.244   Raspberry Pi 3B + Pi-Hole
   └── demás dispositivos

Ventaja principal del monopuesto: el hAP ax³ recibe directamente la IP pública por PPPoE. Se elimina por completo el doble NAT entre el MitraStar y el router, lo que simplifica firewall, redirecciones de puertos, VPN entrante y diagnóstico de red.

Distribución de servicios

El reparto de responsabilidades es deliberado: el router se queda con lo que debe ser siempre del router (red, firewall, NAT, VPN), la Raspberry Pi se encarga del filtrado DNS con Pi-Hole, y tormenta se queda con lo que se beneficia de un sistema operativo completo (DNS recursivo con Unbound, almacenamiento, autenticación).

Servicio	hAP ax³	`tormenta`
Router / NAT	✅
Firewall	✅
DHCP	✅
Unbound	❌	✅
WireGuard	✅
ProtonVPN	✅
Policy routing	✅
NFSv4		✅
Kerberos		✅
ZFS		✅
Samba		✅

Servicios adicionales que no viven en el hAP ax³ ni en tormenta:

Servicio	Host	IP	Sistema
Pi-Hole	`raspberry.casa.lan`	`192.168.88.244`	Raspberry Pi 3B

Inventario de la red:

tormenta.casa.lan → 192.168.88.160 — FreeBSD 14.5. Unbound, NFSv4, Kerberos, ZFS, Samba.
solaris.casa.lan → 192.168.88.51 — FreeBSD 14.5. Cliente de la red.
raspberry.casa.lan → 192.168.88.244 — Raspberry Pi 3B con Pi-Hole.

Cadena DNS prevista: los clientes consultan a Pi-Hole (raspberry.casa.lan), y Pi-Hole reenvía a Unbound (tormenta.casa.lan), que resuelve de forma recursiva. Así se combina el filtrado de Pi-Hole con la resolución recursiva de Unbound, sin depender de DNS externos.

Qué viene en la Parte 2

Con el objetivo y la arquitectura ya claros, la Parte 2 entra en materia: cómo preparar el hAP ax³ completamente aislado de la red actual, en 192.168.50.0/24, sin tocar nada del hAP ac² ni del MitraStar.

Primer contacto con el ax³: comprobaciones, RouterOS y firmware.
Red de laboratorio aislada en 192.168.50.0/24.
Acceso por MAC con WinBox para no perder la sesión.
Configuración base: bridge, DHCP, Wi-Fi 6, firewall y NAT.

Filosofía de la serie: el objetivo no es solo migrar, sino poder volver atrás en menos de 10 minutos si algo falla. Esa garantía es lo que convierte un cambio de router en un proyecto controlado.

Serie: este artículo es la Parte 1 de Proyecto ax³. Continúa en la Parte 2 — Preparar el ax³ sin tocar la red.

Volver al índice de la serie · Cheatsheet RouterOS

FreeBSD es genial!.

Páginas

Buscar este blog

sábado, 31 de octubre de 2026

domingo, 25 de octubre de 2026

Introducción

Copia de seguridad

Fase 8 — El desafío del doble túnel

Paso 1 — Preparar el perfil de Marsella

Paso 2 — Importar y ajustar la interfaz

Paso 3 - Tabla de enrutamiento personalizada con FIB activado

Paso 4 - Crear la tabla de rutas y el Kill Switch

Paso 5 - El detalle de oro: Excluir la red interna del túnel

Paso 6 - Reglas de Firewall y NAT

Paso 7 - Address Lists y Mangle (La magia)

Paso 8 - Ajustar el MSS (Crucial para el rendimiento)

Paso 9 - Limpiar conexiones y probar

Comandos de verificación (El "Checklist" del Administrador)

Resolución de problemas (Lo que aprendimos a golpes)

El flujo de trabajo para alternar países

viernes, 16 de octubre de 2026

Objetivo

Piezas necesarias

1️⃣ Crear el script

Puntos clave:

Redirigir toda la salida a un log para depurar:

Dar permisos:

2️⃣ Script completo

3️⃣ Crear la regla de devd

Aplicar cambios

Comprobar que devd ve el evento

4️⃣ Probar sin suspender

5️⃣ Depurar tras un resume real

Errores frecuentes

Comandos útiles de referencia

jueves, 15 de octubre de 2026

Qué es esta entrada

Índice

SSH y acceso remoto

Usuarios

Backups

Firewall — Filter

Firewall — Mangle (Policy Routing)

Firewall — NAT

Listas de direcciones (Address Lists)

Rutas y Tablas de Enrutamiento

DHCP y PPPoE

DNS

WireGuard

Diagnóstico, Monitorización y Rescate

Cliente — comandos útiles

~/.ssh/config (cliente)

Buenas prácticas aplicadas

Arquitectura de referencia

martes, 13 de octubre de 2026

Proyecto ax³

Arquitectura final

Puntos clave del proyecto

Empezar a leer

Introducción

Fase 5 — Internet O2 y monopuesto

Arquitectura final

Datos PPPoE de O2

Notas sobre el MitraStar GPT-2541GNAC

Configurar el cliente PPPoE en el ax³

Activar el monopuesto en el MitraStar

Fase 6 — VPN, DNS y policy routing

WireGuard y ProtonVPN

Policy routing: el patrón correcto

Estructura final de las reglas de mangle

Paso 1 — Address-list con las redes que NO se marcan

Paso 2 — Marcar conexión por dispositivo

Paso 3 — Enrutar por VPN según la marca de conexión

Paso 4 — Tabla de rutas con kill switch por blackhole

Paso 5 — MSS por interfaz

Paso 6 — Regla de forward para el tráfico del túnel

Paso 7 — DNS con Pi-Hole y Unbound

Verificación final del policy routing

Prueba real desde un cliente VPN

Kill switch: prueba real

Fase 7 — Corte final