Proxy inverso nativo en MikroTik RouterOS 7.22+: Guía completa de configuración

Los administradores de MikroTik llevan tiempo enfrentándose a un dilema arquitectónico clásico. Imagina esta situación: tienes una sola dirección IP pública, pero detrás de ella necesitas publicar varios servicios web en el puerto HTTPS estándar 443.

Por ejemplo:

• cloud.example.com → Nextcloud
• wiki.example.com → Base de conocimiento BookStack
• pihole.example.com → Panel de AdGuard Home o Pi-hole
• ha.example.com → Domótica con Home Assistant

El Destination NAT (reenvío de puertos) convencional no sirve aquí. Solo puede redirigir puertos «a ciegas»: todo el tráfico del puerto WAN:443 irá hacia una única IP interna. El NAT no puede inspeccionar los paquetes y analizar nombres de dominio.

Antes de RouterOS 7.22, los administradores tenían que improvisar: desplegar proxies de terceros (Nginx, HAProxy, Caddy, Traefik) en máquinas virtuales separadas o empaquetarlos como contenedores directamente dentro del router.

En RouterOS 7.22, MikroTik presentó finalmente un Reverse Proxy nativo e integrado. No convierte el router en un reemplazo completo de los servidores web pesados, pero proporciona una herramienta sencilla y elegante para la publicación básica de servicios HTTPS.

Cómo funciona

El proxy inverso integrado en RouterOS opera en la capa de aplicación (L7). Acepta el tráfico HTTPS cifrado desde internet, lo analiza y lo envía a los servidores internos o contenedores de aplicaciones (RouterOS Apps) correspondientes.

El flujo del tráfico es el siguiente:

Cliente desde internet
        |
        | HTTPS (puerto 443)
        v
MikroTik RouterOS (servicio reverse-proxy)
        |
        | Análisis del SNI del paquete TLS ClientHello
        v
Servicio interno en la LAN (o contenedor local)

Punto clave: Como el tráfico está cifrado, RouterOS no puede leer las cabeceras HTTP estándar (p. ej., Host:). En cambio, el router lee el SNI (Server Name Indication) — un campo que el cliente envía en texto plano durante la primera fase del handshake TLS. Al comparar este SNI con su tabla de reglas, MikroTik sabe instantáneamente a dónde dirigir la solicitud.

Anatomía de la configuración

La configuración del proxy en RouterOS se divide en dos niveles lógicos:

1. Servicio global (/ip/service/reverse-proxy) Es un servicio del sistema como winbox, ssh o www-ssl. Gestiona el arranque del motor proxy, la elección del puerto TCP (por defecto 443) y la vinculación del certificado SSL predeterminado.

2. Tabla de reglas (/ip/reverse-proxy) Aquí se crea el mapa de enrutamiento: qué dominio (SNI) debe reenviarse a qué dirección IPv4 interna y puerto.

Guía de configuración paso a paso

Paso 1. Preparación y copia de seguridad

Antes de modificar los servicios de red y el firewall, guarda siempre la configuración:

/system/backup/save name=before-reverse-proxy
/export file=before-reverse-proxy

Paso 2. Liberar el puerto 443

Por defecto, la interfaz web de administración (WebFig) funciona en HTTPS en el mismo puerto 443 (www-ssl). Si no los separas, el proxy simplemente no arrancará por conflicto de puerto.

Tienes dos opciones:

• Opción A (Recomendada): Mover WebFig a un puerto alternativo (p. ej., 8443) y restringir el acceso solo a la red local de confianza:

/ip/service/set www-ssl port=8443 address=192.168.88.0/24

• Opción B: Deshabilitar completamente WebFig (HTTP y HTTPS) si administras el router solo mediante WinBox:

/ip/service/disable www
/ip/service/disable www-ssl

Paso 3. Preparar los certificados SSL

Para evitar advertencias de seguridad en el navegador, el proxy necesita certificados SSL válidos.

Opción 1. Dominio propio con Let’s Encrypt

