Using Multi-Homing to Access Multiple Resources

You can configure an Access Gateway to use one public IP address to protect multiple types of web resources. This is one of the major benefits of Access Gateway, because it conserves valuable resources such as IP addresses. This feature also makes an Access Gateway a multi-homing device because it becomes a single endpoint supporting multiple back-end resources.

You can use one or multiple multi-homing methods. Select methods that meet the needs of your network and resources you are protecting. The first proxy service configured for a reverse proxy is always configured to use the DNS name of Access Gateway. You can configure subsequent proxy services domain-based multi-homing, path-based multi-homing, or virtual multi-homing.

In this Section

Domain-Based Multi-Homing

Domain-based multi-homing is based on the cookie domain. For example, if you have a cookie domain company.com, you can prefix hostnames to a cookie domain name. For a test resource, you can prefix test to company.com and have test.company.com resolve to the IP address of Access Gateway. Access Gateway configuration for the test.company.com proxy service contains the information for accessing its web servers (test1.com).

Figure 2-16 Using a Base Domain Name with Host Names

Domain-based multi-homing has the following characteristics If you are using SSL:

  • Back-end servers can all listen on the same SSL port (the default for HTTPS is 443).

  • Back-end servers can share the same SSL certificate. Instead of using a specific hostname in the SSL certificate, the certificate can use a wildcard name such as *.company.com, which matches all the servers.

Before configuring Access Gateway, you need to complete the following:

  • Create the published DNS names with a common domain name for public access to the back-end resources. For example, the table below lists three DNS names that use company.com as a common domain name, lists the IP address that these DNS names resolve to, and the web servers they protect.

    Published DNS Name

    Access Gateway IP Address

    Web Server Host Name

    Web Server IP Address

    test.company.com

    10.10.195.90:80

    test.internal.com

    10.10.15.10

    sales.company.com

    10.10.195.90:80

    sales.internal.com

    10.10.15.20

    apps.company.com

    10.10.195.90:80

    apps.internal.com

    10.10.15.30

  • Configure your DNS server to resolve the published DNS names to the IP address of Access Gateway.

  • Set up the back-end web servers.

  • Create three proxy services for these published DNS names.

    To create a domain-based multi-homing proxy service, see Creating a Second Proxy Service, and select domain-based for the multi-homing type.

Path-Based Multi-Homing

Path-based multi-homing uses the same DNS name for all resources, but each resource or resource group must have a unique path appended to the DNS name. For example, if the DNS name is test.com, append /sales to test.com. When the user enters www.test.com/sales, Access Gateway resolves the URL to the sales resource group.

Figure 2-17 Using a Domain Name with Path Elements

Path-based multi-homing has the following characteristics:

  • It is considered to be more secure than domain-based multi-homing, because some security experts consider wildcard certificates less secure than a certificate with a specific hostname.

  • Each resource or group of resources must have a unique starting path.

  • JavaScript applications might not work as designed if they obscure the URL path. Access Gateway needs access to the URL path, and if it is obscured, the path cannot be resolved to the correct back-end resource.

  • The protected resources for each path-based child come from the parent proxy service.

The following sections explain how to configure path-based proxy services and your network so that Access Gateway can find the correct protected resources:

Configuring the Remove the Path on Fill Option

If the path that is part of the published DNS name (/sales or /apps) is used to identify a resource but is not part of directory configuration on the web server, the path needs to be removed from the URL before the request is sent to the web server. For example, suppose you use the following configuration:

Browser URL Using the Published DNS Name

Web Server URL

http://www.test.com/sales

http://sales4.internal.com/

In this case, the path needs to be removed from the URL that Access Gateway sends to the web server. Access Gateway does not allow you to set up multiple paths to this type of web server, so all pages must have the same authentication requirements.

If the path in the published DNS name is a path on the web server, the path needs to be passed to the web server as part of the URL. For example, suppose you use the following configuration:

Browser URL Using the Published DNS Name

Web Server URL

http://www.test.com/sales

http://sales4.internal.com/sales

Because the path component specifies a directory on the web server where the content begins, you need to select to include the path. Access Gateway then includes the path as part of the URL it sends to the web server. This configuration allows you to set up multiple paths to the web server, such as

  • sales/payroll

  • sales/reports

  • sales/products

