Remote Sites Linked by VPN Nodes behind a Firewall
This section explains the tasks you complete to configure a site-to-site VPN. This section contains procedures for the following:
This section explains the advanced configuration task for a site-to-site VPN using the VPNCFG utility. Use VPNCFG to regenerate the encryption information.
To maintain security, we recommend that you regenerate the encryption information every six months after the initial configuration of the VPN. To regenerate the encryption information:
At the master server console prompt, enter
LOAD VPNCFG
Select Master Server Configuration.
Generate the master server encryption information.
Select Generate Encryption Information.
Enter up to 255 characters for the random seed.
There is no need to record this value. The software uses this value to help randomize the master server RSA public and private keys and the master server Diffie-Hellman public and private values that it generates.
Copy the master encryption information file (MINFO.VPN) to diskette or save it to a local hard disk.
Give the MINFO.VPN file to the network administrator of each slave server you want to add to the VPN.
You can either send the diskette containing the file by surface mail or send the file as an e-mail attachment. There is no danger of compromising security if the file is intercepted because it cannot be interpreted without the slave server's RSA public and private keys and Diffie-Hellman public and private values.
Exit VPNCFG.
Load VPNCFG on the slave server.
Select Slave Server Configuration.
Generate the slave server encryption information.
Select Generate Encryption Information.
Enter the location of the master encryption information file (MINFO.VPN).
Contact the master server administrator and verify that you have the same digest values.
Having the same digest values ensures the authenticity of the MINFO.VPN file.
IMPORTANT: If the message digest values do not match, the encrypted tunnel between the slave and master servers cannot be created. In this case, the master server administrator must provide a new MINFO.VPN file.
Ask the master server administrator to select Authenticate Encryption Information to authenticate the MINFO.VPN file.
To authenticate this file, the administrator must load VPNCFG and select the following menu path:
Master Server Configuration > Authenticate Encryption Information
If the MINFO.VPN file is valid, enter up to 255 characters for the random seed.
There is no need to record this value. The software uses this value to help randomize the Diffie-Hellman public and private values that it generates for the slave server.
Copy the slave encryption information file (SINFO.VPN) to diskette or save it to a local hard disk.
Select Copy Encryption Information.
Enter the path or name of the file in which you want to save the slave encryption information file. The default is A:\SINFO.VPN.
HINT: Rename your SINFO.VPN file to a name such as SINFO_S1.VPN. This enables the master server administrator to collect all slave encryption information files in a single directory without overwriting them. You can also use a server or location name when renaming the SINFO.VPN file.
Give your slave encryption information file to the master server administrator.
You can either send the diskette containing the file by surface mail, or send the file as an e-mail attachment. There is no danger of compromising security if the file is intercepted because it contains only public information. Any alteration of the file can be detected by verifying the message digest when the master server adds the slave server to the VPN.
Press Esc until you exit VPNCFG.
Use NetWare® Administrator to remove all slave servers and add them back again.
For more information, refer to the Novell BorderManager 3.7 Installation Guide .
This section explains the advanced configuration tasks for a site-to-site VPN using the NetWare Administrator utility. Use NetWare Administrator to complete the following tasks:
With Novell BorderManager 3.7, you can select the network protocols---IP and IPX---that are encrypted and sent over the VPN tunnel.
This capability offers the following advantages:
Both protocols are tunneled by default.
IMPORTANT: Disabling both IPX and IP effectively disables the VPN without bringing it down.
To enable or disable protocol tunneling on your VPN, complete the following steps:
In NetWare Administrator, double-click the VPN master server and select the Novell BorderManager 3.7 Setup page.
Click the VPN tab.
Double-click Master Site-to-Site under Enable Service.
Click Control Options.
Check the check box for the network protocol you want to enable.
A checked box indicates that the protocol will be encrypted and sent over the VPN tunnel.
Click OK until you exit the NetWare Administrator utility.
Exiting the NetWare Administrator utility triggers a VPN synchronization. If you plan to perform additional VPN configuration tasks, you can trigger a synchronization immediately by clicking Status, then clicking Synchronize All.
For each VPN server, you can specify the addresses of one or more local IP networks or hosts that can exchange encrypted data across the VPN. This is equivalent to setting up static routes for encrypted data. When you synchronize the VPN, the static routes are automatically added to the routing tables of the other VPN servers, which use the routes to forward encrypted data to the server.
The alternative to using static routes to determine which networks can exchange encrypted data is using dynamic routing across the VPN. For a description of the advantages and disadvantages of using static routes, refer to the Novell BorderManager 3.7 Overview and Planning Guide.
IMPORTANT: You must set up all static routes for protected networks on VPN servers using the NetWare Administrator utility, not the NIASCFG utility. Any static routes you set up from NIASCFG with a tunnel address as the next-hop router are removed from the VPN server routing tables when a VPN resynchronization occurs.
To specify an address of a local private network or host that you want to be protected by a particular server, complete the following steps:
In NetWare Administrator, double-click the VPN master server and select the Novell BorderManager 3.7 Setup page.
Click the VPN tab.
Double-click Master Site-to-Site under Enable Service.
In the VPN Members list box, double-click the VPN server you want to set up.
To use RIP to dynamically determine which networks are protected by this server, select Enable IP RIP.
To statically configure the list of networks protected by this VPN server, complete the following substeps:
Click Add.
Select Network or Host.
Enter the IP network address and subnet mask of the network or host that you want to be protected by this server.
Click OK.
Specify any additional protected networks, then click OK to return to the main VPN page.
NOTE: At this point, your master server recognizes the slave server, but the slave server has not been updated yet with the VPN configuration information. The slave server must be updated in order for the VPN to come up. Make sure that the master and slave servers can communicate using IP before synchronizing the servers.
To update all VPN members with the entire VPN configuration, complete the following substeps:
From the main VPN page, click Status.
Click Synchronize All to update all VPN members with the current configuration.
This might take some time, depending on the number of members that must be updated. When the process is complete, all members should have a status of Up-to-Date.
If any VPN server remains with a status of Being configured, select that VPN server, then check the audit log for configuration errors.
Click OK.
The preferred data encryption and authentication methods are used during negotiation between the two sides of a VPN connection to determine the actual methods that are used for the connection. The preferred data encryption and authentication methods for the server apply to both site-to-site and client-to-site connections.
To change the preferred values used to negotiate the methods of data encryption and data authentication, complete the following steps:
In NetWare Administrator, double-click the VPN master server and select the Novell BorderManager 3.7 Setup page.
Click the VPN tab.
Double-click Master Site-to-Site under Enable Service.
In the VPN Members list box, double-click the VPN server you want to set up.
Select an option for the Preferred Encryption Method parameter.
Select an option for the Preferred Authentication Method parameter.
Specify a value for the Data Encryption Key Change Interval parameter.
Click OK until you exit the NetWare Administrator utility.
Exiting the NetWare Administrator utility triggers a VPN synchronization. If you plan to perform additional VPN configuration tasks, you can trigger a synchronization immediately by clicking Status, then clicking Synchronize All.
With Novell BorderManager 3.7, you can select from one of the following topologies to use with your VPN:
In this topology, all VPN members have connections to each other.
In this topology, all VPN members have connections only to the master server.
In this topology, each VPN member has connections to two of its neighbors.
To select the topology for your VPN, complete the following steps:
In NetWare Administrator, double-click the VPN master server and select the Novell BorderManager 3.7 Setup page.
Click the VPN tab.
Double-click Master Site-to-Site under Enable Service.
Click Control Options.
Check the check box for the type of topology you want to use.
Click OK until you exit the NetWare Administrator utility.
Exiting the NetWare Administrator utility triggers a VPN synchronization. If you plan to perform additional VPN configuration tasks, you can trigger a synchronization immediately by clicking Status, then clicking Synchronize All.
With Novell BorderManager 3.7, you can specify whether a connection between two VPN servers is always initiated by only one server or is initiated by either server.
Selecting One Side indicates that a connection made between two servers is always initiated by one server. This setting typically results in faster calls. Selecting Both Sides allows either server to initiate the connection. However, if two servers initiate a connection to each other simultaneously, the connection takes longer to be established. In this case, the longer connection time is caused by the servers negotiating which one initiated the connection first.
To specify whether a connection between two VPN servers can be initiated by only one server or either server, complete the following steps:
In NetWare Administrator, double-click the VPN master server and select the Novell BorderManager 3.7 Setup page.
Click the VPN tab.
Double-click Master Site-to-Site under Enable Service.
Click Control Options.
Check the check box for One Side or for Both Sides.
Click OK until you exit the NetWare Administrator utility.
Exiting the NetWare Administrator utility triggers a VPN synchronization. If you plan to perform additional VPN configuration tasks, you can trigger a synchronization immediately by clicking Status, then clicking Synchronize All.
The response timeout determines how long an individual VPN server waits for a response from another server before terminating the connection. Increasing the response timeout can help to maintain connectivity between servers if the link between them is slow.
To adjust the response timeout for a VPN server, complete the following steps:
In NetWare Administrator, double-click the VPN master server and select the Novell BorderManager 3.7 Setup page.
Click the VPN tab.
Double-click Master Site-to-Site under Enable Service.
In the VPN Members list box, double-click the VPN server you want to configure.
Enter the response timeout.
Click OK until you exit the NetWare Administrator utility.
Exiting the NetWare Administrator utility triggers a VPN synchronization. If you plan to perform additional VPN configuration tasks, you can trigger a synchronization immediately by clicking Status, then clicking Synchronize All.
On a VPN, the master server communicates with the slave servers to ensure that they maintain the same information about the VPN topology and use the current public encryption keys. For this purpose, you can customize the Update Interval, Connect Timeout, and Response Timeout parameters. Tuning these parameters represents a balance between quick convergence of the VPN and the traffic and CPU overhead.
If your servers and ISP connections are working properly, the default timeout values are adequate to enable your VPN to synchronize in the shortest possible amount of time.
To tune master-slave server synchronization, complete the following steps:
In NetWare Administrator, double-click the VPN master server and select the Novell BorderManager 3.7 Setup page.
Click the VPN tab.
Double-click Master Site-to-Site under Enable Service.
Click Control Options.
Enter values for the Update Interval, Response Timeout, and Connect Timeout parameters.
Values for the Update Interval and Response Timeout parameters range from 0 to 5 hours and 59 minutes. The Connect Timeout parameter value ranges from 0 to 20 hours and 59 minutes.
Click OK until you exit the NetWare Administrator utility.
Exiting the NetWare Administrator utility triggers a VPN synchronization. If you plan to perform additional VPN configuration tasks, you can trigger a synchronization immediately by clicking Status, then clicking Synchronize All.
When you remove a slave server from a VPN, the master server distributes an updated VPN members list to the remaining slave servers. The master server also sends a request to the removed server to detach itself from the VPN.
NOTE: You cannot remove the master server from a VPN.
To remove a slave server from a VPN, complete the following steps:
Verify that the slave server you want to remove does not have INETCFG loaded.
If INETCFG is loaded when the VPN slave server is removed, the remaining slave servers will not synchronize properly.
In NetWare Administrator, double-click the VPN master server and select the Novell BorderManager 3.7 Setup page.
Click the VPN tab.
Double-click Master Site-to-Site under Enable Service.
In the VPN Members list box, click the slave server you want to remove.
Click Delete in the VPN Members list box.
Click Status.
Click Synchronize All, then click OK.
After the VPN has synchronized, go to the slave server and remove the VPN configuration from the slave, as follows:
A VPN server that is a member of another VPN can also be included in your VPN using the multiple tunnel support provided by Novell BorderManager 3.7.
IMPORTANT: The tunnel connection to the third-party VPN server is an IP-only connection. Only the local VPN server that is associated with the third-party VPN server can exchange encrypted information with the third-party VPN server.
For third-party servers to function, your local VPN must use a mesh topology. If the third-party VPN is running Novell BorderManager 3.7 VPN software, it must also use a mesh topology.
When adding a third-party server to your VPN, the administrators of both VPN servers must configure the same authentication or encryption algorithms or the encrypted tunnel will not be established. Your local VPN server will not negotiate authentication or encryption algorithms with a third-party slave server, even if the third-party server is also running Novell BorderManager 3.7 VPN software.
Servers that are members of two VPNs are managed differently than servers that are members of just one VPN. Refer to the Virtual Private Network online documentation for more information.
If the third-party VPN is running another vendor's VPN software, you must create a new SINFO.VPN file and complete the procedure for adding a server to a VPN, as described in Novell BorderManager 3.7 Installation Guide a new SINFO.VPN file with the following fields:
If the third-party VPN is running Novell BorderManager, you must generate the third-party's encryption information, as described in the Install and Setupguide. Edit the third-party's SINFO.VPN file, and complete the procedure for adding a server to a VPN, as described in the guide. To edit the third-party's SINFO.VPN file, obtain the file from the other VPN's administrator and change the values of only the following fields:
This field must be changed from the third-party server's VPN tunnel address to the VPN tunnel address of your local server.
This field must be changed from the third-party server's VPN tunnel mask to the VPN tunnel mask of your local server.
This field is not present in the SINFO.VPN file that you receive from the third-party VPN. Therefore, you must add the field after the Flag to indicate third-party field.
IMPORTANT: Do not change the Security Capabilities field in the server's SINFO.VPN file.
This section describes implementation-specific examples for site-to-site VPNs. Some of these examples require that you complete the preparatory steps provided in Novell BorderManager 3.7 Installation and Setup guide. For in-depth information to help you plan your VPN configuration, refer to Novell BorderManager 3.7 Overview and Planning Guide.
Site-to-site VPNs can be implemented in the following ways:
In this case, VPN servers at two or more remote sites use the Internet to exchange encrypted confidential information. The VPN servers can connect directly to the Internet, or connect through an existing firewall or high-speed router. Examples of both are provided in this section. In these examples, it is assumed that you selected the Setup Novell BorderManager 3.7 for Secure Access to Public Interface option during Novell BorderManager 3.7 installation.
In this case, a VPN is set up on a corporate intranet or private network to exchange encrypted information. An example of this case is provided in this section.
This section contains the following topics:
This section discusses the following two possible scenarios for using the VPN server as a border server:
In this example, assume the company has offices at two remote sites: San Jose and Athens. The Finance and corporate offices are in San Jose, and the Accounting office is in Athens. At each office, the public and private addresses are on a different subnet of the same Class B IP network address. Both offices must share data without allowing other users on networks that are not protected by the VPN servers 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. The following procedure shows you how to connect the two remote sites in this example by setting up the two border servers as VPN servers and using an encrypted tunnel to send data between the sites.
To connect two remote Internet sites using a VPN:
Choose a master server for your VPN.
In this example, the San Jose site is selected because the corporate office has the Corporate Information Services staff, who are better equipped to manage the VPN.
Contact an ISP and arrange for Internet connectivity. Write down the public IP address and subnet mask that the ISP provides you.
Repeat this step for each site that will be a part of the VPN.
In this example, the public IP address and subnet mask for the VPN master server in San Jose are 135.27.180.1 and FF.FF.FC.0, respectively. The public IP address and subnet mask for the VPN slave server in Athens are 135.145.188.25 and FF.FF.FC.0, respectively.
Choose an IP address and subnet to use for your VPN tunnel interface.
Because this address will never be sent over the Internet, it can be any unregistered address, for example, 10.0.0.1 and FF.0.0.0 for the master server, and 10.0.0.2 and FF.0.0.0 for the slave server.
The master server and all slave servers must use IP addresses on the same network or subnet for the VPN tunnel interfaces.
Install the NetWare and Novell BorderManager 3.7 software on your master server.
Use NIASCFG to configure the protocols and routing on your master server as follows:
Establish a connection to your ISP and verify that the master server can communicate with the ISP router.
Do this before you add the VPN. Before testing the connection, you must verify that the Novell BorderManager 3.7 filters are configured to allow Internet Control Message Protocol (ICMP) packets through. After testing, the filters should be returned to their previous configuration. If you configured your call as Permanent-Automatic, the server should connect to your ISP immediately after you reinitialize the system. If you configured your call as any other type, you might need to initiate the call yourself by loading CALLMGR at the console and initiating an IP WAN call to your ISP. After the call is connected, ping the ISP router by entering LOAD PING at the console prompt and entering the IP address of the router (provided by the ISP). If you can ping the ISP router, you are connected to the ISP and should be able to reach any location on the Internet, including your other sites after they are connected.
Use VPNCFG to configure your VPN master server. Make sure you do the following:
NOTE: VPNCFG automatically adds some filters to prevent the IP address of the VPN tunnel from being sent through the public interface, and to prevent the public IP address from being sent through the tunnel interface.
Refer to Novell BorderManager 3.7 Install and Setup guide or the online help for the procedure to set up the master server.
If you did not select the Setup Novell BorderManager 3.7 for Secure Access to the Public Interface option during installation, load BRDCFG and select this option.
Send the MINFO.VPN file with the master encryption information to the administrator configuring the VPN slave server.
Repeat Step 4, Step 5, Step 6, and Step 8 for the slave server.
At the VPN slave server, use VPNCFG to configure the VPN slave server. Make sure you do the following:
Refer to Novell BorderManager 3.7 Install and Setup or the online help for the procedure to set up the slave server.
Send the SINFO.VPN file with the slave encryption information back to the administrator configuring the VPN master server.
At the administrative workstation, install the Novell BorderManager 3.7 guide snap-in for the NetWare Administrator utility if it has not already been installed.
The installation program for this utility (SETUP.EXE) is in the \PUBLIC\BRDMGR\SNAPINS directory on the SYS: volume of your server after Novell BorderManager 3.7 has been installed.
NOTE: Perform this step from a client that is authenticated to the NDS or eDirectory tree in which the VPN master server resides. The machine must be logged in with Supervisor rights to the VPN master server. If this is the first VPN server or border server on this tree, then Supervisor rights to the root directory are required in order to extend the NDS or eDirectory schema.
In NetWare Administrator, double-click the VPN master server and select the Novell BorderManager 3.7 Setup page.
Click the VPN tab.
Double-click Master Site-to-Site under Enable Service.
Your master server should be listed in the VPN Members list. For example, if you named the master server Corporate, you should see Corporate displayed as a VPN member with an IP address of 135.27.180.1, as configured in Step 7.
Manually configure a list of networks protected by this VPN master server.
In this example, a list of protected networks must be configured for all VPN servers even if Enable IP RIP is selected. Because the public and private networks are subnets of the same network, the RIP packets that pass through the VPN tunnel interface are blocked by the default VPN filters. Because the routes to the protected networks cannot be learned using RIP, a list of protected networks must be configured manually.
In this example, you can specify the 135.27.188.0 network as a protected network by completing the following substeps:
Click Add to add the slave server to the VPN Members list.
Specify the name and pathname for the slave encryption information file (SINFO.VPN).
Ask the administrator of the VPN slave server to use VPNCFG to authenticate the encryption information and verify that the message digest values match. Click Yes if the values match.
To authenticate the encryption information using VPNCFG, select Authenticate Encryption Information.
Click Yes to manually configure a list of networks protected by this VPN slave server.
In this example, a list of protected networks must be configured for all VPN servers even if Enable IP RIP is selected. Because the public and private networks are subnets of the same network, the RIP packets that pass through the VPN tunnel interface are blocked by the default VPN filters. Because the routes to the protected networks cannot be learned using RIP, a list of protected networks must be configured manually.
In this example, you can specify the 135.145.180.0 network as a protected network by completing the following substeps:
Double-click the slave server to view details for that server.
Click Add.
Select Network.
Enter 135.145.180.0 for the IP network address.
Enter FF.FF.FC.0 for the subnet mask.
Click OK.
Specify additional protected networks and modify other VPN parameters as needed, then click OK to return to the main VPN page.
NOTE: At this point, your master server recognizes the slave server, but the slave server has not been updated yet with the VPN configuration information. The slave server must be updated in order for the VPN to be brought up. Make sure that the master and slave servers are attached to the Internet through their respective ISPs so that they can communicate with each other and the master server can update the slave server.
Update all VPN members with the entire VPN configuration as follows:
From the main VPN page, click Status.
Click Synchronize All to update all VPN members with the current configuration.
This might take some time, depending on the types of Internet connections and the number of members that must be updated. When the process is completed, all members should have a status of Up-to-Date.
If any VPN members remain with a status of Being Configured, select the member or master, then check the audit log for configuration errors.
Click OK.
The VPN is now set up between two sites. You can add more sites and update all members at the same time. To add another site, repeat Step 9 through Step 22.
Note that the firewall's public IP address must be prevented from being advertised through the VPN tunnel interface. If it is learned through this interface, packets destined for the public IP address will pass through the VPN tunnel interface and never arrive.
From a routing standpoint, the VPN tunnel interface is just another interface. One attribute of this interface is that all routes that are advertised through it add a cost of only one. Because the VPN tunnel interface provides the lowest cost to any network or host that advertises through it, all future access to that network or host will be through the VPN tunnel interface, in which case the data is encrypted. However, because the networks learned through the VPN tunnel interface can be advertised by the public interface, you might want to configure filters to prevent the networks from being advertised.
In this example, the VPN server is directly connected to the Internet. You must configure this machine as a firewall to secure the server and machines behind it. You should implement basic filtering using TCP/IP RIP filters and TCP/IP packet forwarding filters. If you do not want any clients to access the Internet, set all parameters to Deny, and allow only traffic that must pass through. If you selected the Setup Novell BorderManager 3.7 for Secure Access to Public Interface option during installation, these filters are already set for you and you are not required to perform any further configuration.
As shown in the earlier example, this scenario is the same as the previous scenario, except that the public and private addresses use different Class B IP addresses at each office.
The procedure for this scenario is almost the same as for the previous scenario, with the following differences:
In this example, the VPN master server for the Finance office in San Jose is behind a firewall server that is connected to the Internet, as shown in the following figure Remote Sites Linked by VPN Nodes behind a Firewall. 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 on the Internet connection. The VPN master 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. Both offices are sharing data that must be encrypted and sent through a VPN tunnel. The procedure shows you how to connect the two remote sites using an encrypted tunnel to send the data.
Figure 16
Remote Sites Linked by VPN Nodes behind a Firewall
To connect remote Internet sites using a VPN through a firewall, complete the following steps:
Choose a master server for your VPN.
In this example, the San Jose site is selected because the corporate office has the Corporate Information Services staff, who are better equipped to manage the VPN.
Contact an ISP and arrange for Internet connectivity for the slave server. Write down the public IP address and subnet mask that the ISP provides you.
NOTE: Repeat this step for each site that will be a part of the VPN.
In this example, the public IP address and subnet mask for the VPN master in San Jose are 220.150.17.65 and FF.FF.FF.C0, respectively. The public IP address and subnet mask for the VPN slave in Athens are 135.145.188.25 and FF.FF.FC.0, respectively.
Choose an IP address and mask to use for your VPN tunnel interface.
Because this address will never be sent over the Internet, it can be any unregistered address, for example, 10.0.0.1 and FF.0.0.0 for the master server, and 10.0.0.2 for the slave server.
NOTE: The master server and all slave servers must use IP addresses on the same network or subnet for the VPN tunnel interfaces.
Install NetWare and Novell BorderManager 3.7 software on your master server.
Use NIASCFG to configure the protocols and routing on your master server:
Establish a connection to your firewall router and verify that the master server can communicate with the ISP router.
Do this before you add the VPN. Before testing the connection, you must verify that the firewall is configured to allow ICMP packets through. After testing, the filters should be returned to their previous configuration. Because the Internet connectivity is provided by the firewall or another router, you are not required to make a WAN call. Enter LOAD PING at the console prompt and enter the IP address of the ISP router. If you can ping the router, you are connected to the ISP and should be able to reach any location on the Internet, including your other sites after they are connected.
Use VPNCFG to configure your VPN master server. Make sure you do the following:
NOTE: VPNCFG automatically adds some filters to prevent the IP address of the VPN tunnel from being sent through the public interface, and to prevent the public IP address from being sent through the tunnel interface.
Refer to Novell BorderManager 3.7 Install and Setup guide or the online help for the procedure to set up the master server.
Configure your firewall to allows VPN packets to pass through.
For a list of filters that must be configured, refer to the prerequisites section in Novell BorderManager 3.7 Install and Setup guide.
Send the MINFO.VPN file with the master encryption information to the administrator configuring the VPN slave server.
Repeat Step 4, Step 5, Step 6, and Step 11 for the slave server.
If you did not select the Setup Novell BorderManager 3.7 for Secure Access to the Public Interface option for the slave server during installation, load BRDCFG and select this option.
At the VPN slave server, use VPNCFG to configure the VPN slave server. Make sure you do the following:
Refer to Novell BorderManager 3.7 Install and Setup guide or the online help for the procedure to set up the slave server.
Send the SINFO.VPN file with the slave encryption information back to the administrator configuring the VPN master server.
At the administrative workstation, install the Novell BorderManager 3.7 snap-in for the NetWare Administrator utility if it has not already been installed.
The installation program for this utility (SETUP.EXE) is in the \PUBLIC\BRDMGR\SNAPINS directory on the SYS: volume of your server after Novell BorderManager 3.7 has been installed.
NOTE: Perform this step from a client that is authenticated to the NDS or eDirectory tree in which the VPN master server resides. The machine must be logged in with Supervisor rights to the VPN master server. If this is the first VPN server or border server on this tree, then Supervisor rights to the root directory are required in order to extend the NDS or eDirectory schema.
In NetWare Administrator, double-click the VPN master server and select the Novell BorderManager 3.7 Setup page.
Click the VPN tab.
Double-click Master Site-to-Site under Enable Service.
Your master server should be listed in the VPN Members list. For example, if you named the master server Corporate, you should see Corporate displayed as a VPN member with an IP address of 220.150.17.65, as configured in Step 7.
Manually configure a list of networks protected by the VPN master server.
In this example, a list of protected networks must be configured for all VPN servers even if Enable IP RIP is selected. Because the public and private networks are subnets of the same network, the RIP packets that pass through the VPN tunnel interface are blocked by the default VPN filters. Because the routes to the protected networks cannot be learned using RIP, a list of protected networks must be configured manually.
In this example, you can specify the 220.150.17.128 network as a protected network by completing the following substeps:
Click Add to add the slave server to the VPN Members list.
Specify the name and pathname for the slave encryption information file (SINFO.VPN).
Ask the administrator of the VPN slave server to use VPNCFG to authenticate the encryption information and verify that the message digest values match. Click Yes if the values match.
To authenticate the encryption information using VPNCFG, select Authenticate Encryption Information.
Click Yes to manually configure a list of networks protected by this VPN slave server.
In this example, a list of protected networks must be configured for all VPN servers even if Enable IP RIP is selected. Because the public and private networks are subnets of the same network, the RIP packets that pass through the VPN tunnel interface are blocked by the default VPN filters. Because the routes to the protected networks cannot be learned using RIP, a list of protected networks must be configured manually.
In this example, you can specify the 135.145.180.0 network as a protected network by completing the following substeps:
Double-click the slave server to view details for that server.
Click Add.
Select Network.
Enter 135.145.180.0 for the IP network address.
Enter FF.FF.FC.0 for the subnet mask.
Click OK.
Specify any additional protected networks and modify other VPN parameters as needed, then click OK to return to the main VPN page.
NOTE: At this point, your master server recognizes the slave server, but the slave server has not been updated yet with the VPN configuration information. The slave server must be updated in order for the VPN to be brought up. Make sure that the master and slave servers are attached to the Internet through their respective ISPs so that they can communicate with each other and the master server can update the slave server.
Update all VPN members with the entire VPN configuration as follows:
From the main VPN page, click Status.
Click Synchronize All to update all VPN members with the current configuration.
This might take some time, depending on the types of Internet connections and the number of members that must be updated. When the process is completed, all members should have a status of Up-to-Date.
If any VPN members remain with a status of Being Configured, select the member or master, then check the audit log for configuration errors.
Click OK.
The VPN is now set up between two sites. You can add more sites and update all members at the same time. To add more sites, repeat Step 9 through Step 23.
Note that the firewall's public IP address must be prevented from being advertised through the VPN tunnel interface. If it is learned through this interface, packets destined for the public IP address will pass through the VPN tunnel interface and never arrive.
From a routing standpoint, the VPN tunnel interface is just another interface. One attribute of this interface is that all routes that are advertised through it add a cost of only one. Because the VPN tunnel interface provides the lowest cost to any network or host that advertises through it, all future access to that network or host will be through the VPN tunnel interface, in which case the data is encrypted. However, because the networks learned through the VPN tunnel interface can be advertised by the public interface, you might want to configure filters to prevent the networks from being advertised.
In this example, access to the Internet by private clients is probably controlled by the firewall. However, depending on the firewall's configuration, you might want to implement filtering using TCP/IP RIP filters and TCP/IP packet forwarding filters to prevent access to the Internet. When configuring your firewall, do not remove any of the filters that are listed in the prerequisites section in Novell BorderManager 3.7 Install and Setup guide.
In this example, the Finance and Accounting servers in San Jose are on the corporate intranet or private network, as shown in following figure LAN Segments on an Intranet Linked by a VPN. In this scenario, access to the Internet and an ISP are not required, just IP connectivity between the master server and slave server. 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 server and slaver server 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, which requires that the nodes have the same network address.
Both departments are sharing data that must be encrypted and sent through a VPN tunnel. The procedure shows you how to connect the two LAN segments using an encrypted tunnel to send the data.
Figure 17
LAN Segments on an Intranet Linked by a VPN
To set up a VPN to operate within an intranet, complete the following steps:
Choose a master server for your VPN.
In this example, a machine is selected that is easy to physically secure and easy for the Corporate Information Services staff to access.
Choose an IP address and mask to use for your VPN tunnel interface.
Because this address will never be sent over the Internet, it can be any unregistered address, for example, 10.0.0.1 and FF.0.0.0 for the master server, and 10.0.0.2 for the slave server.
NOTE: The master server and all slave servers must use IP addresses on the same network or subnet for the VPN tunnel interfaces.
Install NetWare and Novell BorderManager 3.7 software on your master server and slave server.
Use NIASCFG to configure the protocols and routing on your master server and slave server:
IMPORTANT: Make sure that the IPX protocol is not bound to the public interface of any of the VPN servers.
Verify that IP connectivity exists between the VPN members.
Before testing the connection, you must verify that the Novell BorderManager 3.7 filters or other firewalls are configured to allow ICMP packets through. After testing, the filters should be returned to their previous configuration. Enter LOAD PING at the console prompt of the VPN master server and enter the IP address of the VPN slave.
Use VPNCFG to configure your VPN master server. Make sure you do the following:
NOTE: VPNCFG automatically adds some filters to prevent the IP address of the VPN tunnel from being sent through the public interface, and to prevent the public IP address from being sent through the VPN tunnel interface.
Refer to Novell BorderManager 3.7 Installation Guide or the online help for the procedure to set up the master server.
If you did not select the Setup Novell BorderManager 3.7 for Secure Access to the Public Interface option during installation on your master server and slave server, load BRDCFG and select this option.
Send the MINFO.VPN file with the master encryption information to the administrator configuring the VPN slave server.
At the VPN slave server, use VPNCFG to configure the VPN slave server. Make sure you do the following:
Refer to Novell BorderManager 3.7 Install and Setup guide or the online help for the procedure to set up the slave server.
Send the SINFO.VPN file with the slave encryption information back to the administrator configuring the VPN master server.
At the administrative workstation, install the Novell BorderManager 3.7 snap-in for the NetWare Administrator utility if it has not already been installed.
The installation program for this utility (SETUP.EXE) is in the \PUBLIC\BRDMGR\SNAPINS directory on the SYS: volume of your server after Novell BorderManager 3.7 has been installed.
NOTE: Perform this step from a client that is authenticated to the NDS or eDirectory tree in which the VPN master server resides. The machine must be logged in with Supervisor rights to the VPN master server. If this is the first VPN server or border server on this tree, then Supervisor rights to the root directory are required in order to extend the NDS or eDirectory schema.
In NetWare Administrator, double-click the VPN master server and select the Novell BorderManager 3.7 Setup page.
Click the VPN tab.
Double-click Master Site-to-Site under Enable Service.
Your master server should be listed in the VPN Members list. For example, if you named the master server Corporate, you should see Corporate displayed as a VPN member with an IP address of 135.27.180.1, as configured in Step 6.
Manually configure a list of networks protected by this VPN master server.
In this example, a list of protected networks must be configured for all VPN servers even if Enable IP RIP is selected. Because the public and private networks are subnets of the same network, the RIP packets that pass through the VPN tunnel interface are blocked by the default VPN filters. Because the routes to the protected networks cannot be learned using RIP, a list of protected networks must be configured manually.
In this example, you can specify the 135.27.188.0 network as a protected network by completing the following substeps:
Click Add to add the slave server to the VPN Members list.
Specify the name and pathname for the slave encryption information file (SINFO.VPN).
Ask the administrator of the VPN slave server to use VPNCFG to authenticate the encryption information and verify that the message digest values match. Click Yes if the values match.
To authenticate the encryption information using VPNCFG, select Authenticate Encryption Information.
Click Yes to manually configure a list of networks protected by this VPN slave server.
In this example, a list of protected networks must be configured for all VPN servers even if Enable IP RIP is selected. Because the public and private networks are subnets of the same network, the RIP packets that pass through the VPN tunnel interface are blocked by the default VPN filters. Because the routes to the protected networks cannot be learned using RIP, a list of protected networks must be configured manually.
In this example, you can specify the 135.27.176.0 network as a protected network by completing the following substeps:
Double-click the slave server to view details for that server.
Click Add.
Select Network.
Enter 135.27.176.0 for the IP network address.
Enter FF.FF.FC.0 for the subnet mask.
Click OK.
Specify any additional protected networks and modify other VPN parameters as needed, then click OK to return to the main VPN page.
NOTE: At this point, your master server recognizes the slave server, but the slave server has not been updated yet with the VPN configuration information. The slave server must be updated in order for the VPN to be brought up. Make sure that the master and slave servers can communicate with each other so that the master server can update the slave server.
Update all VPN members with the entire VPN configuration as follows:
From the main VPN page, click Status.
Click Synchronize All to update all VPN members with the current configuration.
This might take some time, depending on the number of members that must be updated. When the process is completed, all members should have a status of Up-to-Date.
If any VPN members remain with a status of Being Configured, select the member or master, then check the audit log for configuration errors.
Click OK.
The VPN is now set up between two LAN segments. You can add more segments and update all members at the same time. You can repeat Step 3 through Step 20 to add another slave server.
Note that if you are using a firewall, the firewall's public IP address must be prevented from being advertised through the VPN tunnel interface. If it is learned through this interface, packets destined for the public IP address will pass through the VPN tunnel interface and never arrive.
From a routing standpoint, the VPN tunnel interface is just another interface. One attribute of this interface is that all routes that are advertised through it add a cost of only one. Because the VPN tunnel interface provides the lowest cost to any network or host that advertises through it, all future access to that network or host will be through the VPN tunnel interface, in which case the data is encrypted. However, because the networks learned through the VPN tunnel interface can be advertised by the public interface, you might want to configure filters to prevent the networks from being advertised.