If you would like to read the other parts in this article series please go to:
- Terminating VPN Connections in Front of the ISA Firewall (Part 1)
- Terminating VPN Connections in Front of the ISA Firewall (Part 2)
In the first two parts of this three part series on how to terminate VPN client connections in front of the ISA Firewall, we began with a discussion of the issues related to the location of VPN client termination and a variety of scenarios of how VPN clients can connect to the Internet and the internal network through this connection. In the second part of the series, we performed a number of configuration steps on the ISA Firewall to enable VPN clients access to the Internal Network behind the ISA Firewall and the Internet.
As a quick review of what we needed to do on the ISA Firewall to get things set up before creating our Access Rules, we performed the following procedures:
- Configure the front-end NAT device to terminate VPN client connections
- Create an ISA Firewall Network defining DMZ Network and enable the Web proxy listener for that ISA Firewall Network
- Create a Network Rule creating a Route relationship between the DMZ and the default Internal Network behind the ISA Firewall
In this article we’ll finish up by configuring the VPN Client software and then making the connection to the front-end NAT device. We’ll connect to the Internal Network behind the ISA Firewall and to the Internet using the connection. Then we’ll look at some special scenarios where you might want to configure Web proxy and Firewall client configuration for additional security.
Access Rules on the ISA Firewall
I first thought that I might describe a complex set of firewall rules that enforce least privilege between the DMZ and the default Internal Network. I also thought that I would provide information on least privilege access between the default Internal Network and the DMZ and the Internet. However, it later occurred to me that since we’re choosing to terminate the VPN connection in front of the ISA Firewall, instead of at the ISA Firewall, security is secondary consideration, since it would be far more secure to terminate the connection at the ISA Firewall. Given this fact, I’m going to create a single rule that controls access to and from the DMZ, the default Internal Network, and the Internet.
You can see this rule in the figure below. This rule allows:
- All traffic to pass from the DMZ to the default External Network
- All traffic to pass from the DMZ to the default Internal Network
- All traffic to pass from the default Internal Network to the DMZ
- All traffic to pass from the default Internal Network to the default External Network
In production, I would highly recommend that you lock down firewall policy past what I’ve described here. There’s no reason that internal users should have access to all protocols and sites on the Internet, for example. The same would be true for the DMZ – the VPN clients that connect to the VPN server in front of the ISA Firewall are DMZ hosts, so if you want to control what those VPN clients can access on the default Internal Network, you should create more restrictive rules controlling what VPN users on the DMZ can access on the default Internal Network.
Let me know if you want guidance in how to create a more locked down firewall policy. If there’s enough interest, I’ll do a follow up article on a least privilege firewall policy. Send your requests to [email protected]
Keep in mind that you can use the Firewall client on the VPN client computers and gain user/group based access control over what VPN users access on the default Internal Network. That’s because our DMZ Network can be configured to use a Firewall client listener. I’ll go over those details later.
Figure 1
Configuring the VPN Client software
Configuring the VPN client software will vary with the type of VPN client software you’re working with. In this example we’ll be using the Windows VPN client software, since we’re terminating the VPN client connection at an RRAS NAT server in front of the ISA Firewall. The type of VPN client software you’re using is important, because different VPN clients offer different features. The same is true for the VPN server that you’re using – it may support features that the RRAS server doesn’t support and the RRAS VPN server may support features that your VPN server doesn’t support.
After creating the new VPN client connection, open the connection and click the Properties button. On the General tab you’ll see the IP address or FQDN you configured the client to use to make the VPN connection. An example of this is seen in the figure below.
Figure 2
In the VPN client connection’s Properties dialog box, click the Networking tab. On the Networking tab, you’ll see the default Type of VPN setting is Automatic. This means that the VPN client will try L2TP/IPSec first, and if that doesn’t work, it will drop back to PPTP. Our RRAS VPN server is configured to support only PPTP at this time, so that’s what our VPN client is going to use for our connections.
On the Networking tab, click the Internet Protocol (TCP/IP) entry and click the Properties button.
Figure 3
This brings up the Internet Protocol (TCP/IP) Properties dialog box. Notice the default setting is to have the VPN client use automatic address assignment by the VPN server, which is part of the IPCP (Internet Protocol Control Protocol) process. Click the Advanced button.
Figure 4
In the Advanced TCP/IP Settings dialog box, on the General tab, you have a single option: Use default gateway on remote network. When this option is enabled (the default setting), split tunneling is disabled at the client. When split tunneling is disabled, all requests to remote networks, including the Internet, are sent over the VPN link. If split tunneling is enabled (the checkmark is removed from the Use default gateway on remote network checkbox), then traffic destined for the corporate network is sent over the VPN tunnel and traffic destined for the Internet it sent directly to the Internet over the client’s actual interface, not the VPN interface.
Figure 5
The decision on whether to allow split tunneling depends on your security sensitivity as well as the capabilities and configuration of your VPN client and VPN server. In general, split tunneling should be avoided as it’s a major security issue; it allows intruders to easily route connections through the VPN client computer to the corporate network. On the other hand, you may want to allow split tunneling to reduce the bandwidth utilization on your corporate Internet connection.
Some things you might want to consider when deciding whether or not to enable split tunneling:
- It’s a major security issue, so if you’re looking for a secure solution, split tunneling should be disabled
- If your VPN server doesn’t allow you to “loop back” to the Internet over the VPN connection, then you won’t be able to access the Internet unless you choose an alternate solution
- If your VPN server does allow you to “loop back” to the Internet over the VPN connection, then you might want to disable split tunneling and access the Internet over the VPN link – but be aware that the VPN clients will use bandwidth and that bandwidth won’t be available to clients on the corporate network
- If your VPN server does not allow you to “loop back” to the Internet, you might want to consider configuring the VPN clients as Web proxy clients of the ISA Firewall; this will allow the VPN clients access to the corporate network behind the ISA Firewall and access Web sites on the Internet using the Web proxy client configuration. The Web proxy client configuration will also allow Web proxy access into the default Internal Network behind the ISA Firewall
- If your VPN server does not allow you to “loop back” to the Internet, you might want to consider making the VPN clients Firewall clients of the ISA Firewall. When the VPN clients are configured as Firewall clients of the ISA Firewall, they will have access to virtually allow TCP and UDP protocols that are called by Winsock applications.
The most simple solution is to enable split tunneling, but that’s also the least secure solution. The second most simple solution is when your VPN server allows you to “loop back” through it to connect to the Internet; however, this is a less than ideal solution from a security point of view, since you can’t enforce firewall policy over these connections. The most complex solution is to configure the clients as Web proxy and Firewall clients – this allows you to control what the VPN clients do when connected to your corporate network over the VPN link.
The remainder of this article will discuss how you can configure your infrastructure and clients to support the Web proxy and Firewall client configurations for your VPN clients that connect to a VPN server in front of the ISA Firewall.
DNS Configuration
Split DNS, split DNS, split DNS, everyone needs a split DNS!
I’ve written many times on the value of a split DNS. You can read about split DNS in two seminal articles I’ve done on the subject at:
http://www.isaserver.org/tutorials/2004illegaltldsplitdns.html
http://www.isaserver.org/tutorials/You_Need_to_Create_a_Split_DNS.html
The goal of the split DNS is to enable name resolution to be transparent, regardless of the user’s location. In most cases, we use a split DNS to support users moving between the corporate network and the Internet, so that the same names can be used when the user is on the Internet and when he is on the corpnet. The split DNS insures that the same name will resolve to a different IP address based on the user’s location.
In the VPN client scenario, the VPN client isn’t an Internet host, since it has an IP address valid on the DMZ network. What we want to do in this scenario is create a split DNS so that the WPAD entries and the name of the ISA Firewall resolve to a different IP address based on the user’s location.
For example, if the name of the ISA Firewall is isa2006se.msfirewall.org, we want users on the default Internal Network to resolve that name to the internal IP address on the ISA Firewall. However, we want VPN clients to resolve the name isa2006se.msfirewall.org to the IP address on the external interface of the ISA Firewall. This is the IP address that the DMZ ISA Firewall Network listens for both it’s Web proxy and Firewall client listeners.
In order to get this to work, we need to create two WPAD Host (A) records and two Host (A) records for the name of the ISA Firewall, as seen in the figure below. One WPAD and Host (A) record for the name of the ISA Firewall resolve to the internal address of the ISA Firewall, and one WPAD and Host (A) record for the name of the ISA Firewall resolve to the external address of the ISA Firewall. Internal users will resolve the name to the internal IP address, and VPN clients will resolve the name to the external IP address.
Figure 6
You might now be asking yourself how you can force the VPN clients to resolve the names to the external IP address and the internal clients to resolve the names to the internal IP address. The answer is to configure the DNS server to use netmask ordering. When netmask ordering is enabled, if there are multiple entries for the same name, then the record that most closely matches the network ID of the source host will be the one returned to the client.
You can configure netmask ordering in the Properties dialog box of the DNS server. Click on the Advanced tab in the DNS server Properties dialog box and put a checkmark in the Enable netmask ordering checkbox and click OK.
Figure 7
In order to support WPAD based autodiscovery of the ISA Firewall’s Web proxy and Firewall client listeners, the client needs to be able to fully qualify the name WPAD. If the machine isn’t configured to fully qualify the WPAD name, then the unqualified name WPAD is sent to the DNS server and the name resolution attempt fails. If your VPN clients are all domain joined machines, then you won’t have a problem, since they will automatically fully qualify the request using the domain name suffix of your Active Directory domain.
However, if your clients are not configured as domain members, then they need to be configured to append a domain name suffix to their DNS requests which is the same DNS suffix used by your Active Directory domain on the internal network.
You can append DNS suffixes without joining a domain by opening the System Properties dialog box and clicking on the Computer Name tab. On the Computer Name tab, click the Change button.
Figure 8
In the Computer Name Changes dialog box, click the More button.
Figure 9
In the DNS Suffix and NetBIOS Computer Name dialog box, enter the internal Active Directory DNS suffix name in the Primary DNS suffix on this computer text box and click OK.
Figure 10
You’ll have to restart the computer for the new DNS suffix to take effect.
Web Proxy Client Support
The ISA Firewall must be configured to allow Web proxy client connections by enabling the Web proxy listener. Double click on the DMZ ISA Firewall Network in the ISA Firewall console and click on the Web proxy tab. Put a checkmark in the Enable Web Proxy client checkbox and put a checkmark in the Enable HTTP checkbox. The default Web proxy listener port is 8080 and you should leave it as the default. Change the default port only if you have very compelling reasons to change it.
Figure 11
Do the same thing with the Internal ISA Firewall Network. Click the Web Proxy tab in the Internal Properties dialog box and put checkmarks in the Enable Web Proxy clients and Enable HTTP checkboxes and leave the default listening port to TCP 8080.
Figure 12
Now that the ISA Firewall’s Web Proxy listeners are enabled, the next step is to get the VPN clients configured to be Web proxy clients. In this example we’ll do the configuration manually, but in a production environment, you might prefer to use the Connection Manager Administration Kit (CMAK) to create the VPN connections. The CMAK provides you the option to set a Web proxy setting for the VPN clients, so you’ll be able to replicate what we’re doing here.
In Internet Explorer, open the Internet Properties dialog box and click the Connections tab. Notice that you’re VPN connection appears in the Dial-up and Virtual Private Network settings frame. Select your VPN connection and click the Settings button.
Figure 13
In the VPN Settings dialog box, put a checkmark in the Automatically detect settings checkbox. When the VPN client establishes a connection to the VPN server, the VPN client will then issue a WPAD query to the DNS server assigned to the VPN client by the VPN server. This will allow the VPN client to automatically discover the Web proxy listener that should be used by the VPN clients. Click OK to save the changes.
Figure 14
The figure below shows what you would see in the ISA Firewall’s monitoring console when the VPN client connects to the Web proxy listener. In this example, the VPN client is assigned the IP address 10.0.1.104 and it connects to the DMZ ISA Firewall Network’s Web proxy listener at 10.0.1.2 on TCP port 8080.
Figure 15
Note that when you configure hosts to be Web proxy clients, you can create Access Rules that control what users can access on the Internet and on the Internal Network based on the users’ accounts or group membership. I’m not going into the details of such as configuration, since this article is aimed at how to allow termination of the VPN connection in front of the ISA Firewall instead of at the ISA Firewall. However, it is possible to set restrictive policy for these VPN clients for Web access when they are configured as VPN clients.
Firewall Client Support
Firewall client systems need to connect to the Firewall client listener on the ISA Firewall. The Firewall client listener is configured on a per-ISA Firewall Network basis. In the ISA Firewall console, double click on the default Internal Network and click on the Firewall Client tab.
Put a checkmark in the Enable Firewall client support for this network checkbox.
In the Firewall client configuration frame, enter the fully qualified domain name of the ISA Firewall in the ISA Server name or IP address text box. We must enter the FQDN, and not the IP address, because we want to take advantage of our split DNS, and our split DNS is based on DNS name resolution. When WPAD autodiscovery takes place, the client system will resolve the name wpad.domainname.com to the IP address of the ISA Firewall and the name of the ISA Firewall is returned to the Firewall client. It is this name that you enter into the ISA Server name or IP address on the Firewall client tab for the ISA Firewall Network that the Firewall client will use to connect to the ISA Firewall’s Firewall client listener.
In the Web browser configuration on the Firewall client computer frame, put a checkmark in the Use a Web proxy server checkbox. When the Firewall client connects to the ISA Firewall, it will also set the Web proxy client configuration on the client. However, this should have no effect on the VPN client connection, since the Web proxy server used by the VPN client is the one configured for the VPN connection. The setting you put on this tab affects only the configuration on the actual NIC, not the VPN link. However, in order to prevent Web proxy name collision and any unintended consequences, it’s best to put the ISA Firewall’s actual FQDN in the ISA Server name or IP address text box under the Use a Web proxy server option.
Figure 16
If you noticed a little hand waving in the above explanation, you’re right. I know that autodiscovery will be used by the VPN client to find the Web proxy listener, since we configured that in the browser. However, what I do not know is what might happen if we had a Web proxy server name collision if we had one name configured on the VPN client settings and another name set for the actual NIC. If you want you can test this for yourself. Let me know what you find out!
Repeat the above process on the DMZ ISA Firewall Network. Remember, even though we used the same name for internal clients and VPN clients, the name will resolve to a different address based on the location of the client. VPN clients will connect to the listener on the external interface of the ISA Firewall and internal clients will connect to the internal interface of the ISA Firewall for their Firewall client listener.
Figure 17
I might point out here that this is an “off label” use of the Firewall client and Firewall client listener. This scenario, where the VPN clients connect to a listener on the external interface of the ISA Firewall is similar to the single NIC ISA Firewall implementation of the Firewall client. Yes, its true, this is not a supported configuration (not officially supported by PSS), but it does work and there is no technical reason for it not working. However, the ISA Firewall team has not tested this configuration and thus they can’t support it because they’re not sure what will work and not work across thousands of customer scenarios.
Another interesting finding is that when the VPN clients “bounce off” the external interface Firewall client listener, the ISA Firewall sees the clients as coming from the DMZ network. However, when the Web proxy clients “bounce off” the external interface’s Web proxy listener, they are seen as clients from the local host network or the Internal Network, even though the logging will show that they are members of the DMZ Network.
This is important because for Web proxy clients, you don’t need to create a network rule connecting DMZ clients to the Internet. There are already rules that allow members of the default Internal Network and the Local Host Network to the Internet. However, since Firewall clients are handled as members of the DMZ ISA Firewall Network, you need to create a Network Rule that connects the DMZ Network to the Internet.
The figure below shows the configuration of the Network Rule connecting the DMZ Network to the Internet. You should set the Source Network to DMZ and the Destination Network to External. The Network Relationship should be set as Network Address Translation (NAT).
Figure 18
Be aware that when you configure the VPN clients as Firewall clients, you can use the Firewall client configuration to create Access Rules that limit users, on a per user or per group basis, to what protocols and sites they can access. The Firewall client supports virtually any UDP or TCP protocol used by Winsock applications, so the Firewall client extends the secure provided by the Web proxy client configuration. There is also potentially support for complex protocols, although I’ve noted that in the configuration I’ve used in this article series, PORT mode FTP does not work.
SecureNAT Client Support
VPN clients terminating in front of the ISA Firewall that are not configured as Web proxy or Firewall clients are by default SecureNET clients of the ISA Firewall. However, they act as SecureNET clients only when they access resources located behind the ISA Firewall. For Internet access, they depends either on the VPN server’s ability to allow the client to “loop back” to the Internet through the VPN server, or on the split tunneling configuration on the client or server side.
Note that when you use only the SecureNET client configuration, access to resources behind the ISA Firewall must be done on an anonymous basis – you won’t have user/group access controls forced on the VPN clients when connecting to resources on the Internal Network behind the ISA Firewall.
Testing the Connections
Now let’s test the configuration and see what happens. The figure below shows the system tray before the VPN client connection is established. You can see that the Firewall client icon shows that the Firewall client is disconnected because it can’t resolve the name of the ISA Firewall’s Firewall client listener.
Figure 19
After the VPN connection is established, you’ll see the connection icon in the tray and you’ll see that the red “X” no longer appears on the Firewall client icon. This shows that the Firewall client found the ISA Firewall. A green up pointing arrow will appear on the Firewall client icon when the Firewall client connects to the ISA Firewall to transfer data.
Figure 20
When you double click on the Firewall client icon, you’ll see the Microsoft Firewall Client for ISA Server dialog box. Click on the Settings tab. On the Settings tab, click the Detect Now button. This will force the Firewall client to redetect the ISA Firewall and the results appear in the Detecting ISA Server dialog box. You’ll then see that the FQDN appears in the dialog box. This is the value that you entered on the Firewall Client tab in the Properties of the DMZ ISA Firewall Network.
Figure 21
The highlighted line in the figure below shows a Web proxy client connection to the Web proxy listener on the external interface of the ISA Firewall. The VPN client is IP address 10.0.1.102 and the Web proxy listener is on the external interface of the ISA Firewall on IP address 10.0.1.2.
Figure 22
After the Web proxy connection is established, you can see the request from the VPN client to the Internet. The highlighted line in the figure below shows an http connection to destination IP address 207.46.198.60. The lower case http in the log file indicates that the connection is actually being made over a Web proxy client connection – that is to say that even though the line in the log file looks like the connection is being made from the VPN client to the destination Web server, the request is actually being made over the Web proxy client/server channel over TCP port 8080.
A good example of how this works appears in the green line near the bottom. The green log file entry shows that the VPN client is making a request to the destination Web server using the http protocol, which is actually an HTTP request made over the Web proxy client/server channel. The actual HTTP connection is made from the ISA Firewall to the destination Web server, which you can see on the bottom line of the log file in the figure below. The upper case HTTP indicates a non-Web proxied connection, which is what takes place when the ISA Firewall forwards the request from the Web proxy client.
Figure 23
Now let’s take a look at a Firewall client connection. In the figure below I opened a command prompt window and established a telnet connection to an SMTP server.
Figure 24
Checking the ISA Firewall’s log file, you can see the SMTP connection was established from the VPN client’s IP address to the address of the destination SMTP server. You can see a connection to the Firewall client control channel over TCP port 1745 in the line after the SMTP connection.
You might wonder how I knew that it actually a Firewall client connection that established the SMTP link. There are two clues that provide the answer. First, look in the Client Username column in the log file entry for the SMTP connection. Here you see tshinder (?), indicating the user name of the user making the connection. Only the Firewall client can report the user name to the ISA Firewall for non-Web proxy connections.
The second hint can be seen in the diagnostics frame of the ISA Firewall log file (hey! Where did that diagnostics from come from? J). At the bottom of the diagnostics frame you can see a Client agent entry, which indicates that telnet.exe 3.5.1 was being used. Only the Firewall client can send the user agent information to the ISA Firewall for non-Web proxy connections.
Figure 25
The figure below shows the session types made by the VPN client. You’ll see that all three types of sessions are made, Web proxy, Firewall client and SecureNET client. The SecureNET client entry is a bit of an artifact, since these are representing connections from the VPN client to the Web proxy and Firewall client listeners.
Figure 26
Summary
In this article series we went over the policies and procedures involved with terminating a VPN client connection in front of the ISA Firewall. While terminating the VPN client connection at the ISA Firewall would be a more secure solution, many companies may have an established VPN client/server solution that they do not wish to give up. In that case, you have the option to terminate the VPN client connection in front of the ISA Firewall and use the ISA Firewall to allow access to the internal network behind the ISA Firewall and also to the Internet. We finished up in this article by showing how you can use the Web proxy and Firewall client configuration on the VPN client to force a higher degree of security on your remote access VPN client connections. HTH, Tom.
If you would like to read the other parts in this article series please go to:
