VPN deployments have become an integral part of most networking solution providers' portfolios. But in the past couple of years, customers' needs have evolved, creating the need for advanced VPN technologies. In this project FAQ on selling advanced VPN technology, Lisa Phifer, president of Core Competence, will show you how to help customers (including those with existing VPNs) make decisions about buying advanced VPN technologies. Lisa explains how to sell a new SSL VPN concentrator to a customer who already has a firewall/VPN, the effects of cloud computing on solution providers that sell VPNs, and much more information to ensure that you understand how to sell advanced VPN technologies.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
You must have Adobe Flash Player 7 or above to view this content.See http://www.adobe.com/products/flashplayer to download now.
Download for later:
Lisa Phifer: How to sell and market VPN services to a customer
• Internet Explorer: Right Click > Save Target As
• Firefox: Right Click > Save Link As
•How would a VAR sell a new SSL VPN concentrator to a customer who already has a firewall/VPN?
•For VPNs with both browser- and client-based access, why would anyone use the client-based method?
•How can VARs determine which kind of VPN is the best fit for each customer's applications?
•Enterprise customers are asking a lot of questions now about endpoint security. How can VPN offerings address these concerns?
•How can VARs capitalize on customer interest in network access control to sell more VPN solutions?
•Can mobile smartphones like iPhone and BlackBerry be integrated into existing VPN solutions?
•Are there new VPN solutions that can better satisfy mobile workers that roam between customer and carrier networks?
•Is Software as a Service a threat or opportunity for VARs that sell VPN solutions?
How would a VAR sell a new SSL VPN concentrator to a customer who already has a firewall/VPN?
New SSL VPN concentrators are creating competition for both integrated firewall/VPNs and conventional IPsec VPN concentrators. Most analysts say that SSL VPN is fast becoming the dominant solution for remote access. I've worked with many companies that have either used SSL to replace an older IPsec VPN concentrator or have shifted much of their workforce onto a new SSL VPN concentrator.
The most visible advantage of deploying an SSL VPN is avoiding VPN client installation and configuration. SSL VPNs use the Web browsers already found on nearly every remote device as a launch point. Most SSL VPNs do use a little bit of client software, but they push it to the device as needed, over the secure browser session. Avoiding installed clients not only reduces VPN total cost of operation, it makes remote access possible for devices and users that just could not be satisfied by IPsec -- for example, teleworkers connecting from home PCs, consultants who require access from their own laptops, or field workers connecting from behind a customer firewall that does not permit IPsec pass-thru.
Customers who buy an SSL VPN concentrator often ask: Do I still need my firewall/VPN? The answer is absolutely yes -- that investment is still very worthwhile. An SSL VPN concentrator does not firewall, so it must be protected by a separate firewall. In addition, most companies still need integrated firewall/VPNs to secure interoffice traffic using site-to-site IPsec tunnels.
For VPNs with both browser- and client-based access, why would anyone use the client-based method?
IPsec VPNs started with installed clients but lost favor when customers realized that there are many users who didn't really need clients in order to get their jobs done. SSL VPNs started with browser-only access, but most products ended up adding bits of client-side software to support more and more applications.
In the end, I think most customers really want a single VPN concentrator that's flexible enough to support multiple methods. That way, VPN admins can decide which method each user needs and deserves, and they can easily change their minds later, while still bringing all users in through a common network entry point to simplify access control and auditing.
Workers that really need installed clients are those who use more demanding bidirectional applications -- VoIP is a common example. They can also be employees who require broad access to many destinations inside the private network, such as database and system administrators. Finally, it is not unusual for companies to extend browser-based access to new users but leave existing users with installed clients alone -- at least initially.
How can VARs determine which kind of VPN is the best fit for each customer's applications?
IPsec VPNs are the clear choice for secure site-to-site communication, independent of application. The more difficult question is how to map remote user applications onto IPsec and/or SSL VPN access methods.
IPsec VPNs can support any IP-based application. But SSL VPNs can actually offer up to four methods: simple Web proxies, application translators, port-forwarding agents, and network extension clients.
- Simple proxies are great for applications that have Web front ends, like webmail or enterprise application portals.
- SSL VPN translators can do more, but a specific translator must be created for each application. Most products include translators for common business applications like enterprise mail, file sharing and remote terminal sessions. However, translator plug-ins must be developed to support less common or proprietary applications.
- Port-forwarding agents treat every application the same way. That means they can support most user-initiated TCP client/server applications. However, they often require the user to have admin rights.
- Finally, like IPsec clients, SSL network extension clients can tunnel any IP-based application. These clients are needed to support server push and real-time applications, but that requires installed software.
VARs must understand that all SSL VPNs are not alike. Work closely with your VPN vendors to understand the applications they can support and the limitations of each access method offered. When in doubt, ask your vendor whether it has actually tested the specific applications and versions required by a customer.
Enterprise customers are asking a lot of questions now about endpoint security. How can VPN offerings address these concerns?
VPNs make it possible for remote sites and users to become an integral part of a private network, independent of location. But doing so adds risk. If a remote user's device happens to be infected with a virus, worm or trojan, those network-borne threats can ride the VPN tunnel right into the private network.
Most contemporary VPN concentrators incorporate features intended to mitigate these risks. For starters, many can run an endpoint security scan when the VPN tunnel is launched. If required endpoint security programs are running and up to date, the VPN tunnel is allowed. If not, the VPN tunnel is either denied or users are routed to a quarantine server where they can obtain missing software or patches.
Next, during a VPN session, granular role-based policies can be used to limit what the user can do -- for example, giving someone on a home PC very narrow access to email and nothing else. In this way, an infected endpoint might not be able to penetrate the network or steal very much sensitive information.
Finally, after the session, most SSL VPN concentrators have the ability to clean up after themselves by removing temp files, wiping the browser cache, deleting cookies and closing the browser window. This isn't endpoint security per se, but it can help to avoid accidental data breach when VPNs are accessed from public or multi-user endpoints.
Today, many businesses are interested in using network access control (NAC) to stem the rising tide of malware, tighten their grip on network use by visitors and contractors, and document activity for regulatory compliance and audit purposes. Popular NAC architectures defined by Microsoft (Network Access Protection), Cisco (Network Admission Control), and the Trusted Computing Group (Trusted Network Connect) focus largely on controlling local network access. But all can be integrated with remote access VPN platforms, creating new marketing opportunities for VPN VARs.
Mobile wireless devices have blurred the line between local and remote access -- the same notebook may well be connected at the office, at home and at a business center. In each case, employers require the same control over who is permitted to access the corporate network, under what pre-conditions, and to reach which resources. VPN clients and access concentrators can play critical roles in NAC authentication, endpoint assessment, authorization and policy enforcement. For example, many VPN clients now have the ability to query OS patches, antivirus/personal firewall status, and registry settings at connect time, letting the VPN access concentrator take the endpoint's "health" into consideration when granting access to selected systems and services.
Talk to your VPN platform provider to get a handle on support for popular NAC industry architectures and specific features like endpoint assessment and automated remediation for infected or non-compliant endpoints. You will probably be able to incorporate NAC into your remote access VPN portfolio as a value-added service simply by leveraging features already present in your VPN platforms and making them available to customers.
All major smartphone operating systems -- Symbian, Windows Mobile, BlackBerry, iPhone, and Palm -- can now be integrated with IPsec VPNs. Contemporary Symbian, Windows Mobile, and iPhone 3G devices have embedded IPsec clients that let them be connected to many enterprise IPsec VPN concentrators. Certain BlackBerry smartphone models (for example, the 7270) provide embedded IPsec support. And Palm smartphones can be integrated with IPsec VPNs by adding a third-party VPN client like AnthaVPN.
It is important to realize, however, that smartphone IPsec clients may not dovetail with existing IPsec VPN policies or client management practices. For example, a smartphone IPsec client may not support the kind of authentication used by your standard VPN offering, and VPN policies may need to be copied onto smartphones manually instead of being pushed to a notebook using a domain login script or enrollment portal. Therefore, smartphones should be added to your list of supported VPN client platforms only after considering how they will actually fit into your provisioning, maintenance and monitoring practices.
Notebook users that connect to a business VPN from their home, hotel or customer site tend to do so while stationary -- they sit down, connect to a LAN, tunnel into the VPN, do their work, then disconnect. However, mobile workers that carry tablets, smartphones, PDAs and ruggedized notebooks are more likely to need continuous connectivity -- doing their job while actively moving from hotel to train to destination. Accommodating the latter requires more than a static VPN tunnel, bound to a single IP network. Truly mobile workers need persistent connectivity that can survive network roaming and the "dead spots" encountered in between.
IPsec and SSL VPN tunnels disconnect whenever the VPN client's IP address changes. When roaming completes quickly, SSL tunnels may resume with little disruption. But traditional VPNs do not handle lengthy loss of connectivity like Mobile VPNs. Vendors such as BirdStep, Columbitech, NetMotion, Radio IP, and Smith Micro offer Mobile VPN products that assign each client its own virtual IP address that remains constant, independent of network connectivity. When a Mobile VPN client goes out of range or falls asleep, application traffic may be queued up for later delivery, without requiring the user to reconnect or re-authenticate. Adding a Mobile VPN platform like this to your VPN solution portfolio can help you attract customers whose remote access needs are not fully met by traditional VPNs.
Many companies are now being drawn to Software as a Service (SaaS) or "cloud computing" as a way to eliminate capital equipment investment, reduce operating and maintenance costs, and increase business agility. By paying for the right to use a hosted service instead of deploying a service in-house, companies believe they can pay for only what they really need and actually use at any given time, letting their provider do the heavy lifting required to build, deliver, maintain and troubleshoot the service.
But SaaS is not really a new business model for VPN VARs -- VPN solutions have been delivered this way for many years by managed security service providers (MSSPs). For example, many MSSPs are willing to install VPN remote access concentrators on-site at a customer premise or in their own data center, as a hosted platform. Some MSSPs go a step further, using a shared data center platform to deliver VPN services to many customers -- this is effectively the SaaS or cloud computing model, applied to VPN.
VPN VARs that deploy only customer premise VPN platforms (VPN/firewalls or remote access concentrators) may want to consider adding managed VPN services to their portfolio. However, running a customer's VPN requires much more than installing and provisioning a VPN device -- if this is not your forte, consider partnering with an MSSP that has the infrastructure and security expertise to deliver VPN services. Many MSSPs have partner programs that VARs can join to deliver sales leads and earn revenue.
About the author
Lisa Phifer is president of Core Competence Inc., a consulting firm specializing in network security and management technology. Phifer has been involved in the design, implementation, and evaluation of data communications, internetworking, security and network management products for nearly 20 years.