Contivity Local Lan / Dual Nics/ Protocols - No Split Tunneling

[inetbi]

Hi,

I think there should be a difinitive answer for this issue that has come up with the Contivity Client. In situations when split tunneling is not available (or you can't get a big company to enable it)....what is the preferred method of getting access to Local Network Resources (File Shares). So far I have seen the following:

-Install 2 networks cards and use NetBeui (from xp cd) or IPX/SPX to get local computers connected.

-Install IPX/SPX on the main network adapter and use this to communicated (anyone tried this)

-Use two NIC's and do a route add 0.0.0.0 mask 0.0.0.0 GATEWAY for local traffic and manually add the routes for the VPN IP range traffic??? (anyone?)

-Modify the LMHosts file or add a wins server? (Not sure if this will work)

Please comment on ways that you have gotten this to work, I need to get this setup in an office with 10+ users that need to use the Nortel VPN Client at the same time as their Access Based accounting system.

Thanks,

-JM

 

[VPNSteve]

I'm not sure there's a way to do what you'd like. The Contivity Client software has been getting better and better in terms of network security.

The client has been designed to lock down the system it's installed on when the client tunnel is up. This is one of their technical tips, which might help explain what the client looks at in terms of keeping the network secure.

Tech Tip
Contivity Secure IP Services Gateway
“Routing table cannot be altered” message
In some situations the “The routing table cannot be altered after the Extranet Connection has been established.... The Extranet Connection has been Closed” message might appear on the client’s machine followed by the tunnel tear down. This error message was intended to appear on the client’s machine when changes to the routing table are made on the client’s machine. Changing the routing table posses a potential risk of bypassing the policy passed by Contivity* to the client, this in turn leads to a potential security risk by allowing an unauthorized access. So when Contivity detects the routing table change and therefore the violation of the security policy, Contivity drops the tunnel connection to stop the intrusion. The possible causes for the routing table changes are as follows: 1. Client’s machine has several NIC cards, the tunnel is established through one of them and when there are any changes to the other cards (for example, interface goes down) the change to the routing table is made. 2. Client has a short lease time for the IP address acquired through the DHCP, table changes after the address renewal/acquisition (if IP changes). 3. Some applications on the client’s machine rewrite the routing table (for example, issuing the route add command). 4. Routing updates from dynamic protocols like RIP or OSPF change the table. 5. ICMP redirect messages have been received by the client’s machine. 6. MTU discovery causes Windows systems to install a specific route to a destination with a lower MTU (one of the major reasons for disconnects with DSL users). 7. Internet connection sharing. The routing table check security feature was first introduced in the Extranet Access Client (EAC) code version 2_62.47. All versions prior to this release didn’t have the routing table check and therefore considered to be less secure. With the introduction of the filter driver there is no longer a need to check the routing table when client/Contivity are not operating in the split tunneling mode. Since filter driver now only allows the traffic to leave/enter the system which has originated from the Contivity and is destined for the client (or vise versa). This change was introduced in the V04_65.019 Contivity VPN client code version and will be incorporated in all the future releases. The routing table check still applies to the operation in the split tunneling mode to insure the security of the client/server session. With Contivity VPN Client code version 5_01 a change has been made so that specific route installations outside the tunnel due to ICMP redirect and MTU discovery messages do not violate Contivity security policy. Thus, for example, when a specific route outside the tunnel to a destination with a smaller MTU is installed, the client connection stays up. To avoid the “Routing table cannot be altered” message make sure nothing changes the routing table while the secure tunnel connection is established between VPN client and the Contivity server. TT031002 4.00 February 2005 Page: 1 of 2
Tech Tip
Contivity Secure IP Services Gateway
“Routing table cannot be altered” message
Below are basic troubleshooting steps to be taken to resolve the problem: 1. If possible, upgrade the VPN client to the latest version available on Nortel Networks website

http://www.nortel.com/support

2. If upgrade does not help or is not desirable for any reason determine what changes the routing table. For that use netstat -nr or route print commands before, during and after Contivity VPN Client connects/disconnects and compare the output to locate the installed route and determine its origin. Note, the commands should be entered rapidly as route could be installed for a few seconds. Traffic capture on the client’s PC should provide additional information on routing updates origin. Once the reason for routing update is determined, try to eliminate it for the time the tunnel will be up. 3. If the reason for routing update could not be found or elimination of the reason is not possible, consider using mandatory tunneling for the users with problem; in order words avoid using split tunneling for these users. 4. If the above steps are not successful or acceptable, please contact technical support for help in determining the reason of routing table changes and possible resolutions. The contact information is available at

http://www.nortel.com/help/contact/global

Copyright © 2005 Nortel Networks Limited - All Rights Reserved. Nortel, Nortel Networks, the Nortel logo, Globemark, and Contivity are trademarks of Nortel Networks Limited. The information in this document is subject to change without notice. The statements, configurations, technical data, and recommendations in this document are believed to be accurate and reliable, but are presented without express or implied warranty. Users must take full responsibility for their applications of any products specified in this document. The information in this document is proprietary to Nortel Networks Limited. To access more technical documentation, search our knowledge base, or open a service request online, please visit Nortel Networks Technical Support on the web at:

http://www.nortel.com/supportIf

after following this guide you are still having problems, please ensure you have carried out the steps exactly as in this document. If problems still persist, please contact Nortel Networks Technical Support (contact information is available online at:

http://www.nortel.com/cgi-bin/comments/comments.cgi?key=techsupport_cu).

We welcome you comments and suggestions on the quality and usefulness of this document. If you would like to leave a feedback please send your comments to: CRCONT@nortel.com Author: XXXXXXXXXXXX TT031002 4.00 February 2005 Page: 2 of 2

 

[nsantin]

The only way we were able to overcome the "big company says screw you" syndrome is to use Virtual PCs. The Virtual PC can connect to the client network, and still have access to the local PC harddrive, plus as it is running as an applicaiton on your local environemnt you still have full access to your network resources.

Only catch is it takes up a lot os resources (memory) to run.