ArcGIS Portal reverse proxy with iis

[AbdelrahmanAbdelrazek]

Hello,

We have set up ArcGIS Portal and configured a web adaptor, Everything works fine in the local environment.

We need to access it through a DMZ.

We have setup a reverse proxy on IIS, Everything works fine whenever we try to access the Portal through a URL like this https://reverseproxy.domain.com/portal/home.

But as a company policy, everything public should have "/external" added to the URL

So the URL should be https://reverseproxy.domain.com/external/portal/home.

I set a rule to exclude the "/external" part from the URL but I get a 404 error for a URL like this 

https://reverseproxy.domain.com/external/sharing/rest

It seems that some requests are sent without adding the "/portal" part of the URL.

Any ideas please about this?

Thanks in advance.

[Anonymous User]

Which reverse proxy are you using? Does it work ok without the /external requirement? Can you post the relevant proxy config rules (not the entire config).

@ShanonLoughton 

[AbdelrahmanAbdelrazek]

We are using iis (ARR module) for the reverse proxy.

Everything works perfectly without /external

The first inbound rule we used:

whenever a URL matches this regular expression "external/portal/(.*)"

It will redirect the request to a server farm after overwriting this part with "/portal/{R:1}"

With this rule, I was able to hit portal but there were some 404 errors. That is why I had to set two more inbound rules.

I wonder if there is another way for handling such scenarios other than these rules.

[ChristopherPawlyszyn]

I think you're going to be fighting an uphill battle on this one, especially since this is violating two requirements of Portal for ArcGIS.

The first is the system requirement for Portal for ArcGIS only supporting a single DNS.

Domain name service and fully qualified domain name requirements
https://enterprise.arcgis.com/en/system-requirements/latest/linux/portal-for-arcgis-system-requireme...

The second would be the context configuration, which is only supposed to go one sub-page deep in the URL.

Prerequisites to configure a highly available portal
https://enterprise.arcgis.com/en/portal/latest/administer/windows/configuring-a-highly-available-por...

To achieve what you are proposing, it would require the proxy action to cover every circumstance where a request coming into the IIS/ARR machine would be re-written as Portal expects it for the current WebContextURL on the local web adaptor machine. It would also require the proxy to rewrite any redirect response headers with the external URL and context(s). Even that wouldn't account for some of the pages that are initiated by other resources and would likely still use the internal Portal address to load.

[AbdelrahmanAbdelrazek]

Thanks, @ChristopherPawlyszyn  for your response.

I just have a question about the second violation you mentioned.

It is mentioned as a note in the reference you provided that : 

"If you do not use ArcGIS Web Adaptor, ensure that the load balancer context name is only one level deep. For example, you can have a load balancer URL such as https://lb.domain.com/enterprise, but you cannot have a load balancer URL such as https://lb.domain.com/myorg/enterprise"

I believe this only applies if we don't use a web adaptor, and we do use it.

So there should be a way for doing so through the web adaptor, is this correct?

Thanks in advance.

[ChristopherPawlyszyn]

I read that a bit differently than you did. The single context (one level deep) URL is implied during the installation of the ArcGIS Web Adaptor, but when using a load balancer that requirement needed to be explained since the web adaptor isn't integral to the context of the URL(s).

[AbdelrahmanAbdelrazek]

This is a possiblity too, Thanks @ChristopherPawlyszyn!