Networking

Implementing site-to-site VPN with BorderManager 3.x

Have you thought about setting up a VPN to connect two remote sites using BorderManager? It's not as intimidating as it may sound. Ron Nutter walks you through the process in this Daily Drill Down.

Running point-to-point data circuits (also known as private lines) between your company’s locations can be very expensive, especially if one or more of those locations are overseas. BorderManager is more than just a firewall or a method of controlling access to the Internet—you also have the ability to establish a virtual private network (VPN), which will use the Internet to connect your locations. All you will need to do is install a data circuit to a local ISP and a BorderManager server at each location.

In this Daily Drill Down, we will walk through the steps of setting up a site-to-site VPN. The first step involves setting up a master VPN server (each VPN configuration will have only one master VPN server). Although we will be setting up just a two-site VPN in this Daily Drill Down, each additional site you add to your VPN will be a slave server. We will be using NetWare 5.1 with Support Pack 2a applied and BorderManager 3.5 with BorderManager Support Pack 2 applied.

Before you start
One thing you will want to think about before beginning to implement a site-to-site VPN is whether to implement VPN services on your existing BorderManager server or implement a server dedicated solely to the VPN links between locations. If you put the VPN services on your existing BorderManager server, you will need to be very careful about when you reboot the server, as this will take your entire VPN down. If you implement a dedicated VPN server, you should be able to reduce the amount of downtime from reboots, as you shouldn’t be working with this server significantly on a day-to-day basis.

A fault tolerant network (one that can handle problems thrown at it and keep running basically undisturbed) might be accomplished by implementing a dedicated VPN server at each location and then making the BorderManager server you already have a slave VPN server. Before implementing this type of solution, I recommend setting up a proof of concept system to make sure that everything will work as expected.

Establishing site-to-site VPN on the master server
At this point, we will assume that you already have NetWare 5.1 and BorderManager installed on the server that will be your master VPN server and that the appropriate Support Packs have been installed. Type LOAD VPNCFG at the server’s console prompt and press [Enter].

When the VPNCFG main menu screen appears, highlight and press [Enter] on the Master Server Configuration option. A message will appear indicating you can have only one master VPN server in the network. Highlight Continue and press [Enter].

The first thing that you will need to do is tell BorderManager what the TCP/IP addresses are for the public card and for the VPN network. Highlight Configure TCP/IP Addresses and press [Enter]. You will need to enter the TCP/IP address and subnet mask for both the public and VPN tunnels. The public TCP/IP address and mask are the same as the ones you defined on your BorderManager server.

The VPN address and subnet mask will take a little thought before you proceed. This address has to be unique on your network; the address in this range can be used anywhere else on the network—anywhere, that is, except on the other BorderManager server (which will use a different address out of the range defined by the subnet mask that you enter for the VPN tunnel). Once you have entered the required information, press [Esc], highlight Yes, and press [Enter]. A series of messages will shortly appear indicating the NDS schema is being extended and the base VPN configuration is set up.

In order for the VPN to work, you will need to have some type of encryption setup. Highlight the Generate Encryption option and press [Enter]. You will be prompted to enter a random seed to be used to generate the key. Enter a random string of letters and numbers and press [Enter]. Don’t worry about remembering this string. (This doesn’t have to be the same on each server.)

When the encryption generation process is complete, you will see a message on the server screen to that effect. You will be returned to the VPN master server screen. Highlight the Authenticate Encryption Information option and press [Enter].

You will see a screen on the server showing a string of numbers and letters. This is known as the digest, the information used by the servers to set up the VPN between sites. You will need to have this information ready for the network administrator at the other end of the VPN connection (if you aren’t going to do the install yourself) so that they will know they have the setup enabled correctly. Press [Enter] to return to the main VPN menu screen.

You need to export the information necessary so that the slave VPN server will know how to talk to the master VPN server. Put a blank floppy in the server’s A: drive. Highlight the Copy Encryption Information option and press [Enter] to continue. The default path should be A:\. Unless your server’s floppy drive is something other than A:, accept the default and press [Enter].

Once the information is copied to a file, you will see a message on the server’s console screen. The name of the file it creates is Minfo.vpn. You have the option of e-mailing the Minfo.vpn file to the administrator at the other end of the connection, mailing the floppy, or going to that location yourself.

Setting up the site-to-site VPN on the slave server
Now that the master VPN server is set up, we can move on to the slave VPN server. Load the VPNCFG NLM on the slave server. Highlight the Slave VPN Server Configuration option and press [Enter]. Highlight the Configure TCP/IP Address option and press [Enter] just as you did on the master VPN server. When you do, you’ll see the screen shown in Figure A.

Figure A
You must configure TCP/IP on the slave server.


As with the master VPN server, you will need to enter the TCP/IP address and subnet mask for the public card and the VPN tunnel. In the case of the slave VPN tunnel, you will need to do something a little different. For example, if you entered a TCP/IP tunnel address on the master VPN server of 10.0.1.1 with a subnet mask of 255.255.255.0, you will need to use the same subnet mask on the slave VPN but with a different TCP/IP address. In our example, we would use something like 10.0.1.2 for the TCP/IP address of the VPN tunnel on the slave VPN server. Press [Esc], highlight Yes, and press [Enter] to continue.

Your next step will be to generate the encryption information necessary for this server to be able to participate in the VPN. Highlight the Generate Encryption Information option and press [Enter]. A pop-up box will appear asking you to verify the path to the Minfo.vpn file.

