WireGuard en OPNsense 26.1: guía para montar un túnel VPN site-to-site entre dos sedes de forma segura

Introducción: el problema real de conectar sedes

Una empresa manufacturera en Envigado tiene su servidor de facturación en la sede administrativa en Medellín. Un despacho de contadores en Bogotá necesita acceder al ERP que corre en el datacenter de la casa matriz. Una clínica en Rionegro consulta historias clínicas hospedadas en servidores del Valle de Aburrá.

En todos esos escenarios, el problema es el mismo: dos redes físicas separadas necesitan comunicarse como si estuvieran en el mismo edificio.

Las soluciones tradicionales no son gratuitas. IPS dedicadas entre sedes tienen costos recurrentes altos y tiempos de implementación que pueden extenderse semanas. OpenVPN, que ha sido el estándar durante años, funciona, pero su configuración en topologías site-to-site demanda manejar certificados, permisos complejos y un volumen considerable de líneas de configuración que en entornos con varios peers se vuelve difícil de mantener.

WireGuard apareció como una alternativa que resuelve buena parte de esos problemas: menos complejidad en la configuración, cifrado moderno por defecto, mejor rendimiento y un modelo de par que se traduce en menos puntos de falla.

En OPNsense 26.1, la versión actual del firewall de código abierto que usamos en CiberTechSolucion, WireGuard está maduro, estable y con soporte nativo a través de su plugin oficial. Eso significa que cualquier empresa puede montar un túnel site-to-site sin licencias adicionales, sin hardware propietario y con control total sobre la infraestructura.

Este artículo explica por qué WireGuard importa en entornos empresariales y cómo implementar un túnel site-to-site entre dos sedes paso a paso, con una arquitectura real, validaciones concretas y las recomendaciones que aplicamos en nuestros despliegues.

Qué es WireGuard y por qué usarlo en OPNsense 26.1

WireGuard es un protocolo de comunicación VPN diseñado para ser simple, rápido y seguro. A diferencia de OpenVPN o IPsec, que acumularon capas de complejidad durante más de una década, WireGuard parte de un código base reducido —apenas unas 4.000 líneas en el kernel de Linux—, lo que lo hace más auditable, más fácil de mantener y con superficie de ataque menor.

Beneficios concretos para empresas

• Configuración simple. Un túnel WireGuard se define con una clave privada, una clave pública, una dirección IP de túnel y un endpoint. No hay certificados que renovar, no hay CA intermedias ni chains de confianza complejas.
• Rendimiento superior. Al operar dentro del kernel del sistema, WireGuard tiene menos overhead que soluciones que corren en espacio de usuario. En la práctica, esto se traduce en mejor throughput y menor latencia en enlaces entre sedes.
• Cifrado moderno por defecto. Usa ChaCha20 para cifrado simétrico, Poly1305 para autenticación de mensajes y Curve25519 para el intercambio de claves. No hay que elegir algoritmos ni negociar parámetros.
• Roaming transparente. Si el IP público de un extremo cambia (común en enlaces residenciales o con failover de WAN), WireGuard se reconecta automáticamente sin intervención manual.
• Menos complejidad operativa. Un túnel es un peer. Agregar un tercero es agregar otro peer. No hay que reestructurar toda la configuración cada vez que la topología crece.

¿Por qué OPNsense 26.1?

OPNsense 26.1 incorpora mejoras de estabilidad en la gestión de interfaces WireGuard, soporte mejorado para peers múltiples y una interfaz gráfica que permite administrar túneles sin tocar la línea de comandos. Además, al ser un firewall completo, permite aplicar reglas de firewall granulares directamente sobre el tráfico del túnel, integrar el tráfico VPN en el sistema de IDS/IPS con Suricata, y mantener visibilidad centralizada de todo el flujo de red.

En CiberTechSolucion recomendamos OPNsense 26.1 como base para despliegues de VPN empresariales porque combina la flexibilidad de WireGuard con el control de un firewall con capacidades Next-Gen.

Cuándo usar un túnel site-to-site

