Windows Network Load Balancing don't work!



  • Hello!

    I've configured a new 2.0.1-RELEASE Pfsense. All my rules and the new config, work fine, but I have a problem when I try to connect to a cluster NLB (terminal server, RDP) from my WAN connection to my LAN connection, this is impossible to achieve. While, if I try to do this, from my DMZ to LAN I get it.

    The three interfaces are in diferents IP segments: LAN: 172.16.0.0/16, DMZ: 172.31.50.0/24. WAN: 10.10.10.1/24
    I only do routing between interfaces, I m not  doing NAT.
    The rules pass everything, I created one rule for interface, for accept all the traffic.

    I Know that for multicast messages sometimes in somes routers, is necessary to add a manual ARP entry, with the cluster MAC address.  I've tried to add, but it still does no t work.

    Please, can somebody help me? I don't know that I can do it for resolve this problem.

    thanks.

    Multicast
        Note When the local router must send a packet to the virtual IP address, the local router uses address resolution protocol (ARP) to determine the virtual IP's MAC address. WLBS replies to these ARP requests. When you mask the source MAC address, the ARP response from WLBS has a substitute source MAC address in the Ethernet frame, but contains the correct cluster MAC address in the ARP header. Some routers cannot make this ARP mapping and must make a static ARP entry in the router. For additional information about static ARP requirements, click the following article number to view the article in the Microsoft Knowledge Base: 197862  (http://support.microsoft.com/kb/197862/ ) WLBS cluster is unreachable from outside networks

    The cluster uses a multicast MAC address that is mapped to a unicast IP address. The switch does not associate the multicast MAC addresses to a port, so the switch sends frames to this MAC address on all the ports. IP Multicast pruning implementations cannot limit the port flooding, therefore you must use a virtual LAN. Multicast provides no advantage over unicast from the switches perspective. The increased multicast processing overhead for routers and switches may lead to slower performance. Carefully analyze the effect on your network when you uses multicast to avoid congesting other network devices.





  • My RDP cluster is over Windows 2003 server.

    I think, if that was the issue, I wouldn't access to the IP cluster, from DMZ to LAN, because the operation's ARP, was the same for any interfaces. And from DMZ subnet I can accéss to the Virtual IP of my cluster.

    I 've tried to do a port forward, only for the port 3389, and the cluster works fine, but I must accéss  across the WAN IP.

    I don't know what test I can do it, to find a solution.

    Thanks



  • If I do a command ping from DMZ interface or from LAN interface to my cluster IP, I obtained response from my 4 cluster members:

    FROM LAN:

    PING 172.16.50.100 (172.16.50.100) from 172.16.50.224: 56 data bytes
    64 bytes from 172.16.50.100: icmp_seq=0 ttl=128 time=0.330 ms
    64 bytes from 172.16.50.100: icmp_seq=0 ttl=128 time=0.350 ms (DUP!)
    64 bytes from 172.16.50.100: icmp_seq=0 ttl=128 time=0.361 ms (DUP!)
    64 bytes from 172.16.50.100: icmp_seq=0 ttl=128 time=0.440 ms (DUP!)
    64 bytes from 172.16.50.100: icmp_seq=1 ttl=128 time=0.228 ms
    64 bytes from 172.16.50.100: icmp_seq=1 ttl=128 time=0.245 ms (DUP!)
    64 bytes from 172.16.50.100: icmp_seq=1 ttl=128 time=0.256 ms (DUP!)
    64 bytes from 172.16.50.100: icmp_seq=1 ttl=128 time=0.826 ms (DUP!)
    64 bytes from 172.16.50.100: icmp_seq=2 ttl=128 time=0.322 ms

    –- 172.16.50.100 ping statistics ---
    3 packets transmitted, 3 packets received, +6 duplicates, 0.0% packet loss
    round-trip min/avg/max/stddev = 0.228/0.373/0.826/0.172 ms

    FROM DMZ:

    PING 172.16.50.100 (172.16.50.100) from 172.31.50.224: 56 data bytes
    64 bytes from 172.16.50.100: icmp_seq=0 ttl=128 time=0.455 ms
    64 bytes from 172.16.50.100: icmp_seq=0 ttl=128 time=0.474 ms (DUP!)
    64 bytes from 172.16.50.100: icmp_seq=0 ttl=128 time=0.484 ms (DUP!)
    64 bytes from 172.16.50.100: icmp_seq=0 ttl=128 time=3.190 ms (DUP!)
    64 bytes from 172.16.50.100: icmp_seq=1 ttl=128 time=0.230 ms
    64 bytes from 172.16.50.100: icmp_seq=1 ttl=128 time=0.247 ms (DUP!)
    64 bytes from 172.16.50.100: icmp_seq=1 ttl=128 time=0.280 ms (DUP!)
    64 bytes from 172.16.50.100: icmp_seq=1 ttl=128 time=0.535 ms (DUP!)
    64 bytes from 172.16.50.100: icmp_seq=2 ttl=128 time=0.867 ms

    --- 172.16.50.100 ping statistics ---
    3 packets transmitted, 3 packets received, +6 duplicates, 0.0% packet loss
    round-trip min/avg/max/stddev = 0.230/0.751/3.190/0.881 ms

    But from my WAN interface I don't get response:

    PING 172.16.50.100 (172.16.50.100) from 10.10.10.1: 56 data bytes

    --- 172.16.50.100 ping statistics ---
    3 packets transmitted, 0 packets received, 100.0% packet loss