Creating a PPTP Site-to-Site VPN - Dr. Tom Shinderamp;#039;s Configuring ISA Server 1002004 [Electronic resources] نسخه متنی

Creating a PPTP Site-to-Site VPN

Site-to-site VPNs allow you to connect entire networks to one another. This can lead to significant cost savings for organizations that are using dedicated frame relay links to connect branch offices to the main office, or branch offices to one another. The ISA firewall supports site-to-site VPN networking using the following VPN protocols:

PPTP (Point-to-Point Tunneling Protocol)

L2TP/IPSec (Layer Two Tunneling Protocol over IPSec)

IPSec Tunnel Mode

The most secure VPN protocol for site-to-site VPNs is the L2TP/IPSec VPN protocol. L2TP/IPSec allows you to require both machine and user authentication. The second most secure protocol for site-to-site VPNs is a matter of debate. If you have two ISA firewalls, or are connecting an ISA firewall to a Windows RRAS machine, then I recommend that you use PPTP and route certificate authentication. IPSec tunnel mode should only be used when you need to connect to downlevel VPN gateways. The major problem with IPSec tunnel mode is that most downlevel VPN gateway vendors require you to use a pre-shared key instead of certificate authentication, and there are a number of exploits that can take advantage of this situation.

Creating a site-to-site VPN can be a complex process because of the number of steps involved. However, once you understand the steps and why they're performed, you'll find that setting up a site-to-site VPN is a lot easier than you think. In this section we'll begin with creating a site-to-site VPN using the PPTP VPN protocol. After we establish the PPTP link, we'll use the link to connect to the Web enrollment site on the enterprise CA at the main office network and install a machine certificate on the branch office ISA firewall.

In the following exercise, the main office ISA firewall is named ISALOCAL, and the branch office ISA firewall is named REMOTEISA. We will be used the lab network setup described in Chapter 4, so if you don't recall the details of the lab setup, you should take a look at it now. Refreshing your knowledge of the lab setup will help you understand the site-to-site VPN procedures we'll be carrying out.

You'll need to perform the following steps to get the PPTP site-to-site VPN working:

Create the Remote Network at the Main Office A Remote Site Network is what the ISA firewall uses for site-to-site VPN connections. Whenever you connect the ISA firewall to another network using a site-to-site VPN, you must first create the Remote Site Network. The Remote Site Network is then used in Access Rules to control access to and from that Network. The Remote Site Network we create at the main office will represent the IP addresses used at the branch office network.

Create the Network Rule at the Main Office A Network Rule controls the route relationship between Networks. We will configure the site-to-site Network so that there is a Route relationship between the main office and the branch office. We prefer to use Route relationships because not all protocols work with NAT.

Create the Access Rules at the Main Office The Access Rules at the main office will allow all traffic from the main office to reach the branch office and all the traffic from the branch office to reach the main office. On your production network, you will likely want to lock down your rules a bit so that branch office users can only access the information they require at the main office. For example, if branch office users only need to access the OWA sites at the main office, then create Access Rules that only allow users access to the HTTPS protocol to the OWA server.

Create the VPN Gateway Dial-in Account at the Main Office We must create a user account that the branch office ISA firewall can use to authenticate with the main office ISA firewall. This account is created on the main office ISA firewall. When the branch office ISA firewall calls the main office ISA firewall, the branch office will use this user name and password to authenticate with the main office. The branch office ISA firewall's demand-dial interface is configured to use this account.

Create the Remote Network at the Branch Office Once the site-to-site VPN configuration is done at the main office, we move our attention to the branch office's ISA firewall. At the branch office ISA firewall, we begin by creating the Remote Site Network that represents the IP addresses in use at the main office. We'll use this Network Object to control traffic moving to and from the main office from the branch office.

Create the Network Rule at the Branch Office As we did at the main office, we need to create a Network Rule controlling the route relationship for communications between the branch office network and the main office network. We'll configure the Network Rule so that there is a Route relationship between the branch office and the main office.

