The issue here is if forums.mydomain.com resolves to something internal like 192.168.0.1 internally then you are doing requests on the internal network and not the external one. so someone could start poking around your network.
If you trust your users I could possibly add a site setting to disable this extra security, but as you’ve seen it doesn’t happen on our hosting because resolving meta.discourse.org internally brings up the external IP address, not the internal network address.
Hey all,
I’m IT for Josh, so the instance is running in containers, on the container host and inside the container the IP resolves to the external IP (The Load Balancer Public IP {ELB}) same as the clients.
@eviltrout, based on the information you have so far, would this new setting potentially fix the problem?
(No rush, just asking 
)
The setting will bypass this security check. However your IT person above said IPs should be resolving to public values so I’m not sure why it would be failing in your case. You can try out later today and report back though.
Before I add a whitelist setting, one thing I realized is I should just whitelist the current host the site is on. If you are oneboxing the same discourse it should ignore those networking rules now:
https://github.com/discourse/discourse/commit/a3729b51ebc9958904f15e5105754380de723997
That certainly makes sense, thanks @eviltrout! I’ll pull the update once it hits tests_paseed.
