Terminating VPN Connections in Front of the ISA Firewall

[patris1]

http://www.isaserver.org/tutorials/Terminating-VPN-Connection-Front-ISA-Firewall-Part1.html

Thomas Shinder

PART-1

Deployment options for introducing an ISA firewall into an established firewall and remote access VPN infrastructure.

Introducing a new ISA Firewall into your network can be complicated at times. On one hand, you want to take advantage of the features and security advantages provided by the new ISA Firewall, but on the other hand you don’t want to disrupt your current network infrastructure, as such disruptions have the potential for causing service interruptions.

Probably the easiest approach to bringing a new firewall into the mix is to use the Rip and Replace method, where you configure the new firewall with the same IP addressing information as the previous firewall and then pull out the old firewall and drop in the new one. While this might seem simple on paper, the realities are that organizations often have large “sunk costs” in their current firewall infrastructure and want that current infrastructure to earn out before completely replacing it.
Another important consideration is that the new firewall may employ a completely different management and policy model, which may or may not be consistent with what the organization previously had in place.
For these reasons and more, I often recommend that when you introduce a new ISA firewall into a company that you take advantage of the current infrastructure instead of using the Rip and Replace approach. While there are a number of possible designs you can use, the most secure option is to use a back to back firewall configuration.
In the back to back firewall configuration, the company keeps its current firewall on the Internet edge as a front-end firewall and places the ISA firewall behind it. This places the most secure firewall, the ISA firewall, closest to the assets the firewalls are designed to protect.
Introducing an ISA Firewall to a Pre-existing Remote Access VPN Infrastructure

I encounter these infrastructure design and configuration issues often and one issue that frequently comes up is how to deal with remote access VPN client connections to the corporate network. Most companies with an existing firewall infrastructure already have their remote access VPN client connections set up to use the current firewall as a VPN server and may have already deployed proprietary, non-RFC compliant VPN client software that connects only to that vendor’s firewall. These companies want to keep their current remote access VPN infrastructure in place but also want to enable the VPN clients access to resources on the corporate network located behind the ISA firewall.
Another very common scenario where there is a pre-existing remote access VPN server in place is when the company is using some type of “broadband” NAT device to connect to the Internet but want to bring in an ISA firewall as a back-end ISA firewall. The most common situations for this type of configuration is when the company must use PPPoE to connect to a DSL network, or when they must use DHCP to obtain a public address for a cable network.
The latter scenario, where there is a NAT device in front of the ISA firewall is commonly seen with SBS 2003 Service Pack 1 with the ISA firewall installed on it and the SBS box is configured as a multihomed server. While it has never made much sense to me, frequently users want to terminate their remote access VPN connections at the NAT device in front of the SBS box, but still want access to resources located on the SBS computers and to resources located on the corporate network behind the SBS server.
In both the SBS/front-end NAT device and corporate front-end network firewall infrastructure scenarios, the company wants to terminate the remote access VPN connection on a device in front of the ISA firewall and not at the ISA firewall and they want a method to allow the remote access VPN clients access to resources located behind the back-end ISA firewall. It is this scenario that I’ll focus my attention on in this article series.
NOTE:
While the principles and procedures I discuss in this article series can be applied to SBS 2003 Service Pack 1 with ISA 2004 deployments, I will not go over the specific step by step procedures required to make the configuration work in that environment. I’ll leave it up the SBS MVPs to provide that level of detail to their community.
In this article series we’ll focus on the following issues and procedures:

• Terminating the VPN Connection at the Front-end Firewall Issues that must be addressed when terminating the remote access VPN client connections in front of the ISA firewall
• Configuring the front-end VPN Server IP Addressing for VPN Clients VPN clients must be assigned IP addressing information that enable them to connect to the DMZ between the front-end firewall or NAT device and the ISA firewall, and enable connections to the corporate network located behind the ISA firewall.
• Configuring the ISA Firewall The ISA firewall configuration will include configuring a new ISA firewall Network for the DMZ between the firewalls, configuring a Network Rule and Access Policy controlling traffic through the ISA firewall to and from remote access VPN clients.
• Creating the FE DMZ Network We will create a new ISA firewall Network from the address range used by the network ID used on the network segment between the front-end firewall and the ISA firewall on the back-end.
• Configuring the Network Rule between the default Internal Network and the FE DMZ Network After the new ISA firewall Network is created, we’ll create a Route relationship between the DMZ and the default Internal Network located behind the ISA firewall.
• Configuring ISA Firewall Policy for FE DMZ VPN Clients Firewall policy controlling what traffic can move through the ISA firewall to and from the remote access VPN clients must be configured. DNS rules may also be created to enable name resolution for the remote access VPN clients.
• Configuring VPN Client software VPN client software must be configured for the remote access VPN connection. This includes VPN protocol and support for split tunneling, if required. There may be an option for the remote access VPN client to act as one or more ISA firewall client types during the remote access VPN client connection.
• Web Proxy Client Support The remote access VPN client might be able to support Web proxy client connections to the ISA firewall during the VPN session. We’ll see what issues are involved here and an example configuration.
• Firewall Client Support Firewall client support is not available in this scenario. We’ll examine the issues here and explain what you lose in terms of security when terminating the connection at the front-end firewall instead of at the ISA firewall.
• SecureNAT Client Support The remote access VPN clients are de facto SecureNAT clients of the ISA firewall. We’ll discuss the implications and limitations of this situation.
• Testing the Connections The proof of the pudding is in the eating, and in this section we’ll examine what takes place during the remote access VPN client connections when they access the Internet and resources on the corporate network behind the ISA firewall (or even on the ISA firewall itself).

Terminating the VPN Connection at the Front-end Firewall or NAT Device

Before going into the configuration details involved with setting up a remote access VPN solution with the termination point in front of the ISA firewall, you should have some basic understanding of the network architecture, routing relationships, and request/response paths for various types of connections made through the remote access VPN connection.
Figure 1 shows the basic network architecture of a remote access VPN solution where the remote access VPN client terminates the VPN link at the firewall or NAT device located in front of the ISA firewall. In the figure there is green line representing the remote access VPN link to the firewall or NAT device’s external interface.
The internal interface of the front-end firewall/NAT device is connected to a common hub or switch to which the external interface of the ISA firewall is connected. You can also use this network segment to connect Web, FTP and other anonymous access servers to which you want to allow anonymous access from Internet-based clients.
The external interface of the ISA firewall is connected to the common hub/switch to which the internal interface of the front-end firewall or NAT device is connected, as well as any servers that might be placed in the DMZ. Note that an independent hub/switch is not required. Many firewalls and NAT devices have multiple LAN ports. In that case, you can plug the external interface of the ISA firewall into one of the device’s LAN ports and you can plug any anonymous access servers you want into the same device.
WARNING:
It’s critical that you do not allow any direct connections from the protected network behind the ISA firewall and the DMZ network or the Internet. The ISA firewall must be inline in order to control all inbound and outbound traffic to and from the corporate network. I’ll diagram what I call the Nightmare Scenario that violates this security requirement a little later in this article.
The reason why I make it a point to state that you should allow only anonymous access servers in the DMZ between the ISA firewall’s external interface and the firewall/NAT device in front of the ISA firewall is that you are completely dependent on the security provided by the NAT device or simple stateful inspection firewall in front of the ISA firewall to protect the communications going into and out of the DMZ segment.
For this reason, you should not place critical corporate assets in this DMZ. An exception to this security guideline would be if you are using a front-end/back-end ISA firewall configuration, or if you were using a firewall that provides a high level of security similar to the ISA firewall, such as the Check Point firewall with application intelligence.

Figure 1
Terminating the VPN connection at the NAT device or simple stateful packet inspection firewall

Understanding the routing relationships for communications to and from the remote access VPN client is a key component of making this solution work. Figure 2 diagrams the routing relationships between the various networks:

• There is a ROUTE relationship between the default Internal Network behind the ISA firewall and the DMZ segment between the ISA firewall and the firewall/NAT device in front of the ISA firewall. This allows us to create both Publishing and Access Rules to control the traffic between the remote access VPN clients and the corporate network
• There is a ROUTE relationship between the default Internal Network behind the ISA firewall and the Internet. A Network Rule that sets a route relationship between the default Internal Network and the default External Network is created automatically when you install the ISA firewall on a multihomed device and enforces this ROUTE relationship between Internal and the Internet
• There is a ROUTE relationship between the remote access VPN client and the DMZ between the ISA firewall and the front-end firewall/NAT device. The ISA firewall is not aware of this and does not need to be aware of this, as it doesn’t impact on the configuration of the ISA firewall
• There is a ROUTE relationship between the default Internal Network and the remote access VPN client. The reason for this is that we must set a route relationship between the default Internal Network and the DMZ between the ISA firewall and the front-end firewall/NAT device. Since the remote access VPN client will be assigned an IP address on the same network ID used on the DMZ segment, the route relationship between the default Internal Network behind the ISA firewall and the remote access VPN clients is the same as the route relationship between the default Internal Network and the DMZ – which is ROUTE.

Figure 2
Terminating the VPN Connection at the NAT device or simple stateful packet inspection firewall and the route relationships between the Networks

Now that you understand the key route relationships for all communications related to remote access VPN client connections, the next step to understanding how the solution works is to review the request/response paths for communications to and from the remote access VPN clients.
In figure 3, four request/response paths are described:

1. This is the request/response path for connections between the remote access VPN clients and the default Internal Network behind the ISA firewall. There is a route relationship governing these connections, which allows you to use both Access Rules and Publishing Rules to control the level of access remote access VPN clients have when connecting to the corporate network behind the ISA firewall.
2. This is the request/response path for connections between the remote access VPN clients and the DMZ between the ISA firewall and the front-end firewall/NAT device. Access control over VPN client connections to the DMZ is determined by the capabilities of the front-end firewall/NAT device. If you have a higher end device on the front-end, you may be able to exert packet filter based access control, or even user based control. If you have only a simple stateful packet inspection firewall or NAT device, you won’t have much control, if any, over what the remote access VPN clients can access on the DMZ network.
3. This is a request/response path for connections to Internet resources. This is one of two options, depending on the capabilities of your front-end firewall or NAT device. If your front-end firewall/NAT device does not support looping back to the Internet to allow the remote access VPN clients to connect to Internet resources, then you can configure the remote access VPN client software to allow split tunneling. While split tunneling is typically considered a security risk, this is your only option if your front-end firewall/NAT device does not support looping back through its external interface to allow remote access VPN clients access to the Internet.
4. This is a request/response path for connections to Internet resources. This is the second option, where the front-end firewall or NAT device does allow the remote access VPN client to loop through the device to connect to Internet resources. This prevents the need to enable split tunneling on the remote access VPN client and also potentially provides you the option to enforce some form of corporate firewall policy on the remote access VPN client when it’s connected to the VPN server. While this configuration has the advantage of preventing security issues related to split tunneling, it does suffer from the bandwidth toll taken by VPN clients connecting to the Internet through the corporate Internet connection.

Figure 3
Terminating the VPN connection at the NAT device or simple stateful packet inspection firewall and request/response paths for corpnet and Web Proxy Internet connections

Figure 4 shows the request/response paths available when you configure the remote access VPN client to use the ISA firewall as its Web proxy device when connected to the remote access VPN server:

1. This request/response path is used for all non-HTTP/HTTPS connections when the front-end firewall/NAT device does not support looping back through the device to connect to the Internet.
2. This request/response path is used for all non-HTTP/HTTPS connections when the front-end firewall/NAT device support looping back through the device to access the Internet
3. This request/response path is used for all HTTP/HTTPS/HTTP tunneled FTP requests when the remote access VPN client is configured to use the ISA firewall as its Web proxy server when connected to the VPN server. The ability to do this depends on the VPN client software you use and its integration with Windows.
   
   For example, if you use the native VPN client software that comes with Windows XP Service Pack 2, you can connect to the front-end firewall/NAT device using the PPTP, L2TP/IPSec and L2TP/IPSec NAT-T VPN protocols. You can then configure the VPN client machine to use the ISA firewall as a Web proxy device when connected to the VPN server in front o the ISA firewall. This allows you to enforce ISA firewall policy and content filtering on the remote access VPN client when it’s connected to the VPN server.
   
   This configuration also allows you to comprehensively log all sites and content these users access, and includes the user name in the log files, which can be used in reports of the user’s Internet activity when connected to the VPN server. The Web proxy client configuration is automatically stopped when the client disconnects from the VPN server in front of the ISA firewall. Support for Web proxy client configuration varies the VPN client software you choose to use.

