Using ISA Server to Create a Hub and Spoke VPN Network


Using ISA Server to Create a Hub and Spoke VPN Network


By Thomas W Shinder M.D.


I’ve recently spent a lot of time putting together a number of VPN solutions centered around ISA Server. One of the more interesting configurations is the gateway to gateway configuration. One of the nice things about using ISA Server as a VPN gateway is that it includes built-in VPN gateway wizards. The ISA Server VPN gateway wizards make it a lot easier to configure a VPN gateway.


You can use ISA Server to build VPN networks. Many organizations use VPN servers to allow external network VPN clients to connect to the corporate network, but they haven’t graduated to the full implementation of Windows 2000 RRAS services by creating VPN gateways to join corporate networks over the Internet. VPN gateways are huge cost savers because they replace dedicated circuits less expensive with Internet connections. The VPN gateway acts as a router that routes packets between local and remote networks by using the Internet as the network medium.


One type of VPN network is the “hub and spoke” VPN network configuration. In the hub and spoke network, all branch offices connect to the central office and each office is able to connect to resources on the central network, as well as other offices, by going through their VPN gateway link to the central office. The drawback of this type of configuration is that there is a single point of failure. If the central office becomes unavailable, then the branch offices aren’t able to communicate. The disadvantage may be more apparent than real, because it’s unlikely that the branch offices have mission critical requirements to connect to one another.


In this article I’ll go over some of the basic principles of demand-dial interfaces when configuring the hub and spoke gateway to gateway configurations and also provide you the step by steps required to make it happen.


Get the Book!


The Calling (ACTIVE) and Call Recipient (PASSIVE) Gateways


If you’ve read my other articles on configuring VPN gateway connections, you know its important that only one of the VPN gateways initiates the call. If both gateways were able to initiate a call, you could end up with a “race” condition that prevents the VPN gateway connection from being completed. Allowing only one of the VPN gateways to make the call doesn’t present much of a problem as long as you configure the calling side to see the gateway link as permanent and redial on link failure.


The figure below shows how the calling and call recipient gateways are setup in the example we’ll be using today.



 


The Local and Remote VPN Wizards


ISA Server has two Wizards that help you put together a VPN gateway to gateway connection. By design, the Local VPN Wizard is supposed to be run at the main office and the Remote VPN Wizard is supposed to be run on the branch office. The primary difference between the main office and the remote office (in the VPN Wizard scheme of things) is that the remote office is supposed to call the main office (although the Wizard does give you the option to allow both sides to dial up). However, we don’t want both sides to dial up, so you would never select the option.


I prefer to use the Wizards differently. The Local VPN Wizard should be run at each branch office, and the files created by the Local VPN Wizards should be run using the Remote VPN Wizard at the main office. While this is opposite of how the Wizards were designed to be used, it makes it easy to restrict the calling side to the main office. I think its better to allow the calling gateway to be at the main office since most of the IT staff is located there. Problems with call initiation are more common than call reception, so it makes sense to put the calling gateway at the main site. However, you can certainly allow the remote office to be the active side if you prefer.


The figure below shows how the Local and Remote VPN Wizards should be used.



Lab Setup


You can test these concepts in the lab first, before you implement them in your production network. I always recommend you test your ISA Server designs in a VMware network lab (or a physical server lab if you have the cash) before rolling them out on your production network. You can test most ISA Server scenarios using VMware, and you can partition broadcast traffic using different virtual switches (VMNets).


All servers in the lab network are using Windows 2000 Server Service Pack 3. Each network segment is located on a different virtual switch (VMNet) and a central router connected all the “public” networks. The central Internet router is a Windows 2000 Server SP3 device configured as a LAN router.


The IP addressing scheme and VMNet configuration is displayed in the figure below.



 


Installing ISA Server on the VPN Gateway Machines


