A Web Portal service configured in PAM and launched from the PAM client access page fails to connect to a virtually hosted IIS web service on a Windows host when using a native browser. The service is defined as follows:
It works when using the PAM browser. The site binding in IIS for the service is configured with the FQDN that we have configured as device address in PAM.
This is a limitation of how the PAM client works. When the PAM browser is used, PAM builds the URI string that the browser sends after the connection to the remote web server is established. Even though the connection goes through the local IP (127.2.2.2 in the example shown here), the PAM browser knows that the actual URI to connect to is http://<device address>[:<dest port>]. After the connection is established, it sends the HTTP request using this URI, as seen in a network trace between PAM server and target device:
But the native browser does not have this information. It is launched with a request to connect to the local IP and port configured in the TCP/UDP service. The PAM client routes this connection correctly to the web service on the target device, but the URI in the HTTP request once the connection is established is http://<local IP>:<local Port>. Depending on whether or not IIS is listening on local IPs, this may go to a default page, or it may result in a 404 Not Found error, as seen in the screenshot below:
Enter the FQDN in the Host Header field of the TCP/UDP service:
Note that the Host Header field does NOT accept tokens, such as <Device Name>. It has to be a specific host name matching the host name in the site binding. If you have multiple target devices hosting a service that uses the FQDN of each device, you would have to define a dedicated service for each device.
See the information on the Host Header field on page Configure a Service to Access a Web Portal.