Figure 4
The Nightmare Scenario

Figure 5 depicts what I call the Nightmare Scenario and something I see mostly with SBS networks setup by someone unfamiliar with the ISA firewall security model and network security in general. I also see it attempted with users unfamiliar with TCP/IP networking.
In the Nightmare Scenario, there is a path that allows connections between the corporate network and the DMZ and Internet to bypass the ISA firewall. People most often try to accomplish this by putting a hub/switch between the ISA firewall’s external interface and the firewall/NAT device and plugging the external interface of the ISA firewall and the internal interface of the front-end firewall/NAT device into the same hub/switch. In addition, they plug this hub/switch to another hub/switch located on the corporate network. This provides a bypass route away from the ISA firewall.
This is a Nightmare Scenario because:

1. It provides a bypass route that enables malicious users to bypass the ISA firewall.
2. It won’t work. The internal and external interfaces of the ISA firewall must be on different network IDs. The external interface of the ISA firewall must be on the same network ID as the LAN interface of the front-end firewall/NAT device. Since the ISA firewall’s external interface must be on a different network ID as the ISA firewall’s internal interface, then the LAN interface on the front-end firewall/NAT device must be on a different network ID as the internal interface of the ISA firewall, which puts at least the on-subnet hosts on the default Internal Network on a different network ID as the LAN interface of the front-end firewall/NAT device.

Of course, you could get tricky and change the IP address and default gateway of a host on the default Internal Network so that the IP address is on the same network ID as LAN interface of the front-end firewall/NAT device, and then configure the client’s default gateway as the IP address on the LAN interface of the front-end firewall/NAT device. This would allow a malicious user to completely bypass the ISA firewall to connect to the Internet, and a malicious external user to bypass the ISA firewall to access content on the corporate network.
You’re playing a dangerous game when you allow users to bypass the ISA firewall at will. For this reason, the moniker of Nightmare Scenario is well-deserved.

Figure 5: The Nightmare Scenario: Providing a path bypassing the ISA firewall

Summary

In this article we discussed deployment options for introducing an ISA firewall into an established firewall and remote access VPN infrastructure. There are several infrastructure options available, with the most secure options enforcing all connections to and from the corporate network to pass through the ISA firewall. In order to gain a deeper understanding of how the solution works, we went over the route relationships between various networks that comprise the solution and the request/response paths to and from the remote access VPN clients. In the second part of this series, we’ll go over the configuration details and discuss the rationale behind each configuration option

---

موضوعات مشابه:

• مشکل در اجرای سرویس front end
• انتقال تنظیمات ISA به Front TMG
• Allowing Inbound L2TP/IPSec NAT Traversal Connections through a Back to Back ISA Server Firewall DMZ

---

[patris1]

http://www.isaserver.org/tutorials/Terminating-VPN-Connection-Front-ISA-Firewall-Part2.html

PART-2

How to terminate remote access VPN client connections at a device in front of the ISA firewall.


In the first part of this two part series on how to configure the ISA firewall to support remote access VPN clients terminating at a front-end firewall or NAT device, I discussed the core infrastructure design considerations that go into making the working solution. The network architecture, routing relationships, and access control options were discussed in that article. If you haven’t had a chance to read part 1 yet, check it out at Terminating a VPN Connection in Front of the ISA Firewall (Part 1).

In this article I’ll continue the discussion but this time hone in on the specific details of the configuration and include a discussion of some of the key configuration issues and the implications they may have on your network. We’ll go over the following procedures:

• Configure the front-end firewall/NAT device with IP addressing information for remote access VPN clients Remote access VPN clients require a valid address that enables them to access hosts on the DMZ network and the corporate network located behind the ISA firewall
• Create the DMZ ISA firewall Network The ISA firewall uses ISA firewall Networks to determine the route relationship between the source and destination host. We will create a DMZ ISA firewall Network representing the network ID on the DMZ between the external interface of the ISA firewall and the LAN interface of the front-end firewall/NAT device.
• Create a Network Rule settings a Route relationship between the default Internal Network and the DMZ Network The next step after defining the DMZ ISA firewall Network is to create a Network Rule setting a Route relationship between the default Internal Network and the DMZ ISA firewall Network. This will increase our flexibility in creating access controls over what resources the remote access VPN clients can access on the corporate network located behind the ISA firewall

In the next article we’ll finish up the design by discussing the ISA firewall rules you need to create to support this scenario, procedures for configuring the various client types, and testing the configuration.
We should examine example network used in their article before going into the configuration details. The example network appears in figure 1.

Figure 1
On the default Internal Network is a domain controller that also has a DNS server installed on it that can resolve both internal and external names. The ISA firewall uses this DNS server to resolve names on behalf of Web proxy and Firewall clients, and also uses this DNS server to perform forward and reverse lookups to insure that site-based access controls are enforced. This DC on the default Internal Network of the ISA firewall uses the ISA firewall’s internal interface IP address as its default gateway.
The ISA firewall is installed on a computer with two network interfaces: an internal interface on the default Internal Network and an external interface on the DMZ network behind the ISA firewall and the RRAS NAT computer in front of the ISA firewall. The ISA firewall is a domain member so that in the future we can fully leverage strong user/group based access control using the Web proxy and Firewall client configuration.
The front-end firewall/NAT device used in this scenario is the Windows Server 2003 RRAS NAT service. While I realize that the Windows Server 2003 RRAS NAT is not the most commonly used front-end firewall/NAT device used on corporate networks, I decided that this might be the best solution to use to demonstrate the principles discussed in this article series because everyone has access to at least a demo version of Windows Server 2003 on which they can test this scenario, and then you can extrapolate the configuration decisions made on the RRAS NAT server in this example to similar configuration options you can carry out on your own front-end firewall/NAT device.
The RRAS NAT computer has two network interfaces: one interface on the DMZ between itself and the ISA firewall and an external interface connected to the Internet, or a network that provides a path to the Internet. Since I’m demonstrating this configuration on my live network, there is a ISA firewall providing a gateway to the Internet that is in front of the RRAS NAT server used in this scenario.
The relevant IP addressing information for the example network is shown in figure 1.
Configure the front-end VPN Server IP Addressing for VPN Clients

The front-end firewall/NAT device must be able to deliver valid IP addressing information to the VPN clients when they connect to the VPN server. In most cases, you should assign the remote access VPN clients addresses that are on subnet with the LAN interface of the front-end firewall/NAT device. For example, if the internal interface of the NAT device is on network ID 10.0.1.0/24, then you should assign VPN clients addresses within this address range.
VPN clients should also be assigned a DNS server address that enables them to resolve names on the corporate network. You need to do this because the DNS server assigned to the external client is only able to resolve Internet host names and not your internal network host names. What I typically do is assign these remote access VPN clients the IP address of a DNS server on the corporate network behind the ISA firewall, and then create an Access Rule that enables the remote access VPN clients to perform DNS queries against that DNS server.
The front-end firewall/NAT device will need a routing table entry informing it of the correct gateway to the corporate network. Without this routing table entry, the front-end firewall/NAT device acting as a VPN server will not be able to correctly route the request and connection attempts will fail.
To summarize our configuration requirements for the front-end firewall/NAT device:

• VPN clients should be assigned addresses that are on-subnet of the internal/LAN interface of the front-end firewall/NAT device
• VPN clients should be assigned an address of a DNS server that can resolve both internal and external network names
• A routing table entry must be configured on the front-end firewall/NAT device that enables it to find the gateway for all network IDs located behind the ISA firewall

The following procedures will show how to configure the Windows Server 2003 RRAS NAT and create the routing table entry on the RRAS NAT computer. If you want to replicate this configuration on your test network, or if you are using the RRAS NAT for your front-end VPN gateway, then these instructions will apply to you. If you are using something else for a front-end device and do not wish to replicate this configuration in a test lab, then you can continue on to the next section entitled Configure the ISA Firewall.
Perform the following steps on the Windows Server 2003 computer that will act as the remote access VPN server and NAT device:

1. Click Start and then point to Administrative Tools. Click on Routing and Remote Access.
2. The Routing and Remote Access Service is installed by the default but is not enabled. To enable it, in the Routing and Remote Access console, right click the server name in the left pane of the console and click Configure and Enable Routing and Remote Access.
3. Click Next on the Welcome to the Routing and Remote Access Server Setup Wizard page.
4. On the Configuration page, select the Virtual Private Network (VPN) access and NAT option and click Next.

Figure 2

1. On the VPN Connection page, select the network interface that connect the VPN server to the Internet. In this example, the interface named WAN is the external interface and we’ll select that one. Leave the checkmark in the Enable security on the selected interface by setting up Basic Firewall. This configures the RRAS server to allow incoming VPN connections by performs stateful packet inspection and blocks all other inbound communications. Click Next.

Figure 3

1. On the Network Selection page, select the network interface representing the internal interface of the RRAS NAT server. In this example, the interface named LAN is the RRAS NAT server’s internal interface. Click Next.

Figure 4

1. On the IP Address Assignment page, select the From a specified range of addresses option and click Next. The reason we select this option is that we don’t have a DHCP server on the DMZ network, and we don’t have the DHCP Relay Agent installed on the ISA firewall to support DHCP servers that may be located on the default Internal Network located behind the ISA firewall.
2. On the Address Range Assignment page, click the New button. In the New Address Range dialog box, enter a Start IP address and End IP address for your address range. In this example I’ll enter a range that includes 21 addresses. One of the addresses is used by the RRAS NAT server’s VPN interface, and the other 20 are available to assign to remote access VPN clients. Click OK.

Figure 5

1. Click Next on the Address Range Assignment page.
2. The VPN server configuration is complete and now we select options that apply to the NAT service. On the Network Selection page, select the network interface that you want to allow outbound NAT connections from. In this example, we want to allow outbound NAT from the internal interface of the RRAS NAT server. The LAN interface is the internal interface of the RRAS NAT server, so we will select that one and click Next.

Figure 6

1. On the Managing Multiple Remote Access Servers page, select the No, use Routing and Remote Access to authenticate connection requests option. We aren’t using RADIUS authentication in this scenario, although its always a viable option if you want to use RADIUS in your own deployment. If you do choose to use RADIUS authentication, the only thing you need to do on the ISA firewall is create an Access Rule that allows the RADIUS ports outbound to RADIUS server on the corporate network. Click Next.
2. Click Finish on the Completing the Routing and Remote Access Server Setup Wizard page. Click OK in the dialog box informing your about the DHCP Relay Agent.

At this point you’ll see the server icon in the left pane of the console show a green up-pointing arrow. At this point we can check a couple key VPN server configuration settings and configure the routing table entry:

1. Right click the server name in the left pane of the console and click Properties.
2. In the server’s Properties dialog box, click the IP tab.
3. On the IP tab, check the setting in the Adapter drop-down list box. This is the network interface for which the settings are drawn for DNS server assignment to remote access VPN clients. We need to assign the remote access VPN clients a DNS server address that allows them to resolve both public and private host names and that server is most likely installed on the corporate network located behind the ISA firewall. For this reason we need to configure the RRAS NAT servers internal interface to use the internal DNS server. In this example, the internal interface of this RRAS NAT server is configured to use 10.0.0.2 as its DNS server. Click OK.

Figure 7

1. Now we need to set the route table entry. In the left pane of the console, expand the IP Routing node and then right click the Static Routes node and click New Static Route.
2. In the Static Route dialog box, enter the internal network ID in the Destination text box. On our example network, the default Internal Network is located on network ID 10.0.0.0/24, so we’ll enter 10.0.0.0 in the Destination text box. Enter the Network mask in the text box. On our example network, the subnet mask is 255.255.255.0. In the Gateway text box, enter the gateway address that will route the connection to the destination network. In our example, the gateway to the corporate network is the IP address on the external interface of the ISA firewall. On our example network, the IP address on the external interface of the ISA firewall is 10.0.1.2. We can use the default metric on this example network. Click OK.