After putting the basic network infrastructure together, the next step is to install ISA Server on each of the VPN gateways. Perform the following steps to install ISA Server:



  1. Run the ISAAutorun.exe file on the ISA Server CD. Click the Install ISA Server link on the splash page.
  2. Click Continue on the Welcome page.
  3. Enter your CD Key on the CD Key page. Click OK. Click OK on the Product ID page.
  4. Click the I Agree button on the EULA page.
  5. Click the Full Installation button on the installation type page. You can always remove the components you don’t want later.
  6. In this example we are not working with an array, so we’ll select the Yes button on the array warning dialog box.
  7. On the mode page, select the Integrated mode option and click Continue.
  8. Click OK on the dialog box warning you that it must stop the W3SVC. Note that when you restart the computer, the W3SVC will restart.
  9. On the cache settings page, type in a size for your Web cache and click Set. Click OK.
  10. On the LAT page, click on the Construct Table button. Remove the checkmark from the Add the following private ranges checkbox. Put a checkmark in the checkbox that matches your internal interface. Click OK. Click OK on the dialog box informing you of how the LAT was configured. Click OK.
  11. Click OK in the Launch ISA Management Tools dialog box. Click OK on the dialog box that says everything worked out OK.
  12. Install ISA Server Service Pack 1 immediately. After Service Pack 1 is installed, I recommend that you install Feature Pack 1, although its not required. Note that in this lab I have install the Feature Pack.

Running the Local VPN Wizard at the Houston VPN Gateway


We’ll run the Local VPN Wizard on the Houston VPN gateway first. After running the Local VPN Wizard on the Houston VPN gateway, we’ll go over to the Seattle VPN gateway and run the Local VPN Wizard there. Then we’ll take the .vpc files created by the Local VPN gateway Wizards and run them on the Dallas VPN gateway using the Remote VPN gateway Wizard.


Perform the Following Steps to run the Local VPN Gateway Wizard at the Houston site:



  1. Open the ISA Management console. Expand your server name and then right click on the Network Configuration node. Click on the Set Up Local ISA Server VPN Server command. Click Next on the Welcome to the Local ISA Server VPN Configuration Wizard page.
  2. Click Yes on the dialog box asking if you want to start the Routing and Remote Access service.
  3. On the ISA Virtual Private Network (VPN) Identification page, you need to type in a short name for the local network and the remote network. The goal here is to create a meaningful name for the demand dial interface the VPN gateway Wizard will create on this branch office VPN gateway. Notice at the bottom of the dialog box that it say the VPN connection will have the name houston_dallas. This means the demand dial interface sources at houston and ends at dallas. We’ll take a look at the name of the demand-dial interface created at the main office after we run the Remote VPN Wizard there. If I recall correctly, the entire name of the interface must be 15 characters or less, but you can test this out yourself . Click Next.



  1. On the ISA Virtual Private Network (VPN) Protocol page, select the Use L2TP over IPSec, if available. Otherwise, use PPTP. This will cause the demand dial interface to negotiate L2TP/IPSec first, and if both sides don’t support L2TP/IPSec, then they’ll fall back and use PPTP. Even if you don’t have certificates deployed yet, this option will make you ready for when you do. The drawback is that link negotiation may take a little bit longer if you’re using only PPTP at this time. Click Next.



  1. On the Two-way Communication page you can configure the connection so that both sides can dial up. You don’t want both sides to dial up! You only want the main office to dial up, so do not select the Both the local and remote ISA VPN computers can initiate communication option. Click Next.



  1. On the Remote Virtual Private Network (VPN) Network page, you enter the IP address ranges that you want to be reachable from the demand dial interface on this VPN gateway. In the current example, we want the machines in the Houston network to be able to reach the machines on the Dallas network and also machines on the Seattle network. In order for the machines on the Houston network to reach the machines on the Seattle network, the packets will go through VPN connections between Houston and Dallas and then will be forwarded to the Seattle office via the VPN connection between Dallas and Seattle. Click the Add button on this page and enter the start and end address in the IP address range(s) used on each network. Click Next after entering your IP address ranges.



  1. On the Local Virtual Private Network (VPN) Network page, you select which IP address on the external interface of this machine the Remote VPN gateway should call. I recommend you always use the primary address bound to the external interface (the top listed IP address in the list of IP addresses for that interface in the Advanced TCP/IP Properties dialog box). Note that although it appears that you can’t use a FQDN (and you can’t in the Wizard), you can go into the RRAS console and use a FQDN instead of an IP address later. Remind me to show you that when we run the Remote VPN Gateway Wizard. You also use this page of the Wizard to add the local network IDs for this gateway. The Wizard selects a range using the LAT by default. All of your local networks should be in the LAT already, but you can add more IP addresses by clicking the Add button. Click Next to continue.



  1. Type in a file name and password on the ISA VPN Computer Configuration File page. In this example I’m putting the file on a floppy, but you can email to an admin at the other site, which would make more sense in most cases, depending on the level of security you require. You don’t need to type in the “.vpc”, it will be added for you. Passwording of the file is important because the file contains information about your network that would be valuable to an intruder. Click Next to continue.



  1. On the Completing the ISA VPN Setup Wizard page, you can click the Details button to see exactly what the Wizard will do. There’s some interesting information there, so I recommend you take a look. After looking at the information, click the Back button and then click the Finish button.


 


