Acceso remoto seguro con WireGuard en OPNsense

WireGuard ofrece una configuración compacta para acceso remoto al homelab. OPNsense integra instancias, peers, reglas y diagnóstico en la misma interfaz, pero hay que configurar cada pieza en el orden correcto.

1. Por qué WireGuard y no OpenVPN o IPsec

WireGuard es un protocolo VPN moderno con un conjunto pequeño y fijo de algoritmos criptográficos. Frente a OpenVPN y a IPsec tiene tres ventajas prácticas que se notan en el día a día:

• Configuración corta. Cada peer necesita un par de claves, una dirección de túnel y las redes permitidas. No hay que administrar una autoridad certificadora.
• Integración limpia. OPNsense puede asignar la interfaz, aplicar reglas y resolver DNS con los mismos menús utilizados por el resto de la red.
• Roaming transparente. Si el cliente cambia de IP, por ejemplo al pasar de WiFi a datos móviles, el peer puede actualizar su endpoint sin reconstruir toda la configuración.

La guía Montar una VPN con WireGuard en 30 minutos cubre una instalación sobre Linux pelado. Aquí vamos un paso más allá y lo integramos en OPNsense, que ya tiene firewall, aliases y DNS.

2. Instalar el plugin y entender el modelo

WireGuard se administra desde VPN ‣ WireGuard. Si ese menú no aparece en una instalación antigua, revisa System ‣ Firmware ‣ Plugins y la documentación correspondiente a tu versión antes de continuar. La interfaz organiza la configuración en General, Instances, Peers y diagnósticos.

El modelo mental es:

Instancia, peer y redes permitidas

• Instance = el “servidor” WireGuard que escucha en un puerto UDP. Tiene clave pública/privada, puerto, MTU y dirección del túnel.
• Peer = un cliente o un sitio remoto. Tiene clave pública, IP permitida dentro del túnel y endpoint (IP:puerto público del otro lado).
• Allowed IPs = qué tráfico se cifra hacia ese peer. En cliente road warrior suele ser 0.0.0.0/0 (todo el tráfico) o solo las subredes internas.

3. Crear la instancia del servidor

En VPN ‣ WireGuard ‣ Instances pulsa + y rellena:

Campo	Valor de ejemplo	Notas
Enabled	✓
Name	HomeWireGuard	Nombre que verás en logs y reglas
Public Key	(vacío)	Pulsa el engranaje para generar
Private Key	(vacío)	Se genera junto con la pública
Listen Port	51820	UDP; cámbialo si tu ISP lo bloquea
MTU	1420	1412 si usas PPPoE (80 bytes menos que el MTU WAN)
Tunnel Address	10.10.99.1/24	Red del túnel, distinta de tu LAN
Disable Routes	✗	Déjalo desmarcado para que OPNsense enrute
Peers	(vacío al principio)	Se añaden después

La dirección de túnel se configura en esta instancia. Debe pertenecer a una subred distinta de la LAN, servidores o cualquier VLAN. Por ejemplo, si tu LAN es 10.10.10.0/24, usa 10.10.99.0/24 para evitar colisiones. Para una red con varios peers, asigna al firewall una máscara que abarque toda la subred, no una ruta de host /32.

Tras guardar, abre de nuevo la instancia: la clave pública ya está generada. Cópiala, la necesitarán tus clientes.

4. Añadir el primer peer (cliente)

Cada cliente o sede remota es un peer. En VPN ‣ WireGuard ‣ Peers crea uno nuevo con:

Campo	Valor de ejemplo	Notas
Enabled	✓
Name	Movil-Carlos	Etiqueta legible
Public Key	(pegada del cliente)	Generada en el móvil/ordenador
Allowed IPs	10.10.99.2/32	IP única dentro del túnel
Endpoint Address	(vacío si es road warrior)	Se rellena al revés desde el cliente
Endpoint Port	51820	Solo si se rellena el anterior
Keepalive	25	Si el peer está detrás de NAT

Genera la clave pública en el cliente con wg genkey | tee privada | wg pubkey > publica y pégala aquí. Regresa a la instancia, añade el peer en su desplegable y guarda.

Repite por cada dispositivo. El plugin incluye un Peer generator que crea las claves por ti.

5. Asignar la interfaz y activar el servicio

Esto es lo que mucha gente se salta y luego no sabe por qué la VPN funciona pero no enruta. En Interfaces ‣ Assignments asigna el nuevo dispositivo wg0 a una interfaz (por ejemplo opt_wg0). Luego entra en la configuración de esa interfaz y marca:

• Enable: ✓
• Lock: ✓ (evita que la GUI toque reglas automáticas)
• IPv4 Configuration Type: None
• IPv6 Configuration Type: None

No pongas una segunda IP aquí: OPNsense asigna automáticamente a la interfaz la dirección definida en la instancia cuando reinicias WireGuard. Por último, ve a VPN ‣ WireGuard ‣ General, activa WireGuard y aplica los cambios. Después confirma en la página de estado que la interfaz tenga la dirección prevista.

6. Reglas de firewall en la interfaz WireGuard

Sin reglas no pasa nada. En Firewall ‣ Rules ‣ WireGuard crea las reglas que quieres permitir al cliente:

