Hi Jonathan Quinn,
The Esri portal for arcgis product sometimes makes server side requests to its fully qualified domain name (FQDN). Things like map printing, validating federated servers, etc. We also register our web-adaptors using the FQDN and setup server federation with the FQDN.
With our agencies DMZ configuration, we have issues when the server in the DMZ needs to talk to itself (or other apps in the DMZ) on the FQDN. The FQDN resolves to an external IP address hosted on a content inspection web-application firewall (WAF) WAN interface. Traffic is terminated, then inspected. Validated traffic is then routed through a back-end internal (LAN) interface on that WAF. I dont have the full technical details/knowledge here, but I reached out to the network team, and they provided me this information:
DMZ Application would like to access other DMZ application but using the DNS gives the IP address of the application Virtual interface on the Web Application Firewall. This can causes an issue with the Traffic reaching the external interface of the WAF but having the "client" residing on the internal interface. This create what is call asynchronous routing where the flow back and forth does not follow the same path and can cause issue (in this case the WAF receive on one interface IP and send on another thus looking like two different people ).
So, as a work-around to this "asynchronous routing" issue, we typically did 1 of 2 things:
Option 1 - Add a local etc/hosts entry on the 'client' server to resolve the FQDN to the actual server in the DMZ (usually to just itself, but sometimes to other applications/services hosted in the same DMZ). We also had to upload SSL Certificates to the DMZ servers with their FQDN as a SAN to deal with SSL trust issues. We do have issues with option 1 if there are routing rules sending traffic on a certain FQDN to multiple back-end servers (since these routing rules are not on the actual DMZ servers themselves).
Option 2 - Add a local route on the 'client' server to resolve the FQDN to the private interface of the WAF. This was the preferred approach, but was only discovered a short time ago (so most legacy applications were still using option 1).
For this specific environment, we actually moved it to a new DMZ environment that no longer has the same async routing issue (different story there). So our etc\hosts entry is no longer required. I do have a few other apps in the legacy DMZ environment (with the async routing issue), but this issue in this thread (re-direct to 7443) has not popped up there yet. Crossing my fingers it doesnt...
---
From the local machine, When I access the https://localhost:7443/arcgis/sharing/rest, it re-directs me to the https://machine.domain:7443/arcgis/sharing/rest
I do NOT currently have a privatePortalURL property set, and I think I'm going to keep it empty for now. Per the System properties—ArcGIS REST API: Administer your portal | ArcGIS for Developers -
privatePortalURL—Specifies the internal URL that ArcGIS Server should use to communicate with the portal. This property is typically used when you have a highly available ArcGIS Enterprise deployment, or if the server cannot communicate directly with the portal machine.
We do not have a highly available deployment, and our server machines can communicate with the portal on its FQDN.
I'll look at this again if this (or another issue) crops up. Thanks!!
