In many cases, the applications you want to make available via Browser Access are running on a single web server. Because it’s not necessary for the externally advertised DNS hostnames to match the internal ones, unmatched hostnames can be used to handle scenarios where one host is serving web applications on multiple ports.

For Browser Access enabled applications, Service Edges only listen on ports 80 and 443 for inbound connections from web browsers. So, a port 80 connection is automatically redirected to port 443, while a port 443 connection does domain virtualization through the provided Server Name Indication (SNI).

As a consequence, the service only receives one domain name and one port, and mapping that domain with port combination to multiple ports is not possible. However, you can map ports through multiple domain names using one of the following methods:

• Method 1: Use unique hostnames per application by using your internal DNS or by explicitly defining static servers in Private Applications. This allows the advertising of a unique external hostname, that matches an internal hostname and port combination. For example, you could configure:
  • The hostname web.corp.com (advertised externally), and map to web.corp.com:80 (configured internally)
  • The hostname crm.corp.com (advertised externally), and map to crm.corp.com:443 (configured internally)
  • The hostname webadmin.corp.com (advertised externally), and map to webadmin.corp.com:1000 (configured internally)

Using this method, as long as an internal DNS for these three hostnames is configured, then dynamic server discovery for all three applications works. However, if an internal DNS doesn't exist for these three hostnames, then dynamic server discovery doesn't work and you must explicitly define static servers within the Admin Portal for them.

• Learn more about configuring Private Applications using Method 1 above

  To configure Private Applications using Method 1, let’s assume that you have an application that has an FQDN of example.corp.com, which uses ports 80, 443, and 1000:

  1. If your internal DNS can resolve the hostnames, then proceed to step 3 and specify a server group that has Dynamic Server Discovery set to On. Make sure that you specify a server group that includes the proper App Connector groups for your servers. To learn more, see Enabling Dynamic Server Discovery.

  If your internal DNS cannot resolve the hostnames, then you must:

  1. Explicitly define the static servers. In this example, you would need to explicitly define the web.corp.com, crm.corp.com, and webadmin.corp.com servers.
  2. Add the defined servers to a server group that has Dynamic Server Discovery set to Off.
  3. Configure an application segment using the fully qualified domain names (FQDNs) you associated to the main application on your internal DNS:
     1. Go to Policies > Access Control > Private Applications > App Segments.
     2. Click Add Application Segment.
     3. Define the application (i.e., example.corp.com) using the FQDNs you associated to it on your internal DNS, with the proper port numbers applied. For example, for:
        • web.corp.com:80 - Select HTTP and 80
        • crm.corp.com:443 - Select HTTPS and 443
        • webadmin.corp.com:1000 - Select HTTPS and 1000

  FQDNs that are defined in an application segment must map to the Browser Access (web server) certificate selected to maintain the chain trust. In this example, crm.corp.com and webadmin.corp.com don't match with the web server certificate, so we must select Use Untrusted Certificates for both.

  4. Complete the configuration on the 1 Define Applications tab, then click Next.
  5. Complete the configuration on the 2 Segment Group tab, then click Next.
  6. On the 3 Server Groups tab:
     • If your internal DNS can resolve the hostnames, you can use an existing server group that has Dynamic Server Discovery set to On.
     • If your internal DNS cannot resolve the hostnames, make sure that you select the server group you created in step 1.
  7. Review your application segment configuration settings on the 5 Review tab and review and edit any policies, as needed, on the 6 Policies tab.
  8. Publish the CNAMEs for the FQDNs you defined in step 2c above.

  Close
• Method 2: You can define the applications within an application segment internally to point to a specific hostname or IP address. For example, you could configure:
  • The hostname web.corp.com (advertised externally), and map to linux.corp.com:80 (configured internally)
  • The hostname crm.corp.com (advertised externally), and map to linux.corp.com:443 (configured internally)
  • The hostname webadmin.corp.com (advertised externally), and map to linux.corp.com:1000 (configured internally)

However, this causes certificate validation problems because the hostname check fails. So users see web server certificate errors when connecting to any of the three applications in the example above.

Zscaler recommends using Method 1 above, as this method does not provide a satisfactory usability experience for your end users.

Like Method 1 above, as long as the internal DNS for these hostnames are configured, then dynamic server discovery for all applications works. If an internal DNS doesn't exist for these hostnames, then dynamic server discovery doesn't work and you must explicitly define a static server within the Admin Portal and map it to the appropriate server group. In this example, server group linux.corp.com maps to server linux.corp.com. However, the server can be also specified by IP address, if necessary (i.e., server group linux.corp.com maps to server 172.31.23.203). You can then have all three applications use the same server group, but you would not be able to verify web server certificates.

• Learn more about configuring Private Applications using Method 2 above

  To configure Private Applications using Method 2, let’s assume that you have an application that has an FQDN of linux.corp.com, which uses ports 80, 443, and 1000:

  1. If your internal DNS can resolve the hostnames, then proceed to step 3 and specify a server group that has Dynamic Server Discovery set to On. Make sure that you specify a server group that includes the proper App Connector groups for your server. To learn more, see Enabling Dynamic Server Discovery.

  If your internal DNS cannot resolve the hostnames, then you must:

  1. Explicitly define the static servers. In this example, you would need to explicitly define the linux.corp.com server.
  2. Add the defined server to a server group that has Dynamic Server Discovery set to Off.
  3. Configure an application segment using the fully qualified domain names (FQDNs) you associated to the application on your internal DNS:
     1. Go to Policies > Access Control > Private Applications > App Segments.
     2. Click Add Application Segment.
     3. Define the application (i.e., linux.corp.com) using the FQDNs you associated to it on your internal DNS, with the proper port numbers applied. For example, for:
        • web.corp.com:80 - Select HTTP and 80
        • crm.corp.com:443 - Select HTTPS and 443
        • webadmin.corp.com:1000 - Select HTTPS and 1000
     4. Complete the configuration on the 1 Define Applications tab, then click Next.
     5. Complete the configuration on the 2 Segment Group tab, then click Next.
     6. On the 3 Server Groups tab:
        1. If your internal DNS can resolve the hostnames, you can use an existing server group that has Dynamic Server Discovery set to On.
        2. If your internal DNS cannot resolve the hostnames, make sure that you select the server group you created in step 1.
     7. Review your application segment configuration settings on the 5 Review tab and review and edit any policies, as needed, on the 6 Policies tab.
  4. Publish the CNAMEs for the FQDNs you defined in step 2c above.

  Close

To learn more, see Explicitly Defining Servers and Configuring Application Segments.