Such a configuration also allows you to set up different authentication and authorization requirements for each path.

Configuring the Host Header Option

When you create path-based proxy services and also enable the Remove Path on Fill option, you need to know what types of links exist on the web servers. For example, you need to know if the sales web servers in Figure 2-17 have links to the app web servers or to the test web servers. If they don’t, you can set the Host Header option to either Forward Received Host Name or to Web Server Host Name. However, if they do contain links to each other, you need to set the Host Header option to Web Server Host Name and specify a DNS name for the web server in the Web Server Host Name option. Access Gateway needs a method to distinguish between the web servers other than the path, because after the path is removed, all the web servers in Figure 2-17 have the same name: www.test.com.

If you select to use the Forward Received Host Name option for a path-based service, you might also need to add entries to the Additional DNS Name List for the rewriter. For more information, see Determining Whether You Need to Specify Additional DNS Names.

Preparing for Path-Based Multi-Homing

Before configuring Access Gateway, you need to complete the following:

  • Create the published DNS names with paths for public access to the back-end resources. For example, the table below uses test.com as the domain name. It lists three published DNS names (two with paths), the IP address these names resolve to, and the web servers that they are going to protect:

    Published DNS Name

    Access Gateway IP Address

    Web Server Host Name

    Web Server IP Address

    test.com

    10.10.195.90:80

    test.internal.com

    10.10.15.10

    test.com/sales

    10.10.195.90:80

    sales.internal.com

    10.10.15.20

    test.com/apps

    10.10.195.90:80

    apps.internal.com

    10.10.15.30

  • Configure your DNS server to resolve the published DNS names to the IP address of Access Gateway.

  • Set up the backend web servers. If they have links to each other, set up DNS names for the web servers.

  • Create one proxy service that uses test.com as its published DNS name and two path-based proxy services.

    To create a path-based multi-homing proxy service, see Creating a Second Proxy Service, and select path-based for the multi-homing type.

Virtual Multi-Homing

Virtual multi-homing allows you to use DNS names from different domains (for example test.com and sales.com). Each of these domain names must resolve to Access Gateway host.

Figure 2-18 Using Multiple DNS Names

Virtual multi-homing cannot be used with SSL. You must use this configuration with resources that need to be protected, but the information exchanged must be public information that does not need to be secure. For example, you could use this configuration to protect your web servers that contain the catalog of your shipping products. It isn’t until the user selects to order a product that you need to switch the user to a secure site.

Whether a client can use one DNS name or multiple DNS names to access Access Gateway depends upon the configuration of your DNS server. After you have configured your DNS server to allow multiple names to resolve to the same IP address, you are ready to configure Access Gateway.

To create a virtual multi-homing proxy service, see Creating a Second Proxy Service, and select Virtual for the multi-homing type.

Creating a Second Proxy Service

  1. Click Devices > Access Gateways > Edit > [Name of Reverse Proxy].

  2. In the Proxy Service List, select New.

  3. Specify the following details:

    Proxy Service Name: Specify a display name for the proxy service. For the sales group, you might use sales. For the group of application servers, you might use apps.

    Multi-Homing Type: Specify the multi-homing method that Access Gateway must use to identify this proxy service. Select one of the following:

    • Domain-Based: Uses the published DNS name (www.test.com) with a hostname (www.newsite.test.com). For more information, see Domain-Based Multi-Homing.

    • Path-Based: Uses the published DNS name (www.test.com) with a path (www.test.com/path). For more information, see Path-Based Multi-Homing.

    • Virtual: Uses a unique DNS name (www.newsite.newcompany.com). Virtual multi-homing cannot be used with SSL. For information, see Virtual Multi-Homing. If you need a unique DNS name and SSL, create a reverse proxy rather than a proxy service. For information about creating a second reverse proxy, see Managing Multiple Reverse Proxies.

    Published DNS Name: Specify the DNS name you want the public to use to access your site. This DNS name must resolve to the IP address you set up as the listening address. This option is not available when path-based multi-homing is selected.

    Path: Specify the path to use for this proxy service. This option is available only when path-based multi-homing is selected.

    Web Server IP Address: Specify the IP address of the web server you want this proxy service to manage.

    Host Header: Specify whether the HTTP header must contain the name of the back-end web server (Web Server Host Name option) or whether the HTTP header must contain the published DNS name (the Forward Received Host Name option).

    For a path-based multi-homing service, it is usually best to select the Web Server Host Name option. For more information, see Configuring the Host Header Option.

    Web Server Host Name: Specify the DNS name of the web server that Access Gateway must forward to the web server. If you have set up a DNS name for the web server and the web server requires its DNS name in the HTTP header, specify that name in this field. If you selected Forward Received Host Name, this option is not available.

    For iChain administrators, the Web Server Host Name is the alternate hostname when configuring a web server accelerator.

  4. Click OK.

  5. To continue, select one of the following:

