ISA Integrated NLB – Multicast with IGMP… ISA “blocks” IGMP packets


Introduction

After configuring ISA Integrated NLB to use multicast with IGMP, you may see blocked IGMP packets between your ISA array members. The ISA nodes don’t need these packets  to work properly, and it’s ok when they are blocked by the Firewall Engine.


As many customers are using Multicast NLB, we added multicast and multicast with IGMP for ISA Integrated NLB in SP1, (http://support.microsoft.com/kb/938550; also part of ISA 2006 SP1) we’ve heard from some customers  who were confused by seeing denied IGMP packets in the ISA logging after they enabled Multicast IGMP NLB mode.


Scenario

In the following example, the source IP (147.88.201.25) is the primary NLB IP and the destination IP is the multicast IP of the NLB Array:


clip_image002


The packets you see denied are multicast IGMP packages, which are denied by the Firewall Service. As a good admin you start to worry and double check the status of your NLB array by executing the command wlbs query :


WLBS Cluster Control Utility V2.4 (c) 1997-2003 Microsoft Corporation. 


Cluster 147.88.201.25 


Host 3 has entered a converging state 3 time(s) since joining the cluster and the last convergence completed at approximately: 07.05.2009 18:49:20 


Host 3 converged with the following host(s) as part of the cluster: 


2, 3


No errors can be found here. For more details, and to verify, that you’re running IGMP NLB, you can use wlbs display:


WLBS Cluster Control Utility V2.4 (c) 1997-2003 Microsoft Corporation.


Cluster 147.88.201.25


=== Configuration: ===


Current time              = 08.05.2009 18:38:11


ParametersVersion         = 4


VirtualNICName            =


AliveMsgPeriod            = 1000


AliveMsgTolerance         = 5


NumActions                = 100


NumPackets                = 200


NumAliveMsgs              = 66


ClusterNetworkAddress     = 01-00-5e-7f-c9-19


ClusterName               = External


ClusterIPAddress          = 147.88.201.25


ClusterNetworkMask        = 255.255.255.0


DedicatedIPAddress        = 147.88.201.156


DedicatedNetworkMask      = 255.255.255.0


HostPriority              = 3


ClusterModeOnStart        = STOPPED


PersistedStates           = SUSPENDED


DescriptorsPerAlloc       = 512


MaxDescriptorAllocs       = 512


TCPConnectionTimeout      = 60


IPSecConnectionTimeout    = 86400


FilterICMP                = DISABLED


ScaleSingleClient         = 0


NBTSupportEnable          = 1


MulticastSupportEnable    = 1


MulticastARPEnable        = 1


MaskSourceMAC             = 1


IGMPSupport               = ENABLED


IPtoMcastIP               = ENABLED


McastIPAddress            = 239.255.201.25


NetmonAliveMsgs           = 0


EffectiveVersion          = V2.1


IPChangeDelay             = 60000


IPToMACEnable             = 1


ConnectionCleanupDelay    = 300000


RemoteControlEnabled      = 0


RemoteControlUDPPort      = 2504


RemoteControlCode         = 0x0


RemoteMaintenanceEnabled  = 0x0


CurrentVersion            = V2.4


InstallDate               = 0x4A00418C


VerifyDate                = 0x0


NumberOfRules             = 1


BDATeaming                = ENABLED


TeamID                    = {5601BF8D-2D28-46D2-B4DC-0983B2B6532E}


Master                    = ENABLED


ReverseHash               = DISABLED


IdentityHeartbeatPeriod   = 10000


IdentityHeartbeatEnabled  = ENABLED


PortRules                


Virtual IP addr Start   End     Prot    Mode            Pri     Load    Affinity


            ALL     0   65535   Both    Multiple                Equal   S


No problems can be found here and the array is load-balancing traffic just fine…


Behind the scenes

Why is ISA blocking the IGMP status messages from its own NLB array, and why is the array still working?



1. If ISA is not configured to explicitly allow Multicast traffic, ISA will always block the Multicast packets.


2. The Multicast packets you see blocked by the Firewall Engine, are IGMP messages sent periodically from the router to each member in the multicast group (Host membership query). Additionally, you’ll see packets sent from the ISA node to the multicast router (Host membership report or Leave group). http://technet.microsoft.com/en-us/library/cc787925(WS.10).aspx provides more detail on how IGMP works.


In order to understand why NLB is still working, a quick look at the ISA Server Architecture should clarify things:


clip_image004


More information about the ISA architecture can be found in the ISA Server 2006 Firewall Core Whitepaper (http://download.microsoft.com/download/e/7/6/e76fdda3-5c2c-4fbb-9c6f-3bcd0ed4b8ef/Firewall_Corewp.doc)


The ISA Firewall Engine hooks itself to the TCP/IP Stack. However the NLB driver can be found below the TCP/IP Stack in the NDIS layer. Because of this the NLB driver will process the packets before the Firewall Engine can deny them. As other applications don’t need to process those packets, NLB continues working, although it appears as if ISA denied them.



TIP: In order to prevent those denied packets from flooding your logs with data you don’t really need, you may create a deny rule for all IGMP traffic sent to the Multicast IP address (displayed in the wlbs /display output) and configure this rule to not log matched requests.


In order to create this rule you’ll have to create a new protocol, to match the IGMP protocol. In the ISA MMC go to Firewall Policy – Tool Box – Create a new Protocol with the following details:
IGMP – IP Protocol ID 2, send-receive:

clip_image006


in the next step you should create a new computer object for your IGMP Multicast address:


clip_image008


Note:  this IP address will most likely be different in your environment. Make sure to verify it with the output from the wlbs display command.


Create an access rule with the appropriate sources (in this example the source would be External) and choose the IGMP protocol and the new computer object as the destination.


After you finish the new access rule wizard, open the rule properties, and disable the logging for this rule in the Action tab by unchecking ‘Log requests matching this rule’.


clip_image010



Author


Philipp Sand
Microsoft CSS Forefront Security Edge Team


Technical Reviewer


Jim Harrison
Microsoft PM Forefront Edge CS


Doron Juster
Microsoft SENIOR SDE ForeFront Edge

Comments (3)

  1. Anonymous says:

    My Access rule only seems to block when the destination address is set to Localhost and not the newly created multicast address. Any ideas why? Is it a risk to leave it as Localhost?

  2. I have the same issue. I have not yet tried Local Host as the destination. But when I have Internal or a Source IP Address as the source, it bypasses the rule. The protcol matches, also the source and destionation, but nothing is blocked and logged by the rule I have specified. Looks like ISA Server has another behavior with this protocol.

  3. Ignacio says:

    Hi everybody, My scenario is as following: two Forefront TMG 2010 on windows 2008 server (virtualized enviroment).
    Both are in a NLB array, everything seems work fine but I have recently noted that when I try to access to CIFS names, and their shared resources, I can´t, from my TMG´s servers I just can´t even ping Ip destinations of the CIFS names.
    So, I can´t access to those shared resources, when I disable the NLB array, everything works fine, I can access same shared resources, pinging the sites and all its OK.

    Do you know what is happening?

    best regards

Skip to main content