DMZ and Federation

1163
2
02-15-2018 12:36 PM
LevinConway
New Contributor III

Greetings,

We have an internal ArcGIS Enterprise deployment which we have been using for several years with staff, utilizing VPN connections for remote devices.

We now are looking at setting up a separate, external GIS server with public (unauthenticated) GIS services that could be consumed inside ArcGIS Online web maps. I am interested if and how portal federation could be achieved using the design pattern where both the Web Adaptor and ArcGIS Server Site are located in a DMZ (as detailed in this image). What would our options be?

1. Both the GIS Server site and the Portal instance would need to be located in the same DMZ.

2. The GIS Server site could be federated through the DMZ's internal firewall to our existing internal Portal located on the private network.

3. We would be better off with a "classic" implementation of ArcGIS Server, avoiding federation and possibly waiting for

a future release that could federate our external server with ArcGIS Online.

Thanks in advance for any insight!

Tags (3)
0 Kudos
2 Replies
JoeHeggenstaller
New Contributor III

Did you ever get any direction or suggestions on implementing this? I'm in the process of setting up a single machine in a DMZ with ArcGIS Server, Portal, Datastore and WebAdapters installed and it's been quite a challenge, compared to the 3 internal ArcGIS Enterprise sites we've installed.

Any thoughts or hints you may have would be appreciated.

Thank you,

Joe

0 Kudos
JonathanQuinn
Esri Frequent Contributor

Ideally, you'd have your web adaptor or reverse proxy in the DMZ that sends requests to the GIS Server within your internal network. You could set up your reverse proxy in the DMZ and send traffic to the web adaptor on 443 within your internal network so you only have the standard 443 port open between your DMZ and internal network:

https://enterprise.arcgis.com/en/server/latest/administer/windows/firewalls-and-arcgis-server.htm#GU...

We're working on updating that documentation, but that's the general idea.

In terms of federating, Portal doesn't need access to the services URL, only the admin URL used to federate. For example, your machines could be within your internal network and you'd use https://server.domain.com:6443/arcgis as the admin URL. Externally, you'd have your nice FQDN that hides the internal machine names.

0 Kudos