Starlink + MikroTik: failover y balanceo sin conflictos de IP

Starlink resolvió la conectividad en zonas donde la fibra no llega: minería, agro, faenas, sitios rurales y respaldo de última milla. Pero conectarlo solo no basta para una operación seria. Para tener failover (que si un enlace cae, el otro tome la carga) y balanceo, necesitas un router MikroTik bien configurado. Y hay un par de detalles de Starlink que, si no los conoces, te van a dar dolores de cabeza.

El primer obstáculo: todos los Starlink son 192.168.1.1

El router de Starlink entrega DHCP en 192.168.1.0/24 con gateway 192.168.1.1, y esa subred no se puede cambiar. Si tu LAN también usa 192.168.1.0/24, hay conflicto inmediato. Y si quieres dos Starlink, ambos usan la misma subred: no puedes conectarlos directo al mismo router sin aislarlos.

La solución es poner el Starlink en modo Bypass (desde la app de Starlink) para que actúe como puente, y dejar que tu MikroTik tome la IP pública/CGNAT por DHCP-client. Para dos enlaces, cada WAN entra por un puerto distinto y se aísla en su propia tabla de ruteo.

Failover: prioridad por distancia de ruta

La clave del failover en RouterOS es la distancia de la ruta por defecto: la ruta con menor distancia gana, y solo se usa la de mayor distancia cuando la primera desaparece. Configura los DHCP-client de cada WAN sin agregar ruta automática y define tú las distancias:

# WAN1 (fibra) primaria, WAN2 (Starlink) respaldo
/ip/dhcp-client/add interface=ether1-fibra add-default-route=no use-peer-dns=no
/ip/dhcp-client/add interface=ether2-starlink add-default-route=no use-peer-dns=no

# Rutas con chequeo de alcance (recursivas) para detectar caída real
/ip/route/add dst-address=0.0.0.0/0 gateway=GW_FIBRA distance=1 check-gateway=ping
/ip/route/add dst-address=0.0.0.0/0 gateway=GW_STARLINK distance=2 check-gateway=ping

# NAT de salida por cada WAN
/ip/firewall/nat add chain=srcnat out-interface=ether1-fibra action=masquerade
/ip/firewall/nat add chain=srcnat out-interface=ether2-starlink action=masquerade

Con check-gateway=ping, si el enlace primario deja de responder, RouterOS lo marca inactivo y el tráfico pasa al respaldo automáticamente. Para una detección más robusta que un simple ARP, muchos ISP usan rutas recursivas contra un destino estable (por ejemplo 8.8.8.8) para confirmar que hay Internet real, no solo enlace de capa 2.

Balanceo de carga con PCC

Si en vez de respaldo quieres usar los dos enlaces a la vez, la técnica estándar en RouterOS es PCC (Per Connection Classifier): reparte conexiones entre las WAN manteniendo cada conexión en su enlace (evita que una sesión "salte" y se rompa). Se arma con reglas de mangle que marcan conexión y ruta, más una tabla de ruteo por WAN.

Importante: el balanceo no suma anchos de banda para una sola descarga; reparte conexiones distintas. Para VoIP o streaming conviene fijar esos flujos a un enlace estable (Starlink tiene algo de jitter), y dejar el balanceo para el tráfico general.

Ojo con el CGNAT de Starlink

Por defecto, Starlink entrega direcciones CGNAT: no tienes IP pública, así que no puedes abrir puertos ni publicar servicios hacia Internet. Si necesitas llegar a la red remota (gestión, cámaras, un servidor), la salida no es el port-forward: es una VPN de salida como WireGuard o una malla tipo ZeroTier, que funcionan igual detrás de CGNAT.

Objetivo	Configuración
Respaldo (fibra + Starlink)	Failover por distancia + check-gateway
Usar ambos enlaces	Balanceo PCC (mangle + tablas de ruteo)
Llegar al sitio remoto	VPN de salida (WireGuard/ZeroTier), no port-forward

En MikroTik Chile diseñamos enlaces híbridos Starlink + fibra/microondas con failover probado y monitoreo, para faenas, ISP y empresas con sitios remotos. Si necesitas que tu operación no se caiga cuando falla un enlace, agenda una evaluación técnica con nosotros.