>> 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:
- Have all interlab traffic secured by a VPN.
- Maintain some address portability in the event an ISP can advertise our address space.
- 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.