Configuring a Path-Based Multi-Homing Proxy Service

To configure a path-based proxy service:

  1. Click Devices > Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Path-Based Multi-Homing Proxy Service].

    The following fields display information that must be configured on the parent proxy service (the first proxy service created for this reverse proxy).

    Published DNS Name: Displays the value that users are currently using to access this proxy service. This DNS name must resolve to the IP address you set up as a listening address on Access Gateway.

    Cookie Domain: Displays the domain for which the cookie is valid. The web server that the user is accessing must be configured to be part of this domain.

  2. Configure the following options:

    Description: (Optional) Provide a description of the purpose of this proxy service or specify any other pertinent information.

    HTTP Options: Determines how the proxy service handles HTTP headers and caching. For more information, see Section 3.5.2, Controlling Browser Caching.

  3. Configure the path options:

    Remove Path on Fill: Determines whether the multi-homing path is removed from the URL before forwarding it to the web server. If the path is not a directory at the root of the web server, the path must be removed. If this option is selected, the path is stripped from the request before the request is sent to the web server.

    If you enable this option, this proxy service can protect only one path. If you have configured multiple paths in the Path List, you cannot enable this option until you have deleted all but one path.

    Reinsert Path in “set-cookie” Header: Determines whether the path is inserted into the Set-Cookie header. This option is only available if you enable the Remove Path on Fill option.

  4. Determine whether you need to create a protected resource for your path.

    In the Path List, the path you specified is listed along with the protected resource that best matches its path.

    Access Gateway automatically selects the protected resource that is used with the specified path. It selects the current protected resource whose URL path most closely matches the specified path.

    • If you have a protected resource with a URL path of /*, Access Gateway selects that resource unless you have configured a protected resource that has a URL path that more closely matches the path specified on this page.

    • If you add a protected resource at a future time and its URL path more closely matches the path specified on this page, Access Gateway automatically reconfigures to use this new protected resource.

    • If you disable a protected resource that Access Gateway has assigned to a path-based service, Access Gateway automatically reconfigures and selects the next protected resource that most closely matches the path specified on this page.

    1. In the Path List section, click the Protected Resource link.

    2. Examine the contract, Authorization, Identity Injection, and Form Fill policies assigned to this protected resource to ensure that they meet the requirements for your path-based service.

    3. To return to the Path-Based Multi-Homing page, click the Overview tab, then click OK.

      • If the protected resource meets your needs, continue with Step 5

      • If the protected resource does not meet your needs, you must create a protected resource for the path-based proxy service. Continue with Step 4.d.

    4. Click OK, select the name of the parent proxy service, then click Protected Resources.

    5. In the Protected Resource List, click New, specify a name, then click OK.

    6. Select an Authentication Procedure.

    7. In the URL Path List, specify the path you used when creating the path-based proxy service. For example, if your path was /apps, specify /apps/* or /apps in the URL Path List.

      IMPORTANT:If you create multiple protected resources that exactly match the path-based multi-homing service, there is no guarantee that a specific protected resource will be used. For example, if you create protected resources for both of the paths specified above (/apps and /apps/*) and you have a path-based service with a path of /apps, either of these protected resources could be assigned to this path-based service in Administration Console or used when access is requested.

    8. Make sure the protected resource you created is enabled. If the resource is disabled, it does not appear in the Path List for the path-based proxy service.

    9. (Optional) Enable the policies the path-based proxy service requires. Click Authorization, Identity Injection, or Form Fill and enable the appropriate policies.

    10. Click OK.

  5. Click OK.

  6. To apply the changes, click the Access Gateways link, then click Update > OK.