Home > Articles > Operating Systems, Server > Microsoft Servers

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

Host

Internal IP Address

External IP Address

MFServer1

10.1.25.6

161.220.5.10

MFServer2

10.1.25.7

161.220.5.11

MFServer3

10.1.25.8

161.220.5.12

FireWall

10.1.6.2

161.220.5.1

ExtClient

N/A

209.59.13.10

IntClient

10.1.25.35

N/A


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.


  1. 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.

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

  3. 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

Object Name

Type

Description

MFServer1-Ext

Workstation

Represents the external

MFServer2-Ext

Workstation

interface for each

MFServer3-Ext

Workstation

MetaFrame server.

MFServer1-Int

Workstation

Represents the internal

MFServer2-Int

Workstation

interface for each

MFServer3-Int

Workstation

MetaFrame server.

ICATCP

Service

Represents the ICA service itself.

ICAUDP

Service

Represents the UDP requests for master browser information. If you will implement NFuse, you don't need to define this service.


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:

Source

Destination

Service

Action

Tracking

Any

MFServer1-Ext

ICATCP

Accept

Long

 

 

ICAUDP

 

 

Any

MFServer2-Ext

ICATCP

Accept

Long

 

 

ICAUDP

 

 

Any

MFServer3-Ext

ICATCP

Accept

Long

 

 

ICAUDP

 

 

Any

MFServer1-Int

ICATCP

Accept

Long

 

 

ICAUDP

 

 

Any

MFServer2-Int

ICATCP

Accept

Long

 

 

ICAUDP

 

 

Any

MFServer3-Int

ICATCP

Accept

Long

 

 

ICAUDP

 

 

Any

Any

Any

Drop

Long


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:

Source

Destination

Service

Original Packets

Any

MFServer1-Ext

Any

Any

MFServer2-Ext

Any

Any

MFServer3-Ext

Any

Internal Network

Any

Any

Translated Packets

Original

Mfserver1-Int(S)

Original

Original

MFServer2-Int(S)

Original

Original

MFServer3-Int(S)

Original

Firewall(H)

Original

Original


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).


InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020