VPN site-to-site en MikroTik: guia completa

24 de junio de 2026

Tienes dos sucursales, un datacenter y un nodo remoto, y necesitas que se hablen como si estuvieran en la misma LAN: replicación de bases de datos, acceso a un ERP interno, monitoreo SNMP del core, backups nocturnos entre sitios. Sacar ese tráfico por Internet en claro no es opción. Ahí entra la VPN site-to-site: un túnel permanente entre routers que une redes completas, no usuarios sueltos. En este artículo comparamos las opciones reales para armar una VPN site-to-site en MikroTik —IPsec, WireGuard y los túneles EoIP/GRE— con configuración RouterOS concreta y criterios de ingeniería para que elijas bien según tu topología.

Qué resuelve una VPN site-to-site (y qué no)

Una VPN site-to-site conecta redes: el rango 10.1.101.0/24 de la casa matriz con el 10.1.202.0/24 de la sucursal, de forma transparente para los hosts de cada lado. Se diferencia del acceso remoto (road-warrior), donde cada notebook o teléfono levanta su propio túnel. En MikroTik el escenario site-to-site casi siempre se resuelve con uno de tres enfoques:

IPsec puro (tunnel mode): cifrado a nivel de política, sin interfaz de túnel. El estándar interoperable con cualquier fabricante.
WireGuard: interfaz de túnel cifrada, moderna y simple, disponible desde RouterOS v7.
Túnel de capa 2/3 (EoIP o GRE) sobre IPsec: cuando necesitas una interfaz enrutable, bridging entre sitios o correr protocolos de enrutamiento dinámico por dentro.

La decisión no es cuál es "mejor" en abstracto, sino qué exige tu red: interoperabilidad multi-vendor, capa 2 extendida, OSPF sobre el túnel, o el menor overhead posible. Cada opción resuelve un problema distinto.

IPsec: el estándar cifrado para site-to-site en MikroTik

IPsec es la opción por defecto cuando del otro lado hay un Fortinet, un Cisco, un pfSense o cualquier equipo que no sea MikroTik. Es un estándar, negocia claves con IKE (fase 1 para el canal seguro, fase 2 para las SA de datos) y cifra a nivel de política: defines qué subred origen y destino viajan protegidas y RouterOS encapsula ese tráfico en ESP. No aparece una interfaz nueva en /interface; el cifrado ocurre según las /ip/ipsec/policy.

Un site-to-site básico entre dos RouterOS con IP públicas fijas se arma con tres menús: proposal (algoritmos), peer (el extremo remoto y el secreto) y policy (qué subredes se cifran, en modo túnel):

# --- Sitio A (WAN 192.168.33.1, LAN 1.1.1.0/24) ---
/ip/ipsec/proposal
set default enc-algorithms=aes-128

/ip/ipsec/peer
add address=192.168.33.2 secret=UnSecretoLargoYAleatorio

/ip/ipsec/policy
add sa-src-address=192.168.33.1 sa-dst-address=192.168.33.2 \
    src-address=1.1.1.0/24 dst-address=2.2.2.0/24 tunnel=yes

# --- Sitio B (WAN 192.168.33.2, LAN 2.2.2.0/24) ---
/ip/ipsec/proposal
set default enc-algorithms=aes-128

/ip/ipsec/peer
add address=192.168.33.1 secret=UnSecretoLargoYAleatorio

/ip/ipsec/policy
add sa-src-address=192.168.33.2 sa-dst-address=192.168.33.1 \
    src-address=2.2.2.0/24 dst-address=1.1.1.0/24 tunnel=yes

La contraparte de IPsec es la operación: es el protocolo más quisquilloso de depurar. Hay que cuidar que las policies de ambos lados sean espejo exactas, que el NAT no "pise" el tráfico que debe ir cifrado (regla de accept antes del masquerade en el firewall), y que MTU/MSS no fragmenten. Cuando aparece un problema de "el túnel levanta pero no pasa tráfico", nueve de cada diez veces es NAT o una policy mal calzada. Es robusto y universal, pero paga ese precio en complejidad. Revisamos estos matices caso a caso en nuestro soporte de red.

WireGuard: el túnel moderno en RouterOS v7

Desde RouterOS v7, WireGuard es la forma más limpia de armar una VPN site-to-site en MikroTik cuando ambos extremos son MikroTik (o cualquier equipo con WireGuard). A diferencia de IPsec, sí crea una interfaz (wireguard1) que puedes enrutar, apuntar con rutas estáticas o meter en el firewall como cualquier otra. El modelo es criptografía de clave pública: cada router tiene su par de claves y se autentican por public-key, sin secretos compartidos que negociar por IKE.

La configuración se reduce a crear la interfaz, definir el peer remoto con su clave pública y su endpoint, y declarar en allowed-address qué prefijos viajan por el túnel:

# --- Sitio A ---
/interface/wireguard
add listen-port=13231 name=wireguard1
# (copia la public-key que genera: /interface/wireguard/print)
/ip/address
add address=172.16.0.1/30 interface=wireguard1
/interface/wireguard/peers
add interface=wireguard1 public-key="CLAVE_PUBLICA_SITIO_B" \
    endpoint-address=b.tudominio.cl endpoint-port=13231 \
    allowed-address=172.16.0.2/32,10.1.202.0/24 \
    persistent-keepalive=25s
/ip/route
add dst-address=10.1.202.0/24 gateway=172.16.0.2

