In September, eTunnels launched VPN-On-Demand, a unique "instant VPN" service. According to CEO Dimitri Sirota, VPN-On-Demand was designed to meet the top challenges involved in high volume service deployment. "The principals who formed this company worked with carriers that used CheckPoint FireWall-1 and Cisco PIX to build VPNs," said Sirota. "These CPE solutions were complex to deploy and didn't support Extranet very well. They were also hard to budget. This is the origin of VPN-On-Demand."
VPN-On-Demand 1.0 is aimed at providers who want to offer remote access VPN services to the SME market. The fundamental premise: keep VPN simple by making the network smart. eTunnels centralizes enrollment, provisioning, and policy enforcement to speed delivery and reduce cost. The upcoming 2.0 release (now in beta) adds centrally-managed CPE for site-to-site and Extranet VPN services.
Intrigued by this pitch, we took VPN-On-Demand 1.0 for a test drive. We found that this service lived up to its name: with an on-line wizard and software, we created a 3-member PC-to-PC VPN in about an hour. While this service is very simple to use and deploy, there are also limitations. Here's what we found.
The Foundation: eNS
As with other IPsec-based services, customer networks created by VPN-On-Demand provide encrypted communication between authenticated members. In release 1.0, IPsec ESP DES or 3DES tunnels carry traffic between client and server PCs. Release 2.0 adds software and hardware IPsec gateways—devices that terminate WAN tunnels, providing secure access to entire LANs.
But VPN-On-Demand places unusual emphasis on centralized, automated provisioning. Tunnel endpoints don't have to be individually configured with security policies, as in many VPNs today. Configuration and software updates flow from a central source: the eNS (eTunnels Network Server). "eNS operates as a service—like DNS, but for security," explained Sirota.
The eNS tracks VPN membership, state, security parameters, network topology, and resource locations. "Some customers want a worker visiting a customer site to be able to connect into their home network using the customer's network—sort of a hybrid of remote access and Extranet," said Sirota. "In this case, the client may be behind DHCP and a firewall, and eNS needs to understand network topology to make this all work."
The eNS is also a policy enforcer—a traffic cop. Each member of the VPN—client, server, or gateway—initiates an SSL connection to the eNS. The eNS authenticates the member, generates session keys, and orchestrates tunnel setup. An IPsec tunnel is established between the new member and every other active member (a fully-meshed VPN). There are no filters for specific protocols or source/destination pairs—every member is granted full access to the entire VPN. The eNS tracks element status and works to keep this fully-meshed network afloat at all times.
After setup, traffic is tunneled directly between VPN elements, using a point-to-point rather than hub-and-spoke tunnel topology. "This gets us out of the call, and lets us avoid the trust and latency issues that have impacted some other Extranets, like ANX," said Sirota. "If the eNS should go down, tunnels would not be impacted."
Nonetheless, placing so much control and real-time processing at the network center does raise reliability and scalability concerns. Naturally, the eNS is not just one monolithic server. It is a set of servers, hosted at multiple data centers for geographic redundancy. eNS servers are front-ended by L4 switches and back-ended by an Oracle 8 database. With VPN-On-Demand's centralized architecture, eTunnels must clearly do everything possible to prevent the eNS from becoming a single-point-of-failure—and to protect this juicy target from being hacked.
http://www.isp-planet.com/technology/etunnels1.html
