ArcGIS Server behind F5 Load Balancer: Do I need the Web Adaptor?

[JasonTipton]

I have 6  ArcServers participating in 1 site that I am deploying. I have setup the IIS webadaptor on 2 machines that are being load balanced behind an F5. Do I need the webadaptor? All the webadaptor does is forward traffic from port 443 to 6443. It also does a little load balancing (maybe).

With the F5, I can do SSL offloading at the hardware level (much more efficient). I can decrypt once at the F5 instead of having to decrypt at IIS, then re-encrypt to pass on to ArcGIS to un-encrypt and have to do it all again on the return. I don't have to have IIS do any URL routing like the web-adaptor does. All traffic to that particular subdomain will be forwarded to the ArcGIS Server site.

The way I see it, you are using IIS as a router/load balancer. If I have access to the real thing, it will be much more efficient and I don't see that I lose anything.

What am I missing? And has anybody already done this?

[BradGeerdes]

Are you using F5 with Web Adaptor and Portal?  Thanks!

[BradGeerdes]

I know this has been a few years, but I am running into F5 - Web Adaptor issues and the folks on this thread seem to have some quality exposure to F5.  Our deployment works if we route traffic directly to Web Adaptor, but as soon as we introduce F5, Error - too many redirects.

We are running into issues when externalizing our Portal.

Setup:

Windows IIS Servers / ArcGIS Server / Portal / Web Adaptor 10.6

ArcGIS Server and Portal installed on "esritst01.abc.com" (Windows "SERVERA") and Web Adaptor for Server and Web Adaptor for Portal is installed on "esritst02.abc.com" (Windows "SERVERB").  Public URL is https://gistst.abc.com/portal.

In the DMZ, we have SERVERB and F5 (F5 is a load balancer).  Public traffic comes into our DMZ via https://gistst.abc.com/portal and first encounters the F5 (load balancer).  The traffic then continues to SERVERB ((esritst02) - Web Adaptors). Finally, the traffic is routed to SERVERA (esritst01) where we have Portal and Server installed.  See the attached image for a diagram.

Problem:

When a user attempts to hit our https://gistst.abc.com/portal, the user receives an error - "gistst.abc.com redirected you too many times" "ERR_TOO_MANY_REDIRECTS.

Any assistance/insight with this would be greatly appreciated.

Thanks!

Brent

[DavidColey]

Hi Brad, yes I encountered this exactly and we use F5 - as a traffic director but not as a load balancer.  We also employ a separate web server to host the web adaptors.  The web server resides in the DMZ, Portal, our hosted and federated sites and data stores are behind the firewall as you show above. 

The web server hosting our web adaptors does not have a DNS entry, rather it is aliased on the F5.  All other machines in our deployment DO have possess DNS names in order to use our org's Comodo root and intermediate certificates for "*.org.net"

So, what was missing were redirect uri's for the appId 'arcgisonline'.  In the portal admin directory, go to Home>Security>OAuth and either perform a ChageAppID or Update App Info and add the redirect uri's:

{"appId":"arcgisonline","redirectURIs":

["*.org.net","https://portalmachinename.bcc.org.local","https://webservermachinename.bcc.org.local","*.bcc.org.local","*.arcgis.com","https://webserverF5alias","https://portalDNSalias"]}‍‍‍

This was needed in addition to setting the web context url and private portal url for the system properties.  

[DavidColey]

Brad Geerdes I'm curious to know did you have a chance to work on this or did this work for you?  For us, it took awhile to figure out and then had to get ESRI support....

[DavidColey]

By the way, if anyone is still curious on this, you should be: At 10.7, the order of your redirect urls as they appear in the array matters.  After upgrading to 10.7 and performing a reboot, when portal came backup the portal machines DNS name was dropped from my array.  when I placed back in the array at the back, I still could not gain access to my generateToken page using the DNS.  The DNS of the portal machine needs to be placed in the array second behind the F5 alias that's hosting your web adaptors.  

This information on the 'arcgisonline' appID REALLY needs to be part of any upgrade 'Tips' or 'Notes' section in the help and/or be a part of the admin help in some way

[JonathanQuinn]

If the arcgisonline redirect URI's are not maintained during an upgrade, that's an issue that needs to be reported to Support. I don't think the generateToken page via the Sharing API uses oauth, only the home app does, and you're only allowed to reach the oauth page if the URL is within the array of the redirect URI's, so order shouldn't matter either.

[DavidColey]

Sorry, but it does matter - for us, at 10.6.x order did not matter, but it matters now.  I only put this out there to help others in case they experienced a similar issue.

[JonathanQuinn]

I see. I was interested in testing this myself so I set up 10.7:

Machine 1 - reverse proxy/load balancer

   lb.esri.com

Machine 2 - Web Adaptor machine

  wa.esri.com

Machine 3 - Portal

  portal.esri.com

The arcgisonline redirectURI array lists the portal machine first, web adaptor second, RP/LB third, and then wildcard entries for *.esri.com and *.arcgis.com:

I can successfully generate a token via any of the URLs:

LB:

WA:

Portal:

I don't doubt you saw an issue, but I imagine it was a deeper problem than just the ordering of the arcgisonline redirectURIs. The generateToken page doesn't use oauth which is what the redirectURI's are related to. Only web applications and the home application sign in rely on the oauth redirect URI list. I imagine that even the *.esri.com would cover any of the URLs I tried.

[DavidColey]

Hi Jon, yes perhaps for the situation you just described, yes.  But don't forget that this thread is related to F5 and how the F5 distributes traffic, etc. In our situation, the F5 performs no load balancing, it simply forwards the traffic to the internal machine ip address that is hosting my portal web adaptor.  Our web adaptor machine has no DNS entry.  It's external name, ags3.scgov.net, is handled at the F5.  We set up DNS entries for all other machines so that we could use our orgs comodo ssl cert for *.scgov.net

At 10.6, when I kept getting re-directs from the DNS name of my portal server to it's internal name for the generateToken page, all of my public apps would then bounce to the portal sign-in page.  I had to use the DNS name of the portal machine because the F5 wouldn't allow me to reach the token page through the public ags3.scgov.net/portal url.  As such, tech support told me that I needed the DNS name of my portal machine in my uri redirect.  I don't not believe you when you say the generateToken page doesn't use oAuth, but tech support seemed to think so, and for our situation it was the only thing that worked.  

At 10.6 the ordering of the uri resouces did not matter, but it certainly seems to at 10.7 - and at any rate it got me back up.

Yes there is probably more going on with our security team than I know about.  And at any rate thanks for posting up your findings.