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:

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:

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:

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

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

• Anonymous
  January 01, 2003
  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?

• Anonymous
  January 01, 2003
  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.

• Anonymous
  February 27, 2014
  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