Problema

En entornos de homelab o pequeñas oficinas es frecuente usar una única subred amplia (por ejemplo 10.0.0.0/8) para simplificar la asignación de direcciones IP. Después de actualizar o reconfigurar un switch gestionado, varios hosts dejan de comunicarse con el firewall pfSense/Netgate: los intentos de SSH, HTTP o cualquier otro puerto interno terminan en connection timed out. La regla predeterminada “Allow LAN to any” parece estar activa, y los cables están conectados correctamente, pero el tráfico interno simplemente no pasa.

Este patrón se repite cuando:

  • Se añaden o modifican VLANs en el switch sin reflejarlas en pfSense.
  • Se cambian los puertos trunk o los tags de VLAN en los hipervisores (Proxmox, ESXi, etc.).
  • Se actualiza el firmware del switch y se restablecen valores de “port isolation” o “storm control”.

El síntoma típico es la imposibilidad de alcanzar direcciones dentro del rango 10.0.0.0/8 desde cualquier máquina de la LAN, mientras que el acceso a Internet sigue funcionando (porque la regla de salida a WAN está intacta).

Causa

1. Desalineación de VLAN entre switch y pfSense

Los firewalls pfSense tratan cada interfaz como una red distinta. Si el switch envía tráfico etiquetado (802.1Q) pero la interfaz de pfSense está configurada como untagged, los paquetes llegan con un tag que el firewall descarta. Lo mismo ocurre al revés: pfSense envía tráfico sin tag y el switch lo espera etiquetado.

2. Subredes superpuestas o máscara incorrecta

Una regla “LAN → any” solo funciona si la subred de la interfaz coincide con la de los hosts. Si la interfaz de pfSense está configurada como 10.0.0.1/24 y los clientes usan 10.1.x.x, el firewall no reconoce esos hosts como parte de la LAN y los trata como tráfico externo, aplicando la política de NAT o bloqueando según la regla predeterminada.

3. Puertos del switch en modo “access” vs “trunk”

Un puerto configurado como access solo acepta tráfico sin tag. Si el hipervisor asigna una VLAN a la VM y el puerto del switch está en access, el tag se pierde y la VM queda en la VLAN equivocada. El firewall, al recibir paquetes en la VLAN esperada, nunca los ve.

4. Configuración de “block private networks” o “bogon networks”

pfSense incluye reglas opcionales que bloquean rangos RFC1918 cuando se usan como WAN. Si, por error, la interfaz WAN está apuntando a una subred 10.x.x.x, esas reglas pueden bloquear el tráfico interno cuando se enruta de forma inesperada.

5. Cambios en la tabla de rutas estáticas

Al actualizar el switch, a veces se pierde la ruta estática que dirige el tráfico 10.0.0.0/8 hacia la interfaz LAN del firewall. Sin esa ruta, los paquetes se envían a la puerta de enlace predeterminada (WAN) y se pierden.

Solución

Paso 1 – Verificar la topología de VLAN

  1. Identifica qué puertos del switch están conectados al firewall y a los hipervisores.
  2. Confirma que los puertos del firewall estén configurados como trunk y que las VLAN necesarias (por ejemplo VLAN 10) estén permitidas.
  3. En el hipervisor, revisa que la interfaz de la VM tenga el mismo VLAN tag que el puerto del switch. En Proxmox, esto se hace en la pestaña Network → VLAN Tag de la VM.

Si encuentras desalineación, corrígela:

  • En el switch, cambia el puerto del firewall a trunk y habilita la VLAN.
  • En pfSense, crea o edita la interfaz VLAN (Interfaces → Assignments → VLANs) con el mismo ID y asigna la interfaz física correspondiente.

Paso 2 – Ajustar la máscara de red en pfSense

  1. Accede a Interfaces → LAN.
  2. Cambia la IPv4 Address a 10.0.0.1/8 (o a la máscara que realmente uses).
  3. Guarda y aplica los cambios.

Con una máscara /8, pfSense reconocerá cualquier dirección 10.x.x.x como parte de la LAN y la regla “Allow LAN to any” cubrirá todo el rango.

Paso 3 – Revisar reglas de firewall y opciones de bloqueo

  1. En Firewall → Rules → LAN, verifica que la regla “Default allow LAN to any” esté habilitada y que no haya reglas anteriores que la anulen.
  2. Desactiva temporalmente System → Advanced → Firewall & NAT → Block private networks si está habilitado en la interfaz WAN.

Paso 4 – Comprobar rutas estáticas

Ejecuta en la consola de pfSense:

netstat -rn

Busca una entrada 10.0.0.0/8 que apunte a la interfaz LAN (por ejemplo em0). Si falta, añádela:

pfctl -t static_routes -T add 10.0.0.0/8

O, de forma más permanente, crea una ruta estática en System → Routing → Static Routes.

Paso 5 – Reiniciar la tabla de filtros

Después de cualquier cambio de VLAN o máscara, recarga el motor de filtrado:

pfctl -d && pfctl -e

Esto fuerza a pfSense a volver a cargar todas las reglas y a reconocer los nuevos rangos.

Cuándo aplicar esta solución

Aplica cuando:

  • Los hosts dentro de la subred 10.0.0.0/8 no pueden alcanzar servicios en el firewall (SSH, API, etc.).
  • La conectividad a Internet sigue operativa, indicando que la WAN no está afectada.
  • Se ha actualizado o reconfigurado el switch, o se han añadido VLANs en el hipervisor.

No aplica si:

  • El problema se limita a una única máquina y los demás equipos funcionan (posible firewall host‑based).
  • El firewall muestra tráfico en los logs de pf con la etiqueta PASS pero el cliente sigue sin respuesta (posible problema de aplicación o servicio).

Código

# Ver tabla de rutas
netstat -rn

# Añadir ruta estática 10.0.0.0/8 a la interfaz LAN (ejemplo em0)
route add -net 10.0.0.0/8 -interface em0

# Recargar reglas de pfSense
pfctl -d && pfctl -e

Verificación

  1. Desde una VM en la LAN, ejecuta ping 10.0.0.1. Debería recibir respuestas sin pérdida.
  2. Prueba ssh -vvv [email protected] y verifica que la negociación de clave avanza.
  3. En la interfaz web de pfSense, abre Status → System Logs → Firewall y busca entradas PASS para los IP de origen 10.x.x.x y destino 10.x.x.x.
  4. Revisa el panel de Interfaces en pfSense; la barra de estado debe mostrar “up” y la dirección IP con máscara /8.

Si todos los pasos anteriores son exitosos, la conectividad interna está restablecida.

Notas adicionales

  • Evita superponer subredes: mezclar 10.0.0.0/8 con 10.0.0.0/24 en distintas VLAN puede generar rutas ambiguas. Usa subredes más pequeñas (por ejemplo 10.1.0.0/16) cuando necesites segmentar.
  • Documenta los tags: mantén un registro de qué VLAN ID corresponde a cada segmento (por ejemplo VLAN 10 = “Internal LAN”). Así, cuando actualices el switch, sabes exactamente qué cambiar.
  • Proxmox tip: en la configuración de la VM, elige “VLAN aware” en el bridge si vas a pasar múltiples VLANs a través del mismo bridge. De lo contrario, el tráfico quedará sin etiquetar.
  • Backup de configuración: antes de aplicar cambios mayores en el switch o en pfSense, exporta la configuración (Diagnostics → Backup & Restore). Un rollback rápido ahorra tiempo.
  • Monitoriza los logs: pfSense registra paquetes descartados por “no‑match” en System → Logs → Firewall. Un aumento repentino de estos eventos suele indicar un problema de VLAN o máscara.