Create the Access Rules at the Branch Office We will create two Access Rules on the branch office ISA firewall. One allows all traffic to the branch office to reach the main office, and the second rule allows all traffic from the main office to reach the branch office. In a production environment you might wish to limit what traffic can leave the branch office to the main office. Note that you can set these access controls at either or both the branch office or the main office ISA firewall. We prefer to implement the access controls at both sites, but the access controls at the main office are more important because you often may not have change controls tightly regulated at the branch offices.

Create the VPN Gateway Dial-in Account at the Branch Office We need to create a user account on the branch office ISA firewall that the main office ISA firewall can use to authenticate when it calls the branch office ISA firewall. The demand-dial interface on the main office ISA firewall uses this account to authenticate with the branch office ISA firewall.

Activate the Site-to-Site Links We'll activate the site-to-site VPN connection by initiating a connection from a host on the branch office to a host on the main office network.

Create the Remote Site Network at the Main Office

We 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 2004 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 2004 management console and expand the server name. Click Virtual Private Networks (VPN).

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 New Network Wizard page, enter a name for the remote network in the Network name text box. In this example, we will name the remote network Branch. This name is very important because this will be the name of the demand-dial interface created on the ISA firewall at the main office, and it will be the name of the user account that the branch office ISA firewall will use to connect to the main office ISA firewall. 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 and 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, you should 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 until you get the certificates installed). Do not use the IPSec option unless you are connecting to a third-party VPN gateway (because of the low security conferred by IPSec tunnel mode site-to-site links which typically depend on pre-shared keys). In this example, we will configure a site-to-site VPN using PPTP, so select the Point-to-Point Tunneling Protocol (PPTP) (as shown in Figure 9.25). Click Next.

Figure 9.25: Selecting the VPN Protocol

On the Remote Site Gateway page, enter the IP address on the external interface of the remote ISA firewall. In this example, the IP address is 192.168.1.71, so we will enter this value into the text box.

Note that you can also use a fully-qualified domain name in this text box. This is helpful if the branch office uses a dynamic address on its external interface and you use a DDNS service like TZO (www.tzo.com). We have been using TZO for years and highly recommend their service. Click Next.

On the Remote Authentication page, put a checkmark in the Local site can initiate connections to remote site using these credentials checkbox. Enter the name of the account that you will create on the remote ISA firewall to allow the main office ISA firewall to authenticate to the branch office ISA firewall.

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; we haven't created that demand-dial interface yet, but we will when we configure the branch office ISA firewall). The Domain name is the computer name of the branch office ISA firewall, which in this example is REMOTEISA (if the remote ISA firewall were a domain controller, you would use the domain name instead of the computer name, since there are no local accounts stored on a domain controller). Enter a password for the account and confirm the password as shown in Figure 9.26. Make sure that you write down the password so you will remember it when you create the account later on the branch office ISA firewall. Click Next.

Figure 9.26: Setting Dial-in Credentials

Read the information on the Local Authentication page, and click Next.

The information on this page reminds you that you must create a user account on this ISA firewall that the branch office ISA firewall can use to authenticate when it initiates a site-to-site VPN connection. If you forget to create the user account, the authenticate attempt will fail and the site-to-site VPN link will not establish.

Click Add 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.

This is a critical step in your site-to-site VPN configuration. You should include all addresses on the Remote Site Network. While you might create Access Rules that allow access only to a subset of addresses on that network, you should still include all addresses in use on that network. Also, keep in mind any network IDs that are reachable from the branch office ISA firewall. For example, there may be multiple networks reachable from the LAN interface (any of the internal or DMZ interfaces of the branch office ISA firewall). Include all those addresses in this dialog box. See Figure 9.27.

Figure 9.27: Configuring the IP Address Range for the Remote Site Network

Click Next on the Network Addresses page.

Click Finish on the Completing the New Network Wizard page.

Create the Network Rule at the Main Office

The ISA firewall must know how to route packets to the branch office network. There are two options: Route and NAT. A Route relationship routes packets to the branch office and preserves the source IP address of the clients making a connection over the site-to-site link. A NAT relationship replaces the source IP address of the client making the connection. In general, the route relationship provides a higher level of protocol support, but the NAT relationship provides a higher level of security because it hides the original source IP address of the host on the NATed side.

One important reason for why you might want to use a Route relationship is if you plan to have domain members on the Remote Site Network. Kerberos authentication embeds the source IP address in the payload and has no NAT editor or application filter to make this work.

