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


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, (; 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.


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


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. 


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.


=== 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          =

ClusterNetworkMask        =

DedicatedIPAddress        =

DedicatedNetworkMask      =

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            =

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


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). 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:


More information about the ISA architecture can be found in the ISA Server 2006 Firewall Core Whitepaper (

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:


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


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'.



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