Puntos de ingeniería que importan: allowed-address hace doble función —filtra el tráfico entrante y define qué se rutea hacia ese peer—, así que ahí van los prefijos LAN del sitio remoto, no solo la IP del túnel. Si uno de los extremos está detrás de NAT o CGNAT, persistent-keepalive (25s es lo típico) mantiene viva la asociación en el firewall/NAT intermedio. WireGuard usa UDP en un solo puerto (13231 por defecto) y es notablemente más rápido y ligero que IPsec en CPU, lo que se nota en routers pequeños. Cubrimos WireGuard en profundidad en nuestra página de VPN.

EoIP y GRE: cuando necesitas capa 2 o encapsular

IPsec y WireGuard resuelven la conectividad de capa 3 cifrada. Pero a veces el requisito es otro: extender un dominio de broadcast entre sitios, o correr un protocolo de enrutamiento dinámico sobre el túnel. Ahí entran los túneles de encapsulación.

EoIP: Ethernet sobre IP (capa 2)

EoIP es una tecnología propietaria de MikroTik que transporta tramas Ethernet sobre IP, creando un túnel que puedes agregar a un bridge. El resultado es capa 2 extendida: dos LAN geográficamente separadas se comportan como un mismo segmento. Se identifica cada túnel con un tunnel-id y basta la IP remota:

# Sitio A
/interface/eoip/add remote-address=10.0.1.2 tunnel-id=1
# Sitio B
/interface/eoip/add remote-address=10.0.1.1 tunnel-id=1

EoIP no cifra por sí solo. Para protegerlo, se usa la propiedad ipsec-secret del propio túnel, que levanta IPsec transport-mode automáticamente entre los extremos. Ojo con extender capa 2 entre sitios: heredas los broadcasts, el riesgo de loops y el STP a través del enlace WAN. Es potente, pero hay que dimensionarlo con criterio.

GRE: encapsulación genérica (capa 3)

GRE encapsula IP e IPv6 con un overhead de 24 bytes (cabecera GRE de 4 + IP de 20). Su gracia frente a IPsec puro es que crea una interfaz enrutable, ideal para correr OSPF o BGP por dentro del túnel —algo que IPsec por política no permite de forma natural—. Como EoIP, se cifra con ipsec-secret:

# Sitio A
/interface/gre/add name=myGre remote-address=192.168.90.1 local-address=192.168.80.1
/ip/address/add address=172.16.1.1/30 interface=myGre
/ip/route/add dst-address=10.1.202.0/24 gateway=172.16.1.2
# Sitio B (espejo)
/interface/gre/add name=myGre remote-address=192.168.80.1 local-address=192.168.90.1
/ip/address/add address=172.16.1.2/30 interface=myGre
/ip/route/add dst-address=10.1.101.0/24 gateway=172.16.1.1

Un detalle operativo: sin keepalive configurado, la interfaz GRE mantiene la bandera running aunque el otro extremo esté caído, lo que engaña a tu monitoreo y a las rutas. Para detección de fallas real, activa el keepalive del túnel.

IPsec vs WireGuard vs EoIP/GRE: tabla de decisión

Criterio	IPsec (tunnel)	WireGuard	EoIP + IPsec	GRE + IPsec
Capa	L3 (por política)	L3 (interfaz)	L2 (bridge)	L3 (interfaz)
Cifrado	Nativo (ESP)	Nativo	Vía ipsec-secret	Vía ipsec-secret
Interoperable multi-vendor	Sí, es el estándar	Solo si el otro lado habla WireGuard	No (propietario MikroTik)	Sí (GRE es estándar)
Enrutamiento dinámico (OSPF/BGP)	Complejo	Sí	Sí	Sí
Extiende capa 2 / bridge	No	No	Sí	No
Carga en CPU	Media-alta	Baja	Media-alta	Media-alta
Complejidad de operación	Alta	Baja	Media	Media

Cómo elegir tu VPN site-to-site según la topología

La regla práctica que aplicamos en terreno:

Del otro lado hay otro fabricante (o una política de seguridad exige un estándar auditable): IPsec. Es el terreno común con Fortinet, Cisco, Palo Alto y pfSense.
Ambos extremos son MikroTik y quieres simplicidad y rendimiento: WireGuard. Menos líneas, menos CPU, depuración trivial. Es hoy la opción por defecto para site-to-site MikroTik-a-MikroTik en RouterOS v7.
Necesitas correr OSPF/BGP sobre el enlace entre sitios: GRE (o WireGuard) sobre IPsec, porque necesitas una interfaz enrutable.
Necesitas la misma VLAN/segmento L2 en dos sitios (equipos que dependen de broadcast, un cluster que exige la misma subred): EoIP + IPsec, dimensionando bien el riesgo de loops y broadcast sobre WAN.

En redes de misión crítica el diseño no termina en "que levante el túnel". Hay que resolver el failover si cae una WAN, cómo se comporta el CGNAT del ISP, el MTU/MSS clamping para no fragmentar, el ordenamiento de reglas en el firewall para que el tráfico del túnel no se enmascare, y el monitoreo que te avise antes de que el negocio note la caída. Ahí es donde una VPN site-to-site pasa de "funciona en el laboratorio" a "sostiene la operación".

En MikroTik Chile diseñamos, implementamos y operamos VPN site-to-site sobre RouterOS para empresas e ISPs: elegimos la tecnología según tu topología real, documentamos la configuración y dejamos el monitoreo andando. Si estás definiendo cómo unir tus sitios —o tienes un túnel que levanta pero no pasa tráfico— conversemos tu caso con un ingeniero.