Cómo gestionar firewalls y WireGuard en un homelab con rack de 10" y servidor Hetzner

Problema

Los entornos homelab que se extienden a la nube suelen combinar hardware propio (rack, switches, firewalls) con servidores dedicados (por ejemplo, en Hetzner). Cuando la cantidad de servicios crece —SSO, almacenamiento, monitorización, contenedores— la tabla de firewall puede inflar rápidamente, llegando a cientos de reglas. Mantener esa lista coherente, evitar colisiones y garantizar que todo el tráfico pase exclusivamente por un túnel WireGuard se vuelve complejo. El síntoma típico es:

• Regla que “se escapa” y permite tráfico no deseado.
• Dificultad para rastrear qué regla protege cada servicio.
• Incremento de latencia o fallos intermitentes al conectar el sitio local con la nube.

El reto es diseñar una arquitectura de firewall y VPN que escale sin que el número de reglas se convierta en una carga operativa.

Causa

1. Segmentación insuficiente
   Agrupar varios servicios en la misma subred obliga a crear reglas específicas por puerto/protocolo para cada aplicación. Cada nuevo contenedor o VM añade al menos una regla.

2. Falta de abstracción
   Sin alias o grupos de direcciones, cada regla usa IPs individuales. Cuando una IP cambia (por ejemplo, al recrear una VM), hay que actualizar manualmente todas las reglas afectadas.

3. Política “todo permitido” en la zona de enlace
   En muchos diseños el túnel site‑to‑site se abre con una regla de “allow any → any”. Eso elimina la visibilidad y permite que tráfico inesperado cruce la VPN sin inspección.

4. Reglas redundantes
   Copiar y pegar reglas para cada nuevo servicio genera solapamientos que, con el tiempo, hacen que la tabla sea difícil de leer y depurar.

5. Herramientas de gestión limitadas
   OPNsense y otras firewalls ofrecen APIs, pero si se usan solo la UI, la documentación de reglas tiende a quedar en notas sueltas o en hojas de cálculo externas.

Solución

Una arquitectura basada en segmentación por VLAN, alias de red y política de “deny‑by‑default” permite reducir drásticamente el número de reglas y mantenerlas legibles.

1. Diseña una topología de red con VLANs lógicas

Cada VLAN se asigna a una interfaz física o virtual en OPNsense. Con esta separación, la mayoría de las reglas pueden escribirse a nivel de VLAN → VLAN en lugar de IP → IP.

2. Usa alias (grupos) para servidores y puertos

En OPNsense crea alias como:

• SERVERS_INTERNAL → 10.0.20.0/24
• SERVICES_WEB → 80,443
• SERVICES_SSH → 22

Con estos alias, una regla típica “allow web from management to internal servers” se reduce a:

Source: SERVERS_MANAGEMENT
Destination: SERVERS_INTERNAL
Port: SERVICES_WEB
Action: Pass

Cuando añades o eliminas un host, solo actualizas el alias, no la tabla completa.

3. Implementa una política “deny‑by‑default” en cada zona

1. Bloquea todo entre VLANs por defecto.
2. Permite explícitamente solo los flujos necesarios (p.ej., Management → Internal para Ansible, Guest → Internet para DNS).
3. Crea una regla “allow WireGuard” que solo permite tráfico UDP 51820 entre los firewalls locales y el de Hetzner.

4. Centraliza el túnel WireGuard

Configura un único túnel site‑to‑site en cada firewall. Usa la opción AllowedIPs para limitar el tráfico que atraviesa la VPN a los rangos de red internos, por ejemplo:

AllowedIPs = 10.0.0.0/8, 172.16.0.0/12

De esta forma, cualquier paquete que no coincida con esas subredes se descarta antes de entrar al túnel.

5. Automatiza la generación de alias y reglas

Aprovecha la API de OPNsense (REST) para crear/actualizar alias y reglas desde un playbook de Ansible. Un pequeño módulo de Ansible que reciba una lista de hosts y genere los alias elimina la mayor parte del trabajo manual.

6. Documenta con etiquetas y comentarios

OPNsense permite añadir una descripción a cada regla. Usa un formato estándar:

[service] [direction] [src] → [dst] : [nota]

Ejemplo: web inbound WAN → INTERNAL : Traefik + Authentik.

Cuándo aplicar esta solución

• Entornos con > 200 reglas – la complejidad ya supera la gestión manual.
• Presencia de múltiples subredes – cuando tienes al menos dos VLAN o más.
• Uso de VPN site‑to‑site – cualquier túnel que conecta un homelab con la nube.
• Necesidad de SSO o control de acceso granular – cuando varios servicios comparten dominios de autenticación.

No es necesario si:

• Tu red consta de un único segmento /24 y menos de 20 servicios.
• No utilizas VPN y todo el tráfico es local.

Código

# Generar configuración básica de WireGuard para el firewall local
cat > /etc/wireguard/wg0.conf <<EOF
[Interface]
PrivateKey = $(wg genkey)
Address = 10.255.255.1/30
ListenPort = 51820

[Peer]
PublicKey = <PUBLIC_KEY_HETZNER>
Endpoint = <IP_HETZNER>:51820
AllowedIPs = 10.0.0.0/8, 172.16.0.0/12
PersistentKeepalive = 25
EOF

# Activar el túnel
wg-quick up wg0

Verificación

1. Comprobar que sólo pasan los rangos esperados

   wg show wg0 allowed-ips
   

   Verifica que la lista coincida con tus subredes internas.

2. Revisar contadores de reglas en OPNsense
   En Firewall → Rules filtra por alias y comprueba que el tráfico tiene “hits”. Las reglas sin hits pueden eliminarse.

3. Test de aislamiento VLAN
   Desde una máquina en la VLAN Guest, intenta ping 10.0.20.10. Debería fallar a menos que exista una regla explícita.

4. Validar conectividad site‑to‑site
   En el host Hetzner, ejecuta traceroute 10.0.10.1. El primer salto debe ser la IP del túnel WireGuard.

Notas adicionales

• Alias dinámicos: si usas Docker o Kubernetes, exporta la lista de contenedores a un archivo JSON y actualiza los alias con un script cron.
• Reglas de registro: habilita logging solo en reglas de “deny”. El exceso de logs en reglas “pass” genera ruido y consume recursos.
• Backup de configuración: exporta la configuración de OPNsense (config.xml) después de cada cambio mayor y almacénala en un repositorio Git.
• Escalado futuro: cuando superes los 500 alias, considera agruparlos por función (por ejemplo, WEB_SERVERS, DB_SERVERS) y usar nested groups si la firewall lo permite.
• Seguridad del túnel: rota la clave privada de WireGuard cada 90‑180 días y actualiza el peer en ambos extremos mediante Ansible.

Con esta metodología, los cientos de reglas dejan de ser una masa indomable y se convierten en un conjunto manejable de políticas basadas en grupos y zonas. El resultado es una red más segura, más fácil de auditar y preparada para crecer sin que el número de reglas sea el factor limitante.