I have a Portal site with a federated ArcGIS Server site installed inside of an organizational firewall on the same server. Both web adapters are installed on the same server. Everything works as expected on the inside. ESRI Tech support said that I could use IIS on a reverse proxy server in the DMZ to access Portal from the outside using IIS Rewrite/ARR. I can access Portal, but the data itself is not accessible. The links to feature layers are broken in Portal and when you try to open a web map with internal data, it fails as well. It's obvious that the URLs are pointing to internal servers that aren't accessible from the outside. Has anyone been able to implement Portal this way successfully, or did I get bad advice from the start?
PS: Today's solution from Tech Support was to install the web adapter in the DMZ. This is exactly what I don't want to do, because 95% of what the organization needs to do is internal. The external access is only for limited field edits.
I'm very curious about this and what you describe is what I've been told in the past.
It's my understanding that you need a WA in the DMZ in addition to the ones inside the firewall.
At least, that's how I recall having heard the setup described.
Does the Wiki have any additional info on this:
Thanks for the Wiki Paul. I didn't see anything specific in there for what I am trying to do. I have a strong feeling that what I want to do isn't possible. Portal can only have one WA and that's the issue. I don't want my internal users to have to go outside to get in. The system needs to be accessible from inside the firewall at all times.
I wish I could remember better what I've heard about this setup because someday we'll be needing it.
It might be that you need a Portal or AGS out in the DMZ and that's were the WA is installed to act as proxy back inside the firewall. Maybe it's another AGS you put out in the DMZ and then add a WA to it.
If I can find any notes, I'll post back to here.
I second Paul's comment. You need something in the DMZ that can be used to reach your internal ArcGIS Server. The tough part about your implementation will be having separate entry points into a federated Server. For example, you federate using https://internal_services.domain.com/internal_wa/ as the services URL and https://server.domain.com:6443/arcgis as the admin URL. The web adaptor "internal_wa" resides on machine internal_services.domain.com within your internal network and the server is installed on server.domain.com. However, you can't reach these services from outside of the organization. You can set up another entry point within the DMZ, (another web adaptor, reverse proxy, whatever it is), so that people outside of the organization have a way to get to the services they're supposed to get to, (for example https://external_services.domain.com/external_wa/services). Then, you can share whichever services should be publicly available with Everyone within Portal, and external users reach the services through the external URL. The tricky part will be if you're intending on having secure services that are available externally. I don't think that will work, since Portal will be federated to Server through the internal services URL, and that's the URL allowed to go through the oauth authentication for Portal.
Thanks again Paul. I am stepping back through that again today. I read somewhere that you may need to restart the Portal service after updating the WebContextURL. I am giving that a shot.