The .vpc file is written and you’re taken back to the ISA Management console. Now we need to make some changes to how the Wizard configured the demand-dial connection and static routes.



  1. Open the Routing and Remote Access console from the Administrative Tools menu.
  2. Expand the server name in the left pane of the console. Right click on the server name and click the Properties command.
  3. Click the IP tab. Select the Static Address pool option. Click the Add button and add some IP addresses that VPN gateways and VPN clients can use when connecting to this machine. Note that the default is to use DHCP. If you have a DHCP server on the directly connected segment, then you can use DHCP. If you have DHCP, but its not on the directly connected segment, then you’ll need to install and configure the DHCP Relay Agent. Click the down arrow in the Adapter drop-down list box and select the internal interface of the ISA Server. Click Apply and then click OK.



  1. Click on the Routing Interfaces node in the left pane of the console. Right click on the demand dial interface in the right pane of the console and click the Properties command. Note on the General tab that there is no server name or IP address. That’s because this server won’t be doing any dialing; it only receives calls from the Remote VPN gateway. Click on the Options tab. Select the Demand dial option and change the Idle time before hanging up setting to never. Change the Redial attempts to 0. Click OK.



  1. In the Routing and Remote Access console, expand the IP Routing node in the left pane of the console and click the Static Routes node. Double click on one of the static routes. Since this server never dials, remove the checkmark from the Use this route to initiate demand-dial connections checkbox. Click OK. Repeat with each of the demand-dial interfaces created by the Wizard.



  1. That’s all we need to do in the Routing and Remote Access console, so you can close it now.

Open the Computer Management console and expand the Local Users and Groups node in the left pane. Click on the Users node and double click on the user account created by the Local VPN Wizard. This account is automatically given dial-in permissions and the password never expires option is set.



The Wizard also creates packet filters to allow the Remote VPN gateway access.



The packet filters created by the Wizard set the Local Computer to a specific IP address on the external interface of the ISA Server. However, when you look at the Remote Computer tab, you’ll see that All remote computers is selected. If you are confident that the remote computer address won’t change, you can change the Remote Computer entry to list only the IP address of the other gateway. However, the Wizard doesn’t set this restriction because you might also want VPN client to server connections on the same machine.



 


Running the Local VPN Wizard at the Seattle VPN Gateway


Now we’ll run the Local VPN Wizard on the Seattle Gateway. We’ll just go through the steps, since I’ve already given you the details when set ran the Local VPN Wizard at the Houston gateway.



  1. Open the ISA Management console, expand your server name, then right click on the Network Configuration node. Click on the Set Up Local ISA VPN Server command. Click Next on the Welcome page.
  2. Click Yes in the dialog box that asks if you want to start the Routing and Remote Access Service.
  3. On the ISA Virtual Private Network (VPN) Identification page, type in seattle for the local network and dallas for the remote network. Click Next.



  1. On the ISA Virtual Private Network (VPN) Protocol page, select the Use L2TP over IPSec, if available. Otherwise, use PPTP. Click Next.
  2. Select the default on the Two-way Communication page and click Next.
  3. On the Remote Virtual Private Network (VPN) Network page, enter the IP addresses for the main office network and the other branch office. Click Next.



  1. On the Local Virtual Private Network (VPN) Network page, select the primary IP address on the external interface of the ISA Server. Make sure the local network IDs are configured in the IP address list at the bottom of the page. Click Next.



  1. On the ISA VPN Computer Configuration File page, type in a name for the file and a password. Click Next.
  2. Click Finish on the Completing the ISA VPN Setup Wizard page.

