Using IIS as Reverse Proxy for Portal and ArcGIS GIS Server

[lvargas]

Hello,

Its possible configure a reverse proxy in IIS that works fine having one rule for portal (/portal) and another for ArcGIS GIS Server (/server)?

We need that IIS works as a reverse proxy (URL Rewrite is used), and both Portal and Server use different context (https://domain.com/portal > Portal and https://domain.com/server > ArcGIS GIS Server [with full functionality, just as if you were using Web Adaptor]).

In Azure we have something similar (I include the web.config), the difference is  the name used, in this case /arcgis is used for both applications (https://domain.com/arcgis/home > Portal and https://domain.com/arcgis/manager - https://domain.com/arcgis/rest/services - https://domain.com/arcgis/admin etc for ArcGIS GIS Server), that configuration works normally; but it is not the required in this case.

This is the environment:
1x ArcGIS Enterprise 10.8.1 on a Windows Server 2019 Standard  (Portal, ArcGIS GIS Server and ArcGIS Data Store) (on the LAN) and 1x server (DMZ) in Windows Server 2019 Standard with IIS 10.0.18362.1 (ports are open etc.).

I have tried several things, some work partially but I have not yet found a configuration where the whole environment works fine.

web.config

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<rewrite>
<rules>
<clear />
<rule name="RP-HTTPS-Server" stopProcessing="true">
<match url="^[^/]+/(manager|admin|rest|services|mobile|tokens|login|help)(/?)(.*)" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false">
<add input="{HTTPS}" pattern="on" />
<add input="{SERVER_PORT}" pattern="443" />
</conditions>
<serverVariables>
<set name="HTTP_X_FORWARDED_HOST" value="{HTTP_HOST}" />
<set name="ORIGINAL_URL" value="{HTTP_HOST}" />
</serverVariables>
<action type="Rewrite" url="https://internalserver.domain:6443/{R:0}" />
</rule>
<rule name="RP-HTTPS-BaseContextPath" stopProcessing="true">
<match url="(arcgis/?)$" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false">
<add input="{HTTPS}" pattern="on" />
<add input="{SERVER_PORT}" pattern="443" />
</conditions>
<serverVariables>
<set name="HTTP_X_FORWARDED_HOST" value="{HTTP_HOST}" />
<set name="ORIGINAL_URL" value="{HTTP_HOST}" />
</serverVariables>
<action type="Redirect" url="https://exteraldomain.com/{R:0}/home/" redirectType="SeeOther" />
</rule>
<rule name="RP-HTTPS-Portal" stopProcessing="true">
<match url=".*" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false">
<add input="{HTTPS}" pattern="on" />
<add input="{SERVER_PORT}" pattern="443" />
</conditions>
<serverVariables>
<set name="HTTP_X_FORWARDED_HOST" value="{HTTP_HOST}" />
<set name="ORIGINAL_URL" value="{HTTP_HOST}" />
</serverVariables>
<action type="Rewrite" url="https://internalserver.domain:7443/{R:0}" />
</rule>
</rules>
<outboundRules>
<rule name="Rewrite Location Header HTTPS" preCondition="IsRedirection">
<match serverVariable="RESPONSE_Location" pattern="^https://internalserver.domain:(6|7)443/(.*)" />
<action type="Rewrite" value="https://{ORIGINAL_URL}/{R:2}" />
<conditions>
<add input="{ORIGINAL_URL}" pattern=".+" />
</conditions>
</rule>
<preConditions>
<preCondition name="IsRedirection">
<add input="{RESPONSE_STATUS}" pattern="3\d\d" />
</preCondition>
</preConditions>
</outboundRules>
</rewrite>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="2147483647" />
</requestFiltering>
</security>
<directoryBrowse enabled="true" showFlags="Date, Time, Size, Extension" />
<staticContent>
<mimeMap fileExtension=".lyr" mimeType="application/octet-stream" />
</staticContent>
</system.webServer>
</configuration>

Regards.

[CraigRussell]

Hi

Will internal traffic hit the ArcGIS Enterprise machine directly, or will this also go through the DMZ?  The reason that I ask is that Portal only supports one DNS, so you can't have internal traffic going to https://portal.domain.com/portal and external traffic going to https://external-portal.domain.com/portal.  The ArcGIS Server URL used for federation needs to be the same for internal and external traffic as well.

[lvargas]

Hello @CraigRussell 

Thanks for reply.

- Will internal traffic hit the ArcGIS Enterprise machine directly, or will this also go through the DMZ?
Internal and external traffic use the IIS (https 443 TCP) in the DMZ. Internally they have a rule for 443 and registered DNS name (https://external-portal.domain.com/portal) so, on the LAN can resolve the name  external-portal.domain.com

- The reason that I ask is that Portal only supports one DNS
Yes, they use only one DNS name; the external/public.

- so you can't have internal traffic going to https://portal.domain.com/portal and external traffic going to https://external-portal.domain.com/portal.
Yes, we wil use only the external DNS assigned.

- The ArcGIS Server URL used for federation needs to be the same for internal and external traffic as well.
Yes, internal and external traffic use the same DNS, in this case https://external-portal.domain.com/ (WebContextURL its configured for Portal and ArcGIS GIS Server).

A test environment is currently being used to check the requirement. They wants remove the current Web Adaptors (/portal and /server) and use the IIS like reverse proxy.

We tried use a configuration similar to one we have in Azure (it uses IIS as reverse proxy, no Web Adaptors), the differente is the context name used. For AGE 10.4 - 10.1 ESRI Cloud Builder for Azure use /arcgis for portal and server (previous web.config commented). So we have not been able to configure the redirection properly since the required differents contexts (/portal and /server are required and not /arcgis).

The new wizard to deploy environments in Azure can have diffents contexts names, Portal as /portal and ArcGIS Server as /server (for example, we can customize new names for an Image Server /image if a new server its added), but this its using Azure Application Gateway, now they are not using the IIS, so its different and I cant used for example in the end user enviroment 'cause are not Azure servers.

I have been modifying the rules etc, but have not get the whole environment working correctly without errors / issues, so I was wondering if anyone has configured the AGE via IIS using it as a reverse proxy.

Regards.

[CraigRussell]

I'm not aware of any specific examples of using IIS + URL Rewrite as a reverse proxy with ArcGIS Enterprise, so unfortunately I can't help you out there.  Also while I don't have personal experience with this type of configuration yet, the Azure Application Gateway documentation indicates that it can be used to access on-premises servers when they're connected by Azure ExpressRoute or VPN tunnels if traffic is allowed, so this could be an option - Application gateway components | Microsoft Docs

Other than this, have you considered installing the portal and server web adaptors in the DMZ?  This would essentially act as a reverse proxy without having to worry about URL Rewrite or Application Request Routing.

[lvargas]

Hello @CraigRussell

Thanks for your response.

It is a local environment with DMZ, Azure is not used in this case, but it could be an alternative; the thing, its the cost for this external service.

Yes, in production they are now using Web Adaptors but for a special situation it is required to be done through IIS.

If the sites were /arcgis there would be no problem, since I can use the configuration that was in IIS with Azure (10.4 - 10.7), the issue is the custom context /portal or /server.  That's where I've had problems since not everything works for me.

Thanks for your time and comments.

[CraigRussell]

So to confirm, in your OP you have outlined that your current ArcGIS Enterprise 10.8.1 environment is a single server with:

• ArcGIS Portal
• ArcGIS Server
• ArcGIS Data Store

Does this server also have two IIS web adaptors on it - one called portal and another called server?  Did you use ArcGIS Enterprise Builder, or install each component manually?

[lvargas]

Hello @CraigRussell 

 - in your OP you have outlined that your current ArcGIS Enterprise 10.8.1 environment is a single server with:

Yes. There are two environments, one with distributed in servers (production) and the other in which the test is being done, this site is on a single server (Portal, ArcGIS GIS Server and Data Store [Relational]) and its the commented before. Was creating for testing and in this case its were Im trying use the IIS as reverse proxy.

- Does this server also have two IIS web adaptors on it - one called portal and another called server? 

The Web Adaptors, one for /portal (Portal) and /server (ArcGIS GIS Server) were installed on a DMZ server. A snapshot was taken and they were removed, so now only the IIS on this server.

-Did you use ArcGIS Enterprise Builder, or install each component manually?

It was installed manually.

Thanks.

[CraigRussell]

Ok, so referring to the documentation for using a reverse proxy with ArcGIS Server, it states that if you aren't using web adaptor (i.e. you are directly communicating with ArcGIS Server over port 6443) then you need to use /arcgis as your web context to avoid URL redirection issues.  This is somewhat mentioned in the Portal documentation as well, but it doesn't explicitly discuss direct access over port 7443.

Technically while you federated using /portal and /server web adaptors, you've uninstalled them - they are no longer part of the deployment.  

I think you have three options here:

1. Re-install the web adaptors on your DMZ IIS machine and use them instead of URL Rewrite; or
2. Install the portal and server web adaptors on the ArcGIS Enterprise machine, which should allow you to then use the /portal and /server context in the DMZ reverse proxy rules; or
3. Start over (unfederate Portal and Server), but:
   1. Do not install the web adaptors as part of your deployment; and
   2. Set up you reverse proxy/URL rewrite rules using the /arcgis context for both Portal and Server before federating

Regarding option #1, you mentioned this in a previous post:

"...in production they are now using Web Adaptors but for a special situation it is required to be done through IIS."

What is the situation which requires you to use IIS without the Web Adaptors?  While I think that you should be able to set up using the second option if you really want to, it is clearly not as well documented as using the Web Adaptors, and supportability might be an issue.

One other thing - ensure that your URL Rewrite reverse proxy rule isn't doing SSL offloading.  This is not supported in ArcGIS Enterprise.

[lvargas]

Hello @CraigRussell 

- Ok, so referring to the documentation for using a reverse proxy with ArcGIS Server, it states that if you aren't using web adaptor (i.e. you are directly communicating with ArcGIS Server over port 6443) then you need to use /arcgis as your web context to avoid URL redirection issues. This is somewhat mentioned in the Portal documentation as well, but it doesn't explicitly discuss direct access over port 7443.
It is possible to have a name other than /arcgis and works; we have environments where use an F5, an Apache or an IBM WAS where the paths are different (/portal & /server) and use a reverse proxy, we don't always use the /arcgis; since 10.8.1 in Azure with the cloud builder contexts can be other than /arcgis. The key is in the configuration and being able to rewrite the output / input.

- Technically while you federated using /portal and /server web adaptors, you've uninstalled them - they are no longer part of the deployment.
There is a snapshot of the server and it can always be reconfigured; the change was first made in testing so it is not critical for normal operation.

I think you have three options here:

- Re-install the web adaptors on your DMZ IIS machine and use them instead of URL Rewrite; or
Yes, this is possible but it is what we want to avoid.

- Install the portal and server web adaptors on the ArcGIS Enterprise machine, which should allow you to then use the /portal and /server context in the DMZ reverse proxy rules; or
Start over (unfederate Portal and Server), but:
Do not install the web adaptors as part of your deployment; and
Its needed keep the environments separated, in other scenarios we could have the Web Adpators in the IIS and put them in the server with Portal, or in some other and make a NAT in the router to be exposed; but in this situation the internal servers can not be exposed in this way, its required use the DMZ.

- Set up you reverse proxy/URL rewrite rules using the /arcgis context for both Portal and Server before federating

We could use /arcgis to make it work, the long short story is that this required un-federate and then federate again, then having to do some work with web maps, viewers etc. this is preferred to avoid.

- Regarding option #1, you mentioned this in a previous post:

"...in production they are now using Web Adaptors but for a special situation it is required to be done through IIS."

- What is the situation which requires you to use IIS without the Web Adaptors?
By organization rules, they have chosen not to have third-party applications on this servers in the DMZ, they do it directly with the IIS; this is due to a security breach with a similar application that caused them inconveniences. 

- While I think that you should be able to set up using the second option if you really want to, it is clearly not as well documented as using the Web Adaptors, and supportability might be an issue.
The reverse proxy settings I've found on forums / youtube works partially, I've been editing and testing, some work with Portal fine, but then I have issues with ArcGIS Server for publishing etc. I haven't found one that works fine. I haven't found specific information in forums, articles or Salesforce either.

- One other thing - ensure that your URL Rewrite reverse proxy rule isn't doing SSL offloading. This is not supported in ArcGIS Enterprise.
Yes, we are not using/doing SSL offloading.

Regards.

[CraigRussell]

It is possible to have a name other than /arcgis and works; we have environments where use an F5, an Apache or an IBM WAS where the paths are different (/portal & /server) and use a reverse proxy, we don't always use the /arcgis; since 10.8.1 in Azure with the cloud builder contexts can be other than /arcgis. The key is in the configuration and being able to rewrite the output / input.

It might be possible, and it might work, but it doesn't mean that it is documented and/or supported.  And CloudBuilder isn't the exact same scenario as a standard reverse proxy setup because its doing all of the config for you.  This is from Configure a reverse proxy server with ArcGIS Server—ArcGIS Server | Documentation for ArcGIS Enterpr...:

Its needed keep the environments separated, in other scenarios we could have the Web Adpators in the IIS and put them in the server with Portal, or in some other and make a NAT in the router to be exposed; but in this situation the internal servers can not be exposed in this way, its required use the DMZ.

To clarify this option, I mean that you would still use your reverse proxy in the DMZ, and this would point to the internal web adaptors.  Installing the web adaptors on the ArcGIS Enterprise machine would allow you to use the /portal and /server context that you've already used in federation with URL Rewrite and it would then align to the requirements outlined in the ArcGIS Server documentation referenced above.  I can't say for certain that this will work, but on the surface it looks like a better fit without having to worry about unfederating and refederating.

By organization rules, they have chosen not to have third-party applications on this servers in the DMZ, they do it directly with the IIS; this is due to a security breach with a similar application that caused them inconveniences.

I suspected it was something like this.  The counterargument that I would provide is that instead of using Web Adaptor which is a well supported mechanism with many real world examples of usage for public-facing deployments, you're being made to use two non-standard IIS modules (URL Rewrite and Application Request Routing) with custom logic which could potentially be less secure.  But I appreciate why these determinations are made and that you're really just trying to make the best of the situation.