In this example, we will use a Route relationship between the main and branch office so that we have the option later to make machines on the branch office network members of the main office's Active Directory domain. Perform the following step to create a Network Rule to control the routing relationship between the main office and branch office networks:

Expand the Configuration node in the left pane of the console. Click Networks.

Click on the Network Rules tab in the Details pane. Click on the Tasks tab in the Task pane. Click Create a New Network Rule.

On the Welcome to the New Network Rule Wizard page, enter a name for the rule in the Network rule name text box. In this example, we will call the rule Main to Branch. Click Next.

On the Network Traffic Sources page, click Add.

In the Add Network Entities dialog box, click the Networks folder. Double-click on the Internal network. Click Close.

Click Next on the Network Traffic Sources page.

On the Network Traffic Destinations page, click Add.

In the Add Network Entities dialog box, double-click the Branch network. Click Close.

Click Next on the Network Traffic Destinations page.

On the Network Relationship page (Figure 9.28), select the Route relationship.

Figure 9.28: The Network Relationship Page

Click Finish on the Completing the New Network Rule Wizard page.

Create the Access Rules at the Main Office

We want hosts on both the main and branch office networks to have full access to all resources on each network. We must create Access Rules allowing traffic from the main office to the branch office and from the branch office to the main office.

Perform the following steps to create Access Rules allowing traffic to move between the main and branch offices:

Click the Firewall Policy node in the Microsoft Internet Security and Acceleration Server 2004 management console. Click the Tasks tab in the Task pane. Click Create New Access Rule.

On the Welcome to the New Access Rule Wizard page, enter a name for the rule in the Access Rule name text box. In this example, enter Main to Branch. Click Next.

On the Rule Action page, select Allow, and click Next.

On the Protocols page, select All outbound traffic in the This rule applies to list (Figure 9.29). Click Next.

Figure 9.29: The Protocols page

On the Access Rule Sources page, click Add.

In the Add Network Entities dialog box, click the Networks folder, and double-click the Internal network. Click Close.

Click Next on the Access Rule Sources page.

On the Access Rule Destinations page, click Add.

In the Add Network Entities dialog box, click on the Networks folder, and double-click on the Branch network. Click Close.

Click Next on the Access Rule Destinations page.

On the User Sets page, accept the default entry All Users, and click Next.

Click Finish on the Completing the New Access Rule Wizard page.

The second rule allows hosts on the branch office network access to the main office network:

Click the Tasks tab in the Task pane. Click Create New Access Rule.

On the Welcome to the New Access Rule Wizard page, enter a name for the rule in the Access rule name text box. In this example, enter Branch to Main. Click Next.

On the Rule Action page, select Allow and click Next.

On the Protocols page, select All outbound protocols in the This rule applies to list. Click Next.

On the Access Rule Sources page, click Add.

In the Add Network Entities dialog box, click the Networks folder, and double-click the Branch network. Click Close.

Click Next on the Access Rule Sources page.

On the Access Rule Destinations page, click Add.

In the Add Network Entities dialog box, click on the Networks folder, and double-click on the Internal network. Click Close.

Click Next on the Access Rule Destinations page.

On the User Sets page, accept the default entry All Users, and click Next.

Click Finish on the Completing the New Access Rule Wizard page. Figure 9.30 shows the resulting firewall policy.

Figure 9.30: The Resulting Firewall Policy

