VPN sitio a sitio: guía técnica para conectar sedes de forma segura

Una VPN sitio a sitio crea un túnel cifrado permanente entre dos redes completas para que sus equipos se comuniquen como si estuvieran en la misma oficina. El resultado es directo: los recursos compartidos (servidores, impresoras, aplicaciones internas) quedan accesibles entre sedes sin exponer tráfico en abierto por internet.

Para la mayoría de empresas, la opción más práctica y con mejor recorrido a futuro es una implementación IPsec con IKEv2 route-based, por su equilibrio entre seguridad, compatibilidad con fabricantes y facilidad para escalar cuando se suman nuevas sedes.

• Túnel cifrado entre dos redes completas, no entre un usuario y una red.
• Las LAN remotas se ven entre sí como si fueran locales.
• IKEv2 route-based facilita añadir sedes y migrar a SD-WAN más adelante.

---

En resumen:

• Es recomendable optar por VPNs sitio a sitio basadas en IPsec con IKEv2 y configuración route-based para facilitar escalabilidad y migración a SD-WAN.
• La validación del estado del túnel requiere pruebas con tráfico real, no solo inspeccionar el estado en la interfaz, ya que un túnel activo puede no permitir la circulación de datos.
• La configuración correcta de reglas NAT, orden y reglas de firewall, junto con la sincronización horaria y la planificación previa, son esenciales para evitar fallos operativos.
• La arquitectura en malla completa es adecuada para muchas sedes y aumenta la complejidad, pero reduce latencias en comunicaciones directas entre sucursales.
• Externalizar el diseño, implementación y monitorización con expertos como Kipmion ayuda a evitar errores comunes y asegura una operativa fiable a largo plazo.

---

Qué es una VPN sitio a sitio y cuándo tiene sentido usarla

Una VPN de acceso remoto conecta a una persona con una red corporativa. Una VPN sitio a sitio conecta dos redes enteras entre sí, sin que cada empleado necesite instalar cliente alguno. La diferencia es estructural: en la primera hay un usuario en un extremo; en la segunda hay una puerta de enlace (gateway) en cada extremo negociando el túnel de forma automática.

Los casos de uso más habituales en pymes y empresas medianas son:

• Conectar una sucursal con la sede central para compartir servidor de ficheros, ERP o CRM.
• Enlazar la red local con una VPC en la nube (Azure, AWS, Google Cloud) para extender la infraestructura.
• Interconectar dos centros de datos propios para replicación o continuidad de negocio.

Frente a una línea dedicada tipo MPLS, la VPN sitio a sitio corre sobre internet convencional, lo que reduce drásticamente el coste mensual a cambio de depender de la calidad del enlace de cada sede. Para la mayoría de pymes con ancho de banda razonable, esa diferencia es asumible y compensa con creces el ahorro.

Tipos de VPN sitio a sitio: policy-based, route-based e IKEv2

La primera decisión técnica es si el túnel se define por política o por ruta. En una VPN policy-based, cada túnel se asocia a selectores (pares de subredes origen/destino) definidos explícitamente en la política de cifrado; funciona bien con pocos túneles, pero se vuelve difícil de mantener cuando crecen las sedes. En una VPN route-based, el tráfico se enruta hacia una interfaz virtual (a menudo llamada XFRM), separando el cifrado del enrutamiento. Esto facilita integrar routing dinámico y SD-WAN sin rehacer la configuración de cifrado cada vez.

Sobre el protocolo, IKEv2 es hoy la referencia por su estabilidad ante cambios de IP, su gestión más eficiente de las renegociaciones de claves (rekeys) y su compatibilidad amplia entre fabricantes. Para el cifrado, las combinaciones recomendadas son AES-GCM o AES-CBC con SHA-2, junto con Perfect Forward Secrecy (PFS) activado, que impide que el compromiso de una clave exponga sesiones pasadas.