Let’s assume you are doing the slave VPN install yourself and have brought this file on a floppy. Insert the floppy into the slave server’s floppy drive and press [Enter]. After the Minfo.vpn file copies, you will see a digest screen displayed. This information should match exactly what you saw on the master VPN server. If this matches, highlight Yes and press [Enter].

You will next be asked to enter information to help randomize the Diffie-Hellman public and private keys that will be generated on this server. This information will be used on the master VPN server to actually build the VPN connection between servers. Enter the requested information and press [Enter]. A screen will appear when the VPN information has been created, and another screen follows when NDS has been extended to handle this task.

The next step involves copying the VPN information from the slave server to a floppy so that the master VPN server will know how to set up the VPN tunnel between servers. Highlight the Copy Encryption Information option and press [Enter]. You will be asked to verify the drive and path to the Sinfo.vpn file that will be created. Press [Enter] to continue. One thing to note at this point is that if you will have multiple slave servers in your VPN configuration, you will want to rename the Sinfo.vpn file to another name descriptive of the site it is for. This will make the process easier if you have to tear down and recreate the VPN for some reason. Once the VPN file has been copied to the floppy, you will see a message on the server telling you about renaming the file.

Completing the VPN setup in NetWare Administrator
To complete the site-to-site setup, you will need to go into NetWare Administrator. Double-click on the NDS server object that is running BorderManager. Click on the BorderManager Setup tab and then click on the VPN tab on the BorderManager Setup properties screen. Highlight the Master Site To Site option and click on the Details button. When the VPN Master properties screen appears, click Control Options. On the Control Options properties screen, you will need to select what protocols you want to cross the VPN.

You will also want to choose the topology you want for your VPN, as shown in Figure B. You have a choice of three topologies: Full Mesh, Star, and Ring. With Full Mesh, all the VPN sites can reach all of the other sites directly without having to go to the master VPN site first. With a Star topology, all slave sites will have to go through the master site before they will be able to talk to other slave sites. The disadvantage with this solution is that it will produce additional traffic at your master VPN site. With the Ring option, each VPN site will have connections to two of its neighbors. This solution is fine if most of the traffic will be between adjacent systems but could cause delay because of additional hops produced by this configuration when the most distant systems need to talk to each other. Both the Star and Ring options could suffer communication problems if a critical part of the system were to go down. With the Full Mesh option, you should still be able to talk between systems even if one or two are down. If the master VPN server is down, you should still be able to talk, but you won’t be able to add or remove slave VPN servers until the master VPN server is back online.

Figure B
You must choose your topology in NetWare Administrator.


Once you have selected the options on the Control Options screen and clicked OK, you will be presented with a screen that will allow you to add the slave VPN server to your VPN network. From the VPN Master Server properties screen, click Add and browse the floppy containing the Sinfo.vpn file. Double-click on Sinfo.vpn (or the file name you have renamed it to).

After NetWare Administrator reads the file, you will see a digest info screen containing a series of letter and number combinations. The information on this screen should match what was displayed on the digest screen on the slave server when you created the encryption information. Click Yes to proceed. When the Adding Server To VPN screen appears, click Yes to enter the info read from the Sinfo.vpn file.

The VPN Members screen should now be visible. TCP/IP RIP is enabled by default. Leaving this option enabled will allow the remote sites to seamlessly route over your network without you having to enter static routes within NetWare Administrator. If you will be connecting other companies (and other NDS trees) into your VPN, you may want to deselect TCP/IP RIP and go with static route mappings to help prevent access to parts of your network by the other companies that will be connecting to you.

Click OK to save this configuration and return to the VPN Master properties screen. When the VPN Master screen appears, you will see the slave VPN server you just added appear in the list of VPN servers. Click on the Status button and check the sync status of the VPN servers. Any time you add another slave VPN server or make significant changes to the network and have what appear to be communications problems, this is a good screen to check to make sure that all the servers are up-to-date with the information about the rest of the network. Congratulations, you now have a VPN up and running.

Monitoring the VPN
Monitoring the VPN is something that should be done periodically even if things are going well. Any time you add a server to the VPN, you will see a message appear on the master VPN server console screen telling you that a server has been added. A similar message will appear on the slave VPN servers.

Depending on the way you have implemented filtering in BorderManager, you may need to temporarily unload the filters to do this next series of tests. After you have added a slave VPN server to your network, first try pinging the TCP/IP address of the VPN tunnel on your end. Next, ping the TCP/IP address of the VPN tunnel on the server you just added and finally the TCP/IP address of the private card on the slave VPN server. If your pinging fails to get a response at any point in this process, this indicates a communication problem that should be addressed before proceeding.

Another screen to check periodically is the VPN Member Activity screen, shown in Figure C. This screen is reached from the sync status screen mentioned earlier. Highlight the VPN server that you want to check and click on the Activity button. When the VPN Member Activity screen appears, you will see what is going on with a particular slave VPN server (what protocols are being used, how many packets are being sent/received, etc.).

Figure C
You can monitor your VPN on the VPN Member Activity screen.


Conclusion
As you can see, setting up a site-to-site VPN isn’t that hard. As with any other network addition, take a few moments to document what you have done and the TCP/IP addresses being used for the VPN tunnel and make a copy of the .VPN files you used to create the VPN in case you need to tear down and re-create the VPN. If you haven’t already started doing so, have the individual responsible for the slave VPN servers keep a log of changes made to the servers so that if things stop working, you will have a base from which to start when figuring out the problem.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.
0 comments