Asegúrate de que tus dominios (cloud.example.com, pihole.example.com) apuntan en el DNS a la IP pública de tu MikroTik. Puedes emitir un certificado oficial gratuito directamente desde el cliente ACME integrado del router:

/certificate/add-acme directory-url=https://acme-v02.api.letsencrypt.org/directory domain-names=cloud.example.com,pihole.example.com

RouterOS creará los certificados automáticamente y los renovará antes de que expiren (al alcanzar el 80% de su vida útil).

Opción 2. MikroTik Cloud DDNS

Si no tienes dominio propio, puedes usar un nombre gratuito de MikroTik del tipo xxxxx.sn.mynetname.net:

# Activar DDNS
/ip/cloud/set ddns-enabled=yes update-time=yes

# Solicitar certificado Let's Encrypt para este nombre
/certificate/add-acme directory-url=https://acme-v02.api.letsencrypt.org/directory domain-names=[/ip/cloud/get dns-name]

Paso 4. Activar el servicio global de Reverse Proxy

Consulta el nombre del certificado emitido con /certificate/print y activa el servicio proxy:

/ip/service/set reverse-proxy port=443 certificate=letsencrypt_cloud.example.com disabled=no

Paso 5. Crear las reglas de proxy

Ahora vincula los nombres de dominio externos con los servidores internos. Supongamos que Nextcloud está en 192.168.88.10 y Pi-hole en 192.168.88.20, ambos ejecutándose en HTTP plano (puerto 80) dentro de la red:

# Redirigir cloud.example.com a Nextcloud
/ip/reverse-proxy/add sni=cloud.example.com ip-address=192.168.88.10 port=80 comment="Nextcloud proxy"

# Redirigir pihole.example.com a Pi-hole
/ip/reverse-proxy/add sni=pihole.example.com ip-address=192.168.88.20 port=80 comment="Pi-hole proxy"

Si dejas el parámetro certificate con el valor none, MikroTik usará automáticamente el certificado global definido en el Paso 4.

Paso 6. Configurar el firewall

Como el Reverse Proxy se ejecuta en el propio router, el tráfico entrante va directamente hacia él. Esto significa que las reglas deben añadirse en la cadena input, no en la habitual forward.

Permite el tráfico HTTPS entrante en la interfaz WAN:

/ip/firewall/filter/add chain=input action=accept protocol=tcp dst-port=443 in-interface-list=WAN comment="Allow HTTPS reverse-proxy from WAN"

Si usas Let’s Encrypt con validación HTTP (HTTP-01 challenge), el router también necesita el puerto 80 abierto para las solicitudes de la autoridad certificadora:

/ip/firewall/filter/add chain=input action=accept protocol=tcp dst-port=80 in-interface-list=WAN comment="Allow HTTP for ACME challenge"

⚠️ Atención: Asegúrate de que estas reglas estén al principio de la tabla en /ip/firewall/filter/print — obligatoriamente antes de cualquier regla de bloqueo (drop).

Paso 7. Resolver el acceso desde la red interna (Split-Brain DNS)

Si ahora intentas abrir cloud.example.com desde dentro de tu red doméstica u oficina (conectado al Wi-Fi del mismo router), probablemente verás un error. Los clientes locales intentarán acceder a la IP externa del router, lo que suele estar bloqueado por el firewall o produce un enrutamiento incorrecto (bucle NAT).

Para que todo funcione sin problemas tanto desde internet como desde la red interna, configura el Split-Brain DNS. Crea registros estáticos locales en MikroTik para que estos dominios resuelvan a la IP LAN del router:

/ip/dns/static/add name=cloud.example.com address=192.168.88.1
/ip/dns/static/add name=pihole.example.com address=192.168.88.1

Donde 192.168.88.1 es la IP LAN de tu MikroTik. El proxy integrado interceptará este tráfico local en el puerto 443 exactamente igual que el tráfico externo.

Configuración de las aplicaciones backend

Después de que MikroTik acepte el tráfico HTTPS cifrado, realice la terminación TLS y reenvíe la solicitud al servidor interno en HTTP plano, la aplicación backend puede confundirse. Los servicios de seguridad de aplicaciones web suelen bloquear solicitudes cuando creen que se está accediendo a ellos a través de un proxy externo.