Un túnel site-to-site no es la solución universal para todas las necesidades de conectividad. Es la herramienta correcta cuando la empresa necesita:

• Conectar dos o más oficinas para que compartan recursos internos (servidores, impresoras, aplicaciones de gestión) como si estuvieran en la misma red local.
• Centralizar servicios. Un servidor ERP, un sistema de respaldo o un Active Directory que deben estar accesibles desde múltiples sedes sin exponerlos a internet.
• Acceso a recursos internos entre LANs. Usuarios de la sede B necesitan acceder a bases de datos o sistemas que corren exclusivamente en la red de la sede A.
• Segmentación y control. Filtrar qué tráfico pasa entre sedes y aplicar políticas de seguridad granulares en cada dirección.

Para pymes y empresas medianas con dos a diez sedes, un túnel WireGuard site-to-site es la combinación correcta de simplicidad, seguridad y costo.

Arquitectura de ejemplo: dos sedes conectadas por WireGuard

Para esta guía usamos una topología realista que representa un caso frecuente en empresas colombianas:

Flujo del tráfico entre sedes

Cuando un equipo en la sede A con IP 172.16.0.50 necesita conectarse a un servidor en la sede B con IP 192.168.0.10, el paquete sigue esta ruta:

El paquete viaja cifrado por internet. Nadie en el camino puede ver el contenido ni las IPs de origen y destino reales. Solo ve tráfico UDP cifrado entre dos IPs públicas.

Tutorial paso a paso: crear el túnel WireGuard site-to-site en OPNsense

A continuación, la configuración completa para ambos extremos del túnel. La guía aplica directamente a OPNsense 26.1 con el plugin de WireGuard instalado.

Configuración recomendada: buenas prácticas empresariales

Además de lo ya configurado, estas son las recomendaciones que aplicamos en CiberTechSolucion para despliegues empresariales:

1. Usar puertos únicos por túnel. Si la empresa tiene múltiples túneles WireGuard (por ejemplo, uno site-to-site y varios road warrior), asignar puertos distintos a cada uno. Esto facilita la identificación de tráfico en logs y reglas de firewall.
2. Usar redes de túnel no superpuestas. Nunca usar rangos de IP de túnel que se superpongan con las LANs existentes ni con otras redes de túnel.
3. Documentar claves y peers. Guardar las claves públicas y privadas en un gestor de contraseñas seguro. Registrar qué peer corresponde a qué sede, qué Allowed IPs se configuraron y cuándo se creó el túnel.
4. Limitar Allowed IPs al mínimo necesario. No configurar Allowed IPs como 0.0.0.0/0 salvo que el túnel se use para enrutar todo el tráfico (configuración tipo "full tunnel"). En un site-to-site, especificar exactamente la IP del túnel remoto y la LAN remota.
5. Mantener reglas de firewall restrictivas. La regla por defecto en la interfaz de WireGuard debe ser BLOCK. Solo permitir el tráfico estrictamente necesario.
6. Probar MTU si hay problemas. WireGuard añade overhead de aproximadamente 80 bytes al paquete. Si hay problemas de conectividad esporádica, reducir el MTU de la interfaz WireGuard a 1420 en OPNsense.

Validación del enlace: cómo verificar que el túnel funciona

1. Verificar handshake de WireGuard

En el Sitio A, ir a Status → WireGuard. Buscar la entrada del peer peer_siteb. Debe mostrar:

• Latest Handshake: una fecha reciente (hace menos de 3 minutos).
• Transfer: contadores de bytes enviados y recibidos (deben ser > 0).

Si no hay handshake, el túnel no se ha establecido. Revisar: endpoint correcto, claves intercambiadas correctamente, regla de firewall WAN permitiendo UDP 51820.

2. Ping entre IPs de túnel

Desde la LAN del Sitio A:
$ ping 10.2.2.2

Desde la LAN del Sitio B:
$ ping 10.2.2.1

Ambos deben responder. Si el ping al túnel funciona pero el ping a la LAN no, el problema está en las Allowed IPs o en las rutas.

3. Ping entre LANs