Now we need to tweak the RRAS Settings:



  1. Open the Routing and Remote Access console from the Administrative Tools menu.
  2. Expand the server name in the left pane of the console. Right click on the server name and click the Properties command.
  3. Click the IP tab. Select the Static Address pool option. Click the Add button and add some IP addresses that VPN gateways and VPN clients can use when connecting to this machine. Use addresses that valid on the ISA Server’s directly connected internal network interface, unless you have reason to use other addresses and understand the consequences. You can also use a DHCP server, as explained earlier.
  4. Click on the Routing Interfaces node in the left pane of the console. Right click on the demand dial interface in the right pane of the console and click the Properties command. Click on the Options tab. Select the Demand dial option and change the Idle time before hanging up setting to never. Change the Redial attempts to 0. Click OK.
  5. In the Routing and Remote Access console, expand the IP Routing node in the left pane of the console and click the Static Routes node. Double click on one of the static routes. Since this server never dials, remove the checkmark from the Use this route to initiate demand-dial connections checkbox. Click OK. Repeat with each of the demand-dial interfaces created by the Wizard.

Running the Remote VPN Wizard on the Main Office VPN Gateway


We’re almost there! Now we need to run the Remote VPN Wizard on the main office VPN gateway. We’ll take the floppy disk created at the Houston and Seattle sites to the Dallas site and use the files on that disk to completely the VPN gateway configuration.



  1. Open the ISA Management console on the Dallas ISA Server. Expand the server name and then right click on the Network Configuration node. Click on the Setup Up Remote ISA VPN Server command.
  2. Click Next on the Welcome to the Remote ISA Server VPN Configuration Wizard page.
  3. Click Yes on the dialog box that asks if you want to start the Routing and Remote Access Service.
  4. On the ISA VPN Computer Configuration File page, click the Browse button and browse for the file. Pick one of the configuration files and click Open. Type in the password you assigned to the file.
  5. Click Finish to complete the configuration. You can see the changes the Wizard will make to the server by clicking on the Details button.
  6. Repeat the process with the other .vpc file.

Now we need to go into the Routing and Remote Access console and tweak the settings.



  1. Open the Routing and Remote Access console from the Administrative Tools menu.
  2. Right click on your server name and click the Properties command.
  3. Click on the IP tab. The same principles apply here as they did when you set up the branch office gateways. The branch office gateways need an IP address, as do other VPN clients that might be calling this gateway. You can use a static address pool or DHCP, just like I described for the remote sites. In this example I’ll use a static address pool. Make sure to change the Adapter setting to be the internal interface of the ISA Server. Click Apply and then click OK.



  1. Click on the Routing Interfaces node in the left pane of the console. Double click on one of the demand dial interfaces. You’ll notice on the General tab that there is an IP address for the server to call. That’s because this VPN gateway will initiate connections with the branch office VPN gateways. Click on the Options tab. Set the Connection type to Persistent connection and set the Redial attempts to 9999. Click OK.


Now you can test your connections. Go to an client behind the main office VPN gateway and ping a host behind one of the VPN gateways. Use the ping –t command so that the client continues pinging. You can open a second command prompt and ping a client behind the other VPN gateways. After a few moments you’ll see the pings pass to both remote networks, as seen in the figure below.



If you click on the General node under the IP Routing node in the RRAS console, and change the view, you’ll see the demand dial interfaces are connected and assigned IP addresses.



Get the Book!


Summary


In this article we went over the procedures involved with putting together a hub and spoke VPN network using the ISA Server Local and Remote VPN Wizards. The Local and Remote VPN Wizards do a lot of work in setting up and configuring the demand dial interfaces required to make the gateway to gateway connections required to join the networks. The ISA Server VPN Wizards also automatically create the packet filters required to allow the inbound VPN calls from other gateways.


I hope you enjoyed this article and found something in it that you can apply to your own network. If you have any questions on anything I discussed in this article, head on over to http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=13;t=001475 and post a message. I’ll be informed of your post and will answer your questions ASAP. Thanks! –Tom

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top