Our WAN contract with our service provider was up, and pricing for the frame relay connections had increased to the point where buying our own equipment and moving to less pricey DSL circuits just made sense, so we decided to move our interlab traffic to a VPN. Although we aren't running what some would consider a critical WAN network, we do use our WAN connections every day, and loss of connectivity means downtime. We've expanded our Real-World Labs® to new locations, and incorporating frame relay into a dynamic environment is tricky. Plus we want more control over our networks and to build in some perimeter security. Finally, we need to support our editors who telecommute or travel for the publication.
We started the migration project in July 2000 with the expectation that the entire changeover would take several months. Like many IT projects, though, ours has taken much longer than expected--primarily because of organizational and not technical issues.
In our frame relay environment (see "Pre-VPN Network"), our interlab traffic passed over the frame, which was fine for most traffic. However, when we started shoving files around the frame, performance suffered. We also had some support issues, especially when we needed to have our ISP-owned routers configured. Some simple configuration changes would cut off one or more of the labs for hours to days at a time. We needed more control over our network.
Our plan was to move to local broadband for all the sites except the Syracuse University and the University of Wisconsin labs--these both use their host networks' existing Internet connections. During the transition, the Syracuse University, University of Wisconsin and the Washington, D.C., labs are connected via a VPN using equipment from NetScreen Technologies. The other labs access internal resources over the Internet. Unfortunately, at one point over the course of our migration, two of our labs were cut off from the Internet when their DSL carriers closed operations, and we had to scramble to replace our broadband connections.
Network Computing's Web site currently is hosted by cerf.net. Editors at our corporate offices use Lotus Notes. But the technical editorial team is distributed across the country, and many of these editors don't use Notes. Therefore, we are focused on supporting these users. Our production servers, such as SMTP, DNS and file stores, are hosted in Syracuse; backup servers are in the Washington lab.
We decided that our goal migration scenario, in which the local provider serves up basic connectivity and bandwidth and we take care of security by placing firewalls at each perimeter, puts us in a much better position for maintaining our own infrastructure. We selected firewalls from the Nokia IP line and software for the VPN and firewalls from Check Point Software Technologies' VPN-1 line, because these products are relatively simple to install. We have tested both sets and are confident they will work well with our network and application needs.
Our goal is simple: Protect our labs from the Internet using a firewall and connect all the labs over the Internet using IPsec VPN. But as with any sites, ours have some special needs.
We want to be able to add and remove new labs from the VPN easily. And, as mentioned, we need to support our remote and mobile editorial staff. Our broadband connections are "business class," meaning that we have a handful of static IP addresses. Lot of good that does us, though, as none of the broadband service providers are willing to advertise our Class C subnets. With these issues in mind, we developed an architecture to fit our current needs and included considerations for future expansion.
REPORTS
ANALYTICS
Follow 
