Client routing problems with NIC not releasing IP address

[sdetoffol]

I'm having a hard time with the following problem. Cisco seems to think this is minor, yet all my customers complain. If you have users that use their laptop on the LAN during work hours and then travel or work from home using a modem, this will cause endless hours of tech support. Is there a REAL resolution coming?

From the Cisco VPN Client 3.0 Release Notes

CSCds31366

Routing problems can occur when the VPN Client gets an IP Address from the VPN 3000 Concentrator that is on the same network that is currently assigned to a local NIC (Ethernet Card). This can occur if a user has a laptop on the corporate network with a static IP Address (100.50.0.1), brings his/her laptop home and dials into his/her ISP and connects using the VPN Client. If the VPN 3000 Concentrator sends the VPN Client an IP Address that is on the same network (100.50.100.X), the user cannot send any data over the VPN Client connection because the packets are sent to the NIC instead of over the VPN connection. Other scenarios also exist; this is just a simple one.

The IP address must be released (if using DHCP via ipconfig or winipcfg). This issue is also referred to as the "overlapping Ethernet address" problem.

Microsoft has two open bugs on the fact that for dynamic (DHCP assigned) IP addresses, they are not properly released upon shutdown:

– MS BUG: Q154091 - Section 3 of the Release Notes "Known bugs and

limitations": The Windows 98 solution involves disabling fast shutdown and adding a value "ReleaseLeaseOnShutdown". This was tested on 98 and does appear to work properly.

– MS BUG: Q271455 Windows NT: For Windows NT (article Q271455) they recommend that the user create a .bat file that does a ipconfig /release and then a shutdown using a utility that they provide.

These may not be the easiest solutions to implement, but is recommended by Microsoft and will fix the problem in a DHCP case. The only problem that remains is one where the IP is static.

[mdahl]

I've had to fight this one as well for both users that take laptops home from the corporate network and remote offices that try getting back to their LAN across our WAN because their system have a route for their network that is directly connected, therefore does not use the tunnel. Since our laptop users have local administrative rights on their PC's, we used the "Application launcher" within the VPN dialer to fire off the "ipconfig /release" as they connect to VPN. If your users do not have local admin rights, then the next best thing to do is to change the security settings on the c:\winnt\system32\route.exe application to full control. You can then use the "Application launcher" to run the "c:winnt\system32\route.exe DELETE xxx.xxx.xxx.xxx".

[tboblin]

I have also had similar problems with Checkpoint products. My interim solution has been to use multiple hardware profiles on our laptops. By configuring descriptive profile names

- "Remote-Dialup Only" for modem access.

- "Remote-Network support" for cable/xDSL access.

- "Docked or In-office" for normal access.

User's then select the profile needed when they startup. Disabling the network adapters in the appropriate profiles provides the workaround in our environment. One benefit is that this approach can be implemented in NT or 9X.