Upcoming Events

Cloud Connect
Santa Clara
Feb 13-16, 2012

Cloud Connect brings together the entire cloud eco-system to better understand the transformation we're experiencing and promises to be the defining event of the cloud computing industry. Learn about the latest cloud technologies and platforms from thought leaders in Cloud Connect’s comprehensive conference.

Register Now!

More Events »

Subscribe to Newsletter

  • Keep up with all of the latest news and analysis on the fast-moving IT industry with Network Computing newsletters.
Sign Up
Infrastructure
W O R K S H O P  
Our Long and Winding Road to VPN

  January 21, 2002
  By Mike Fratto



Printer Print Full Article
Printer Print This Page
Printer Download the PDF
E-Mail E-Mail This URL
>> continued from previous page

Interlab Connections

We plan to implement our solution in the near future. In the meantime, here are some details about the specific challenges we had to meet and the solutions we came up with (see "Proposed VPN Network").

One of the first issues we've faced involved basic IP networking. The labs at both Syracuse University and University of Wisconsin had publicly addressable Class C addresses. The remaining labs had a handful of addresses in a completely different address space. And, as we learned when our DSL providers went belly up, those addresses can change quickly. During the course of the migration, we want to do three things:

  1. Have all interlab traffic secured by a VPN.

  2. Maintain some address portability in the event an ISP can advertise our address space.

  3. Maintain access to the Internet through the ISP.
These requirements are related. Passing all interlab traffic over the VPN is relatively simple.

We want to create a full-mesh network where each lab can talk directly to every other lab. A hub-and-spoke model would be needlessly complex and cause performance issues. The hardest part of a mesh design is setting and maintaining the correct routing on each firewall. In our case, that's a minimum of six route statements per firewall that must be maintained manually. Depending on our telecommuter situation, we may use a routing protocol like RIP or OSPF just to simplify route management.

Our second goal is to maintain address portability. Network renumbering is a difficult and tedious task, and an amazing number of network applications tie licenses to IP addresses. We would rather have a static address space in each lab. However, the subnets we use initially will be for internal use only, which means we will have to be careful not to route foreign traffic through one of our existing Internet connections inadvertently.

Because we don't want a hub-and-spoke network, we will have to route all Internet traffic over the local connection. We can't advertise our subnets over the local ISP, so we will have to use NAT (Network Address Translation) for all outbound connections to the Internet. Not all the connections between the labs will require NAT.

For the most part, we don't expect NAT to pose any problems. However, in the rare case where we need to allow some inbound access to lab equipment, we will have to set up static NAT rules on a per-case basis.


   Page: 1 | 2 | 3 | Next Page

Research and Reports

Hypervisor Derby
August 2011

Network Computing: August 2011

TechWeb Careers