Web Computing with MetaFrame

MetaFrame and Firewall Considerations

Figure 15.31 demonstrates a simple configuration involving an external firewall connected to the Internet, and one or more internal MetaFrame servers that people on the Internet want to access. To add to this, network address translation (NAT) is involved, meaning that addresses on the internal network are not visible to users on the external side. The only way for someone on the Internet to access an internal resource is through a public IP address (shown as the second external address in the diagram) that the firewall product translates and routes to the corresponding server on the internal side.

Figure 15.31
Simple firewall design involving MetaFrame.

---

Author's Note - To demonstrate how a MetaFrame environment and a firewall would be configured for client access via the Internet, I have purposely kept the configuration in this section fairly simple. Most corporate environments would employ a much more advanced firewall configuration, but the basic requirements for TCP and UDP port access would still apply.

---

In this example, I have three MetaFrame servers on the internal network that I want to be accessible externally. Table 15.5 lists the internal and external addresses for the objects in this example.

Table 15.5  Internal and External IP Addresses for the Firewall Example

Published Application Accessibility Requirements

Although the diagram in Figure 15.31 (see the preceding section) is straightforward, the process involved in configuring this environment to work properly is not quite as trivial when a MetaFrame server is involved. The problem is not in the connectivity between a client and a specific server, since the process of configuring this with NAT is identical to that for setting up an FTP or Web server. The problem arises when you want to allow access to published applications or desktops in a load-balanced configuration. The difficulty lies in how the ICA client and the ICA master browser perform this communication.

I'll start by demonstrating how the internal client would communicate with a master browser. Let's assume that the MFServer3 is the master browser and that the IntClient has MFServer1 in its server location list.

1. IntClient contacts MFServer1, requesting the location of the master browser.

2. MFServer1 returns the IP address for MFServer3 (10.1.25.8).

3. IntClient contacts 10.1.25.8 and requests the desired published application.

4. 10.1.25.8 returns the IP address for MFServer2 (10.1.25.7), which is where the application is located.

5. IntClient connects to 10.1.25.7 and runs the published application.

Now let's repeat this process with the ExtClient, with the assumption that NAT is in place on the firewall. We'll assume that ExtClient also has MFServer1's external IP address (161.220.5.10) in its server location list.

1. ExtClient attempts to contact MFServer1, requesting the location of the master browser. The firewall translates the external address to the internal one and routes the request to MFServer1.

2. MFServer1 returns the IP address for MFServer3 (10.1.25.8) to ExtClient. The firewall handles routing the request back to the client, but the payload still contains the internal address to MFServer3.

3. ExtClient attempts to contact 10.1.25.8, at which point the connection fails.

Obviously, the problem arises when MFServer1 returns the internal IP address to MFServer3. The firewall won't perform NAT on this address since it's not in the source or destination portion of the packet, but instead is in the payload.

What we really want is for MFServer1 to return the external address for MFServer3 to ExtClient so that the client can properly contact that server. Fortunately, Citrix provides a means of doing this.

---

Author's Note - This problem doesn't occur if an external client attempts to connect directly to a MetaFrame server instead of requesting a server from the master browser. For example, if ExtClient had a connection set explicitly for the server MFServer3, it would establish that connection without issue. The IP address translation issue that I'm discussing here deals only with communication between the master ICA browser and the ICA client when attempting to access published applications across a firewall.

---

The resolution to this problem is actually broken down into two parts: a server component and a client component. You configure the MetaFrame server to maintain information on its equivalent external IP address, and configure the client to request the MetaFrame server's alternate address from the master browser.

MetaFrame Server Configuration

For each MetaFrame server that will be available externally, you need to define its alternate address. This information is maintained on the server and is passed to the ICA master browser so that it can be passed to a client if requested.

The alternate address is configured using the command-line tool ALTADDR. For example, to set the alternate (external) IP address for MFServer1, you would enter the following command while logged onto MFServer1:

altaddr /set 161.220.5.10

You can set the alternate address on a different server by including the /server: option. While logged onto MFServer1, you could set the alternate address on MFServer2 as follows:

altaddr /server:MFServer2 /set 161.220.5.11

After the alternate address has been set, the information is made available to the master browser, which can then pass it on to the client if requested. The master browser returns this information only when requested, so that clients on the internal network can still access the same MetaFrame servers. Otherwise, you would only be able to use the servers in one situation or the other, but not both.

For a complete list of the ALTADDR parameters, see Appendix A, "Terminal Server/MetaFrame Command Reference."

ICA Client Configuration

To use the alternate address for a MetaFrame server, the client must explicitly request it. The exact location where this is done varies slightly from client to client, but in general it's configured on the same screen as where you specify the server location list information. For Program Neighborhood clients (Win32 and Java), you can specify this in two locations: one for the custom connections and the other for each created Program Neighborhood application set. Unless you're accessing published applications through a firewall where NAT is involved, you don't need to configure the alternate address request. Figure 15.32 shows where you set this option for an application set on the Win32 client.

