pfSense con balanceo en redes con Samba

pfSense es una de esas joyas del Open Source ideal para mantener un router y firewall aunque tiene muchas más utilidades en base a “paquetes” autoinstalables (proxy, monitorización, seguridad, etc).  La curva de aprendizaje es propia del nivel de la herramienta, pero una vez puesta en marcha bien merece la pena para redes medianas y grandes y alternativa a costosos routers o software. Puede incluso ejecutarse y configurarse desde un pen drive y corre bien en maquinas virtuales.

Aunque hacía tiempo que lo usábamos, hace unas semanas actualizamos a la última versión estable del momento (1.2.3) con idea de poner en marcha un sistema eficaz de balanceo y fail over entre 2 ADSLs. Nuestros anteriores intentos en base a IPTABLES y marca de paquetes en Linux habían tenido resultados desiguales y era de estas “asignaturas pendientes” en las que nos habíamos dado por vencido.

Seguimos con algunos matices este tutorial de la propia documentación y el resultado fue el esperado y de forma más rápida de lo previsto. El problema nos surgió cuando empezamos a tener problemas con la red Windows de la oficina y la conexión a uno de los servidores Samba. Las maquinas empezaban a quejarse de “Nombre de usuario duplicado” en la red a pesar de que el trafico por TCP/IP funcionaban sin problemas, así que tras volvernos locos con otras opciones, determinamos que el problema tenía que estar en los cambios en el router.

Para crear la configuración de balanceo se crean dos reglas que fuerzan que el trafico de cada una de las interfaces de red de salida circulen obligatoriamente por ella. Parece que al hacer pfsense broadcasting en la LAN, los paquetes UDP que usa Netbios en los puertos 137, 138, 139 son replicados y la red de Windows (en realidad protocolos CIFS/Samba) estima que el mismo nombre de red esta presente en x ocasiones y deja de funcionar. Una explicación más clara que nos dio la pista correcta aquí y aquí.

La solución, crear una regla en el firewall de la LAN para que bloquee todo el tráfico a esos puertos, es decir cualquier cosa desde la LAN con cualquier destino en ese rango de puertos: 137 al 139. El bloqueo del puerto 67 también salía en alguna referencia al mismo tema, aunque entiendo que no es necesario. Aquí un pantallazo.

Confiemos que alguien le ahorre algunas de las horas que nos costo a nosotros dar con ello.