No funciona NLB de windows desde la WAN



  • Hola!

    Resulta que he cambiado el firewall de pfsense que tenía, tanto el hardware como la versión, he actualizado a la 2.0.1-RELEASE. También he aprovechado para segmentar correctamente las interfaces y configurar ya de paso una alta disponibilidad entre dos equipos. Todo ha ido correctamente, menos la conexión a una IP virtual de un cluster de windows que tengo, a la cual ahora no puedo acceder desde la interface externa del pfsense.

    Tengo 3 segmentos de red diferenciados: LAN: 172.16.0.0/16, DMZ: 172.31.50.0/24. WAN: 10.10.10.1/24. En reglas no tengo nada que pueda bloquearme el tráfico y no estoy haciendo ningún NAT.

    Es muy extraño, al principio pensaba que podría ser por los mensajes ARP  y el problema reconocido en dispositivos de capa 3, asigné la MAC estáticamente en la tabla ARP, pero como el acceso al cluster desde la DMZ me estaba funcionando, entiendo que no es problema de estos paquetes de multidifusión.

    Si alguien sabe que puede ser o que puedo hacer para encontrar el problema se lo agradecería.

    Saludos



  • Supongo -> NLB, http://en.wikipedia.org/wiki/Network_Load_Balancing_Services (para que entendamos mejor).

    Revisa que en la interfase WAN que se permita tráfico desde redes privadas, desactivando la casilla Block private networks

    Verifica las reglas para el tráfico entrante en WAN yendo hacia DMZ.

    Verifica gateways de DMZ y de tus equipos en DMZ (físicos y virtuales).

    Verifica posible cortafuegos en máquinas y servicios en DMZ.



  • Todo está correctamente.

    El problema es cuando intento acceder desde la WAN. La IP del cluster NLB, está configurada dentro de la LAN y con la misma regla configurada en la DMZ y en la WAN, desde la DMZ puedo acceder a él, pero desde la WAN no.

    De hecho, pruebo hacer un PING desde las interfaces conectadas directamente al pfsense y desde la DMZ puedo acceder, pero desde la WAN no.

    Como es obvio, tengo muchos otros servicios corriendo en la LAN y la DMZ respectivamente y tan sólo tengo el problema con la IP del CLUSTER, si por ejemplo accedo directamente a una de las IPs de algún miembro del cluster, funciona correctamente, por lo que me lleva a pensar que sea alguna respuesta restrictiva del pfsense.

    En el log puedo ver que la regla que me permite el acceso al cluster se registra cuando intento acceder, es decir que el pfsense deja pasar la solicitud de entrada, pero a partir de ahí ya no veo nada más,



  • Si ves la solicitud de entrada y no es denegada, entonces es un problema de enrutado asimétrico.

    Es decir, te funciona la ida pero no la vuelta. ¿Puerta para la IP del cluster?



  • Si fuera eso no funcionaría desde la DMZ.

    IP cluster: 172.16.50.100/16
    DG: 172.16.50.254 (IP virtual entre dos pfsense, configurados con CARP en alta disponibilidad, el pfsense que hace de master, hace de master en todas las interfaces)

    El pfsense, todo lo que no esté conectado a él directamente, lo envía a una IP virtual con HSRP de cisco, entre dos routers de mi proveedor de servicios.



  • Si fuera eso no funcionaría desde la DMZ.

    No estoy seguro. pfSense sabe las rutas entre sus subredes.

    IP cluster: 172.16.50.100/16
    DG: 172.16.50.254 (IP virtual entre dos pfsense, configurados con CARP en alta disponibilidad, el pfsense que hace de master, hace de master en todas las interfaces)

    El pfsense, todo lo que no esté conectado a él directamente, lo envía a una IP virtual con HSRP de cisco, entre dos routers de mi proveedor de servicios.

    Primera noticia de que estás con CARP y dos pfSense.

    Un esquema de lo que tienes ayudaría a entender qué puede estar pasando.

    https://doc.pfsense.org/index.php/Configuring_pfSense_Hardware_Redundancy_(CARP)



  • En el primer post, comenté que había aprovechado para montar una alta disponibilidad, pero no lo había descrito explicitamente, porqué pienso que no es eso lo que me esta dando problemas y no quiero complicar mucho el hilo, porqué sino quizás no encontraré la solución.

    Aún así te explico todo el diseño que tengo montado y funcionando correctamente, excepto el acceso a la IP del cluster virtual de windows.

    Adjunto una imagen para intentar definir el esquema.

    Antes de nada explicaré que tengo montado un appliance para PFSENSE, concretamente este:
    http://www.applianceshop.eu/index.php/firewalls/opnsense/opnsense-dual-ghz-hd-rack-edition-19-pfsense-appliance.html#specifications.
    La  idea que teníamos era montar una alta disponibilidad de firewall y de los servicios adicionales que me permite pfsense. La cual tengo montada y funciona de maravilla.

    Este appliance tiene 3 Interfaces y tal y como se recomienda para montar CARP (HA, alta disponibilidad) es recomendable tener una interface dedicada para la sincronización de los N equipos miembros del grupo de firewalls; por lo que he tenido que crear 2 VLANS, una para la DMZ y otra para el SYNC, las cuales conmutan a través de una única interface del appliance. Esta interface esta conectada a un switch a través de dos puertos de trunk, por lo que la conmutación de las dos VLAN y la aplicación de sus reglas, funcionan correctamente.

    Por otro lado los segmentos de red quedan de la siquiente manera, que ahora explicaré:

    ^ Interface                    ^ Rango IP          ^ IP Master            ^ IP Slave            ^ IP Virtual    ^
    | LAN                            | 172.16.0.0/16    | 172.16.50.224    | 172.16.50.226  | 172.16.50.254  |
    | WAN                            | 10.10.10.0/24    | 10.10.10.1          | 10.10.10.2          | 10.10.10.3        | Router P 10.10.10.224  | Router B 10.10.10.226  | Router virtual 10.10.10.225 |
    | DMZ VLAN 110        | 172.31.50.0/24  | 172.31.50.224    | 172.31.50.226  | 172.31.50.225  |
    | PFSYNC VLAN 120  | 10.10.12.0/24    | 10.10.12.1          | 10.10.12.2          |                            |

    Al montar CARP, es necesario crear IPs virtuales, para que independientemente del firewall que esté activo, los equipos que estén por debajo puedan seguir trabajando sin que se enteren, para ello hay creadas 3 IPs virtuales:

    - 1 el DG de la LAN.
      - 1 el DG de la DMZ
      - 1 es una IP virtual para que el router de mi ISP me envíe el tráfico que no esta conectado directamente a su router. Ya que recuerdo que mi pfsense esta trabajando como firewall sin NAT, con lo que esta enrutando tráfico entre redes diferentes.

    La otra IP virtual que queda, es la de mi proveedor que me suministra 2 routers cisco con alta disponibilidad, para que funcione al igual que en mi firewall, el DG de mi interface WAN debe ser esta IP virtual: 10.10.10.225.

    Por lo que todo lo que si quiero llegar algún sitio que esté conectado directamente a mi pfsense sabre hacerlo y si quiero llegar algún sitio que no esta conectado directamente, mi pfsense lo enrutará hacía la 10.10.10.225, donde mi proveedor ya se encarga de enrutar correctamente el tráfico.

    Creo que no olvidarme de ningún punto, si crees que falta algún dato, coméntame y te lo añado.

    Gracias.




  • El montaje parece correcto. De hecho…

    • He leído todo el hilo de nuevo y veo que dijiste que no te funciona el acceso de WAN a LAN para la IP virtual del Windows NLB desde que cambiaste la versión de pfSense.

    • He buscado información y he visto que hace unos días posteaste el problema en el foro en inglés, http://forum.pfsense.org/index.php?topic=69848.0

    Google windows nlb site:forum.pfsense.org

    Se me ocurren varias cosas:

    • Probar una regla en WAN que autorice cualquier protocolo con destino las IPs del NLB.

    • Probar activando en la anterior regla la opción Advanced Options - This allows packets with IP options to pass. Otherwise they are blocked by default. This is usually only seen with multicast traffic. Digo esto porque he leído por encima que interviene multicast.

    • Plantearse emplear el Load Balancer de pfSense para el acceso desde WAN.

    Siento no poder decirte más porque el tema es muy específico y en estos casos hay que leer y probar cosas con la instalación que se tiene entre manos.

    ¡Suerte!



  • De hecho todo lo que planteas ya lo probé y sigue sin funcionar.

    Con la versión anterior funcionaba porqué tenía el firewall actuando en modo transparente y tenía tanto la LAN como la DMZ, en puente con la WAN, por lo que todo el tema de multidifusión al ser capa 2 debía dejarlo pasar.

    La única forma que he visto que me funciona és si habilito un port forward hacia esa IP, pero eso supone que tengo que hacer una conversión al firewall y preferiría evitarlo.

    Gracias