cancel
Showing results for 
Search instead for 
Did you mean: 

Network Connect 6.2.0 - many problems

Contributor

Re: Network Connect 6.2.0 - many problems

Mentioned that in a different post already.

The frozen sessions can be related to ESP as the transport protocol!

Try it with oNCP.

The frozen sessions have been caused by different MTU sizes of network components in the transfer path which made ESP (udp) crash and lead to kernel panics on the IVE afaik.

Try it with oNCP or try an firmware upgrade.

The MTU issue should have been fixed in an actual release.

Best regards,

Ate RocKz

Super Contributor

Re: Network Connect 6.2.0 - many problems

Please make sure your SE and Sales Rep know about all the NetConnect problems you have been experiencing. Anyone from the Neoteris days can tell you that NetConnect was added as an afterthought to their Web Rewriting and Port forwarding products. Juniper attracted a lot of companies to their NetConnect product and like you I believe it's buggy and not supported like it should be.

I have heard that Juniper is creating a all-in one client piece that will hopefully resolve many of these upgrade issues.

New Contributor

Re: Network Connect 6.2.0 - many problems

Typically we see significant new NetworkConnect (or related hostchecker) issues in about one of every three releases that we test - but its critical to us (and in our experience so far the best of the light weight VPN clients on the market) - still it shouldn't be this hard...

FYI we qualified 6.3R2 as being one of the best recent releases, still have a few users struggling with 3G (or older) aircards, but this release has been very stable so far.

JD

Highlighted
New Contributor

Re: Network Connect 6.2.0 - many problems

All -

We resolved this issue and are now running 6.3. It turned out to be a custom sign on page that was causing the problems. I turned off the custom sign on page and it works great now.

Frequent Contributor

Re: Network Connect 6.2.0 - many problems


@RobertN wrote:

We are having issues also... When users first boot a cold machine and then launch NC, the NC session times out on initiation and we get a "Network Connect session terminated. Do you want to reconnect? error 23712"... The user answers "Yes" and the NC session starts, as expected...

If the user disconnects the NC session and does not reboot the machine, and then relaunches NC...no error is seen...and the connection happens as expected.

Is anyone else seeing this activity? I am not seeing this issue in 6.0r4.


I used to see this issue all the time in 6.0R3. JTAC had me upgrade to 6.0R5 and it still happens. No resolution my friend. We got so tired of the user calls that we dumped NC and only use WSAM.

I am currently working on a project to go back to Windows 2008-based VPN with NAP.

Contributor

Re: Network Connect 6.2.0 - many problems

I have found you need to enable session IP roaming with air cards. If you don't allow this in the Role session settings, the connection will drop if the IP changes. FWIW.

-=Dan=-

Not applicable

Re: Network Connect 6.2.0 - many problems

The Verizon Wireless disconnect issue with Network Connect can be resolved by checking "NDIS mode" in the VZAccess Manager... Tools > Preferences... > WWAN > "NDIS mode".

Here's an additional item that might cause the problem. Please open up a ticket with JTAC (888-314-JTAC) to obtain the quickest resolution...

Issue: After using Verizon AirCard to connect to the Internet, then connecting to NC, within 30 seconds the Aircard will shut down

Cause: The problem is 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.

Per Bug 398879 this is an issue with whatever application is broadcasting the DHCP informs. Even though the source IP is NC, the DHCP inform packets are being sent to the Ethernet adapter, therefore, NC can't encrypt them.

Solution: This is a known issue for both Novell and Microsoft.

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. However, Microsoft has chosen to provide the solution to this issue only 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")

Please see the following KB article provided by Novell as to how to prevent the DHCP informs from being sent out. http://www.novell.com/support/php/search.do?cmd=displayKC&docType=kc&externalId=3861100&sliceId=1&do...

Novell Client DHCP Inform packets result in loss of wireless connection

This document (3861100) is provided subject to the disclaimer at the end of this document.

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")

Document

Document ID:

3861100

Creation Date:

04-04-2007

Modified Date:

06-20-2008

Novell Product:

Novell Client

Disclaimer

The Origin of this information may be internal or external to Novell. Novell makes all reasonable efforts to verify this information. However, the information provided in this document is for your information only. Novell makes no explicit or implied claims to the validity of this information.
Any trademarks referenced in this document are the property of their respective owners. Consult your product manuals for complete trademark information.

Thanks,

David

Not applicable

Re: Network Connect 6.2.0 - many problems

I would like to add to this thread. I was having the same issue with "Network Connect" 6.3 dropping after a minute or two with the ....90 message. In looking the diagnosis test, I would see it start failing around DHCP. I tried changing some of the settings on my AT&T Quicksilver 3G USB but nothing. Until I found someone on an AT&T thread mention...

"When connecting to a VPN make sure you are are not using accelerated mode. - DWC1."

So, under AT&T Connection Manager go to Tools -> Settings -> Acceleration Tab -> Startup Type (Manual) and STOP it.

Once I made this change... I noticed my security, compression and transport mode showing up in the basic view of "network connect", something I hadn't seen previously. As of this moment I've been connected without any drops. I hope this helps the community.

- Paul