Una caída drástica de la velocidad de 600‑700 Mbps a menos de 100 Mbps y cortes recurrentes tras instalar pfSense 2.7.2‑RELEASE suele indicar un problema de configuración y no un fallo físico del cortafuegos. A continuación encontrarás una guía completa —desde el diagnóstico hasta la optimización avanzada— para que tu red vuelva a rendir al máximo.

Resumen del problema

El escenario típico es el siguiente: reemplazas tu antiguo router por un nuevo firewall con pfSense, mantienes el mismo módem y proveedor de Internet, pero la experiencia empeora radicalmente. Además de la bajada de rendimiento, observas que la puerta de enlace predeterminada cambia sola y las rutas estáticas desaparecen. Esto se traduce en micro‑cortes, vídeos que hacen buffering y descargas que se congelan.

Diagnóstico inicial

• Prueba de bypass: conecta un PC directamente al módem del ISP para confirmar que la línea sigue entregando los 600‑700 Mbps contratados.
• Speedtest y iperf3: realiza tres mediciones consecutivas en cada escenario (bypass y detrás de pfSense) para comparar métricas de bajada y subida.
• Logs del sistema: en Status > System Logs > System > General revisa avisos de watchdog timeout, flapping de enlaces o servicios que se reinician.
• Monitor de puerta de enlace (dpinger): si el ISP responde con ICMP rate‑limit o pierde paquetes, pfSense puede marcar la gateway como inactiva y cambiarla automáticamente.
• Consumo de CPU: en Status > System Activity verifica si procesos como snort, suricata o pfblockerng saturan un núcleo.

Solución paso a paso

Revisar limitadores y reglas de tráfico

pfSense contiene un potente motor de Traffic Shaping; sin embargo, basta una regla mal configurada para estrangular la WAN. Deshabilita:

Firewall > Traffic Shaper > Limiter
– Limiter In
– Limiter Out

Si necesitas QoS, define de nuevo los limiters partiendo de valores iguales o ligeramente superiores a tu caudal real, y verifica que ninguna regla de Floating aplica un match global.

Verificar interfaces WAN/LAN

Parámetro	Valor recomendado	Dónde cambiarlo
Speed/Duplex	1 Gbps Full	Interfaces > [WAN/LAN] > Advanced
MTU	1500 (por defecto)	Interfaces > [WAN]
Checksum Offload	Deshabilitado si tu NIC es Realtek	System > Advanced > Networking

Guarda cada cambio y reinicia la interfaz para confirmar que negocia correctamente. Si usas VLAN o PPPoE, reduce el MTU a 1492 o 1480 y repite la prueba de velocidad.

Comprobar DHCP y conflictos de puerta de enlace

Cuando un dispositivo obtiene una default gateway errónea su tráfico sale por el camino equivocado. Asegúrate de que:

• El rango DHCP no incluye la IP del propio pfSense ni de otros routers antiguos.
• No hay otro servidor DHCP activo en la red (p.ej. ONT del operador o un punto de acceso en modo router).
• Las reservas de IP se aplican a los clientes críticos (NAS, cámaras, VoIP) para evitar cambios de puerta de enlace.

Si tu ISP te asigna varias puertas de enlace vía PPPoE, desmarca la casilla Block private networks sólo en la WAN para permitir rutas internas, pero mantén filtrado bogon.

Ajustar el MTU

El tamaño máximo de transmisión influye directamente en la fragmentación de paquetes:

# Descubre el MTU ideal desde pfSense
$ ping -s 1472 -c 4 google.com

Empieza en 1472 (1500 bytes menos 28 de cabecera IP/ICMP) y desciende de 10 en 10 hasta que no haya fragmentación (“Frag needed”). Añade 28 al valor resultante y aplícalo como nuevo MTU en la interfaz WAN.

Revisar los registros

Busca patrones repetitivos cada vez que la velocidad cae o el enlace se reinicia:

Jun 30 12:14:07 kernel: re0: watchdog timeout
Jun 30 12:14:12 dpinger: WAN_DHCP  Packet loss: 100%

Más de tres watchdog timeout por minuto indican driver inestable. Considera cambiar de puerto, de NIC o aplicar un parche del kernel disponible en el repositorio de System Patches.