Figure 8

1. Close the Routing and Remote Access console.

Configure the ISA Firewall

Now that the configuration is complete on the front-end NAT device, we can begin our work on the back-end ISA firewall. There are three key ISA firewall procedures we need to carry out:

• Create the front-end DMZ ISA firewall Network
• Configure the Network Rule between the Default Internal Network and the FE DMZ Network
• Configure ISA Firewall Policy for Remote Access VPN Clients

Create the FE DMZ Network

An ISA firewall Network is an ISA firewall Network Object that you can use to control the Route relationship between a source and destination host. ISA firewall Networks are defined as all IP addresses accessible by a specific network interface on the ISA firewall, where the network interface represent the “root” of a particular ISA firewall Network. For more detailed coverage of ISA firewall Network and how the ISA firewall uses them, check out Creating and Configuring ISA Firewall Networks (2004) [v1.02] and Understanding ISA Firewall Networks (v1.1)
We want to define the DMZ segment between the external interface of the ISA firewall and the LAN interface of the front-end firewall/NAT device to be its own ISA firewall Network. This will allow use to define a route relationship between the default Internal Network behind the ISA firewall and the DMZ network in front of the ISA firewall. With a Route relationship defined between these network, we’ll be able to use either Access Rules or Publishing Rules to control the traffic between the DMZ network (which is where the remote access VPN clients are located) and the default Internal Network behind the ISA firewall.
In the example network used in this article series, we’ll define the ISA firewall Network using all the addresses in network ID 10.0.1.0/24. The remote access VPN clients are assigned addresses within this network ID, so they will be automatically included in the definition of the DMZ ISA firewall Network.
Perform the following steps to create the ISA firewall Network for the DMZ:

1. In the ISA firewall console, expand the server name in the left pane of the console and then expand the Configuration node. Click the Network node.
2. Click the Create a New Network link in the Tasks tab of the Task Pane.
3. In the Welcome to the New Network Wizard enter the name of the ISA firewall Network in the Network name text box. In this example we’ll name the DMZ ISA firewall Network FE DMZ and click Next.
4. On the Network Type page, select the Perimeter Network option. Note that functionally speaking, the Perimeter Network option is no different from the Internet Network or External Network option. Click Next.

Figure 9

1. On the Network Addresses page, click the Add button.
2. In the IP Address Range Properties dialog box, enter the range of IP addresses that define the FE DMZ ISA firewall Network. In this example, the FE DMZ is defined by the entire network ID 10.0.1.0/24, so we enter 10.0.1.0 as the Starting address and 10.0.1.255 as the Ending address. Click OK.

Figure 10

1. Click Next on the Network Addresses page.
2. Click Finish on the Completing the New Network Wizard page.

At this point the new ISA firewall Network appears on the Networks tab in the middle pane of the ISA firewall console. The next step is to configure this network to support Web proxy client connections. This provides us with the option of making the remote access VPN clients Web proxy clients of the ISA firewall when they’re connected to the front-end firewall/NAT device.

1. Double click the FE DMZ entry in the list of ISA firewall Networks on the Networks tab.
2. In the FE DMZ Properties dialog box, click the Web proxy tab. On the Web proxy tab, put a checkmark in the Enable Web proxy clients checkbox.

Figure 11

1. Click the Authentication button. In the Authentication dialog box you’ll see that the default authentication option is Integrated. This option will work for transparent authentication if the users are logged into a domain account and the ISA firewall is a member of the Active Directory domain. If the users are not logged into a domain account and the ISA firewall is a member of the domain, then you should enable the Basic authentication option so that users can enter user name and password information. If the ISA firewall is not a member of the domain, you can create users in the ISA firewall’s local SAM database and mirror those accounts on the user workstations; this will allow you to use integrated authentication, which is transparent and will not require users to enter username and password information. On the example network used in this article, the ISA firewall is a domain member, and the external user is logged on with cached domain credentials.
   
   However, we’ll enable the basic authentication option to support non-domain users who want to explicitly log in. Note that these credentials are passed in the clear and that anyone who is able to capture packets in the DMZ will be able to access the user account information easily. After putting a checkmark in the Basic checkbox, click Yes in the dialog box informing you that the credentials are passed in clear text. Click OK in the Authentication dialog box. (Note: these settings set only the type of authentication supported – if your rule does not require authentication, no authentication will be requested by the ISA firewall’s Web proxy filter).