• Policy-based: sencillo para 1-2 túneles fijos, poco escalable.
• Route-based: recomendado para diseños nuevos y multisitio.
• WireGuard o SSL VPN: alternativas ligeras cuando se prioriza rendimiento y no hace falta cumplir con equipos IPsec heredados.

Consejo profesional: Si prevé superar varios túneles activos, empiece directamente en route-based. Migrar una VPN policy-based ya operativa suele implicar una ventana de corte que se puede evitar eligiendo bien desde el diseño inicial.

Cómo configurar una VPN sitio a sitio paso a paso

Configurar el túnel exige orden. Un fallo típico es saltarse la preparación y lanzarse directamente a las fases IKE, lo que multiplica el tiempo de diagnóstico después.

1. Preparación previa
Confirme que ambos extremos tienen IP pública fija (o dinámica con DNS dinámico), que las subredes internas de cada sede no se solapan entre sí y que los relojes de ambos equipos están sincronizados por NTP, porque un desfase horario puede invalidar la negociación de certificados o los tiempos de vida de las claves.

2. Perfil IKE (Fase 1)
Elija IKEv2, un grupo Diffie-Hellman de al menos 2048 bits (o curva elíptica si el equipo lo soporta), tiempos de vida razonables (entre 8 y 24 horas es habitual) y PFS activado. Sophos recomienda IKEv2 por su robustez precisamente porque simplifica la reconexión tras cortes de enlace.

3. Fase 2 y selectores
Defina las propuestas de cifrado de Fase 2 y mapee las subredes que deben viajar por el túnel. Este es el punto donde más errores aparecen: si un extremo declara la subred 192.168.1.0/24 y el otro 192.168.1.0/25, el túnel puede levantarse pero el tráfico real nunca pasará.

4. Reglas críticas de NAT y firewall
La regla de bypass NAT debe colocarse por encima de la regla de enmascaramiento (masquerade) general, o el tráfico destinado al túnel se traducirá por error y nunca llegará al otro extremo. Las guías prácticas de MikroTik señalan este error como la causa más frecuente de fallos en despliegues nuevos. Además, abra los puertos UDP 500 y 4500 y permita el protocolo ESP en el firewall perimetral; configure las políticas para permitir únicamente el tráfico necesario entre las subredes concretas, nunca “todo permitido”.

5. Validación real
Un túnel que aparece como “establecido” no garantiza que el tráfico de aplicación funcione. Pruebe con tráfico real de las aplicaciones que van a usarlo, revise los contadores de bytes en ambos extremos y capture paquetes (packet capture) para confirmar que el tráfico entra y sale cifrado correctamente.

Dato operativo: un túnel puede mostrarse en estado activo sin que el tráfico de aplicaciones fluya, si faltan rutas de retorno o reglas de firewall adecuadas: el semáforo verde en la consola no sustituye a una prueba con tráfico real.

Qué topología conviene según el número de sedes

La arquitectura hub-spoke concentra el tráfico en una sede central que actúa de nodo principal, y cada sucursal levanta un único túnel hacia ella. Es sencilla de administrar y funciona bien hasta que el tráfico entre sucursales empieza a saturar el enlace central, porque todo pasa por ese nodo aunque las dos sucursales estén geográficamente cerca.

Una malla (mesh) conecta cada sede con todas las demás directamente, lo que reduce la latencia entre sucursales pero multiplica el número de túneles a mantener: con seis sedes en malla completa ya se gestionan quince túneles.

• Hub-spoke: ideal para 3-8 sedes con tráfico centralizado en la sede principal.
• Malla completa: mejor cuando hay tráfico intenso entre sucursales sin pasar por un nodo central.
• Conexión a nube: una puerta de enlace virtual en Azure o AWS permite escalar añadiendo sedes sin tocar la infraestructura on-premise, aunque el ancho de banda del gateway suele ser compartido entre todos los túneles conectados.
• Alta disponibilidad: túneles redundantes en configuración activo-activo reducen el impacto de una caída de enlace en una sede.

Seguridad de la VPN sitio a sitio: límites reales y cuándo mirar a SASE

