Novell Client DHCP Inform packets result in loss of wireless connection

  • 3861100
  • 04-Apr-2007
  • 27-Apr-2012

Environment

Novell Client for Windows 2000/XP/2003 4.91 Support Pack 1
Novell Client for Windows 2000/XP/2003 4.91 Support Pack 2
Novell Client for Windows 2000/XP/2003 4.91 Support Pack 3
Novell ZENworks 6.5 Desktop Management
Novell ZENworks 7 Desktop Management
Verizon Wireless Broadband Adapter (AirCard)
other vendors providing the AirCard adapter
Cisco VPN Client
Nortel VPN Client
Microsoft Windows 2003
Microsoft Windows XP
Microsoft Windows 2000

Situation

After using the Verizon AirCard to connect to the Internet, the Cisco VPN 4.6 client is used to connect to the network.
After connecting to the Internet with the AirCard, the Nortel VPN client is used to connect to the network.

Within 30 seconds, the AirCard will shut down.

A LAN trace shows the Novell Client sending DHCP Inform requests over the private IP address. Verizon monitors the address and detects a private address and disconnects the connection. This is seen as a Denial of Service (DoS) attack and then disconnects the AirCard. This also breaks the VPN connection.

Novell Client for Windows 4.91 and ZENworks 7 Agent installed with default settings or with Middle Tier (XTier) support enabled and configured.

Resolution

The work arounds for this issue involve reducing the number of DHCP Inform packets sent out when the VPN connection is established. This can be accomplished by:

A) disabling SLP DHCP discovery,
B) disabling DHCP use by the Novell Client or
C) disabling the DHCP use by the ZENworks Agent to identify the nearest Middle Tier server.

These options are listed in no particular order and different options or combination of options may be appropriate for different environments.

A) Disable SLP DHCP discovery by disabling the "Use DHCP for SLP" option.

1. Right-click the "Red N" in the system tray
2. Select "Novell Client Properties"
3. Select "Advanced Settings" tab
4. Select "Use DHCP for SLP"
5. Change the setting to "Off."

Note: The SLP configuration - SLP DA addresses and SLP Scope names - must be hard-coded in the Novell Client configuration instead of solicited from DHCP for this workaround. Changes to this hard coded information can be deployed using a ZENworks Application to update the related registry values.

B) Disable the Novell client DHCP options by turning off all options on the "DHCP Settings" tab in the Novell Client Properties

1. Right-click the "Red N" in the system tray
2. Select "Novell Client Properties"
3. Select "DHCP Settings" tab
4. De-select all check boxes

C) Disable DHCP use by the ZENworks agent to determine the closest Middle Tier server by renaming NOVDHCP.DLL. This work around is only an option if ZENworks Agent is installed.

Rename\system32\novell\novdhcp.dll

The goal of these workaround options is to reduce the number of DHCP Inform requests by Novell software to some number below the"forged" limit being imposed by the Aircard Service Provider. On Verizon this limit is known to be 10-packets.

Additional Information

The Windows 2000/XP/2003 TCPIP stack handles UDP sends that are addressed to the IP broadcast address. Windows 2000/XP actually sends these IP broadcasts out all interfaces, even though the caller/sender had opened an address object for a specific interface.

When the VPN tunnel is established and the Novell Client/ZENworks Agent begin sending DHCP Inform requests out over the new virtual interface, Windows 2000/XP/2003 transmits the DHCP Inform request over all interfaces. So in addition to a DHCP Inform request being seen on the VPN interface, the exact same packet is seen on every other interface, including the public (Verizon) interface.
 
The Verizon switches tolerate up to ten (10) "forged" packets (packets that don't have a source IP address that matches the AirCard's public IP address) before they disconnect the interface.

Microsoft prevents this issue for themselves on Windows 2000/XP/2003 by using undocumented IOCTL interfaces to TCPIP.SYS in order to suppress a broadcast from going out all interfaces when Microsoft knows its about to perform an action that would cause this. Microsoft has chosen to provide the solution to this issue in Windows Vista instead of expanding support of an undocumented interface in Windows 2003, XP and 2000.

On Windows Vista and later, this issue is addressed with a re-written TCPIP.SYS stack that conforms to the "strong host" model. This means that by default an IP datagram with a specific source address will only be sent out over the interface that corresponds to that source address. (RFC 1122, section 3.3.4.2 "Multihoming Requirements")

Note: Verizon Has Updated their VZAccess Manager Tool.  Selecting the "NDIS MODE" checkbox should also resolve the issue without needing to Disable any Novell Features.
 

Feedback service temporarily unavailable. For content questions or problems, please contact Support.