This section describes the various configuration decisions you must make before configuring a VPN and explains the options available for each decision. In some cases, examples are provided to explain the options. This section describes the following types of options:
This section provides examples of the following site-to-site configuration options:
In this example, the company has offices at two remote sites: San Jose and Athens, as shown in the following figure. The Finance and corporate offices are in San Jose, and the Accounting office is in Athens. Both offices must share data without allowing other users to access the data from within the company or through the Internet. At both sites, the VPN server is connected directly to the Internet and is being used as the border server.
Compared to the other two site-to-site configuration options, this option has the advantage of requiring only one machine per site to provide both the connectivity of a VPN and the protection of a firewall. Also, when the firewall and VPN are on the same machine, it is easier to administer them. When the firewall and VPN are on different machines and different operating systems, more than one administrator might be needed to manage both machines.
The disadvantage of this configuration, however, is that it has a single point of failure. This configuration also impacts performance for users who want to send unencrypted data to other networks without using the VPN.
For this configuration, you should implement basic filtering using TCP/IP RIP filters and TCP/IP packet forwarding filters. Basic filtering is automatically configured during installation if you select Setup Novell BorderManager 3.7 for Secure Access to the Public Interface during installation. To configure filters manually, refer to the packet filtering online documentation.
In this example, the master VPN server for the Finance office in San Jose is behind a firewall server that is connected to the Internet. Both offices are sharing data that must be encrypted and sent through a VPN tunnel.
The public IP address and subnet mask for the VPN server are part of a local network. The firewall has an IP address of 200.20.176.12 for the Internet connection. The master VPN server has a public IP address of 220.150.17.65. The local network is using a subnet mask of FF.FF.FF.C0. The slave server in Athens is connected through an ISP. The public IP address and subnet mask are 135.145.188.25 and FF.FF.FC.0, respectively.
Compared to the other two site-to-site configuration options, this option has the advantage that the VPN node is better protected against attack from the outside. You can also choose which machine to use as a firewall, resulting in the best protection and control of your network resources. Installing the VPN on a high-speed machine separate from the firewall also enhances the performance of both firewall activities and encryption and decryption traffic flow.
The disadvantages of this configuration are that two machines are required and the administration of two machines is more difficult. With the firewall and VPN on different machines and different operating systems, more than one administrator might be needed to manage both machines.
In this example, the Finance and Accounting servers in San Jose are on the corporate intranet or private network. Both departments are sharing data that must be encrypted and sent through a VPN tunnel.
In this scenario, access to the Internet and an ISP are not required, just IP connectivity between the master and slave servers. The master server has a public IP address of 135.27.180.1, and the local network is using a subnet mask of FF.FF.FC.0. In this example, the master and slave servers must use different subnet addresses because they are on different LAN segments. The slave server has an IP address of 135.27.184.1 and a subnet mask of FF.FF.FC.0.
Although not shown in this example, the VPN nodes could also be joined using a point-to-point connection and would have the same network address.
Compared to the other two site-to-site configuration options, this option has the advantage that it allows work groups to protect the privacy of their data from other users within a corporate LAN or WAN intranet. Because 80 percent of all attempts to compromise network security originate from within intranets, this benefit is significant.
The disadvantage of this configuration is that protected work groups must be behind a machine running Novell BorderManager 3.7. Therefore, additional equipment might be required and performance probably is impacted.
Two methods are available for determining which private networks are protected by a VPN:
These options and their advantages and disadvantages are as follows:
This option eliminates routing traffic in the VPN tunnel, making more bandwidth available for data transfer. Static configuration also eliminates routing loops and enables the administrator to better control which networks are granted access to the encrypted network. The use of a static list ensures that access to the VPN is limited to specified networks and that the data in the tunnel is always encrypted. However, a static list must be entered manually and requires more administrative overhead.
This option does not require administrative overhead to configure updates when changes to the network topology occur. However, this option does require that a RIP filter is configured to block unwanted routes. More important, if the encrypted tunnel goes down, data might be sent unencrypted.
Static routes between VPN servers are required in the following situations:
The version of VPN software that you use determines which encryption and authentication methods are available. Because encryption software is subject to export restrictions, U.S. export laws determine which version can be purchased in any given country. The following two versions are available:
The encryption schemes included in each version of the VPN software are listed in Table 1, VPN Encryption Methods in order of priority, from highest to lowest. The authentication schemes included in each version of the VPN software are listed in Table 2,
VPN Authentication Methods in order of priority, from highest to lowest. The priority of the schemes configured for both ends of the VPN connection is one of the factors used to determined which scheme is used in site-to-site and client-to-site communications.
Table 1. VPN Encryption Methods
|
Domestic |
Export |
Triple DES |
192-bit (including |
Not available |
DES |
64-bit (including |
64-bit (including |
RC2 |
128- or 40-bit |
40-bit |
RC5 |
128- or 40-bit |
40-bit |
Table 2.
VPN Authentication Methods
|
Domestic |
Export |
SHA1 HMAC |
160-bit |
160-bit |
SHA1 KEYED |
160-bit |
160-bit |
MD5 HMAC |
128-bit |
128-bit |
MD5 KEYED |
128-bit |
128-bit |
The following factors are used in the negotiation that determines which encryption and authentication schemes are implemented for each VPN connection:
By default, both VPN servers and clients have RC5 and MD5 KEYED set as the preferred security schemes. For VPN servers, the preferred security schemes can be changed to any scheme supported by the server's VPN software, but VPN clients cannot reconfigure their preferred security schemes.
During the negotiation of the security schemes, the preferred scheme configured for each VPN member is checked to determine whether the scheme is supported by both VPN members. If the security scheme with the higher priority is supported by both VPN members, that security scheme is used for VPN communications between the two VPN members. If only one of the preferred schemes is supported by both VPN members, that scheme, the lower priority scheme, is used.
If one of the VPN members is a client and the server has been configured to restrict a VPN client to its preferred scheme, the client is checked to determine whether it can support the server's preferred security scheme. If the client cannot support the server's preferred security scheme, the connection is rejected.
Various negotiation combinations are shown in Table 3, VPN Security Options Negotiation. For example, a server running the Domestic version with the preferred security set to Triple DES and SHA1 HMAC connecting to a server running the Domestic version with the preferred security set to RC5 and MD5 KEYED would use the options with the higher priority: Triple DES and SHA1 HMAC. A connection to a client running the Domestic version would use the same options.
The opposite is true for a server running the Domestic version with the preferred security set to Triple DES and SHA1 HMAC connecting to a server running the export version with the preferred security set to RC5 and MD5 KEYED. They would use the options with the lower priority: RC5 and MD5 KEYED. If the server is configured to restrict a client to using the server's preferred security, a connection to a client running the export version would be rejected.
Table 3. VPN Security Options Negotiation
You can configure the VPN to support full mesh, star, and ring connectivity between VPN members. The topology you select determines the types and number of connections that are established, the flow of data, and the flow of routing traffic. Connections in any of these topologies can be one-sided (always initiated by one server) or both-sided (initiated by either server). The topologies are described as follows:
This is the default topology. All servers are interconnected to form a web, or mesh, with only one hop to any VPN member. Communication can occur between every member of the VPN, whether required or not.
This topology is the most fault-tolerant. If a VPN member goes down, only the connection to that member's protected network is lost. Also, after the encryption keys have been established, the master server is no longer required. However, this topology has more routing traffic because each VPN member must send updates to every other member. Also, routing loops in a mesh topology can require a significant amount of time to be resolved.
The master server is the central hub of this topology, with all communications radiating outward to other servers and returning to the master server. In terms of routing traffic, this is the least traffic-intensive topology, but the master server is the single point of failure. If the master server goes down, an encrypted tunnel cannot be established to any slave server and the ability to send encrypted data to all protected networks is lost.
In this topology, each member communicates with its immediate neighbors. The ring loops from the master server to subsequent slave servers and back to the master server. This topology has less traffic through the tunnel than the mesh network. It is also more reliable than the star network. However, one disadvantage of this topology is that routing loops to require a significant amount of time to be resolved. Also, the other networks could be more than one hop away.
Connections can be initiated from one side or both sides. The advantages and disadvantages of each option are as follows:
This option offers administrative control because only the master VPN server can initiate a connection. Connections are established only if the center office needs a connection. However, one disadvantage is that if a passive VPN member is restarted, it must wait for the other side to initiate the call before you can send encrypted traffic
This option allows either side to initiate a connection automatically without having to wait for the other side. However, if a connection to a particular VPN member is not needed, you cannot bring that connection down because the other side will always automatically initiate an outgoing call.
Master-slave server synchronization is tuned using the following parameters:
The Connect Timeout value is the amount of time the master server can wait while attempting to establish a connection with a slave server. The Response Timeout value is the amount of time the master server can wait to receive a response to configuration information it sent to a slave server. The slave server also has a Response Timeout value. Finally, the Update Interval value is the amount of time the master server must wait before reattempting to contact slave servers that could not be updated with current configuration information during the last attempt.
Determining the values for these parameters represents a balance between quick convergence of the VPN and both traffic and CPU overhead.
If your servers and ISP connections are operating properly, the default timeout values are adequate to allow your VPN to synchronize in the shortest possible amount of time.
During synchronization, use the audit log to determine whether any slave servers cannot be contacted. If a server cannot be contacted because of latency in the connection path, increasing the Connect Timeout value might allow a connection to be established. If a server cannot be contacted because the server or ISP connection is down, increasing the timeout values will not cause the VPN to converge more quickly. To enable your VPN to synchronize more quickly, make sure that all slave servers are operating properly and their ISP connections have minimal latency. To determine which slave servers cannot be contacted, use the VPN Activity window, as described in the VPN online documentation. In a large VPN with many servers that are down, temporarily decreasing the Connect Timeout value to about 10 seconds enables all the functional servers to converge more quickly and enables you to quickly determine which slave servers are down.
Aside from the effects on server synchronization, increasing the Response Timeout value can help to maintain connectivity between servers if the link between them is slow.
The Novell BorderManager 3.7 VPN software enables remote dial-in clients to access one or more VPN servers using a PPP connection. When VPN clients establish a PPP connection, they use TCP/IP to communicate with the VPN Authentication Gateway and authenticate themselves. The Authentication Gateway passes configuration information to the client so that the client can generate its keys and establish an encrypted tunnel with the VPN server. Thereafter, all IPX and IP traffic to and from the client is encrypted. To configure access control for client-to-site connections, refer to the access control online documentation.
The client can connect to the VPN server using one of the following options:
With this option, the client uses PPP to establish a connection with an ISP and then connects to the VPN server over the Internet. Although using an ISP connection does not offer guaranteed bandwidth and could be slower than a direct dial-in connection, this option has the advantage of being less expensive than a direct dial-in connection. In addition to the cost of the phone line, a direct dial-in connection requires that you maintain a dial-up server, modems, and other related equipment.
If your ISP supports the Point-to-Point Tunneling Protocol (PPTP), the VPN client can use PPTP to access the VPN server through an ISP connection.
VPN servers can support both client-to-site and site-to-site connections. If the VPN server is part of a site-to-site VPN, the client can also access all the other members of the site-to-site VPN and the networks that they protect. In addition, the site-to-site connections can be either Internet connections or intranet connections.
With this option, the client uses the Point-to-Point Protocol (PPP) to dial directly in to the VPN server. Although a direct PPP connection has guaranteed bandwidth, it is more expensive and might not be any faster than an ISP connection.
For some remote clients, a direct dial-in connection might be the only option available.
VPN servers can support both client-to-site and site-to-site connections. If the VPN server is part of a site-to-site VPN, the client can also access all the other members of the site-to-site VPN and the networks that they protect. In addition, the site-to-site connections can be either Internet connections or intranet connections.
With this option, the client accesses the VPN server through an ISP using a cable modem, an ADSL device, or an established dial-up connection. If it is available, a broadband connection is faster and less expensive than a dial-in connection.
VPN servers can support both client-to-site and site-to-site connections. If the VPN server is part of a site-to-site VPN, the client can also access all the other members of the site-to-site VPN and the networks that they protect. In addition, the site-to-site connections can be either Internet connections or intranet connections.