(Book) Networking with MikroTik RouterOS: A Practical Approach to Understanding and Implementing RouterOS
Study material for the MTCNA Certification Course, updated to RouterOS v7
$19,97
ExpoISP Quito 18 y 19 de Noviembre 2026
MikroTik IPsec: elegir entre modo túnel y modo transporte para una VPN
- Ingrid Espinoza
- No hay comentarios
- Comparte este artículo
Facebook
Twitter
LinkedIn
WhatsApp
Telegram
Cuando configuro una VPN IPsec en MikroTik, una de las decisiones que más dudas genera es elegir entre modo túnel y modo transporte.
A primera vista puede parecer una opción más dentro de la configuración de IPsec, pero realmente define cómo se protege el paquete IP y qué tipo de comunicación estamos intentando establecer.
La diferencia fundamental es sencilla: en modo transporte, IPsec protege principalmente la carga útil del paquete original y conserva su encabezado IP; en modo túnel, el paquete IP original completo se encapsula dentro de un nuevo paquete IP. RouterOS documenta explícitamente este comportamiento para ESP, que es el protocolo IPsec utilizado habitualmente para cifrar el tráfico.
Y aquí aparece la primera regla práctica que conviene recordar:
Si quiero conectar dos redes completas mediante una VPN IPsec site-to-site en MikroTik, mi opción habitual es el modo túnel.
En mi caso, de hecho, cuando configuro IPsec site-to-site siempre utilizo modo túnel. No es porque el modo transporte sea inútil, sino porque responde a un escenario diferente.
En este artículo vamos a ver qué cambia realmente entre ambos modos, cuándo utilizar cada uno y, sobre todo, cómo tomar la decisión correcta en RouterOS sin complicar innecesariamente la configuración.
¿Qué diferencia hay entre el modo túnel y el modo transporte en IPsec?
Antes de entrar en comandos de MikroTik, merece la pena entender qué ocurre con un paquete cuando pasa por IPsec.
Supongamos que un equipo de una LAN tiene que comunicarse con otro equipo situado en una red remota.
Sin IPsec podríamos tener algo parecido a:
IP origen → IP destino → datosPor ejemplo:
192.168.10.50 → 192.168.20.50Cuando utilizamos IPsec, el paquete puede protegerse de dos maneras diferentes.
Modo transporte
En modo transporte, el encabezado IP original permanece visible y IPsec se incorpora después de ese encabezado. Con ESP, el payload del paquete se cifra y autentica, mientras que el encabezado IP original no queda protegido de la misma manera.
Simplificando:
[IP original][ESP][datos protegidos]La dirección IP de origen y destino continúa formando parte del encabezado exterior.
Este diseño tiene sentido cuando los dos extremos de la comunicación ya son los propios hosts que participan en IPsec y no necesitamos envolver un paquete IP completo dentro de otro.
Por eso el modo transporte suele asociarse a escenarios host-to-host o comunicaciones muy concretas entre dos extremos.
Modo túnel
En modo túnel, el paquete IP original se convierte en la carga de un nuevo paquete IP.
Conceptualmente:
[Nuevo IP][ESP][IP original + datos protegidos]Aquí el paquete original completo queda encapsulado y el paquete exterior utiliza las direcciones de los extremos del túnel.
Esta diferencia es especialmente importante cuando queremos utilizar IPsec para conectar redes completas.
Por ejemplo:
LAN A → MikroTik A → Internet → MikroTik B → LAN BEl tráfico puede comenzar siendo:
192.168.10.50 → 192.168.20.50pero el transporte IPsec utiliza los extremos de la VPN para transportar ese paquete encapsulado.
La documentación oficial de MikroTik describe precisamente el modo túnel como la encapsulación del paquete IP original dentro de un paquete IP nuevo, mientras que en transporte el encabezado IP original queda fuera de la parte cifrada de ESP.
Y esta distinción explica buena parte de la respuesta a la pregunta de qué modo elegir en MikroTik.
Modo túnel vs. modo transporte: diferencias clave
La comparación no debería reducirse a “túnel = seguro” y “transporte = rápido”. Esa explicación es demasiado simplista.
Los dos modos forman parte de IPsec y pueden utilizar mecanismos criptográficos como ESP. La diferencia principal está en qué se encapsula, qué encabezado queda expuesto y cuál es el escenario de comunicación.
| Característica | Modo túnel | Modo transporte |
|---|---|---|
| Paquete IP original | Se encapsula completo | Se mantiene el encabezado exterior |
| Nuevo encabezado IP | Sí | No |
| Protección del encabezado IP original con ESP | Sí, queda dentro del paquete encapsulado | No |
| Escenario típico | Red ↔ red | Host ↔ host |
| VPN site-to-site | Muy habitual | No suele ser la elección |
| Overhead | Mayor | Menor |
tunnel en política RouterOS | yes | no |
| Uso para conectar LAN completas | Sí | No es el escenario habitual |
RouterOS refleja esta diferencia directamente en las políticas IPsec: la Fase 2 debe negociar, entre otros parámetros, el modo túnel o transporte.
Encapsulación y cabeceras IP
La principal diferencia técnica está en la encapsulación.
Con transporte, el paquete conserva su encabezado IP original y ESP se coloca después de él. Con túnel, el paquete original se introduce dentro de otro paquete IP.
Esto significa que el modo túnel añade más información al paquete y, por tanto, introduce más overhead.
No obstante, ese overhead no debería convertirse automáticamente en un argumento para elegir transporte.
Si el objetivo es unir dos redes mediante IPsec, ahorrar unos bytes de encapsulación no compensa elegir un modelo que no corresponde al diseño que queremos implementar.
Seguridad y protección del tráfico
Aquí conviene corregir una idea muy extendida.
No es correcto interpretar el modo transporte como un modo “sin seguridad”.
El modo transporte puede proporcionar confidencialidad e integridad mediante ESP. La diferencia está en que el encabezado IP exterior no se protege como ocurre con el paquete IP completo encapsulado en modo túnel.
Por eso la pregunta correcta no es:
“¿Cuál cifra mejor?”
sino:
“¿Qué parte del paquete necesito proteger y cómo están definidos los extremos de mi comunicación?”
Para una comunicación entre dos hosts concretos, transporte puede ser perfectamente válido.
Para conectar dos LAN completas, el modo túnel resulta mucho más natural porque permite transportar los paquetes originales de esas redes dentro de la asociación IPsec.
Overhead y rendimiento
El modo túnel necesita un nuevo encabezado IP y, además, la estructura adicional de ESP. Esto incrementa el tamaño del paquete.
El modo transporte tiene menos overhead porque no encapsula un paquete IP completo dentro de otro.
Eso puede parecer una razón suficiente para escoger transporte, especialmente cuando estamos pensando en rendimiento. Pero hay que mirar el problema completo.
El rendimiento de IPsec en MikroTik también depende del modelo de hardware y de los algoritmos utilizados. RouterOS incluye soporte para aceleración criptográfica por hardware en determinados equipos y algoritmos, por lo que no tiene sentido asumir que cualquier diferencia teórica de encapsulación será el factor dominante en el rendimiento real.
En otras palabras: no elegiría transporte únicamente porque añade menos overhead.
Primero definiría correctamente el tipo de VPN y después comprobaría el rendimiento del equipo y de los algoritmos utilizados.
¿Cuándo usar modo túnel en MikroTik?
El modo túnel tiene sentido cuando queremos proteger una comunicación en la que existe un paquete IP completo que debe viajar entre dos extremos IPsec.
El ejemplo más claro es una VPN site-to-site.
VPN IPsec site-to-site
Imaginemos dos oficinas:
- Site A:
192.168.10.0/24 - Site B:
192.168.20.0/24
En Site A tenemos un MikroTik y en Site B otro MikroTik.
Un ordenador de la primera oficina:
192.168.10.50
necesita comunicarse con:
192.168.20.50
El objetivo es que ambas LAN puedan intercambiar tráfico a través de Internet de manera protegida.
Aquí el modo túnel encaja perfectamente.
La política IPsec puede especificar:
src-address=192.168.10.0/24
dst-address=192.168.20.0/24
tunnel=yesEn RouterOS, tunnel=yes indica que esa política utiliza modo túnel. La documentación oficial muestra este mismo patrón para políticas que protegen tráfico entre redes.
Además, una guía práctica reciente de configuración site-to-site para RouterOS v7 utiliza precisamente tunnel=yes en la política que conecta las dos subredes.
Este es exactamente el escenario que encuentro más habitual cuando trabajo con IPsec site-to-site. En mi caso, para este tipo de configuración siempre utilizo modo túnel.
Conectar redes completas mediante IPsec
La ventaja del túnel es que no necesitamos pensar en IPsec como una conexión independiente para cada aplicación.
La política puede describir el tráfico entre subredes completas.
Por ejemplo:
LAN A: 10.10.10.0/24
↓
MikroTik A
↓
IPsec
↓
MikroTik B
↓
LAN B: 10.20.20.0/24Un servidor, una impresora, un ordenador o cualquier otro host permitido de una LAN puede comunicarse con los recursos de la otra LAN siempre que el enrutamiento y las políticas estén correctamente configurados.
Esta es precisamente la diferencia práctica entre pensar en una VPN red-a-red y una asociación IPsec host-a-host.
La guía de MKController para RouterOS v7 también estructura la configuración alrededor de dos LAN y una política que define el tráfico de la red local hacia la red remota.
Conectar una red con un host
El modo túnel tampoco está limitado exclusivamente a dos redes completas.
Puede utilizarse cuando necesitamos proteger un paquete IP completo aunque uno de los extremos sea un host concreto.
Lo importante es entender que la decisión se toma en función de cómo queremos encapsular el tráfico y cuáles son los selectores de la política IPsec, no simplemente por el nombre comercial de la VPN.
Por eso, si estamos construyendo una política en RouterOS y tenemos dudas entre tunnel=yes y tunnel=no, conviene empezar por identificar qué representan src-address y dst-address en esa política.
¿Cuándo usar modo transporte en MikroTik?
El modo transporte tiene su lugar, pero normalmente aparece cuando el diseño necesita proteger directamente la comunicación entre dos extremos IPsec y no necesitamos encapsular un paquete IP completo dentro de otro.
Su ventaja principal es que evita la encapsulación completa del paquete original.
Comunicación IPsec entre dos hosts
Un ejemplo conceptual sería:
Host A ↔ IPsec ↔ Host B
Los propios hosts son los extremos de la comunicación protegida.
En este caso, mantener el encabezado IP original puede ser apropiado y el modo transporte permite evitar parte del overhead asociado al túnel.
Por tanto, transporte puede ser una buena elección cuando el problema que estamos resolviendo es host-to-host y ambos extremos están preparados para trabajar con IPsec de esa forma.
Esto es muy diferente de decir:
“Tengo dos oficinas y quiero que todas sus máquinas se comuniquen”.
En ese segundo caso estamos ante un problema de red-a-red y el modo túnel resulta mucho más adecuado.
Casos en los que no necesitas encapsular el paquete IP
La mejor forma de entender transporte es pensar que no siempre necesitamos crear una nueva envoltura IP.
Si el encabezado IP exterior puede seguir identificando correctamente los extremos y únicamente necesitamos proteger la información transportada, el modo transporte puede evitar una capa adicional de encapsulación.
Esto puede resultar útil en determinados diseños específicos y puede reducir el overhead.
Pero no conviene convertir esta ventaja en una recomendación universal.
Menos overhead no significa automáticamente que sea el modo correcto.
En una VPN, primero hay que conseguir que la arquitectura sea correcta y después optimizar.
¿Qué modo elegir para una VPN IPsec site-to-site en MikroTik?
Si la pregunta es directamente:
“Tengo dos MikroTik y quiero crear una VPN IPsec site-to-site. ¿Qué modo debería utilizar?”
Mi respuesta práctica es:
Modo túnel.
No tendría sentido complicarlo más de lo necesario.
En una VPN site-to-site queremos conectar, por ejemplo:
192.168.10.0/24 ↔ 192.168.20.0/24
La política IPsec define precisamente esas redes como origen y destino y utiliza tunnel=yes.
En RouterOS, una política de este tipo puede verse conceptualmente así:
/ip ipsec policy
add peer=siteB \
tunnel=yes \
src-address=192.168.10.0/24 \
dst-address=192.168.20.0/24 \
action=encryptLos parámetros reales dependerán del diseño, RouterOS, peer, proposal, autenticación y demás elementos de la configuración. No conviene copiar un bloque de configuración sin adaptar esos valores a la topología real.
La documentación de MikroTik muestra que el modo forma parte de la negociación de Fase 2 y que una política puede establecer explícitamente tunnel=yes.
Por qué el modo túnel es la opción habitual
La razón es sencilla: una VPN site-to-site no pretende proteger únicamente una conversación entre dos hosts concretos.
Pretende unir dos dominios de red.
Por eso resulta natural que el paquete original:
IP origen: 192.168.10.50
IP destino: 192.168.20.50sea transportado dentro de un nuevo paquete IP correspondiente a la asociación IPsec.
Además, el enfoque encaja con la forma en que RouterOS define las políticas: podemos indicar las subredes que deben cifrarse y dejar que IPsec se encargue del tráfico que coincida con ellas.
En mis configuraciones site-to-site siempre parto del modo túnel. Es una regla práctica que me evita intentar resolver un problema de red-a-red con un mecanismo pensado para otro tipo de comunicación.
Qué significa tunnel=yes en RouterOS
Este parámetro merece especial atención porque aparece continuamente en configuraciones MikroTik.
Cuando vemos:
tunnel=yesen una política IPsec, estamos indicando que la política debe utilizar modo túnel.
No significa que estemos activando IKEv2, ni que estemos seleccionando el algoritmo de cifrado, ni que estemos creando por sí solo una VPN completa.
Son conceptos diferentes.
En IPsec intervienen varios componentes:
- IKE negocia y autentica.
- La Fase 1 establece los parámetros del intercambio.
- La Fase 2 establece las asociaciones utilizadas para proteger los datos.
- ESP proporciona la protección del tráfico.
- La política determina qué tráfico debe procesarse y con qué parámetros.
tunnel=yesdetermina que esa política utiliza modo túnel.
RouterOS documenta que, durante la Fase 2, los extremos deben coincidir también en el modo IPsec, además del protocolo, autenticación, PFS y lifetime.
Por eso un error en el modo puede impedir que la Fase 2 llegue a establecerse correctamente.
Errores habituales al configurar el modo IPsec
Elegir el modo correcto es importante, pero una VPN site-to-site puede fallar aunque hayamos elegido tunnel=yes.
De hecho, algunos de los problemas más comunes aparecen en otros puntos de la configuración.
Elegir transporte para una VPN entre redes
Este es el primer error conceptual.
Si la intención es:
LAN A ↔ LAN Bno deberíamos elegir transporte simplemente porque “consume menos”.
El modo transporte está pensado para otro modelo de comunicación.
Si tenemos dos redes completas detrás de dos routers, el modo túnel refleja mucho mejor lo que queremos hacer.
Confundir el modo IPsec con IKE, ESP o la propuesta de cifrado
Otro error frecuente es mezclar conceptos.
IKEv2 no es un modo túnel.
IKEv2 es el protocolo utilizado para establecer y gestionar las asociaciones de seguridad.
ESP tampoco es un modo.
ESP es el protocolo que proporciona la protección del tráfico.
Y AES, SHA-256 o PFS tampoco determinan por sí mismos si estamos usando túnel o transporte.
El modo es un parámetro independiente de la política/Fase 2.
RouterOS separa explícitamente estos elementos en su documentación: IKE gestiona el establecimiento de las asociaciones y la Fase 2 negocia, entre otros parámetros, el protocolo IPsec y el modo túnel/transporte.
Problemas de MTU y encapsulación
El modo túnel añade encapsulación, por lo que el tamaño final del paquete aumenta.
Esto puede tener consecuencias sobre MTU y fragmentación, especialmente en enlaces donde ya existe poco margen.
Por eso, cuando una VPN IPsec funciona para algunos protocolos pero aparecen problemas extraños con otros tipos de tráfico, no hay que mirar únicamente el cifrado.
También conviene revisar:
- MTU.
- Fragmentación.
- MSS.
- NAT.
- Firewall.
- Rutas.
- Políticas IPsec.
- Estado de las asociaciones.
La encapsulación adicional del modo túnel es un factor técnico real y debe tenerse presente durante el diagnóstico.
Ejemplo práctico de IPsec site-to-site en MikroTik
Supongamos una arquitectura sencilla:
INTERNET
┌─────────────┐
│ │
MikroTik A MikroTik B
│ │
192.168.10.0/24 192.168.20.0/24
│ │
Site A Site BQueremos que:
192.168.10.0/24
pueda comunicarse con:
192.168.20.0/24
La política de Site A podría tener conceptualmente:
src-address=192.168.10.0/24
dst-address=192.168.20.0/24
action=encrypt
tunnel=yesY Site B utilizaría las redes invertidas.
Este diseño coincide con el patrón práctico de RouterOS v7 utilizado en guías de configuración site-to-site: una política para el tráfico LAN local hacia la LAN remota, con tunnel=yes.
Pero hay algo importante: IPsec no sustituye al resto de la configuración de red.
También necesitamos que el tráfico tenga una ruta adecuada y que las reglas de NAT y firewall no interfieran.
El NAT bypass es especialmente importante
Imaginemos que el MikroTik tiene una regla general:
chain=srcnat
action=masqueradeSi el tráfico destinado a la LAN remota pasa por el masquerade antes de ser procesado correctamente por IPsec, la dirección de origen puede dejar de coincidir con los selectores definidos en la política.
Por eso es habitual colocar una regla de excepción para el tráfico entre las dos LAN antes de la regla general de masquerade.
Un ejemplo conceptual sería:
/ip firewall nat
add chain=srcnat \
action=accept \
src-address=192.168.10.0/24 \
dst-address=192.168.20.0/24La guía de configuración site-to-site de MKController destaca precisamente el NAT bypass como uno de los puntos que más problemas causa en los primeros intentos de configuración.
En mi experiencia, este tipo de detalle es tan importante como haber elegido correctamente el modo túnel: puedes tener el tunnel=yes perfectamente configurado y, aun así, no conseguir tráfico útil si NAT, firewall o las políticas no están alineados.
Cómo comprobar si la VPN está funcionando
Una vez configurado IPsec, no me limitaría a mirar si existe un peer.
Hay que comprobar que la Fase 2 esté realmente establecida y que el tráfico coincida con la política.
En RouterOS podemos revisar, entre otras cosas:
/ip ipsec active-peers print
/ip ipsec policy printDespués podemos probar conectividad desde un host de una LAN hacia un host de la otra.
La documentación y las guías prácticas de RouterOS utilizan el estado de las políticas y las asociaciones activas como parte del proceso de verificación.
Si el peer está activo pero no hay una Fase 2 establecida, el problema no necesariamente está en IKE.
Puede estar en:
- Selectores.
- Proposal.
- PFS.
- Modo túnel/transporte.
- Direcciones.
- Políticas.
- Algoritmos incompatibles.
Conclusión
La elección entre modo túnel y modo transporte en MikroTik IPsec es mucho más fácil cuando dejamos de pensar en ellos como dos niveles de seguridad y empezamos a pensar en qué tipo de comunicación queremos proteger.
Si necesitas proteger una comunicación directa entre dos hosts y no necesitas encapsular el paquete IP completo, el modo transporte puede tener sentido. Su principal ventaja es una menor encapsulación y, por tanto, menor overhead.
Pero si tu objetivo es crear una VPN IPsec site-to-site entre dos redes, el modo túnel es la opción que utilizaría.
La idea puede resumirse así:
Host ↔ host: considera transporte.
Red ↔ red: utiliza túnel.
En MikroTik RouterOS esto se refleja directamente en la política IPsec mediante tunnel=yes.
Y hay una segunda lección importante: elegir correctamente el modo no garantiza por sí solo que la VPN funcione. En una implementación real también hay que revisar la Fase 1, Fase 2, proposal, PFS, selectores, rutas, NAT bypass, firewall y estado de las asociaciones.
Para mí, la regla práctica queda muy clara: cuando configuro una VPN IPsec site-to-site en MikroTik, siempre parto del modo túnel y tunnel=yes. Después ajusto el resto de parámetros a la topología y a los requisitos de seguridad.
La documentación oficial de MikroTik confirma la diferencia de encapsulación entre ambos modos y muestra el uso de tunnel=yes en políticas IPsec que protegen tráfico de redes remotas.
Preguntas Frecuentes
¿El modo transporte es menos seguro que el modo túnel?
No conviene expresarlo de esa manera.
Ambos pueden utilizar ESP para proporcionar confidencialidad e integridad. La diferencia principal está en qué parte del paquete queda protegida y cómo se encapsula.
Con ESP en transporte, el encabezado IP exterior permanece fuera de la protección de la carga útil; en túnel, el paquete IP original queda encapsulado dentro de un nuevo paquete IP.
Por tanto, la elección debe depender del diseño y de los extremos de la comunicación, no de una clasificación simplista de “seguro” frente a “inseguro”.
¿Puedo usar modo transporte para una VPN site-to-site?
Técnicamente existen diseños IPsec más específicos en los que transporte puede aparecer, pero para una VPN site-to-site convencional entre dos redes completas el modo túnel es la elección habitual.
Si tienes:
LAN A ↔ LAN B
y dos MikroTik actuando como extremos de la VPN, utilizaría una política con tunnel=yes.
Es también el patrón utilizado en configuraciones prácticas de RouterOS para conectar dos subredes.
¿Qué significa tunnel=yes en MikroTik?
Significa que la política IPsec utiliza modo túnel.
El paquete IP original se encapsula dentro de un nuevo paquete IP.
En una política site-to-site, normalmente encontraremos algo parecido a:
src-address=LAN_A
dst-address=LAN_B
tunnel=yes
action=encrypt¿Qué modo IPsec consume menos recursos?
En igualdad de condiciones, el modo transporte introduce menos overhead de encapsulación porque no encapsula el paquete IP completo dentro de otro.
Pero no recomendaría seleccionar el modo únicamente por este criterio.
La carga criptográfica, el algoritmo utilizado, el hardware del MikroTik, el tráfico y la aceleración disponible también influyen en el rendimiento. RouterOS ofrece aceleración por hardware para determinados equipos y algoritmos.
¿Qué modo debería utilizar para conectar dos oficinas con MikroTik?
Modo túnel.
Si quieres conectar:
Oficina A → Oficina B
y cada oficina tiene su propia LAN detrás de un MikroTik, el modo túnel es la opción natural.
En mi caso, esta es precisamente la configuración que utilizo para las VPN IPsec site-to-site: modo túnel.
¿Modo túnel significa que estoy usando IKEv2?
No.
Son conceptos diferentes.
Puedes utilizar IKEv2 para establecer la negociación y, durante la Fase 2, utilizar IPsec en modo túnel.
IKEv2 se ocupa del intercambio y establecimiento de las asociaciones; el modo túnel/transporte describe cómo se protege y encapsula el tráfico IP. RouterOS separa ambos conceptos en su configuración.
Breve cuestionario de conocimientos
¿Qué te pareció este artículo?
¿Te atreves a evaluar tus conocimientos aprendidos?
Libros recomendados para éste artículo
Libro Conceptos Fundamentales de MikroTik, RouterOS v7
Material de estudio para el Curso de Certificación MTCNA, actualizado a RouterOS v7
$19,97
Autoestudio MikroTik
Estudia las certificaciones MikroTik a tu propio ritmo
Autoestudio
Aprende a tu propio ritmo
advertisement (anuncio)
[taxopress_relatedposts id="1"]
MikroLABs
Otros temas que te pueden interesar
MikroTik IPsec: elegir entre modo túnel y modo transporte para una VPN
noviembre 13, 2026
Entre Stateful y Stateless: Dominando el Firewall de MikroTik
noviembre 12, 2026
advertisement (anuncio)
Escríbenos por WhatsApp (+593 98 700 0604)
¿Quieres sugerir un tema?
Todas las semanas posteamos nuevo contenido. Quieres que tratemos sobre algo específico?
Próximos Cursos
Libros MikroTik (español)
advertisement (anuncio)
MONARC Latin America: Soluciones Tecnológicas - monarclatinamerica.com.gt - Guatemala
Inteligencia Artificial Aplicada
- Compara ChatGPT, Gemini y Claude. Explora sus opciones de integración y elige la más adecuada para cada tarea.
- Aprende cómo funcionan las integraciones. Entiende para qué sirven las APIs, los MCP, las skills y los plugins, y cuándo usar cada uno.
- Conecta la IA con Microsoft 365 y Google Workspace. Practica con las herramientas que ya usas para trabajar con documentos y hojas de cálculo.
- Resume documentos y extrae información clave. Usa la IA para identificar los puntos importantes de un archivo y preparar un resumen para tu equipo.
