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:

1. Conflicto de IP interna: ProtonVPN asigna la misma IP interna a todos los perfiles (ej. 10.2.0.2/32).
2. Conflicto de puerto: Dos interfaces WireGuard no pueden usar el mismo puerto de escucha local.
3. 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:

1. Ve a IP → Firewall → Address Lists.
2. Busca su IP y cambia la columna List de vpn-marsella a vpn-barcelona.
3. 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!.

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

1. Conectar la alimentación.
2. Conectar un cable Ethernet del portátil a un puerto LAN del ax³ (no al puerto WAN/Internet).
3. No conectar nada al puerto WAN del ax³.
4. 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³

1. WinBox → IP → Addresses.
2. Buscar 192.168.88.1/24.
3. Editar.
4. Cambiar a 192.168.50.1/24.
5. Mantener la interfaz exactamente igual (probablemente bridge).
6. 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

1. Conectar el portátil a un puerto LAN del ax³.
2. WinBox → pestaña Neighbors.
3. Conectar por MAC (D0:EA:11:DF:9B:80).
4. Si la sesión se perdió por un cambio en firewall, RouterOS habrá revertido automáticamente al reiniciar (Safe Mode).
5. 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!.