Figure 12

1. Click OK in the FE DMZ Properties dialog box.

Configure the Network Rule between the Default Internal Network and the FE DMZ Network

Network Rules control the route relationship between the source and destination. You can create either a NAT or ROUTE relationship using Network Rules. A ROUTE relationship is bidirectional. A bidirectional relationship means that if there is a ROUTE relationship between source and destination, there is also a ROUTE relationship between destination and source. On the other hand, if there is a NAT relationship between source and destination, there is not a NAT relationship between destination and source, and that you have to create publishing rules (reverse NAT) to allow connections between destination and source.
We want to create a route relationship between the default Internal and the FE DMZ ISA firewall Networks. This allows us to use both Access Rules and Publishing Rules to control the traffic between these Networks.
The advantage of this configuration is that you can use Access Rules to allow connections to non-Web protocols, and you can use Web Publishing Rules for connections to Web servers if you like. The reason why you might want to use Web Publishing Rules is if you don’t want to configure your remote access VPN clients as Web proxy clients and you want to require them to authenticate at the ISA firewall before allowing them access to Web resources on the corporate network.
For example, suppose you have very high security requirements and you do not want to allow connections to your OWA server without first requiring a VPN connection. Or perhaps you don’t want to implement a PKI, and will use the VPN link as your encrypted channel instead of an SSL link. In these scenarios, you can have your remote access VPN clients authenticated at the ISA firewall before allowing the connections to the OWA site. The pre-authentication insures that even if the integrity of your DMZ is violated, attackers will not be able to leverage anonymous connections to the OWA site and will have to present credentials first at the ISA firewall.
Note that for Access Rules and Server Publishing Rules, you do not have the option for pre-authentication, but you can use source IP address-based access controls in these circumstances. This is one of the limitations of terminating the VPN connection at a device in front of the ISA firewall. If we terminated the VPN connection at the ISA firewall, you could enforce user/group based access controls for both Internet and corporate network access for all VPN clients.
Perform the following steps to create the Network Rule:

1. Click on the Networks node in the left pane of the ISA firewall console. Click on the Network Rules tab in the middle pane of the console, and then click the Create a New Network Rule link on the Tasks tab in the Task Pane.
2. On the Welcome to the New Network Rule page, enter the name of the rule in the Network rule name text box. In this example we’ll name the rule Internal to DMZ and click Next.
3. On the Network Traffic Sources page, click the Add button. In the Add Network Entities dialog box, click the Networks folder and double click the Internal network. Click Close.
4. Click Next on the Network Traffic Sources page.
5. On the Network Traffic Destinations page, click the Add button. In the Add Network Entities dialog box, click the Networks folder and double click the FE DMZ entry. Click Close.
6. Click Next on the Network Traffic Destinations page.
7. On the Network Relationship page, select the Route option and click Next.

Figure 13

1. Click Finish on the Completing the New Network Rule Wizard page.
2. Click Apply to save the changes and update the firewall policy.
3. Click OK in the Apply New Configuration dialog box.

Summary

In this article we continued our discussion on how to terminate remote access VPN client connections at a device in front of the ISA firewall. We went over the procedures involved with configuring the front-end VPN device, creating the DMZ ISA firewall Network, and creating the Network Rule controlling the route relationship between networks. In the next and final article in the series, we’ll create the Access Rules required to allow VPN clients access to resources on the corporate network

[patris1]

http://www.isaserver.org/tutorials/Terminating-VPN-Connection-Front-ISA-Firewall-Part3.html

PART-3

The policies and procedures involved with terminating a VPN client connection in front of the ISA Firewall.


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 tshinder@isaserver.org
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:
Supporting ISA Firewall Networks Protecting Illegal Top-level Domains: You Need a Split DNS!
You Need to Create a Split DNS!
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