If your organization is currently paying for dedicated T1, frame relay, or other leased lines as part of your WAN solution, you may not realize just how much money you can save by implementing a site-to-site VPN. However, as a new technology, VPN brings with it a new set of technological challenges.
In this week’s From the Trenches column, we’ll follow TechRepublic systems administrator Lori Hyde, who oversees routing and LAN/WAN issues, through the trials and tribulations she experienced when she designed and implemented a “hub-and-spoke” VPN. She accomplished this by combining a couple of Cisco solutions, one of which Cisco apparently rolled out a bit prematurely.
Get insights From the Trenches
You can learn quite a bit by reading about the methods other administrators and engineers use to resolve challenging technology issues. Our hope is that this column will provide you with unique solutions and valuable techniques that can help you become a better IT professional. If you have an experience that would be a good candidate for a future From the Trenches column, please e-mail us. All administrators and their companies remain anonymous in this column so that no sensitive company or network information is revealed.
It’s a quirk to you, but money to me
At one point in TechRepublic’s history, we had offices in New York, Minnesota, and California, along with our corporate headquarters in Louisville, KY. We needed to be able to communicate securely from Kentucky to each of these offices and between each of the remote offices.
VPN seemed like the best alternative because it offered security without the use of elaborate firewalls. We also wanted a solution that didn’t require spending lots of money on dedicated leased lines. To give you an idea of the cost difference, let’s look at the connection costs for the three main options available for connecting our Louisville office to our California office:
- Dedicated T1 line: $9,000/month (on each end)
- Frame relay connection: $4,500/month (on each end)
- VPN solution: $1,200/month (on each end)
Once we decided that VPN was going to be the best option, we looked at solutions from Intel, Nortel, and Cisco. Because we were already using a lot of Cisco equipment, Cisco’s solution seemed to make the most sense. In addition, we could use our existing router hardware and simply plug in encryption cards rather than buy new VPN routers.
“We wanted the continuity of the vendor and the hardware,” Hyde said.
TechRepublic’s director of IT, Troy Atwood, said his experience with Cisco had been pretty good. However, that good relationship was strained a bit when Cisco pointed us to its IOS-to-IOS VPN solution. (IOS is Cisco’s proprietary Internetwork Operating System.) Having presented Cisco with a detailed plan of what we wanted to do with the equipment, Hyde said the Cisco salesperson assured her that this solution would work. It did work—eventually.
TechRepublic bought the encryption cards and installed them in routers at most of the remote offices and at corporate headquarters. At first, the IOS solution seemed to be working as advertised, particularly when the remote offices were communicating with the corporate office.
In our hub-and-spoke configuration, however, we needed the spokes to be able to talk to each other.
“We had developers in Minnesota who needed to do stuff to the back end of our Web site hosted in San Francisco,” Hyde said. She added that the IOS software and encryption card hardware proved to be pretty buggy, which caused lots of grief.
“It’s not meant to do that,” Cisco told Atwood when he explained the situation. “It’s an unsupported configuration.”
It took awhile, but Atwood and Hyde eventually got Cisco to admit that it had sold TechRepublic a solution that its equipment couldn’t quite support yet.
After that, Cisco restored some of Atwood’s faith in the company by working diligently with TechRepublic to make the connections work.
A temporary solution
While Cisco worked to eliminate bugs in its IOS-to-IOS VPN solution, it gave us an indefinite loan of several Series 3000 Cisco VPN Concentrators. The Concentrators are faster and rock solid in reliability, Hyde said. In remote offices, they also can function as DHCP servers and have other useful capabilities. The downside to Concentrators is that they are much more expensive than the IOS-to-IOS solution. However, while Cisco was updating its IOS, the on-loan Concentrators did all the VPN work for our links and solved the connection problems.
“Cisco has really wanted to support us,” Hyde said. So she took the encryption cards out of the loop until Cisco released version 12.2.2 of the IOS software. Then, she upgraded the routers to the new system software and took the Concentrators out of the loop unless they are needed.
According to Hyde, the new software has had things running stable since the upgrade. Nevertheless, a few wrinkles remain.
After CNET bought TechRepublic, we connected to CNET’s worldwide network via IOS-to-IOS VPN. Hyde has been studying the network and she has noticed that the IOS solution is sensitive to Internet latency.
“It’s just an observation, but when ping times get greater than 200 milliseconds, you get problems,” she said. “If you really want a good VPN performance, you need to keep as many of your sites on one carrier, preferably a Tier 1 provider.”
Network design matters
Hyde has studied Cisco’s various VPN solutions and has come to the conclusion that different equipment options are critical to a successful and problem-free site-to-site VPN solution.
She said these are the deciding factors that determine the best solution:
- The latency in the circuit
- The size of the remote office and the network traffic it produces
- The needs of the remote office
“You really have to look at each site individually,” she said. She cites two examples from TechRepublic’s experience.
“When we had the San Francisco office before CNET bought us, we were sharing a T1 with another company in the same building,” she said.
To make this arrangement work, TechRepublic used a Cisco 3005 Concentrator in the remote office with a Cisco 3015 in Louisville. The Concentrator acted as a DHCP server for the remote office, carved out a fixed amount of the T1 we were sharing, and allowed for a faster and more secure connection.
For the Louisville-to-Minnesota connection, the IOS-to-IOS solution worked best because we already had decent ping times, and that office had its own servers and routers.
“That was hardware we didn’t want to replicate,” Hyde said.
In both cases, she was able to share routing protocols across the Internet through the secure VPN connections, saving the hassle of static route administration. “When you share dynamic routing tables, any changes automatically and instantaneously are shared.”
Despite all the headaches, Hyde remains convinced that site-to-site VPN offers a viable solution for efficient and secure connectivity. “VPN is still an infant technology, as far as I’m concerned,” she said. “With any infant technology, there are going to be quirks.”
Do you use site-to-site VPN?
How are you making site-to-site VPN work at your organization? What vendors or equipment are you using to accomplish what you need to do? Send us a note or post a comment in the discussion below.