Guest User!

You are not Sophos Staff.

Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 26 subscribers
  • Views 14220 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Windows Server NLB IGMP not working

Florian Stellet1

I recently switched from PFSENSE to Sophos XG and I am now running into some problems with Windows Server NLB.

 

I have a Windows Server cluster providing DNS and Web services. The cluster is configured to use Windows NLB in IGMP mode in order to increase availability and protect against outages.

Everything worked fine with pfsense (it was necessary to add a parameter: net.link.ether.inet.allow_multicast)

 

But now with Sophos XG I am no longer able to reach services configured on the NLB VIP.

 

Clients are able to ping the VIP, but any kind of service request (NSLOOKUP, DIG, HTTP, HTTPS) just times out. However, the XG firewall itself is able to communicate with the VIP successfully for both ping and services.

 

I added a static ARP entry for the VIP but this did not seem to make a difference.

 

I have searched all over but have not found any documentation regarding this problem.

I also checked the Sophos Firewall logs, but have not seen any indication as to what would cause the issue. In fact, i dont see any traffic trying to reach the Windows Server VIP.

 

I would greatly appreciate help and feedback in this matter.



This thread was automatically locked due to age.
  • 0

    Florian,

    first of all you should enable multicast forwarding from Console: option 3 > 2 > 1

    and then from multicast menu you can add multicast rules using mroute command as explained here:

    https://community.sophos.com/kb/en-us/123135

    or use the GUI

    Routing Menu > static routing > Multicast route.

    Regards

  • 0 in reply to lferrara

    Luk,

     

    thank you so much for the fast reply. I had multicast routing enabled. I turned it back off in order to follow your instructions exactly however without success.

     

    I entered the multicast route based on information provided by Microsoft 

    https://support.microsoft.com/en-us/help/283028/igmp-support-for-network-load-balancing

    (The address range of the multicast group that is used is 239.255.x.y, where
    x.y corresponds to the last two octets of the Network Load Balancing virtual IP address. For example, if the virtual IP address is 10.1.2.3, the multicast address that cluster nodes are a part of would be 239.255.2.3.)

     

     

    in the following format:

     

     

     

    However, testing still has been unsuccessful.

  • 0 in reply to Florian Stellet1

    Florian,

    use tcpdump igmp to understand what is wrong.

    Let us know

  • 0 in reply to lferrara

    Attached please find my TCP dump:

    tcpdump: Starting Packet Dump
    16:05:06.589409 Port1, IN: M 00:18:0a:b5:c5:2b (oui Unknown) ethertype Unknown (0xe064), length 66:
    0x0000: 0000 0800 46c0 0024 15f2 0000 0102 2e21 ....F..$.......!
    0x0010: 0000 0000 e000 0001 9404 0000 1164 6c1e .............dl.
    0x0020: 0000 0000 827d 0000 0000 0000 0000 0000 .....}..........
    0x0030: 0000 ..
    16:05:06.589409 Port1.100, IN: IP 0.0.0.0 > all-systems.mcast.net: igmp query v3
    16:05:07.075889 Port1.100, OUT: IP 10.0.100.1 > igmp.mcast.net: igmp v3 report, 1 group record(s)
    16:05:07.075896 Port1, OUT: Out 00:25:90:60:64:18 (oui Unknown) ethertype Unknown (0x0064), length 60:
    0x0000: 0000 0800 46c0 0028 0000 4000 0102 95f8 ....F..(..@.....
    0x0010: 0a00 6401 e000 0016 9404 0000 2200 8736 ..d........."..6
    0x0020: 0000 0001 0200 0000 efff 64c8 ..........d.
    16:07:16.584846 Port1, IN: M 00:18:0a:b5:c5:2b (oui Unknown) ethertype Unknown (0xe064), length 66:
    0x0000: 0000 0800 46c0 0024 15fc 0000 0102 2e17 ....F..$........
    0x0010: 0000 0000 e000 0001 9404 0000 1164 6c1e .............dl.
    0x0020: 0000 0000 827d 0000 0000 0000 0000 0000 .....}..........
    0x0030: 0000 ..
    16:07:16.584846 Port1.100, IN: IP 0.0.0.0 > all-systems.mcast.net: igmp query v3
    16:07:17.506631 Port1.100, OUT: IP 10.0.100.1 > igmp.mcast.net: igmp v3 report, 1 group record(s)
    16:07:17.506638 Port1, OUT: Out 00:25:90:60:64:18 (oui Unknown) ethertype Unknown (0x0064), length 60:
    0x0000: 0000 0800 46c0 0028 0000 4000 0102 95f8 ....F..(..@.....
    0x0010: 0a00 6401 e000 0016 9404 0000 2200 8736 ..d........."..6
    0x0020: 0000 0001 0200 0000 efff 64c8 ..........d.
    16:09:26.580872 Port1, IN: M 00:18:0a:b5:c5:2b (oui Unknown) ethertype Unknown (0xe064), length 66:
    0x0000: 0000 0800 46c0 0024 1605 0000 0102 2e0e ....F..$........
    0x0010: 0000 0000 e000 0001 9404 0000 1164 6c1e .............dl.
    0x0020: 0000 0000 827d 0000 0000 0000 0000 0000 .....}..........
    0x0030: 0000 ..
    16:09:26.580872 Port1.100, IN: IP 0.0.0.0 > all-systems.mcast.net: igmp query v3
    16:09:31.337356 Port1.100, OUT: IP 10.0.100.1 > igmp.mcast.net: igmp v3 report, 1 group record(s)
    16:09:31.337366 Port1, OUT: Out 00:25:90:60:64:18 (oui Unknown) ethertype Unknown (0x0064), length 60:
    0x0000: 0000 0800 46c0 0028 0000 4000 0102 95f8 ....F..(..@.....
    0x0010: 0a00 6401 e000 0016 9404 0000 2200 8736 ..d........."..6
    0x0020: 0000 0001 0200 0000 efff 64c8 ..........d.
    16:11:36.618526 Port1, IN: M 00:18:0a:b5:c5:2b (oui Unknown) ethertype Unknown (0xe064), length 66:
    0x0000: 0000 0800 46c0 0024 160f 0000 0102 2e04 ....F..$........
    0x0010: 0000 0000 e000 0001 9404 0000 1164 6c1e .............dl.
    0x0020: 0000 0000 827d 0000 0000 0000 0000 0000 .....}..........
    0x0030: 0000 ..
    16:11:36.618526 Port1.100, IN: IP 0.0.0.0 > all-systems.mcast.net: igmp query v3
    16:11:41.240092 Port1.100, OUT: IP 10.0.100.1 > igmp.mcast.net: igmp v3 report, 1 group record(s)
    16:11:41.240099 Port1, OUT: Out 00:25:90:60:64:18 (oui Unknown) ethertype Unknown (0x0064), length 60:
    0x0000: 0000 0800 46c0 0028 0000 4000 0102 95f8 ....F..(..@.....
    0x0010: 0a00 6401 e000 0016 9404 0000 2200 8736 ..d........."..6
    0x0020: 0000 0001 0200 0000 efff 64c8 ..........d.
    16:13:46.613813 Port1, IN: M 00:18:0a:b5:c5:2b (oui Unknown) ethertype Unknown (0xe064), length 66:
    0x0000: 0000 0800 46c0 0024 1619 0000 0102 2dfa ....F..$......-.
    0x0010: 0000 0000 e000 0001 9404 0000 1164 6c1e .............dl.
    0x0020: 0000 0000 827d 0000 0000 0000 0000 0000 .....}..........
    0x0030: 0000

     

     

    Also, something that is unique about Microsoft NLB from what I understand is the fact that despite the use of a multicast MAC, Windows NLB traffic is not multicast traffic.

     

    Microsoft uses a unicast IP paired with a multicast MAC to avoid port flooding. However, the windows NLB cluster can also run in unicast mode.

    I tried all three different modi of windows NLB:

    - Unicast

    - Multicast

    - IGMP Multicast

     

    and was not able to get it to work with Sophos on either setting.

    Also, on various other networking devices (PFSense, Cisco Equipment, Palo Alto, etc.) Windows NLB works without the need to configure Multicast routing, but some special settings such as static ARP entries have to be configured.

     

    I am wondering if I am overlooking some setting or some firewall rule to make it work.

     

    As far as my current firewall rules are concerned:

    I permit all traffic from VPN, LAN Zone and Server Zone to Server Zone where the NLB cluster is located. All other IPs are reachable and properly respond with the exception of the Windows NLB VIP.

  • 0 in reply to Florian Stellet1

    Florian,

    thanks for the tcpdump. While you are running it "tcpdump igmp" please run on another console the drop-packet-capture "host x.x.x.x" command to undestand if XG blocks something.

    Thanks