Network Computingwww.networkcomputing.com

	Print Full Article Print This Page Download the PDF E-Mail This URL

Supporting telecommuters poses special problems because of the wide array of issues, including IP addressing, desktop client support, authentication, and logging, to be resolved. Most of our remote editors have broadband connections and use NAT routers to support home networks.

This creates problems for IPsec VPN, though, because in many cases IPsec traffic won't pass through a NAT. That leaves us with the following options:

1. Purchase NAT routers that will pass IPsec or purchase SOHO firewall/VPN devices.

2. Use PPTP for a VPN connection to Network Computing's network.

3. Use a client that will bypass NAT routers using UDP encapsulation

Many of our staffers have SOHO firewall/VPN routers, and the main difficulty is getting them to interoperate with the Nokia-Check Point VPN-1 hardware. The SOHO firewalls will be configured to send all traffic bound for our internal networks over the VPN, and all other traffic will pass to the Internet through the local ISP.

Not all our editors have SOHO firewalls, though, so where there is just a NAT router, we can use PPTP for remote access. We also will use PPTP for our users who are running non-Microsoft Windows machines that cannot use a third-party IPsec client.

In those cases where we have to rely on PPTP or a third-party IPsec client that is not interoperable with Check Point VPN-1, in Syracuse we can fall back to using Cisco Systems' VPN 3005 Concentrator, which we employ for our local remote users. Unfortunately, this traffic will have a longer path to traverse, but we would rather support one remote-access concentrator for all users than install and maintain multiple concentrators.

Simultaneously, Network Computing is building an intranet site. One of the major goals for the intranet is to consolidate user authentication and access control to resources. We run a wide range of platforms--from Microsoft Windows and Novell NetWare to Sun Microsystems Solaris and Linux--and bringing all the systems under a single authentication mechanism is critical. Our goal is to provide at minimum user name/password authentication via LDAP over SSL.

During the initial rollout of our telecommuter VPN solution, we will integrate it with an LDAP-enabled directory and add other services as needed. Although we will not achieve single sign-on, centralizing user accounts and passwords will make management easier and simplify user-account management.

The next step for VPN authentication is to use digital certificates for IKE authentication and then user name/passwords to identify the user. To make this happen, we first need to build and integrate a certificate authority that will work with our VPN clients and server. This is a much more difficult task than it appears. For example, Microsoft Windows 2000 and XP Professional Dial-Up Networking components expect digital certificates to have extensions that allow the certificate to be used for IPsec authentication. So if we want to support native VPN in the Windows environment, we must ensure the certificates issued are configured properly. Other VPN clients may have similar constraints.

Of course, this all sounds good in theory. We plan on building out the VPN using the Nokia hardware in the next two months. We will first build a test bed to perform initial configuration and build the VPN and security policies. Prebuilding will let us test the configuration in a controlled environment and ship the hardware preconfigured to the remote sites.

Once it's installed, we will be carefully monitoring the firewalls and traffic ensuring that our policies are functioning as expected. In a few months, we'll publish a follow-up article and post updates online regarding the status of our migration.