If you missed the other parts in this article series, check them out at:
If you missed the other parts in this article series, check them out at:
Branch Office Domain Controller Scenario
One of the improvements included with the Enterprise Edition of the 2006 ISA Firewall is the branch office connectivity wizard. In ISA 2000, we had the site to site VPN wizard that made is very easy to create a site to site VPN. However, in ISA 2004, our beloved site to site VPN wizard disappeared, and people had no end of difficulties getting site to site VPN working between two ISA Firewalls. The ISA Firewall dev team heard our pleas, and now we have an excellent site to site VPN wizard, which has been rechristened as the Branch Office Connectivity Wizard.
The Branch Office Connectivity Wizard uses information contained in the Remote Site configuration you create at the main office and uses that information to help make it easier for you to create the site to site VPN. When you’re done with the wizard, a file is created that you can take to the branch office ISA Firewall to create the site to site VPN. In addition to creating the site to site VPN connection, the wizard gives you the option to make the branch office ISA Firewall a domain member, which is an ISA Firewall best practice, since the overall security posture of a domain member ISA Firewall is superior to a standalone ISA Firewall. For proof of this assertion, please read the definitive white paper on ISA Firewall domain membership.
In this article series on using the ISA Firewall Branch Office Connectivity Wizard to create a site to site VPN, I’ll first go through the process of creating the site to site VPN connection using the Wizard, and then after the site to site VPN is complete, we’ll create Access Rules that allow for a branch office domain controller and domain member clients to be located at the branch office and use least privilege to do this.
The figure below shows a high level view of the lab network used in this article series.
There are five machines used in this scenario:
- Dedicated CSS (css2006.msfirewall.org) A dedicated CSS will be used to house the CSS for the ISA Enterprise Edition firewall arrays. There will be two ISA Firewall arrays: one array for the ISA Firewall array at the main office, and an ISA Firewall array at the branch office. We can’t put the main and branch office ISA Firewalls in the same array, because the intra-array communications addresses for all array members must be on the same network ID, and that’s not possible when array members are located at branch offices. However, we can apply enterprise policy to all arrays in the same ISA Firewall enterprise
- Domain Controller (dc.msfirewall.org) All machines in this scenario belong to the same domain, which is msfirewall.org.
- Main office ISA Firewall (isa2006se.msfirewall.org) This machine is the main office ISA Firewall and will belong to an array named Main. This machine is a domain member, and has an internal and external interface.
- Branch office ISA Firewall (isa2006branch.msfirewall.org) This machine is the branch office ISA Firewall and will be made a member of the domain using the branch office connectivity wizard. Windows Server 2003 is installed on this machine and the machine is initially a standalone server. ISA 2006 will be installed on this machine while the machine is a standalone server. After ISA 2006 Enterprise Edition is installed on this machine, we will run the Branch Office Connectivity Wizard on this machine, which will create the site to site VPN and join the machine to the domain. The wizard will also connect the branch office ISA Firewall to the branch office array configured on the main office CSS.
- Branch office Domain Controller This is a branch office domain controller that branch office users will use to authenticate. We will create custom Access Rules that will allow the DC to communicate with the DC at the main office.
We will also make changes to the DNS configuration of the branch office ISA Firewall so that it uses the branch office DC after the configuration is complete.
- Configure the main office DNS server to reject dynamic updates and add static DNS entries for array names and the branch office ISA Firewall
- Install the CSS on the dedicated CSS machine
- Install the Firewall services on the main office ISA Firewall
- Install a local CSS and Firewall Services on the branch office ISA Firewall
- Create the answer file at the main office ISA Firewall that will be used by the branch office connectivity wizard
- Run the Branch Office Connectivity Wizard on the branch office ISA Firewall
- Create Access Rules that allow intradomain communications between the main and branch office domain controllers
- Install the DC at the branch office
- Make DNS changes at the branch office so that the ISA Firewall uses the branch office DC
Notes on Site to Site VPNs
One of the busiest sections of the ISAserver.org Web boards are the VPN sections, and it’s often site to site VPN connection issues that fill up the VPN board posts. I think the reason for this is that a lot of people don’t understand how site to site VPN connections work and what some of the basic requirements for these are.
The VPN Gateway is a VPN Router
When the ISA Firewall is configured as a site to site VPN gateway, the ISA Firewall becomes a router to the network IDs located behind the remote VPN gateway. For example, suppose that the main office is located on network ID 10.1.0.0/16 and the branch office IP addresses are located on network ID 10.2.0.0/16. When a host at the main office needs to connect to the remote network ID, 10.2.0.0/16, it must do so through the VPN gateway at the main office.
In order for this to work, the clients on the main office network must be configured with a gateway address that knows the route to network ID 10.2.0.0/16. The ISA Firewall clearly knows the route, so clients that are configured to use the ISA Firewall as their default gateway will be able to reach the remote network through the ISA Firewall’s VPN gateway. For client systems that do not use the ISA Firewall as their default gateway, those hosts must be configured to use a LAN router that is configured with a routing table entry to forward connections to network ID 10.2.0.0/16 to the ISA Firewall’s LAN IP address.
I see a lot of questions regarding how to “fix” the problems seen when the local and remote sites are addressed using the same network ID. They want to know if there is a way to “fix” this problem. The answer is that there really is no way to fix this problem from a routing point of view, since client systems connecting to local network IDs will never forward connections to a gateway address. Why would clients forward connections to a local network ID to a gateway when that’s not required and violates all tenets of TCP/IP routing principles?
Remember Name Resolution
Another common problem with site to site VPNs is name resolution. Clients at the branch office need to be able to resolve names for computers at the main office, and often at the branch office as well. In order to do this, there needs to be a DNS server infrastructure in place that can resolve all of these names. In addition, you need to think about whether users at the branch office should be able to resolve Internet host names directly, or depend on the ISA Firewall either at the main or branch offices to resolve Internet host names on their behalf.
There are two primary scenarios regarding name resolution at the branch office: one whether there is a domain controller at the branch office and the other where there is no domain controller at the branch office. If the company keeps DCs at the branch office, the hosts at the branch office can use their local domain controller for logging on and name resolution, as that machine can be configured as an Active Directory integrated DNS server. If there is no DC at the branch office, then the clients at the branch offices can be configured to use the main office DNS servers for name resolution for main and branch office servers.
Internet host name resolution is a separate issue. Some organizations will be happy to allow clients to resolve Internet host names themselves (which is required for SecureNET clients), while other organizations may want to have tight control over Internet host name resolution and only allow the ISA Firewall to resolve names on behalf of the clients.
There are many ways to approach Internet host name resolution and it’s impossible for me to give you a hard and fast rule about which is best. However, what I most often do is configure the ISA Firewalls and the hosts on the corporate networks to use Active Directory integrated DNS servers to resolve host names, and then configure the Active Directory integrated DNS to use a forwarder controlled by the company to resolve Internet host names.
An important name resolution issue in a branch office environment is related to WPAD entries. As you know, both the Web proxy and Firewall clients use WPAD entries to automatically discover the local address of the ISA Firewall to use for Web proxy and Firewall client connections to the ISA Firewall. This can be problematic when you use a single DNS infrastructure for the main and branch offices, since you can’t use the single WPAD entry for all locations, assuming that you want hosts to connect to local ISA Firewalls, which is most often the case. On the other hand, if you want all hosts to connect to the Internet through a single main office Firewall array, then it is possible to use a single WPAD entry.
You can solve the problem by creating multiple WPAD entries, one for the main office and one for each of the branch offices and then enabling netmask ordering on the DNS servers. When netmask ordering is enabled, the DNS servers will resolve the WPAD queries to match the network ID from which the request is received. That means that when a host at the main office sends a WPAD query to DNS, the address returned will be one closest to the network ID of the host at the main office and when a WPAD query is received by a host at a branch office, the address returned will be the one closest to the network ID where the branch office host is located.
For more information on how to do this, check out Stefaan Pouseele’s article.
One final DNS issue that you need to consider is the effect of DDNS registrations for VPN gateways. When DDNS is enabled on a DNS server, the ISA Firewall’s RAS interface will register itself in DNS and create connectivity issues for Web proxy and Firewall clients, as they will try to connect to the RAS interface and not the actual LAN address of the ISA Firewall. For this reason, in the scenarios discussed in this article series, we’ll disable DDNS on our DNS servers when creating the VPN gateways and then we’ll investigate whether it’s possible to disable DDNS registration in the demand-dial interface using the RRAS console.
The ISA Firewall supports three VPN protocols for site to site VPNs: IPSec tunnel mode, L2TP/IPSec and PPTP.
IPSec tunnel mode support was introduced with ISA 2004 so that the ISA Firewall could be used as a site to site VPN gateway with third party VPN gateways. This is the only scenario where you should use IPSec tunnel mode, as IPSec tunnel mode is considered to be less secure and lower performance compared to L2TP/IPSec. In addition, routing support for IPSec tunnel mode is abysmal, laborious and limited.
L2TP/IPSec is the preferred site to site VPN protocol when both sides of the site to site VPN are using ISA Firewalls, or when the third party VPN gateway supports L2TP/IPSec. While L2TP/IPSec supports pre-shared keys, in a secure production environment you would used certificate authentication for both the machine accounts and the user accounts used to authenticate the VPN tunnel. While this is a very secure configuration, most companies I’ve worked with prefer to use non-EAP authentication for the demand-dial interface user accounts and use certificate authentication for the machine accounts.
PPTP is the easiest protocol to support for site to site VPN connections. No certificates are required and most ISA Firewall admins find that PPTP “just works”. The drawback is that PPTP is a bit less secure than L2TP/IPSec because the credentials hash is sent over a non-encrypted channel. Therefore, the level of security the PPTP connection can provide is highly dependent password complexity. In addition, PPTP doesn’t provide the non-repudiation features and protection from replay that L2TP/IPSec provides.
When using IPSec tunnel mode to connect to third party VPN gateways, there’s no easy way out. The first thing you should try is the information on using the ISA Firewall with third party VPN gateways at the Microsoft site.
If that guidance does not address your deployment scenario, then you’re going to have to fall back on your understanding of IPSec and make sure that all IPSec parameters are correct on both sides. Even if you get the IPSec parameters correct on both sides, you can run into problems with non-RFC compliant VPN gateways. For example, I’ve heard several reports of Sonicwall firewalls not working with the ISA Firewall VPN gateway because they are not RFC compliant and do not allow the source port for the IKE to be anything than UDP 500. Since the ISA Firewall is RFC compliant, it may use an alternate port and therefore not connect to the Sonicwall device. In the case of the Sonicwall, there may be a software update to make the device RFC compliant.
Another common problem is that the site to site VPN user accounts are not correctly configured to match the demand-dial interface names. When this happens, there are times when it may appear that the site to site VPN is connected, but no traffic passes through the VPN gateways from one network to another, or it might seem like connections are allowed from one network, but not from the other network. The reason for this is that a site to site VPN connection was not established. You can confirm this by opening the RRAS console and checking the Remote Access Clients node in the left pane of the RRAS console. If you see a remote access client connection for the remote VPN gateway, then you know that the a remote access client VPN connection was made, not a site to site VPN connection. Remote access client connections will not allow routing through the VPN gateways.
As for my recommendation, I always recommend that ISA Firewall admins use L2TP/IPSec with machine certificate authentication. However, in most cases, during the initial deployment, I will set up the site to site VPN using a pre-shared key, so as to build confidence in the solution and remove some of the complexities inherent in a PKI. After the site to site VPN solution has completed a short shake down period, I’ll move the customer to machine certificate authentication and away from pre-shared keys.
This article is the first part of a series on how to configure a site to site VPN using the branch office connectivity wizard. In this scenario there will be ISA Firewalls at the main and branch offices as well as domain controllers at the main and branch offices. We’ll see how to use the branch office connectivity wizard included with ISA 2006 Enterprise Edition to create the connection and then we’ll customize access rules, DNS and other configuration parameters to fully support the site to site VPN connection from the branch office. See you next week! –Tom.
If you missed the other parts in this article series, check them out at:
- Creating a Site to Site VPN using the ISA 2006 Firewall Branch Office Connection Wizard (Part 2)
- Creating a Site to Site VPN using the ISA 2006 Firewall Branch Office Connection Wizard (Part 3)
- Creating a Site to Site VPN using the ISA 2006 Firewall Branch Office Connection Wizard (Part 4)
- Creating a Site to Site VPN using the ISA 2006 Firewall Branch Office Connection Wizard (Part 5)
- Creating a Site to Site VPN using the ISA 2006 Firewall Branch Office Connection Wizard (Part 6)
- Creating a Site to Site VPN using the ISA 2006 Firewall Branch Office Connection Wizard (Part 7)