Using iptables PREROUTING NAT Instead of HTTP Proxy for Redirecting Port 443 to 8443 in ArcGIS Enterprise

Question

Hello everyone,

I’m currently configuring an ArcGIS Enterprise environment on an Oracle Linux server with a single-machine deployment where both the Portal and Server are deployed on the same Tomcat instance. By default, Tomcat handles HTTPS traffic on port 8443. However, to simplify access, I want to redirect HTTPS traffic from the standard port 443 to Tomcat’s 8443.

Instead of using a traditional HTTP proxy (like Apache or Nginx) as suggested in the documentation, I'm considering using iptables with a PREROUTING NAT rule to achieve this port redirection.

My current iptables configuration is as follows:

iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 8443
This approach seems to work for redirecting traffic, but I'm curious about the potential implications or limitations compared to using an HTTP proxy. Specifically:

* Are there any known issues or performance considerations when using iptables NAT for port redirection in an ArcGIS Enterprise setup?
* What advantages might I be missing by not using a dedicated HTTP proxy for this purpose?
* Could this approach affect SSL/TLS management or impact other ArcGIS Enterprise components?Given that this is a single-machine deployment on Oracle Linux with both Portal and Server on the same Tomcat server, I would appreciate any insights or experiences that others have had with similar setups.

Thanks in advance!

JonathanEpstein · Accepted Answer

@JPBogado I urge you (for reasons having little to do with Esri, but only as a modern best-practice) to avoid iptables and instead use a firewalld-based solution such as Esri uses in their cookbooks.   See:

https://github.com/Esri/arcgis-cookbook/tree/main/cookbooks/esri-tomcat

and drilling down, use the port-forwarding shown at https://github.com/Esri/arcgis-cookbook/blob/main/cookbooks/esri-tomcat/recipes/firewalld.rb#L46

My team has wrapped Ansible playbooks around these Chef cookbooks, and it works very well for us.   Unfortunately we have too many custom and proprietary bits to share these Ansible playbooks anytime soon.