La VPN sitio a sitio clásica concede acceso amplio entre redes completas. Si un equipo de una sucursal se ve comprometido, el atacante puede moverse lateralmente hacia la sede central sin más obstáculo que el propio firewall interno, porque el túnel en sí no distingue qué aplicación o usuario está generando ese tráfico.

Esa limitación se mitiga con controles complementarios: segmentación de red por VLAN, reglas de firewall específicas por aplicación en lugar de por subred completa, y autenticación reforzada con certificados en vez de claves precompartidas cuando el número de túneles crece.

• Segmente la red interna aunque el túnel ya esté cifrado.
• Sustituya claves precompartidas por certificados a partir de cierto volumen de sedes.
• Revise periódicamente qué subredes tienen realmente acceso mutuo.

Cuando la prioridad pasa a ser visibilidad granular por identidad y reducción de superficie de ataque, los modelos SASE y Zero Trust ofrecen un enfoque más moderno: en lugar de conceder acceso a toda una subred, autorizan aplicación por aplicación y usuario por usuario. No sustituyen necesariamente a la VPN sitio a sitio en todos los escenarios, pero conviene evaluarlos cuando la organización opera con múltiples sedes y necesita control fino sobre quién accede a qué.

Consejo profesional: No espere a sufrir un incidente para segmentar la red interna. Es mucho más barato aplicar esa disciplina desde el diseño inicial que reestructurar reglas de firewall con el túnel ya en producción.

Por qué el ping no basta para validar el túnel

El protocolo ICMP (el que usa el comando ping) suele estar permitido en el firewall aunque los puertos reales de las aplicaciones estén bloqueados. Las pruebas fiables exigen packet capture y tráfico de aplicación real, no solo un ping exitoso entre extremos.

Los errores más frecuentes al levantar un túnel siguen un patrón reconocible:

1. Bypass NAT olvidado o mal posicionado: el tráfico se traduce antes de entrar al túnel y nunca llega a destino.
2. MTU y fragmentación: paquetes grandes se fragmentan o se descartan silenciosamente, afectando a transferencias de archivos pero no a un ping simple.
3. Selectores desalineados: las subredes declaradas en cada extremo no coinciden exactamente, y el túnel se establece solo para parte del tráfico.
4. Policy mismatch en Fase 2: propuestas de cifrado distintas en cada extremo impiden renegociar tras el primer rekey.

Revise también el estado de Dead Peer Detection (DPD), los contadores de paquetes cifrados/descifrados y los logs de renegociación: ahí suele estar la pista que el ping nunca mostrará.

Cómo mantener operativa una VPN sitio a sitio a largo plazo

Un túnel bien configurado se puede degradar con el tiempo sin que nadie lo note hasta que falla en el peor momento. La monitorización continua debe cubrir el estado de las asociaciones de seguridad (SA), los contadores de bytes transmitidos y recibidos, la latencia entre extremos y la pérdida de paquetes.

• Configure alertas automáticas ante caídas de túnel o renegociaciones fallidas.
• Documente y guarde copias de seguridad de la configuración tras cada cambio.
• Pruebe el túnel después de actualizaciones de firmware, cambios en reglas de firewall o renovación de certificados, no solo cuando algo deja de funcionar.
• Revise periódicamente los tiempos de vida configurados en Fase 1 y Fase 2 para evitar rekeys demasiado frecuentes que penalicen el rendimiento.

Una red bien monitorizada detecta la degradación de un túnel antes de que afecte a la operativa diaria, en lugar de descubrirla cuando un empleado ya no puede acceder al servidor de la sede central.

Cómo puede ayudar Kipmion con su VPN sitio a sitio

Kipmion diseña e implementa VPN sitio a sitio para empresas que necesitan conectar sucursales, centros de datos o entornos en la nube sin depender de prueba y error interno. El servicio cubre diseño de topología, configuración de perfiles IKE, integración con VPC en la nube, y monitorización posterior.