Figure 15.32
Setting the alternate address request for an application set.

---

Tip - The alternate address option can be requested only if you have specified at least one address in your server location list for TCP/IP. If you have selected AutoLocate, the alternate address option won't be used.

Also, the SOCKS connection option is used to communicate through a SOCKS-compatible proxy server to a MetaFrame server. Proxy servers are commonly used to manage access from an internal network out onto the Internet.

---

NFuse Configuration

If you're implementing NFuse in a firewall implementation, you also need to modify the template ICA file to support alternate addresses. The changes you make will depend on whether the NFuse Java objects are responsible for contacting the master browser, or the client will do this by itself.

If the Java objects are communicating with the master browser, replace this entry:

[[NFuse_AppName]]Address=[NFuse_IPV4Address]

with this:

[[NFuse_AppName]]Address=[NFuse_IPV4AddressAlternate]

If the ICA client will be responsible for communicating with the master browser, add the UseAlternateAddress option to the [[NFuse_AppName]] section, along with one or more TCPBrowserAddress entries. For example:

[[NFuse_AppName]]
Address=[NFuse_AppName]
TCPBrowserAddress=161.220.5.10
TCPBrowserAddress2=161.220.5.11
TCPBrowserAddress2=161.220.5.12UseAlternateAddress=1

Sample Configuration with CheckPoint FireWall-1

To complete this chapter, I would like to provide a brief demonstration of how the basic configuration shown in Figure 15.33 could be implemented using the popular firewall software CheckPoint FireWall-1.

---

Author's Note - Of course, an alternate implementation is to employ a VPN solution at the firewall and require all clients that want to access the MetaFrame server to first connect with the appropriate VPN client.

---

Figure 15.33
Simple firewall implementation with MetaFrame and CheckPoint Firewall-1.

---

Warning - Please be aware that this is only a demonstration of the steps required to perform the configuration. It's not a recommendation as to how best to configure your production firewall. I highly recommend that someone skilled in the administration of firewall software and Internet security configure your environment for production use (with any necessary corporate approval, of course).

---

To review, the goal is to allow clients over the Internet to connect to any one of the three MetaFrame servers, which are physically located behind the firewall. There are three public or external IP addresses that I'll map using network address translation through to the internal servers. There are four basic steps:

1. Include static ARP entries on the firewall to manage the three external IP addresses. This will allow the external firewall interface to receive data for all three external IPs.

---

Tip - Address Resolution Protocol (ARP) maps an IP address to a physical machine address that's recognized on the local network. Hosts on a network maintain a list of dynamic and sometimes static ARP entries that tell it where an IP is located on their network.

---

2. Set up static routes on the firewall so that it directs requests for the three external IP addresses into the internal network instead of back out onto the Internet, which it will do based on its dynamic routing table.

3. Configure the necessary objects in FireWall-1, and apply the security and NAT policies.

4. Configure the MetaFrame servers with their alternate addresses so that they can properly service external clients.

I'll review each of these steps with the assumption that FireWall-1 is installed and running on an NT 4.0 or Windows 2000 server.

Update the ARP Cache on the Firewall

The first step is to configure the existing external interface on the firewall to act as a proxy for the three external IP addresses. To do this, you need the MAC (Media Access Control) address of the external network card. This can be done by typing ipconfig /all from a command prompt on the firewall. I'll assume that the MAC for my interface is 00-c0-7a-2a-11-6d.

Windows does not support proxy ARPing using the ARP –s command, as you could do on a UNIX server. Instead, you need to create a file in the folder <FW-1 Install Path>\State, called LOCAL.ARP. This file should contain across reference between the external IP addresses and MAC addresses of the external NIC. In my example, this file contains the following entries:

161.220.5.10    00-c0-7a-2a-11-6d
161.220.5.11    00-c0-7a-2a-11-6d
161.220.5.12    00-c0-7a-2a-11-6d

The next time the security policy is installed on Firewall-1, these ARP proxy settings will take effect.

---

Author's Note - When a gateway receives a packet, it checks its local ARP cache to find the MAC address that matches the packet's destination IP address. If no local entry is found, an ARP broadcast tries to find the machine with that IP, which will respond to the request. This information is then stored in the gateway's local cache for future reference. The reference is kept for only a fixed length of time. After the time expires, the reference is flushed from the cache.

---

Add Static Routes

Next you set up the required static routes, which will direct packets destined for the external IP address to their internal equivalents. The route add command will be used, along with the -p option, which marks the entries as persistent so that they'll remain even after a server reboot. The static routes would be added as follows:

route add 161.220.5.10 10.1.6.1 -p
route add 161.220.5.11 10.1.6.1 -p
route add 161.220.5.12 10.1.6.1 -p

Notice that I've directed all of these to the appropriate internal router interface instead of the destination MetaFrame servers. Attempting to route directly to the MetaFrame servers would result in a "destination unreachable" message.