El Reverse Proxy integrado de RouterOS añade automáticamente las cabeceras estándar X-Forwarded-For (transmite la IP real del cliente) y X-Forwarded-Proto (indica que la solicitud original llegó por HTTPS). Solo necesitas configurar tus aplicaciones para que confíen en estas cabeceras.

Ejemplo para Nextcloud (config.php)

Añade la IP LAN del router a la lista de proxies de confianza; de lo contrario, obtendrás un error de seguridad:

'trusted_domains' => [
  'cloud.example.com',
],
'trusted_proxies' => [
  '192.168.88.1', // Dirección LAN de tu MikroTik
],
'overwritehost'     => 'cloud.example.com',
'overwriteprotocol' => 'https',
'overwrite.cli.url' => 'https://cloud.example.com',

Integración con RouterOS Apps (Contenedores)

RouterOS 7.22 introdujo una capa sobre los contenedores — el menú /app. Los desarrolladores la integraron estrechamente con el proxy integrado.

Si despliegas una aplicación directamente en el router a través del menú de apps, basta con activar un único parámetro: use-https=yes. RouterOS creará automáticamente una regla dinámica en /ip/reverse-proxy, la vinculará al certificado DDNS cloud y generará una URL segura lista para usar para acceder al contenedor.

Limitaciones: cuándo el proxy integrado no es suficiente

La herramienta integrada es ligera y cómoda, pero no es para producción a gran escala. Restricciones importantes a tener en cuenta:

1. Solo IPv4 para servidores backend. El campo ip-address en la tabla de reglas solo acepta IPv4. Por ahora no es posible hacer proxy de tráfico hacia backends internos por IPv6.

2. Carga en la CPU. El proceso de cifrado y descifrado TLS recae sobre la CPU del router. En dispositivos más débiles (hEX, hAP) una carga elevada de solicitudes puede llevar la CPU al 100%. Los chips ARM/ARM64 modernos (hAP ax, RB5009, CCR) y CHR tienen acceso a la aceleración hardware de HTTP/2.

3. Funciones web mínimas. MikroTik no ofrece manipulación avanzada de cabeceras, registro de accesos detallado, WAF integrado, autenticación a nivel de proxy ni balanceo de carga complejo. Si necesitas WebSocket, gRPC, sticky sessions o reglas de distribución de tráfico complejas — Nginx/Caddy/HAProxy sigue siendo insustituible.

Diagnóstico

Si algo no funciona, revisa la cadena paso a paso:

• Verificar el servicio: /ip/service/print where name=reverse-proxy

• Verificar desde el exterior: curl -vk https://cloud.example.com

• Verificar el certificado: openssl s_client -connect cloud.example.com:443 -servername cloud.example.com

• Verificar el backend: /ping 192.168.88.10

Lista de verificación rápida

# 1. Deshabilitar WebFig HTTPS (conflicto de puerto)
/ip/service/disable www-ssl

# 2. Emitir certificados para los dominios
/certificate/add-acme directory-url=https://acme-v02.api.letsencrypt.org/directory domain-names=cloud.example.com,pihole.example.com

# 3. Activar el proxy (usa el nombre exacto del certificado de /certificate print)
/ip/service/set reverse-proxy port=443 certificate=letsencrypt_cloud.example.com disabled=no

# 4. Añadir reglas de reenvío hacia la LAN
/ip/reverse-proxy/add sni=cloud.example.com ip-address=192.168.88.10 port=80
/ip/reverse-proxy/add sni=pihole.example.com ip-address=192.168.88.20 port=80

# 5. Permitir tráfico HTTPS entrante al router desde internet
/ip/firewall/filter/add chain=input action=accept protocol=tcp dst-port=443 in-interface-list=WAN comment="Allow HTTPS reverse-proxy"

# 6. Configurar Split-Brain DNS para acceso desde la red Wi-Fi/LAN interna
/ip/dns/static/add name=cloud.example.com address=192.168.88.1
/ip/dns/static/add name=pihole.example.com address=192.168.88.1