Have Questions about the article?
If you would like to read the next article in this series please go to Creating a Site to Site VPN using ISA 2006 Firewalls at the Main and Branch Office (Part 2)
A site-to-site VPN connection connects two or more networks using a VPN link over the Internet. The VPN site-to-site configuration works just like a LAN router; packets destined for IP addresses at a remote site are routed through the ISA Server 2006 firewall. The ISA firewall acts as a VPN gateway joining two networks over the Internet.
Each site-to-site link can use one of the following VPN protocols:
- IPSec Tunnel Mode
PPTP is the Point-to-Point Tunneling Protocol and can provide a good level of security, depending on the complexity of the password used to authenticate the PPTP connection. You can enhance the level of security applied to a PPTP link by using EAP/TLS-based authentication methods. For information on how to use EAP/TLS authentication for site to site VPN links, check out this link.
The L2TP/IPSec VPN protocol provides a higher level of security because it uses the IPSec encryption protocol to secure the connection and enforces machine authentication as well as user authentication. You can use computer and user certificates to provide an even higher level of security to the L2TP/IPSec connection. If you are not ready to deploy a certificate infrastructure, you can use a pre-shared key to create the site-to-site L2TP/IPSec VPN connection.
ISA 2006 firewall support IPSec tunnel mode for site-to-site VPN connections. Only use IPSec tunnel mode when you need to create a site-to-site link with third-party VPN gateways. There are three primary reasons for avoiding IPSec tunnel mode:
- IPSec tunnel mode is less secure
- IPSec tunnel mode has limited routing abilities on Windows Server 2003 machines
- IPSec tunnel mode can reduce effective throughput through the VPN tunnel by as much as 50%. You can confirm this by reading the ISA 2004 performance white paper.
The figure below depicts how such a site-to-site VPN works:
In this two part article series we will go through procedures required to create an L2TP/IPSec site-to-site link between two ISA Server 2006 firewall machines. The ISALOCAL machine will simulate the Main Office firewall, and the ISA2005BRANCH will simulate the Branch Office firewall. We will use the L2TP/IPSec VPN protocol to create the site-to-site link and both computer certificates and pre-shared keys to support the IPSec encryption protocol.
You will complete the following procedures to create the site-to-site VPN connection:
- Create the Remote Network at the Main Office
- Create the VPN Gateway Dial-in Account at the Main Office
- Create the Remote Network at the Branch Office
- Create the Network Rule at the Branch Office
- Create the Access Rules at the Branch Office
- Create the VPN Gateway Dial-in Account at the Branch Office
- Activate the Site-to-Site Links
The lab network includes two ISA firewalls, one at the main office and one at the branch office, a domain controller that is also running Exchange 2003, and a client machine located behind the branch office ISA firewall, which in this case is Windows Server 2003 SP1. The figure below depicts the machines in this article and their IP addresses.
It is important to note that both the EXCHANGE2003BE machine and the REMOTEHOST machine are DHCP servers. This is required to provide Routing and Remote Access Service IP addresses to assign the calling VPN gateways. If your network does not have a DHCP server, you can use static address pools configured on each of the ISA Server 2006 firewall/VPN gateways. I prefer to use DHCP because it will make it easier to assign on-subnet addresses to the VPN gateways virtual interfaces.
In this article I will not go through the process of deploying certificates and will use a pre-shared key for our L2TP/IPSec site to site VPN connection. I should note here that this is not a best practice and that you should use certificates for machine authentication for your site to site VPNs. There are a number of methods you can use to obtain and install machine certificates and I have gone through this procedure many times on the ISAserver.org Web site.
For a comprehensive review of how to obtain and install machine certificates for ISA firewalls in a site to site VPN scenario, I highly recommend that you check out the ISA Server 2000 VPN deployment kit. While the ISA firewall configuration is quite different, the certificate deployment issues remain unchanged. Check out the ISA Server 2000 VPN Deployment Kit.
Create the Remote Site at the Main Office ISA Firewall
We will begin by configuring the ISA firewall at the Main Office. The first step is to configure the Remote Site Network in the Microsoft Internet Security and Acceleration Server 2006 management console.
Perform the following steps to create the Remote Site Network at the Main Office ISA firewall:
- Open the Microsoft Internet Security and Acceleration Server 2006 management console and expand the server name. Click on Virtual Private Networks (VPN) node.
- Click on the Remote Sites tab in the Details pane. Click on the Tasks tab in the Task pane. Click Add Remote Site Network.
- On the Welcome to the Create VPN Site to Site Connection Wizard page, enter a name for the remote network in the Site to site network name text box. In this example, enter Branch. Click Next.
- On the VPN Protocol page, you have the choice of using
IP Security protocol (IPSec Tunnel Mode,
Layer Two Tunneling Protocol (L2TP) over IPSec or
Point-to-Point Tunneling Protocol.
If you do not have certificates installed on the Main and Branch Office machines and do not plan to deploy them in the future, choose the PPTP option. If you have certificates installed on the Main and Branch Office firewalls, or if you plan to install them in the future, choose the L2TP/IPSec option (you can use the pre-shared key prior to installing the certificates).
Do not use the IPSec option unless you are connecting to a third-party VPN server (because of the low security conferred by IPSec Tunnel Mode site-to-site links and much lower throughput).
In this example, we will use pre-shared keys for our site to site VPN connection in preparation for deploying certificates after the L2TP/IPSec tunnels are established. Select Layer Two Tunneling Protocol (L2TP) over IPSec. Click Next.
- A dialog box appears informing you that you need to create a user account on the main office ISA firewall. This user account will be used by the branch office ISA firewall to authenticate to the main office ISA firewall when the branch office ISA firewall attempts to create its site to site VPN connection to the main office ISA firewall.
The user account must have the same name as the Remote Site Network we’re creating, and that’s defined by the name we included in the first page in the wizard. In this example, we named the site to site Network connection Branch, so the user account we create on the main office ISA firewall must also have the name Branch, and we will need to enable dial-up access for that account. We’ll go through the details of creating that account later in this article. Click OK.
- On the Connection Owner page you select which machine in the array should be the connection own for this site to site VPN connection. This option is only seen in ISA Enterprise Edition and not in Standard Edition. If you have NLB enabled on the array, then you don’t need to manually assign the connection owner, as the integrated NLB process will automatically assign a connection owner when NLB is enabled on the array.
In this example we are not using NLB on the main office array (I’ll do another article on how to do that in the future), and there is only one member of our main office ISA firewall Enterprise Edition array. So we’ll use the default entry, which is the name of the ISA firewall at the main office and click Next. (note, the name of the server in the graphic suggests that this machine is Standard Edition, but it is in fact Enterprise Edition).
- On the Remote Site Gateway page, enter the IP address or FQDN representing the external interface of the remote ISA Server 2006 firewall machine. Note that this is a new feature in the 2006 ISA firewall, in that before you could not use a FQDN. This is helpful as many branch offices must use dynamic addresses and so the only way to reliably connect to the branch office was via a DDNS service.
In this example, we’ll use the FQDN branch.msfirewall.org, so enter this value into the text box. Click Next.
- On the Remote Authentication page, put a checkmark in the Local site can initiate connections to remote site using these credentials check box. Enter the name of the account that you will create on the branch office ISA Server 2006 firewall to allow the Main Office ISA firewall access. In this example, the user account will be named Main (the user account much match the name of the demand-dial interface created on the remote site). When we get to configuring the branch office ISA firewall, we will create a Remote Site Network with the name Main and then create a user account with the name Main on the branch office ISA firewall. The main office ISA firewall will use this account to authenticate to the branch office ISA firewall to create the site to site VPN connection.
The Domain name is the name of the branch office ISA Server 2006 firewall, which in this example is ISA2006BRANCH (if the remote ISA Server 2006 firewall were a domain controller, you would use the domain name instead of the computer name). Enter a password for the account and confirm the password. Write down the password so you will remember it when you create an account later on the branch office ISA 2006 firewall. Click Next.
On the L2TP/IPSec Outgoing Authentication page you select the method you want authenticate your machine against the branch office ISA firewall. In this example we’ll use the Pre-shared key authentication option and then enter a pre-shared key in the Pre-shared key text box. Make sure you write this down, as we’ll need this information when configuring the machine authentication settings at the branch office. Click Next.
- Click Add Range on the Network Addresses page. In the IP Address Range Properties dialog box, enter 10.0.1.0 in the Starting address text box. Enter 10.0.1.255 in the Ending address text box. Click OK.
- Click Next on the Network Addresses page.
- On the Remote NLB page you tell the ISA firewall if NLB is being used on the branch office ISA firewall. If NLB is being used, then you would put a checkmark in the The remote site is enabled for Network Load Balancing checkbox. Then you would add the dedicated IP addresses on the branch office NLB array by clicking the Add Range button.
We’re not running NLB at the branch office, so we’ll remove the checkmark from the The remote site is enabled for Network Load Balancing. In a future article I’ll show you how to create site to site VPNs with the NLB feature enabled. Click Next.
- On the Site to Site Network Rule page you can configure a Network Rule that connects the main and branch office ISA firewall Networks. Remember, the ISA firewall requires that you always have a Network Rule to connect ISA firewall Networks to each other. Even if you create the Networks and create Access Rules, the connections will not work until you create a Network Rule.
The new ISA firewall fixes a problem that people had when creating site to site VPNs with ISA 2004, in that most people forget or didn’t know that they needed a Network Rule in order for it work. The 2006 ISA firewall will ask you if you want to create the Network Rule while still in the wizard, which is a nice convenience and great usability improvement. It’s clear that the ISA firewall’s development team are a lot more mindful of ease of use than the Exchange 2007 beta team!
Select the Create a Network Rule specifying a route relationship option and accept the default name. Note that you also have the I’ll create a Network Rule later option if you want to create the Network Rule manually. Notice that the default option is to set a route relationship between the main and branch office ISA firewall Networks. This is a excellent choice because you have a much wider range of protocol access when using route relationships.
- Another new feature in the 2006 ISA firewall is the Site to Site Network Access Rule page. Here you can configure an Access Rule allowing connections from the main office to the branch office. With the ISA 2004 firewall, you had to do this manually after the wizard was completed, another kudo for the VPN developers on the ISA team!
You also have the option to not create an Access Rules at this time by selecting the I’ll change the Access Policy later option.
When you select the Create an allow Access Rule. This rule will allow traffic cetween the Internal Network and the new site to site Network for all users option, you’ll be given three choices from the Apply the rule to these protocols drop down list. This include:
All outbound traffic: Use this option if you want to allow all traffic from the main office to the branch office.
Selected protocols: Use this option if you want to control which traffic can move from the main office to the branch office. If you want to limit the connections to a selected list of protocols, select this option and click the Add button to all the protocols. Note that at this point you can’t lock down the protocol usage on a per user/group basis. You’ll have to wait until the wizard is complete and then go into the Firewall policy to make that change.
All outbound traffic except selected: Select this option if you want to allow all traffic except for a few protocols. Again, you use the Add button to set which protocols you want to block.
In this example, we’ll being by allowing all protocols. Later, I’ll show you how you can use user/group based authentication to control which users at the main office are allowed to connect to the branch office. This is important, as typically you don’t want average users to access to the branch office, you just want the administrators to get there. We’ll also see how you can use user/group based access controls at the branch office to prevent branch office users from getting adventurous.
Select the All outbound traffic option and click Next.
- Click Finish on the Completing the New Site to Site Network Wizard page.
- In the Remaining VPN Site to Site Tasks dialog box, it informs you that that you need to create a user account with the name Branch. We’ll do that in the next section. Click OK.
You can see the new ISA firewall Remote Site Network in the ISA firewall console, as seen in the figure below.
Select the Remote Site Network and click the Edit Selected Network link in the Task Pane.
In the Branch Properties dialog box, the General tab provides information about the Remote Site Network. You can also enable or disable the site to site VPN connection from this tab.
Have Questions about the article?
On the Server tab, you can change the connection owner for the site to site VPN. You only have to assign a connection owner when NLB isn’t enabled on the external interface of the ISA firewall. If NLB is enabled on the external interface of the ISA firewall, then NLB will automatically assign the connection own for you. Keep in mind that you can create ISA firewall arrays of VPN gateways without NLB enabled on the external interface. However, in most cases you will want to use NLB. We’re not using NLB on the external interface in this article because there is a single ISA Enterprise Edition firewall in our current configuration.
On the Addresses tab, you can change or add addresses to the definition of the Remote Site Network.
On the Remote NLB tab, you specify the dedicated IP addresses on the remote site VPN gateway. You only need to configure these addresses if the Remote Site Network’s VPN gateway is using NLB. We won’t be adding addresses in our example because NLB won’t be enabled at the branch office ISA firewall.
On the Authentication tab you choose the authentication protocol you want the main office ISA firewall to use when authenticating with the branch office VPN gateway. The default is Microsoft CHAP Version 2. The most secure option is EAP, but that requires that you assign user certificates to the accounts used to authenticate with each gateway. Maybe in the future I’ll show you how to do it with 2006 ISA firewall’s, but the procedure is very similar to how you do it in ISA 2004, as shown in http://www.isaserver.org/articles/2004s2seapauth.html.
On the Protocol tab you configure what VPN protocol you want to use to create the site to site VPN tunnel. You can also change the pre-shared key here.
On the Connection tab you can change the credentials used to authenticated to the Remote Site Network’s VPN gateway. You can also configure how long you want the site to site VPN to stay up during idle periods. The default is Never drop the connection.
Close the Branch Properties dialog box.
Right click the Remote Site Network and click the Site to Site Summary command. In the Site to Site Summary dialog box you’ll see summary information about the local site to site settings and the Required site to site settings for the other end of this tunnel.
You can right click in the lower frame and Select All and then Copy to get the information on how to configure the Remote Site VPN gateway.
General VPN Settings Authentication Protocols (one or more of the following):
VPN Network Authentication Protocols (one or more of the following):
Outgoing Authentication Method: Pre-shared secret (the pre-shared key will appear here)
Incoming Authentication Method: Certificate and pre-shared secret (the pre-shared key will appear here)
Remote Gateway Address:
An IP address or a DNS resolvable name.
If NLB is enabled, the VIP of the remote array should be used.
Local User: ISA2006BRANCH\main
Remote Site User: Branch
Site-to-Site Network IP Addresses: 10.0.0.0-10.0.0.255, 10.255.255.255
Routable Local IP Addresses: 10.0.1.0-10.0.1.255
Complete the configuration by clicking Apply to save the changes and then click OK in the Apply New Configuration dialog box.
One last thing you need to confirm is your addressing information for the site to site VPN gateway. You have two options to assign IP addresses:
Static address pool
I prefer to use DHCP because it allows you to assign VPN clients and gateways on-subnet addresses without having to manually remove those addresses from the definition of the default Internet Network, to which the internal interface of the ISA firewall belongs.
For example, suppose the ISA firewall’s internal interface has the IP address 192.168.1.1. The definition of the default Internal Network is 192.168.1.0-192.168.1.255. If we wanted to use a static address pool to assign on-subnet addresses, such as 192.168.1.10-192.168.1.20, we would have to change the definition of the default Internal Network because these addresses we want to assign VPN clients overlap with the definition of the default Internal Network. In this case the definition of the default Internal Network would change to:
On the other hand, if we used DHCP to assign the VPN clients on-subnet addresses, the ISA firewall will automatically remove any address assigned to a VPN client or VPN gateway from the definition of the default Internal Network and dynamically assign them to the definition of the VPN clients Network. This prevents overlap between the VPN Clients Network and the default Internal Network.
You can check on the IP address assignment method by clicking on the Virtual Private Networks (VPN) node in the left pane of the console and then clicking the Defiane Address Assignments link in on the Tasks tab in the Task Pane. You’ll see what appears in the figure below.
Note that the Dynamic Host Configuration Protocol (DHCP) option is only available on ISA Standard Edition or single-member ISA Enterprise Edition arrays. If you choose not to use DHCP, then you must click the Add button to manually add your IP addresses assignment to VPN clients and VPN gateways.
If you use a static address pool, you might want to consider using off-subnet IP addresses. There is no problem with this, but you must make your routing infrastructure aware that in order to reach the network ID used for the VPN clients network that they must forward those connections to the ISA firewall interface from which the connection was received.
In a simple dual NIC configuration, this would be the Internal interface. In a 3+ NIC configuration, you would configure the routers to forward requests to the VPN clients network ID to the ISA firewall interface closest to the routers.
Configure the Main Office Firewall’s Demand-dial Interface to not Register in DNS
A common problem encountered with multihomed computers is that they register multiple interfaces in the DNS. This is especially problematic when machines create site-to-site connections and register their demand-dial interface IP address. This can cause difficult to troubleshoot problems, such as Web Proxy and Firewall clients being unable to connect to the Internet. The reason why the Web Proxy and Firewall clients cannot connect to the Internet in this scenario is that the ISA Server 2004 firewall’s Demand-dial interface registered itself in the DNS, and the Web Proxy and Firewall clients attempt to connect to the ISA Server 2004 firewall via that address.
Perform the following steps to disable dynamic DNS registration for the ISA Server 2004 firewall’s Demand-dial interface:
- At the Main Office ISA Server 2004 firewall, click Start, and point to Administrative Tools. Click Routing and Remote Access.
- In the Routing and Remote Access console, expand the server name in the left pane of the console. Click the Network Interfaces node.
- In the right pane of the Network Interfaces node, right click on Branch, and click Properties.
- On the Branch Properties dialog box, click the Networking tab.
- On the Networking tab, click Internet Protocol (TCP/IP) in the This connection uses the following items list, and click Properties.
- On the Internet Protocol (TCP/IP) Properties dialog box, click Advanced.
- On the Advanced TCP/IP Settings dialog box, click the DNS tab. On the DNS tab, remove the checkmark from the Register this connection’s addresses in DNS check box, and click OK.
- Click OK in the Internet Protocol (TCP/IP) Properties dialog box.
- Click OK in the Branch Properties dialog box.
- Close the Routing and Remote Access console.
Create the VPN Gateway Dial-in Account at the Main Office
A user account must be created on the Main Office ISA firewall that the Branch Office firewall can use to authenticate when it creates the site-to-site connection. This user account must have the same name as the demand-dial interface on the Main Office computer. You will later configure the Branch Office ISA firewall to use this account when it dials the VPN site-to-site link.
Perform the following steps to create the account the remote ISA Server 2006 firewall will use to connect to the Main Office VPN gateway:
- Right click My Computer on the desktop, and click Manage.
- In the Computer Management console, expand the Local Users and Groups node. Right click the Users node, and click New User.
- In the New User dialog box, enter the name of the Main Office demand-dial interface. In our current example, the demand-dial interface is named Branch. Enter Branch into the text box. Enter a Password and confirm the Password. Write down this password because you’ll need to use it when you configure the remote ISA Server 2006 VPN gateway machine. Remove the checkmark from the User must change password at next logon check box. Place checkmarks in the User cannot change password and Password never expires check boxes. Click Create.
- Click Close in the New User dialog box.
- Double click the Branch user in the right pane of the console.
- In the Branch Properties dialog box, click the Dial-in tab. Select Allow access. Click Apply, and then click OK.
Have Questions about the article?
Ask on the Web boards at http://tinyurl.com/nwylg
In this, part 1 of a two part series on creating site to site VPNs using the new ISA firewall, we went over the basic network configuration and then started the configuration for the site to site VPN at the main office ISA firewall. We created the Remote Site Network at the main office ISA firewall and created the user account that the branch office ISA firewall will use when calling the main office ISA firewall.
In the second and last part of the site to site VPN series, we’ll move our attention to the branch office ISA firewall and configure it to connect to the main office ISA firewall. We’ll also create a user account that the main office firewall will be able to use when calling the branch office ISA firewall. Then we’ll test the solution by activating the site to site VPN link and checking the log files and sessions information to see what things look like in the ISA firewall console when the site to site VPN is successfully established.
If you would like to read the next article in this series please go to Creating a Site to Site VPN using ISA 2006 Firewalls at the Main and Branch Office (Part 2)