Actualizar pfSense

En System > Update > Branch selecciona 2.7‑Stable y mira si existe un patch‑set posterior a tu compilación. Las notas de versión suelen detallar mejoras en drivers Intel igb/ixgbe, Realtek re o Broadcom bge que afectan directamente la performance.

Reiniciar equipos de red

Parece trivial, pero muchos problemas de autonegociación o tablas ARP corruptas se resuelven con un corte de energía ordenado: apaga primero el módem, luego el switch, después pfSense; espera 30 s y enciende en sentido inverso.

Consultar la comunidad o soporte

pfSense cuenta con un foro activo y grupos de Telegram donde ingenieros de red responden rápido. Publica:

1. Modelo exacto de hardware (CPU, NIC, RAM, almacenamiento).
2. Capturas de Dashboard > Interfaces mostrando velocidad negociada.
3. Logs del último reinicio y salida de ifconfig -a.
4. Resultados de iperf3 en ambas direcciones.

Con estos datos podrán replicar tu escenario y proponer parches o ajustes finos.

Optimización avanzada para alto rendimiento

Habilitar multiqueue (RSS/IRQ Balance)

En sistemas con CPU multinúcleo, repartir las interrupciones de red mejora el throughput. Verifica si tu NIC admite Receive‑Side Scaling (RSS):

# en pfSense Shell
sysctl net.inet.rss.enabled=1

Luego, añade la entrada a System > Tunables para hacerla permanente. Comprueba en Diagnostics > Interrupts que las interrupciones migran entre núcleos.

Desactivar servicios intensivos temporalmente

Prueba la velocidad sin módulos que inspeccionan paquetes en capa 7:

• pfBlocker‑NG: filtra DNS y listas IP, pero crea miles de alias.
• Snort/Suricata: el modo IPS reinyecta tráfico y puede limitar a 100 Mbps en hardware sin AES‑NI.
• ntopng, Darkstat: herramientas de sondeo continuo.

Si la velocidad vuelve a 600‑700 Mbps, reintroduce cada servicio de forma individual hasta encontrar el culpable.

Afinar dpinger

El monitor de puerta de enlace marca una red como inactiva si supera cierto umbral de pérdida. En conexiones con jitter (DOCSIS, LTE) basta un falso positivo para que pfSense cambie la ruta:

Opción	Valor por defecto	Valor recomendado
High Latency Threshold	500 ms	750 ms
Packet Loss Threshold	20 %	50 %
Probe Interval	1 s	0.5 s

Aumentar los umbrales evita que la puerta de enlace se declare muerta por un pico de latencia puntual.

Pruebas de rendimiento y validación

1. Apaga todos los clientes, deja solo un portátil conectado por cable Cat 6 a la LAN.
2. Ejecuta iperf3 -s en un servidor de pruebas fuera de tu red (o usa un VPS).
3. Desde el portátil lanza iperf3 -c <IP‑VPS> -P 4 -R y anota velocidad media y desviación.
4. Repite con iperf3 -R para tráfico inverso.
5. Si obtienes al menos el 90 % de los 700 Mbps prometidos en ambos sentidos, considera resuelto el cuello de botella.

Buenas prácticas de mantenimiento

• Programa copias de seguridad automáticas del archivo config.xml en Diagnostics > Backup & Restore.
• Crea un cron para reiniciar pfSense cada domingo a las 04:00 si tu hardware es propenso a pérdidas de memoria.
• Actualiza paquetes desde System > Package Manager sólo cuando existan notas de versión que referencien tu problema.
• Documenta cada cambio en un registro interno: fecha, parámetro modificado y resultado. Así podrás revertir rápidamente.

Conclusión

La mayoría de los problemas de velocidad y desconexión tras migrar a pfSense 2.7.2 derivan de configuraciones heredadas o módulos mal optimizados. Siguiendo esta guía —desde la verificación de limitadores hasta la activación de RSS— podrás recuperar tu ancho de banda original y, en muchos casos, obtener un rendimiento superior al del router comercial anterior. Dedica tiempo a medir antes y después de cada ajuste; los números serán tu mejor aliado para demostrar que la solución funciona a largo plazo.