nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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.

Encuentra más publicaciones etiquetadas con

Accepted answers

All comments

lvargas

Hello @CraigRussell

Thanks for your time.

- It might be possible, and it might work, but it doesn't mean that it is documented and/or supported.

There is documentation, for example.

https://enterprise.arcgis.com/en/portal/latest/administer/windows/using-a-reverse-proxy-server-with-portal-for-arcgis.htm

The Web Adaptor is a reverse proxy built to act as such, some time ago support had been consulted about, and the answer was something like "Web Adaptor is not the only way to perform the process, if configured properly the alternative should work normally".

But there is no official step-by-step, so you have to build it manually without a base and this maybe can cause issues, I understand your argument and you are right.

- And CloudBuilder isn't the exact same scenario as a standard reverse proxy setup because its doing all of the config for you.

It is interesting how it is configured in new versions, since it discards IIS; there must be some performance / security reason involved.

- 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.

Ah ok, yes this can be an option. At the moment I see it as the best alternative in case the environment cannot be configured.

The intention is make it as simple as possible, a reverse proxy to both sites and filter the rest through rules in the antivirus / firewall; the detail with this redirection from the IIS in the DMZ to the internal IIS would be the performance, it could be a temporary alternative while we figure out how to configure the environment.

It has been possible to configure Portal, create hosted services too but I have had problems with the ArcGIS GIS Server. The IIS does not rewrite the rest fine and sometimes place the context /arcgis in the url, I do a manual change to /server and you can access.

Regards.

crussell_esriau

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 Enterprise:

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.

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.

crussell_esriau

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:

Re-install the web adaptors on your DMZ IIS machine and use them instead of URL Rewrite; or
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:
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

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.

crussell_esriau

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 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.

crussell_esriau

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.

Únete a la Conversación

Los miembros registrados pueden publicar, seguir actualizaciones y más. ¿Nuevo aquí? Regístrate gratis.

Enlaces Rápidos

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.