Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Windows Network Load Balancing don't work!

    Scheduled Pinned Locked Moved
    Firewalling
    2
    4
    3.1k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • P
      pedro.dominguez
      last edited by

      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.

      1 Reply Last reply Reply Quote 0
      • GruensFroeschliG
        GruensFroeschli
        last edited by

        This might be relevant:
        http://blog.serverfault.com/2011/05/11/windows-2008-and-broken-arp/

        We do what we must, because we can.

        Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

        1 Reply Last reply Reply Quote 0
        • P
          pedro.dominguez
          last edited by

          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

          1 Reply Last reply Reply Quote 0
          • P
            pedro.dominguez
            last edited by

            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

            1 Reply Last reply Reply Quote 0
            • First post
              Last post
            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.