It may seem strange that routes are being added for the external IP addresses into the internal network, but this is required because NAT on Firewall-1 doesn't occur until the packet is leaving the gateway. This means that until the point where it leaves the firewall, it still has the external IP. Firewall-1 processes a packet in the following order:

1. The packet passes through the security policy.

2. The packet is routed based on routing information at the operating system level.

3. NAT is applied as the packet leaves the gateway.

4. The packet once again passes through the security policies as it leaves the gateway (after NAT has taken place).

Configure the Required Firewall-1 Policies

Next, you need to create the necessary objects and define the appropriate security policies and NAT rules. The objects to create are listed in Table 15.6.

Table 15.6  Firewall-1 Objects to Be Created

Each of these objects is created by selecting the Manage, Network Objects menu option. Click New and then Workstation to open the properties dialog box, as shown in Figure 15.34. It contains the information for MFServer1-Ext. You need to repeat this for each of the external and internal objects. Be sure to select the Internal location option when updating the internal IP addresses.

Figure 15.34
The Workstation Properties dialog box for Firewall-1 workstation objects.

To create the ICA services, simply select the Manage, Services menu item. A list of all the existing services appears. Click the New button and select the network protocol to assign to your service. Begin by selecting TCP to display the dialog box shown in Figure 15.35, which contains the information for the ICA connection service. Notice that I'm using port 1494, the default listening port for ICA.

Figure 15.35
Configuring the ICA TCP service.

To give users access to published applications, you also need to define the ICAUDP service, as shown in Figure 15.36. If you'll be using NFuse, the service definition is not required because the remote users won't be required to contact the master ICA browser; the NFuse Java objects on your Web server are configured by default to perform this service.

Figure 15.36
Configuring the ICA UDP service.

Now that all of the required objects have been defined, the necessary security and NAT policies can be created. The security policies would look like this:

The first three policies allow anyone on the Internet to connect to one of the external MetaFrame IP addresses using either the ICATCP or the ICAUDP service. The next three policies are actually tested after the packet leaves the firewall. These allow a packet with a source IP located on the Internet to access an internal MetaFrame server's IP address. The last policy is simply a catchall that drops all traffic not destined for the MetaFrame servers. You need to fit these policies into your firewall configuration where appropriate. A security policy is inserted by clicking the row number for an existing policy, right-clicking the policy, and then selecting Insert Rule Above or Add Rule Below. You can then modify the policy by right-clicking the appropriate cell and setting the contents as desired.

Here are the corresponding NAT rules:

Any connection directed to a MetaFrame server's external IP address is automatically translated to the internal address as it leaves the firewall's internal interface. Any replies made by the MetaFrame server are automatically translated. You don't need to define an explicit rule for this unless you want connections initiating from a MetaFrame server to appear as if they were coming from the external address. The last rule hides all internal addresses behind the firewall's external interface IP address. The (S) and (H) refer to Static and Hide, respectively, and describe what form of NAT is taking place.

NAT rules are added using the same technique that was employed for creating security policies.

---

Author's Note - Remember that NAT is not applied until after the packet has passed the security policy inspection. Once translated, the packet will be inspected again on its way out of the interface. This is why the security policies explicitly state both the internal and external rules.

---

Alternate Addressing on the MetaFrame Servers

The final piece required in order to allow external clients to communicate with the internal MetaFrame servers (via published applications) is to set up the appropriate alternate addressing. Remember that this is required whether you're allowing users to access the ICA browser or you're doing it through NFuse. These alternate addresses are returned by the master ICA browser to tell the client what MetaFrame server to connect to in order to run its desired published application. For more information on why this is required, see the earlier section "Published Application Accessibility Requirements."

The following commands set the alternate address on the three MetaFrame servers. You can run these on any one of the servers. Also note that you need to use the "real" server name with this command and not the object names you defined within Firewall-1.

altaddr /server:MFServer1 /set 161.220.5.10
altaddr /server:MFServer2 /set 161.220.5.11
altaddr /server:MFServer3 /set 161.220.5.11

Your MetaFrame/firewall configuration is now complete. If you're having issues with connecting to any of the MetaFrame servers, I suggest that you review the Firewall-1 audit logs. These logs provide valuable information on what might be happening to connection attempts that are failing.

Here are three things to remember when troubleshooting a problem:

• Before attempting to access a published application, you should try to hit a MetaFrame server directly. This will validate that the necessary NAT and security rules are functioning for the ICATCP component.

• Security policies are always checked first and in order from first to last. The first rule that matches a packet is used and the rest are ignored. The same applies for NAT.

• Address translation doesn't occur until the packet is leaving the firewall, so all security rules and routing information must be based on the address the packet contains when it enters the firewall.

---

Author's Note - An excellent (and one of the only) reference for FireWall-1 administration is CheckPoint FireWall-1 Administration Guide by Marcus Goncalves and Steven Brown (McGraw-Hill, 1999, ISBN 0-0713-4229-X).

---