• Validación con tráfico real y packet capture antes de dar por cerrado el proyecto, no solo comprobación de estado del túnel.
• Auditoría posterior a la implantación para detectar reglas de firewall demasiado permisivas.
• Acceso a un catálogo con más de 180.000 referencias tecnológicas para equipar cada sede con el hardware adecuado.

Consejo profesional: Antes de contratar cualquier implantación, pida que se documente el procedimiento de rekey y el plan de copia de seguridad de la configuración. Es lo primero que se pierde cuando cambia el proveedor de soporte.

Lo que la mayoría de guías sobre VPN sitio a sitio no dice

La mayoría de tutoriales tratan la configuración de una VPN sitio a sitio como un ejercicio de manual: se copian los parámetros de Fase 1 y Fase 2, el túnel se pone en verde, y se da por terminado el trabajo. Esa es precisamente la parte que menos importa. El verdadero riesgo aparece semanas después, cuando una regla de firewall cambia, un certificado caduca o alguien añade una subred nueva sin comprobar que no colisiona con la del otro extremo.

La disciplina que de verdad separa una VPN estable de una que falla en el peor momento no está en la elección de IKEv2 frente a IKEv1, sino en la validación con tráfico real y en la monitorización continua después del despliegue. Un túnel establecido no es sinónimo de un túnel funcional, y confundir ambas cosas es el error operativo más caro que se comete en este tipo de proyectos.

Si dirige el área TI de una pyme, priorice primero la documentación del diseño y el procedimiento de recuperación ante fallos, antes que perseguir el protocolo más moderno disponible. Un WireGuard perfectamente configurado sin plan de contingencia es más frágil que un IPsec clásico bien documentado y monitorizado.

— Sem

Cómo diseña Kipmion su servicio de VPN sitio a sitio para empresas

Externalizar el diseño y la implantación evita el ensayo y error que suele costar semanas de productividad a un equipo TI interno sin dedicación exclusiva a redes. Kipmion es la alternativa a resolverlo por su cuenta cuando su equipo necesita conectar sedes con garantías desde el primer día: diseño de topología, configuración de perfiles IKE, integración con entornos en la nube y validación con tráfico real antes de cerrar el proyecto.

El proceso arranca con una auditoría de la infraestructura actual (subredes, anchos de banda, número de sedes previstas) para elegir entre hub-spoke, malla o conexión híbrida con la nube. Después llega la implantación, con pruebas de tráfico real y packet capture antes de considerar el túnel operativo, y finalmente el soporte continuado para monitorización y mantenimiento.

Consulte los servicios y soluciones de Kipmion para solicitar una auditoría inicial de su red y recibir una propuesta de implantación ajustada al número de sedes y al presupuesto disponible.

Puntos clave

Una VPN sitio a sitio bien diseñada requiere IKEv2 route-based, reglas de NAT correctamente ordenadas y validación con tráfico real, no solo con ping.

Punto	Detalles
Elegir route-based desde el diseño	Facilita añadir sedes y migrar a SD-WAN sin rehacer la configuración de cifrado.
Bypass NAT antes de masquerade	Es el error más frecuente al levantar túneles nuevos y bloquea el tráfico real.
Validar con tráfico real	Un túnel “establecido” no garantiza que las aplicaciones funcionen; use packet capture.
Monitorizar tras cada cambio	Firmware, reglas de firewall o certificados nuevos exigen una prueba posterior, no solo al fallar.
Externalizar con Kipmion	Kipmion audita, implementa y valida VPN sitio a sitio con pruebas operativas reales.

Fuentes

• Sophos community — Sophos firewall best practice for site-to-site policy based IPsec VPN
• Guía de VPN IPsec Sitio a Sitio MikroTik
• Avanet — Configurar VPN IPsec Site-to-Site Sophos Firewall

Recomendación

• SAI para servidores: guía técnica de selección y dimensionamiento
• Teletrabajo seguro para empresas: guía práctica para pymes
• Cómo auditar infraestructura TI: guía práctica para pymes
• Tz80 Secure Connect 3yr – Kipmion Tecnología