The last step is to enable access for VPN clients (although technically, the branch office VPN gateway isn't really a remote access VPN client):

Click on the Virtual Private Network node in the left pane of the console.

Click the VPN Clients tab in the Details pane. Click the Tasks tab in the Task pane. Click Enable VPN Client Access.

Click OK in the ISA 2004 dialog box informing you that the Routing and Remote Access service must be restarted.

Click Apply to save the changes and update the firewall policy.

Click OK in the Apply New Configuration dialog box.

Create the VPN Gateway Dial-in Account at the Main Office

You must create a user account on the main office firewall that the branch office firewall can use to authenticate the site-to-site VPN link. 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 2004 to use this account when it dials the VPN site-to-site link.

User accounts and demand-dial interface naming conventions are a common source of confusion for ISA firewall administrators. The key here is that the calling VPN gateway must present credentials with a user name that is the same as the name of the demand-dial interface answering the call. In Figure 9.31, you can see how this works when the main office calls the branch office and when the branch office calls the main office.

Figure 9.31: Demand Dial Interface Configuration on Local and Remote Sites

The name of the demand dial interface at the main office is Branch. When the branch office calls the main office, the user account the branch office uses to authenticate with the main office ISA firewall is Branch. Because the name of the user account is the same as the name of the demand-dial interface, the main office ISA firewall knows that it's a remote VPN gateway making the call, and the ISA firewall does not treat this as a remote access VPN client connection.

When the main office calls the branch office, it presents the user credentials of a user named Main, which is the same name as the demand-dial interface on the branch office ISA firewall. Because the name of the user account presented during authentication is the same as the name of the demand-dial interface, the branch office ISA firewall knows that this is a VPN gateway connection (VPN router) and not a remote access client VPN connection. Figure 9.31 shows the demand dial interface configuration.

Perform the following steps to create the account the remote ISA 2004 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 branch office ISA firewall. Remove the checkmark from the User must change password at next logon checkbox. Place checkmarks in the User cannot change password and Password never expires checkboxes. 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.

Restart the ISA firewall computer.

Create the Remote Site Network at the Branch Office

We can now turn our attention to the branch office ISA firewall. We will repeat the same steps we performed on the main office ISA firewall, but this time we begin by creating a Remote Site Network on the branch office firewall that represents the IP addresses used on the main office network.

Perform the following steps to create the Remote Site Network at the branch office:

Open the Microsoft Internet Security and Acceleration Server 2004 management console and expand the server name. Click the Virtual Private Networks (VPN) node.

Click Remote Sites in the Details pane. Click Tasks in the Task pane. Click Add Remote Site Network.

On the Welcome to the New Network Wizard page, enter a name for the remote network in the Network name text box. In this example, we will name the remote network Main. Click Next.

On the VPN Protocol page, select Point-to-Point Tunneling Protocol (PPTP), and click Next.

On the Remote Site Gateway page, enter the IP address on the external interface of the main office ISA firewall. In this example, the IP address is 192.168.1.70, so we will enter this value into the text box. Click Next.

On the Remote Authentication page, put a checkmark by Local site can initiate connections to remote site using these credentials. Enter the name of the account that you created on the main office ISA firewall to allow the branch office VPN gateway access.

In this example, the user account is named Branch (the user account much match the name of the demand-dial interface created at the main office). The Domain name is the name of the remote ISA 2004 firewall computer, which, in this example, is ISALOCAL (if the remote ISA firewall were a domain controller, you would use the domain name instead of the computer name). Enter the password for the account and confirm the password as shown in Figure 9.32. Click Next.

Figure 9.32: Configure Dial-in Credentials

Read the information on the Local Authentication page, and click Next.

Click Add on the Network Addresses page. In the IP Address Range Properties dialog box, enter 10.0.0.0 in the Starting address text box. Enter 10.0.0.255 in the Ending address text box. Click OK.

Click Next on the Network Addresses page.

Click Finish on the Completing the New Network Wizard page.

Create the Network Rule at the Branch Office

As we did at the main office, we must create a Network Rule that controls the routing relationship between the branch and the main office networks. We will configure a route relationship so that we can get the highest level of protocol support.

Perform the following steps to create the Network Rule at the branch office:

Expand the Configuration node in the left pane of the console. Click on Networks.

Click on the Network Rules tab in the Details pane. Click on the Tasks tab in the Task pane. Click Create a New Network Rule.

On the Welcome to the New Network Rule Wizard page, enter a name for the rule in the Network rule name text box. In this example, we will call the rule Branch to Main. Click Next.

On the Network Traffic Sources page, click Add.

In the Add Network Entities dialog box, click the Networks folder. Double-click on the Internal network. Click Close.

Click Next on the Network Traffic Sources page.

On the Network Traffic Destinations page, click Add.

In the Add Network Entities dialog box, double-click on the Main network. Click Close.

Click Next on the Network Traffic Destinations page.

On the Network Relationship page, select Route.

Click Finish on the Completing the New Network Rule Wizard page. Figure 9.33 shows the new Network Rule.

Figure 9.33: The New Network Rule

Create the Access Rules at the Branch Office

We will create two Access Rules, one allowing all traffic from the branch office to the main office, and a second allowing all traffic from the main office to the branch office.

Perform the following steps to create Access Rules allowing all traffic to move between the branch and main office networks:

Click Firewall Policy in the left pane of the console. Click the Tasks tab in the Task pane. Click Create New Access Rule.

On the Welcome to the New Access Rule Wizard page, enter a name for the rule in the Access Rule name text box. In this example, we will call it Branch to Main. Click Next.

On the Rule Action page, select Allow, and click Next.

On the Protocols page, select All outbound traffic in the This rule applies to list. Click Next.

On the Access Rule Sources page, click Add.

In the Add Network Entities dialog box, click the Networks folder and double-click the Internal network. Click Close.

Click Next on the Access Rule Sources page.

On the Access Rule Destinations page, click Add.

In the Add Network Entities dialog box, click on the Networks folder, and then double-click on the Main network. Click Close.

Click Next on the Access Rule Destinations page.

On the User Sets page, accept the default entry All Users, and click Next.

Click Finish on the Completing the New Access Rule Wizard page.

The second rule allows hosts on the main office network access to the branch office network:

Click the Tasks tab in the Task pane. Click Create New Access Rule.

On the Welcome to the New Access Rule Wizard page, enter a name for the rule in the Access Rule name text box. In this example, we will call it Main to Branch. Click Next.

On the Rule Action page, select Allow, and click Next.

On the Protocols page, select All outbound traffic in the This rule applies to list. Click Next.

On the Access Rule Sources page, click Add.

In the Add Network Entities dialog box, click the Networks folder and double-click the Main network. Click Close.

Click Next on the Access Rule Sources page.

On the Access Rule Destinations page, click Add.

In the Add Network Entities dialog box, click the Networks folder, and double-click the Internal network. Click Close.

Click Next on the Access Rule Destinations page.

On the User Sets page, accept the default entry All Users and click Next.

Click Finish on Completing the New Access Rule Wizard page. Figure 9.34 shows the resulting firewall policy.

Figure 9.34: The Resulting Firewall Policy

The next step is to enable access for VPN clients:

Click on the Virtual Private Network node in the left pane of the console.

Click the VPN Clients tab in the Details pane. Click the Tasks tab in the Task pane. Click Enable VPN Client Access.

Click OK in the ISA 2004 dialog box informing you that the Routing and Remote Access service must be restarted as shown in Figure 9.35.

Figure 9.35: Restarting the Routing and Remote Access Service

Click Apply to save the changes and update the firewall policy.

Click OK in the Apply New Configuration dialog box.

Create the VPN Gateway Dial-in Account at the Branch Office

We must create a user account the main office VPN gateway can use to authenticate when it initiates the VPN site-to-site connection to the branch office. The user account must have the same name as the demand-dial interface created on the branch office machine, which, in this example, is Main.

Perform the following steps to create the account the remote ISA 2004 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 Main. Enter Main into the text box. Enter a Password and confirm the Password. This is the same password you used when you created the Remote Site Network at the Main office. Remove the checkmark from the User must change password at next logon checkbox. Place checkmarks in the User cannot change password and Password never expires checkboxes. Click Create.

Click Close in the New User dialog box.

Double-click the Main user in the right pane of the console.

In the Main Properties dialog box, click the Dial-in tab (Figure 9.36). Select Allow access. Click Apply, and then click OK.

Figure 9.36: The Dial-in Tab

Restart the ISA firewall computer.

Activate the Site-to-Site Links

Now that both the main and branch office ISA firewalls are configured as VPN routers, you can test the site-to-site connection.

Perform the following steps to test the site-to-site link:

At the remote client computer behind the remote ISA 2004 firewall machine, click Start, and then click Run.

In the Run dialog box, enter cmd in the Open text box, and click OK.

In the command prompt window, enter ping -t 10.0.0.2, and press ENTER

You will see a few pings time out, and then the ping responses will be returned by the domain controller on the main office network.

Perform the same procedures at the domain controller at the main office network, but this time ping 10.0.1.2.