Desde la LAN del Sitio A:
$ ping 192.168.0.10

Si esto responde, el túnel está operando correctamente para tráfico site-to-site.

4. Acceso a servicios específicos

Probar el acceso real al servicio que motivó la implementación del túnel: conexión a un servidor SQL remoto, acceso a una aplicación web interna, o montaje de un recurso compartido de red.

5. Revisar logs

Ir a Status → System Logs → General y filtrar por "WireGuard". No deben aparecer errores repetidos ni warnings de handshake fallido.

6. Verificar reglas de firewall

Ir a Firewall → Log Files → Live View y filtrar por la interfaz de WireGuard. Verificar que el tráfico legítimo pasa (PASS) y que el tráfico no deseado se bloquea (BLOCK).

Errores comunes y cómo resolverlos

Estos son los problemas más frecuentes que vemos en implementaciones de WireGuard site-to-site y cómo los resolvemos:

1. Allowed IPs mal configuradas

2. Falta de reglas de firewall

3. Redes LAN superpuestas

4. Endpoint mal definido

5. Problemas de MTU

6. Claves equivocadas

7. NAT o enrutamiento incorrecto

Recomendaciones empresariales

Un túnel WireGuard site-to-site resuelve el problema de conectividad entre sedes, pero no es una solución aislada. En una arquitectura de red empresarial real, hay factores complementarios que marcan la diferencia entre un túnel que "funciona" y uno que es confiable, monitoreable y seguro.

• Integrar con IDS/IPS. En OPNsense 26.1, la interfaz de WireGuard puede ser monitoreada por Suricata. Activar IDS/IPS sobre el tráfico VPN permite detectar actividad sospechosa que viaje por el túnel —como intentos de lateral movement o escaneo de puertos internos— sin afectar el rendimiento significativamente.
• Implementar monitoreo. Configurar alertas proactivas (con Zabbix, Check_MK o el sistema de notificaciones de OPNsense) que disparen cuando el handshake de WireGuard supere los 3 minutos sin renovarse. Saber que el túnel está caído después de que un servicio dejó de funcionar no es aceptable.
• Documentar la topología. Mantener un diagrama de red actualizado que incluya todos los túneles, sus rangos de IP, los firewalls involucrados y las sedes conectadas. Cuando la empresa crece de dos sedes a cinco, la documentación evita errores de configuración y acelera la resolución de incidencias.
• Planificar la escalabilidad. Si la empresa prevé agregar más sedes, considerar una topología hub-and-spoke donde una sede central actúa como hub y las demás se conectan a ella. WireGuard soporta múltiples peers por instancia.
• Complementar con segmentación. Usar VLANs del lado de cada LAN y reglas de firewall específicas en la interfaz de WireGuard para limitar el acceso por segmento, por equipo o por servicio.
• Revisar el túnel periódicamente. Programar una revisión trimestral: verificación de handshakes, revisión de reglas de firewall, rotación de claves si se considera necesario, y actualización de OPNsense si hay nuevas versiones disponibles.

Cierre: WireGuard simplifica la VPN entre sedes

WireGuard no es una moda. Es un protocolo de VPN que resuelve un problema real de las empresas con un enfoque que se traduce en menos tiempo de implementación, menos complejidad operativa y más confiabilidad.

En combinación con OPNsense 26.1, WireGuard ofrece una plataforma completa para conectar sedes sin depender de hardware propietario, sin pagar licencias por túnel y con la capacidad de aplicar políticas de seguridad granulares directamente en el firewall.

Un túnel site-to-site bien configurado:

• Conecta las LANs de las sedes sin exponer recursos a internet
• Cifra todo el tráfico con algoritmos modernos
• Se integra al firewall para aplicar reglas y monitoreo
• Se escala fácilmente cuando la empresa crece
• Cuesta menos que un enlace dedicado y se implementa en horas, no en semanas

La diferencia entre un túnel que funciona y uno que es confiable para la operación de una empresa está en los detalles: reglas de firewall correctas, Allowed IPs precisas, rutas bien definidas, monitoreo proactivo y documentación actualizada.