#	Acción	Origen	Destino	Puerto destino	Descripción
1	Pass	WireGuard net	LAN net		Acceso a la LAN
2	Pass	WireGuard net	SERVERS net		Acceso a NAS
3	Pass	WireGuard net	DNS	53	Resolver nombres vía OPNsense
4	Pass	WireGuard net	any	80, 443	Salida a internet opcional
5	Block	WireGuard net	IoT net	*	Por defecto no tocar IoT

El orden importa: la primera regla que casea gana. Si activas la regla 4 (salida a internet), el cliente usará la VPN también para navegar; si no, solo accederá a las subredes internas.

En la WAN crea una regla que permita UDP 51820 con destino a WAN address. Como WireGuard termina en el propio OPNsense, no necesitas port forwarding hacia otro equipo. Sin esa regla, el handshake nunca llega.

7. DNS para los clientes

Una VPN sin DNS útil es medio inútil. En Services ‣ Unbound DNS ‣ General asegúrate de que el servicio escucha en la interfaz WireGuard (marca “All” o la interfaz opt_wg0). Eso hace que 10.10.99.1 (la IP del túnel) sea un resolver DNS válido para los peers.

En el cliente, la configuración WireGuard suele tener un campo DNS; rellénalo con la dirección del túnel de OPNsense. La documentación oficial de WireGuard Road Warrior advierte de no rellenar el DNS en la instancia de OPNsense, porque sobrescribe la configuración global de Unbound.

8. Configurar el cliente

Puedes crear el cliente con el generador de peers de OPNsense o construir el archivo .conf a mano con los datos de la instancia. Ejemplo para un móvil:

[Interface]
PrivateKey = <clave_privada_cliente>
Address = 10.10.99.2/32
DNS = 10.10.99.1
[Peer]
PublicKey = <clave_publica_servidor>
Endpoint = tuippublica.dyndns.org:51820
AllowedIPs = 10.10.10.0/24, 10.10.20.0/24
PersistentKeepalive = 25

AllowedIPs decide qué tráfico entra en el túnel. Si pones 0.0.0.0/0 todo el tráfico del móvil pasa por casa (útil para usar el DNS local en redes WiFi ajenas). Si pones solo las subredes, solo esas se enrutan.

Para el DNS del túnel, si quieres bloquear publicidad en la VPN sin instalar nada en cada cliente, Pi-hole frente a AdGuard Home en 2026 compara las dos opciones más cómodas.

9. Caso de uso: site-to-site entre dos casas

Si tienes dos ubicaciones (casa de campo y pueblo, por ejemplo) y quieres que parezcan la misma red, montas un WireGuard site-to-site. La documentación oficial WireGuard Site-to-Site Setup lo explica al detalle; aquí el resumen:

• Cada OPNsense tiene su instance con clave pública y Tunnel Address en la misma subred del túnel (por ejemplo 10.2.2.1/24 y 10.2.2.2/24).
• Cada OPNsense tiene un peer que apunta a la IP pública del otro.
• En Allowed IPs del peer se añaden tanto la IP del túnel contrario como la LAN remota: 10.2.2.2/32, 192.168.0.0/24.
• Se habilita Depend on (CARP) en cada instance si hay HA.
• El firewall permite el tráfico entre las LANs de las dos sedes.

Tip clave de la guía oficial: si una sede tiene IP dinámica, deja el Endpoint vacío en el lado con IP fija y configura el keepalive a 25 segundos en el lado con NAT. Así la sede con IP estática es la que responde, y no se rompe cuando el DHCP del ISP renueva la IP.

10. Monitorizar y depurar

Tres vistas valen oro cuando algo no levanta:

• VPN ‣ WireGuard ‣ Diagnostics muestra los peers conectados con handshake reciente, bytes transferidos y endpoint. Si ves un handshake pero Allowed IPs en 0, el firewall está cortando.
• VPN ‣ WireGuard ‣ Log File enseña el log del plugin WireGuard de OPNsense (módulo del kernel if_wg, no wg-quick). Busca “Handshake did not complete” o “Received invalid handshake initiation” si hay problemas de claves.
• En el cliente, wg show (Linux) o la pestaña “Status” en la app de WireGuard enseña lo mismo.

Si el túnel sube pero no ves la LAN, casi siempre es una de tres: regla en el firewall de OPNsense, ruta en el cliente o DNS mal configurado. El artículo sobre firewall Linux con nftables puede ayudar a entender la lógica de tablas y chains por si quieres montar reglas equivalentes en el cliente.

11. HA con CARP (opcional, pero importante)

Si tienes dos OPNsense en alta disponibilidad, el plugin WireGuard soporta CARP: en la pestaña Instance hay un campo “Depend on (CARP)” para indicar qué interfaz CARP debe estar activa para que la instance se levante. Así, cuando un nodo cae, el otro se queda con la IP flotante y el túnel sigue funcionando.

Conclusiones

WireGuard sobre OPNsense encaja bien en un homelab: el cliente es ligero, la configuración es declarativa y las reglas usan la misma lógica del resto del firewall. La parte delicada no son las claves, sino mantener separadas las direcciones del túnel, las redes permitidas y los permisos de cada peer.

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux