In-Depth

Private and Secure: The VPN Solution

If you want a better way to connect remote users, offices and servers securely, consider the humble, easy-to-implement virtual private network. Here’s how to make it work in Windows 2000.

• By Anil Desai
• March 29, 2001

Recently, we had a “snowstorm” (in Texas, that means the temperature dropped below 50 degrees), and many of our employees decided to work from home. The ability to access all of our LAN resources with our laptop machines really helped productivity. Similarly, you can use a VPN to allow your remote users and branch offices easily and securely to connect to your LAN. Better yet, the cost savings may be dramatic, and you can set up a basic VPN in just a few hours! In this article I share how to do so in Windows 2000.

What Is a VPN?
A VPN, or virtual private network, allows you to transfer information securely over a potentially insecure network. VPN connections generally manage authentication between servers and clients and handle data encryption for the connection. However, you can implement a VPN in many different ways—using several types of protocols and standards.

But why would you want a VPN in the first place? Several years ago this might have been a tougher sell. Dial-in solutions may have met your users’ needs and leased lines let you connect your remote offices. For example, you might have set up a bank of modems to which your remote users could dial in from home or while on the road. Of course, if you’ve used those solutions, you know about their shortcomings:

• Difficult administration. Modem banks and leased network links often come with a large amount of administration overhead. For example, analog modem banks generally use proprietary technology.
• High costs. Leased lines are generally much more expensive than Internet connections, and they can be difficult to implement and administer. For dial-in solutions, serial port concentrators and analog modem ports are also expensive. Also, CFOs rarely like to see the amount of money spent on long-distance charges or 800-number dial-ins.
• Limited support for technology. If your organization only supports dial-up connections via analog modems, users with faster connections (such as cable modems or xDSL solutions) will be stuck in the slow lane when it comes to connecting to your LAN. Just because it’s called a cable “modem” doesn’t mean it can connect back to your analog modem bank!
• Inconvenience. In order to use dial-in solutions, users have to configure their modems and operating systems to make remote connections. For analog modems, each connection can take more than 30 seconds (a time that many users find unacceptable). Plus, there’s the possibility of reaching busy signals at peak times.
• Hardware failure. Oftentimes, individual analog modems just plain blow up. This can be a nightmare if they’re heavily used and/or depended upon.

These problems tend to be large and costly. However, new network technologies often depend on better connectivity between your machines. For example, Win2K’s Active Directory requires connectivity between all of your domain controllers in order to work optimally. Although you could connect all of your branch offices and remote locations with dedicated leased lines (such as T1 connections), this can be prohibitively costly and difficult to set up. There must be a better way!

Fortunately, VPNs alleviate many of these obstacles. However, you’ll still need to address other issues about using the Internet for secure data communications, including security, reliability, scalability and performance. Let’s look at how you might want to design and deploy a VPN for your environment.

Making the Connection
The purpose of a VPN is to secure your network communications across another network. There are two broad categories of VPN connections, often referred to as “tunneling” mechanisms:

• Voluntary tunneling. Remote access users generally create voluntary tunnels directly with a VPN server. This case is best illustrated by a notebook computer user who already has an Internet connection, say, via cable modem or dial-in to a local ISP. The user simply “dials up” a VPN server via the Internet to create a secure, encrypted connection. The VPN isn’t actually dialing, but, indeed, this is how it appears to the user.
• Compulsory tunneling. You may want to implement the features of a VPN transparently for your users. Compulsory tunnels are often set up between two VPN servers that act as routers for all network traffic. As with switching or routing, clients may not even be aware that their data is traversing a secure, encrypted connection. This type of tunnel is useful for connecting a central office to remote offices, each with its own network. Compulsory tunnels can also be created in an outsourced fashion by which an ISP handles all data encryption between its Points of Presence (POPs). Clients and servers simply “dial in” to this network as they normally would, and the ISP handles the rest.

Figure 1 shows the voluntary and compulsory tunneling scenarios. Both types of VPN connections can be used in various ways.

Figure 1. A comparison of compulsory and voluntary VPN tunnels. Voluntary tunnels are created between a client and a server, whereas compulsory tunnels are created between two servers that act as secure routers. (Click image to view larger version.)

A Typical VPN Scenario
When considering the implementation of any technology, it’s important to consider the real goals of a VPN solution. Let’s look at a simplified example of some situations where a VPN might be useful.

Here’s a classic situation: You’re supporting a distributed company. For the most part, your servers and most of your users are located in a central office. However, you have several users working out of remote offices. Some of these “offices” consist of only one sales representative while others may have hundreds of employees. You need to offer all of your users connectivity to the network, but the cost of licensing leased lines for each of them is expensive. In this case, a VPN could reduce costs and make the job quite easy. A simple solution might involve four broad steps.

First, obtain Internet access for each of the remote offices. These connections can range in speed from dial-ups (for locations that support few users or that may require access to only corporate messaging systems or an intranet) to much faster connections such as T1 lines (operating at about 1.544 Mbps). Remote users can use any form of Internet connectivity, including analog dial-up lines (everyone’s favorite!), ISDN, xDSL and cable modems.

Second, set up a VPN server at your central office. This sets the stage for others to join your party.

Third, for larger offices, implement a VPN server at the remote office. Configure this machine to create a server-to-server VPN connection between your main office and your branch office (in Win2K, this could be a persistent connection or one created on demand). The benefit is that your users don’t need to be aware that they’re using a VPN connection. It’s all handled at the network level. This is a good example of a compulsory tunnel. You may want to use a persistent connection if you’re on an “all-you-can-eat” plan with your ISP. Choose an on-demand connection if you’re on a “pay-as-you-go” plan with your ISP and wish to save some money.

Fourth, for smaller offices and for traveling or remote users, you might choose to have your users directly create a connection with their local VPN server. Provided that they have Internet access, they can create a VPN connection directly with the central corporate VPN server or a VPN server closest to them.

When you’re finished with this configuration, you’ll have created a voluntary tunneling situation. Figure 2 provides a high-level overview of what such a network might look like. Now, let’s look at how you implement the VPN.

Figure 2. A typical VPN scenario using VPN servers and clients. (Click image to view larger version.)

Protocols and Standards
If you’ve given some thought to transferring your sensitive company data over the Internet, it’s likely that you already know two of the requirements for VPNs: authentication and data security (encryption). Here’s where it starts getting confusing. Unlike the situation of just a few years ago, you can choose from several VPN protocols. The good news is that these protocols are standards. The bad news is that you have to understand the strengths and weaknesses of each.

• Point-to-Point Tunneling Protocol. Microsoft and other industry partners originally introduced PPTP with the release of Windows NT 4.0 (think way back to August 1996). It currently has widespread support on all current versions of Windows as well as some third-party solutions.
• Layer 2 Forwarding. Cisco’s answer to the VPN problem was its hardware-based L2F protocol. L2F was designed to allow Cisco routers to form secure connections over the Internet or other IP-based networks.
• Layer 2 Tunneling Protocol. Developed as the best parts of both PPTP and L2F, L2TP allows for strong security, protocol independence and for flexible authentication mechanisms.
• Internet Protocol Security. The next version of TCP/IP, IPv6, will support a mechanism for securely transferring data. The IPSec standard defines methods for communicating between servers and clients, but it lacks standard support for authentication mechanisms. Furthermore, IPSec can be difficult to configure for simple client-side access and is currently used mainly for server-to-server connections. However, look for IPSec to become increasingly common as the standards continue to mature. [Read Roberta Bragg’s two-part “Security Advisor” series on IPSec in the March and April issues.—Ed.]

But wait, there’s more! You can use a combination of L2TP and IPSec to get the best of both worlds (authentication support and strong security, respectively). And some VPN servers (such as Win2K) support the use of multiple VPN protocols at the same time. For example, some clients can connect using PPTP, while others connect using IPSec. A complete, in-depth analysis of these protocols is outside the scope of this article (this magazine would get pretty heavy if we started discussing packet structure). However, Table 1 provides an overview of the various features of each protocol.

If you need compatibility with various Windows-based clients, PPTP is a good basic choice. It’s important to remember that if you create a “compulsory tunneling” VPN, client and server support may be a non-issue. That is, since the VPN servers act as routers and handle encryption and authentication for all data, the clients on your network need not even know this is happening (read: no reconfiguring desktop machines on your internal network!). Windows servers can support up to 256 logical VPN connections. NT Workstation and Win2K Professional only allow a single inbound VPN connection at a time. As shown in Table 1, you now have several choices when determining what protocols to support in your environment.

Table 1. Comparing features of VPN protocols.

Protocol	IETF RFC # (see www.ietf.org)	Windows server-side support	Windows client-side support	Pros	Cons
PPTP	2637	NT 4.0, Win2K	Windows 9x/ME/NT 4.0/2000	Most compatible; quick to set up; easy to implement and administer	Not the most secure
L2F	N/A	None - hardware solution	N/A (encryption is handled at the network level, transparent to clients)	Can be set up without client reconfiguration	Hardware-only solution; supports IP traffic only
L2TP	2661	Win2K	Win2K	Protocol-independent; includes authentication mechanisms	Supported only on Win2K clients
IPSec	2401 - 2409	Win2K	Win2K	Provides strongest security; part of IPv6 specification; potential cross-platform support	Most difficult to set up; lack of complete interoperability between vendors
L2TP/ IPSec	See RFCs for L2TP and IPSec	Win2K	Win2K	Provides strong security (IPSec) plus authentication mechanisms (L2TP)	Difficult to set up

In general, I’d recommend starting with PPTP (if you need to support non-Win2K clients) or L2TP (if you’re a pure Win2K shop). Both protocols are quick and easy to set up using wizards, and client configuration is simple. If your environment needs more security (at the expense of ease of administration), look into an L2TP/IPSec solution. You’ll get stronger security for data transfers plus L2TP’s authentication mechanisms. Beware that setting up IPSec can be challenging—so be sure to do your homework and make sure it’s worth the effort for your business.

Implementing Your VPN
OK, so we’ve looked at some of the choices you need to make when planning for a VPN and examined a few possible connection scenarios. The next step, of course, would be to implement the solution. In the remainder of the article, I provide a quick overview for setting up a simple PPTP-based VPN using Win2K Server and Professional machines. The overall process is quick and easy. (I often set up clients and servers in my presentations in less than 10 minutes.)

Set Up the Server
Obviously, you must begin with a machine that meets the minimum system requirements for Win2K Server. In addition, your machine must have two physical network connections: one with a network connection to your LAN and another with a connection to the Internet. The VPN server will be responsible for routing between the two “networks.”

To start configuring a Win2K VPN server, you’ll need to access the Routing and Remote Access (RRAS) admin tool. The RRAS admin tool is used to set up and configure advanced networking features on your server. If it hasn’t already been configured, you can easily set up your server to allow VPN connections by right-clicking on your server name and selecting “Configure and enable routing and remote access.” You’ll see the handy wizard shown in Figure 3.

Figure 3. The wizard you use to set up routing and remote access is available by right-clicking on your server name in the Routing and Remote Access Administrative Tool.

The wizard will walk you through the steps you’ll need to complete in order to configure your server. Note that if the RRAS server has already been configured, you’ll no longer be able to use the convenient wizard interface. Instead, you’ll need to access the property sheets for the various configuration options.

When you configure your VPN server, there are several decisions to make. First, you need to choose which protocols you plan to support. The list will include any protocols currently enabled on the server, but there’s a good chance you’ll want to use TCP/IP. If you tell the wizard that not all of the protocols you plan to support are installed, it kindly tells you to install them and then come back when you’re really ready. Next, you’ll have to choose an adapter for your Internet connection. (Remember, it must have separate LAN and Internet network interfaces.) Generally, the decision will be easy. The VPN service should be configured to use the server’s Internet connection. For example, if you have one network adapter that connects to your LAN and another that connects to a T1 router (which, in turn, connects to your ISP), you’ll want to configure the VPN server to listen on the network interface that’s connected to the T1.

With the basic settings out of the way, it’s time to look at configuration options for the client. The main choice is to determine how clients will receive their IP addresses. You have two methods. First, you can use the Dynamic Host Configuration Protocol (DHCP) to assign IP address information. In this case, you can use a DHCP server that has already been configured on the network, or you can set up the local server to act as a DHCP server. One important consideration is that you must make sure that remote clients will have access to the DHCP server. That is, if your VPN server is sitting on a different subnet from the DHCP server, you may need to configure a DHCP Relay Agent or reconfigure your routers to allow BOOTP broadcasts. If you need help in making the necessary choices, be sure to refer to the resources in “Additional Information.” The simpler (though more-difficult-to-administer) solution is to create a static set of IP addresses. The VPN server will simply choose addresses from this pool and assign them to clients. Once you make this decision, all that’s left to do is click on Finish to configure the VPN server.

Once the basic options for a VPN server have been configured, you’ll see several changes to the Routing and Remote Access administrator tool. First, you’ll be able to expand the local server and see configuration options. For the purpose of VPNs, the most relevant is the presence of new “Ports” (see Figure 4).

Figure 4. Viewing logical ports configured for the VPN service in the Routing and Remote Access administrative tool.

The Ports container holds one item for each logical port you have configured on this server. By default, the wizard creates multiple “WAN Miniports” (for both PPTP and L2TP connections). Additionally, you’ll see any other ports (such as modems or the ever-popular direct cable connection) that you might have configured on this machine. To monitor a port, you simply right-click on one and choose the “Status” option. This provides you with details about the usage statistics of a connection. Remember that the total number of logical ports you have configured will be the maximum number of simultaneous connections your server will allow.

Other areas of interest in the RRAS admin tool include the following:

• Routing Interfaces. This section will provide one item for every available network interface on the machine. If you’ve enabled routing for any of these interfaces, you can view details about the configuration by right-clicking on one of the items and choosing Properties. The details of configuring routing are beyond the scope of this article, so if you need help, be sure to check out the RRAS help file.
• Remote Access Clients. This section shows you all of the people that are currently connected to your remote access server (including VPN connections). From here, you can easily identify who’s connected, how long they’ve been connected and how much data they’ve transferred. You can also drop stuck connections from here.
• IP Routing. If you’re configuring static or dynamic routing, this is the place for you to configure the RRAS service and to create your route assignments. Note that you can also configure the DHCP Relay Agent here. Again, the details of routing are beyond the scope of this article.
• Remote Access Policies. This useful icon lets you configure various security options for remote users. For example, by default, there’s a master switch for whether or not you allow users to connect to this remote access server. The specific options will vary based on whether or not the VPN server is the member of an Active Directory domain.
• Remote Access Logging. This is a very useful option for tracking the action that your VPN server is seeing. By viewing the properties of the log file settings, you can specify exactly what types of actions are logged and where the log file is stored. This is handy when you’re troubleshooting connectivity or trying to get a better handle on the usage of your VPN servers.

Finally, you can right-click on the name of your local server and select Properties to view the main configuration information about this machine. Figure 5 shows the General tab from which you can configure the “master switch” for VPNs.

Figure 5. Viewing the General properties of a RRAS server using the RRAS administrative tool.

If, for example, you want to disable all VPN-based access to this server temporarily without losing your configuration, simply uncheck the “Remote access server” box. As you can see, the RRAS admin is “command central” for managing your VPN, and it will become your best friend when you need to monitor and troubleshoot VPN issues.

Increase Server Security
Invariably, when discussing VPNs and tunneling over the Internet, the most common concerns I hear involve security. Fortunately, you have several additional options for increasing the security of your VPN solution. The list of features includes:

• Active Directory-based security. VPNs may be relatively new technology, but the same basic rules regarding user accounts and security still apply. Your best bet in a Win2K environment is to take advantage of the features of AD for ensuring only authorized users can get to your network. So, don’t forget about good password policies and account policies—there’s little administrative cost, and you’ll get a lot of additional security.
• Remote Authentication Dial-In User Services support. RADIUS allows multiple remote access servers (such as a VPN server) to communicate information about connected users. It’s important because it lets you manage your remote access user accounts centrally and allows for centralized logging of remote access connection information. Consider investing in RADIUS-based solutions when you’re supporting a large number of remote users (hundreds of concurrent connections), when you have multiple remote access servers and when centralized management is worthwhile.
• Authentication mechanisms. In addition to standard password-based security, you can take advantage of biometric devices, smart-cards, and two-factor authentication token cards (such as the SecurID system from RSA Security Corp.). Also, Win2K can take advantage of the Extensible Authentication Protocol (EAP), which means it can tap into other third-party authentication schemes. If you want to avoid password-based security (and all of the potential hassles associated with it), consider looking into biometric solutions (such as fingerprint scanners) and token authentication schemes. Know, however, that you’ll probably need to absorb some short-term expenses.
• Group Policy settings. You can use Group Policy settings (in AD environments) or Local Security Policy settings to restrict access to your VPN servers. By default, the security settings are quite liberal—basically, they don’t put very strong restrictions on user accounts, passwords and auditing. You’ll probably want to make several configuration changes from the defaults to enforce stronger passwords. You’ll also want to audit, at the very least, successful and failed logons and logoffs. It doesn’t take a lot of effort, and you’ll be able to sleep better at night knowing that common causes of network intrusion have been reduced.
• Integration with AD. You can administer settings for remote users from the comfort and security of your AD administration tools. Furthermore, you can configure AD Sites and Services to use your VPN connections. Just treat your VPN connection like you would any other dial-up or standard network connection. If you plan to change the settings from their defaults, it’s a good idea to keep in mind the speeds of your underlying Internet connections.
• Network design. A VPN server can be configured to exist inside, outside or as part of your firewall solution. The most common solution is to place the VPN server outside the firewall. For the utmost security, you’ll probably want to ensure that your VPN server isn’t running any additional services. For example, you would probably want to disable IIS on that machine. Then, if the VPN server is compromised, you won’t risk losing any data stored on that machine.
• Network-level security. Windows-based servers support packet-filtering of TCP/IP connections. This can be useful for preventing certain types of traffic from entering your network. For example, on the public interface of your VPN server, you might choose to restrict all traffic except data transferred through the VPN connections. That way, you can avoid common methods of denial-of-service attacks and prevent issues related to known vulnerabilities of Web, FTP, mail, telnet and other services. It’s important to remember that technology is only part of the solution. Make sure users are educated in the value of strong passwords and good security practices.

Set Up The Clients
The process used to set up Windows 95/98/Me, NT 4.0 and Win2K clients is fairly straightforward. However, the exact steps you need to follow differ somewhat based on which operating system you’re dealing with. Fortunately, Microsoft has made it easy to set up VPN clients. Most users could go through the necessary steps in less than 15 minutes or so. Here’s the two-step process to connect clients to servers:

1. Establish Internet access. This may be through a LAN, broadband or dial-up connection. The point is that the user must have access to the Internet—it doesn’t matter how.
2. Connect to the VPN server. The second step involves “dialing” another connection to the VPN server. Instead of using a phone number, however, the connection will use an IP address (or DNS name, if it’s available) for the server. In Win2K Professional, you simply set up a standard dial-up connection. Right-click on the My Network Places icon and choose Properties. Then select, “Make New Connection.” This will begin the Network Connection wizard (see Figure 6).

Figure 6. Using the Network Connection wizard to create a VPN connection.

Choose the option to “Connect to a private network through the Internet.” You’ll be prompted for the IP address or DNS name of the remote VPN server. You’ll also have the option of first connecting to the Internet via another network connection before creating the VPN connection. This is especially useful if your clients will be using dial-up Internet connections since it allows single-click access to your VPN. When the connection has been created, you should be able to “dial” it like any other. Note that this new form of connectivity doesn’t come for free — there’s also a potential security risk. For details, see “Mitigating Security Risks.”

Test the VPN
OK, so far you’ve set up the VPN clients and servers. Now, it’s time to test the solution to make sure it works properly. Fortunately, this should be pretty easy to do. The first step would be to try to connect to your server from a client machine located across the Internet (that is, not on your LAN). If the connection doesn’t succeed at first, you need to determine whether the problem comes from the client side or the server side. The easiest way to determine this might be to test the creation of a VPN connection on your LAN. Connect both the client and server to the same subnet and see if they can connect to each other that way. If they can, then the problem might be related to a connectivity issue (such as a firewall that’s in the way, which I’ll discuss shortly).

If you’re unable to create a VPN connection between your machines when they’re connected to the same LAN, then it’s time to verify the configuration. If the client can connect to the VPN server, but can’t access some (or all) network resources, then check to see if they have the appropriate network configuration (this is most easily done by running IPCONFIG from the command line). If the network configuration looks good, put on your standard TCP/IP troubleshooting hat. First, find out if the issues are related to name resolution. That is, does connecting via IP addresses work while connecting by machine- or DNS-name fail? If so, make sure your DNS (and WINS, if you support it) configuration is working properly. Remember that clients can resolve some names via broadcasts, even without the proper name resolution set up on a LAN. But when working over a VPN connection, your organization’s routers may not allow broadcasts to be transferred between subnets. Also, be sure to verify that your users have appropriate permissions to log on to the VPN server and access specific network resources.

Still stuck? Read on for more information on troubleshooting...

Tips, Tricks, Troubleshooting and Gotchas
Remember, your VPN server must be accessible to users from the Internet. It’s often advisable to create a public DNS entry for your VPN server so users can connect to a server such as “vpn.mycompany.com.” Some may see this as a potential security problem, but remember that you’re creating a DNS entry for an IP address that’s already publicly available (that is, in general, “security through obscurity” isn’t a good practice). Here’s a common issue: You’ve set up your VPN client and server properly, but they’re still unable to connect with each other. Or, more commonly, you can create a VPN connection on your LAN, but clients from outside the network can’t connect. The issue may have to do with network-level security. Technically, you can configure a VPN server to be inside, outside or part of your firewall. There are several different considerations that might make you choose one idea over the other. Regardless, your firewall must allow the passage of VPN information between clients and servers. Table 2 provides a brief summary of the types of traffic you’ll need to permit for use with each type of VPN protocol.

Table 2. Firewall configuration requirements for VPN protocols.

Protocol	Communication methods	Notes
PPTP	TCP Port 1723; IP Protocol 47	Both types of traffic must be allowed for a successful connection.
L2TP	UDP Port 1701	The port number can be reconfigured.
L2TP/IPSec	UDP Port 500; IP Protocol 50	Port numbers and assignments can vary among different implementations. The exact details related to configuring your firewall will vary depending on your firewall implementation.

Remember that even basic routers can provide some functionality of firewalls (such as port- and packet-filtering). However, the basics are pretty much the same. The bottom line is that your VPN clients and servers must be able to communicate using the appropriate IP ports and protocols, or you won’t be able to create the connection.

Additional Information

Mitigating Risks Although, in general, network connectivity for remote and traveling users is a good thing, it comes with risks. Remember that when you create a connection to your LAN resources using a VPN, you’re opening up a whole new avenue onto your network. That is, if someone were to compromise the security of your VPN client, he or she might be able to use that information to access your company’s network. A simple setting like a cached password or a machine that has been left logged-on can provide potential hackers with the opportunity they need. Fortunately, several solutions are available. Personal firewalls are an important feature that can greatly reduce the chances of network-based attacks against your home-based and remote users. It’s so important, in fact, that Microsoft is building this technology into its upcoming Windows XP products. For current clients, solutions such as Zone Labs’ ZoneAlarm (www.zonealarm.com) might do the trick. Another potential solution might be to use a device that performs Network Address Translation (NAT) functionality, such as products from Linksys (www.linksys.com). Not only do these devices allow you to share a single Internet connection with multiple machines, but they also provide a reasonable level of security by reducing the exposure of your internal network to the Internet. As well, it’s important to find and understand your vulnerabilities. A good way is to use the ShieldsUp! Web-based test (which can be performed from www.grc.com) to check potential vulnerabilities of your VPN clients by scanning for open and responding ports and looking for shared resources. Finally, no security plan is complete without laying down (and enforcing) the rules. Be sure your users understand the importance of strong passwords. And, don’t trust that they’re creating them—use password-cracking tools to enforce the quality of passwords. Also, be sure your users understand the potential risks of sharing passwords (or even sharing machines, such as laptops, which may contain cached passwords). All of these measures are vital to keeping your network virtually private! More Resources Internet Engineering Task Force (www.ietf.org) for detailed information about standards and protocols. The Microsoft Windows 2000 Web Site (www.microsoft.com/Windows2000), which contains these useful articles: “VPNs and Network Address Translators,” “VPN Security,” “Troubleshooting VPNs,” and “Supporting Windows 2000 VPNs/Interoperability.” The Microsoft TechNet Networking and RAS home page at www.microsoft.com/technet/treeview/default.asp?url=/technet/itsolutions/network/Default.asp Microsoft’s public newsgroups (microsoft.public.win2000.ras_routing and microsoft.public.windowsnt.protocol.routing) at nntp://news.microsoft.com.

Virtually Private, at Last
If you’ve been able to hang with me so far, there’s a good chance that you know pretty much everything you need to get started implementing a VPN. Once you’ve done it a few times, you’ll be able to configure a VPN client and server in less than 10 minutes. It’s likely that you’ll need to monitor and enhance security and performance based on the needs of your organization. However, pitching VPNs to your management should be a quick and easy sell (think quick ROI, low TCO) as well as a great benefit for system administrators and users alike. May your sensitive information always remain private and secure!