I have OS X Server 5.0.15 and I am currently trying to load the website in HTTP, but the HTTP section is only available on your local network but I wants it to be reachable over the internet. SSL works fine, that one is reachable over the internet. Any help will be appreciated.
Mac mini, OS X El Capitan (10.11.1)
If HTTPS TCP port 443 is reachable remotely but HTTP TCP port 80 is not, then this is either the local firewall or the ISP filtering TCP port 80 HTTP traffic, or the port-forwarding rules are missing or mis-configured, or maybe remote service access to HTTP TCP port 80 is blocked on the local server.
Some ISPs can block server-oriented ports on their dynamic (residential) tier of service connections.
Run a traceroute, and see where the connection ends?
Here is the trace route output:
traceroute to tomandjerry.ddns.net (61.49.232.163), 64 hops max, 52 byte packets
1 61.49.232.163 (61.49.232.163) 3.161 ms 2.941 ms 2.591 ms
2 61.49.232.163 (61.49.232.163) 5.320 ms 5.193 ms 5.237
That's a dynamic DNS provider, and that (exceptionally short, and the very fast times) IP traceroute shown is getting the same address repeatedly — that implies a loop exists in the forwarding or somewhere in the local routing configuration. Try a traceroute from where you're also trying the remote HTTP and HTTPS testing. Then check with your ISP, and see if they have policies against HTTP — use of dynamic DNS implies that the public IP address of the target server might be a dynamic IP address.
Here I did a trace route without the dynamic IP Address:
traceroute to 192.168.0.112 (192.168.0.112), 64 hops max, 52 byte packets
1 localhost (192.168.0.112) 6.946 ms 4.603 ms 4.593 ms
Tom Shen wrote:
Here I did a trace route without the dynamic IP Address:
traceroute to 192.168.0.112 (192.168.0.112), 64 hops max, 52 byte packets
1 localhost (192.168.0.112) 6.946 ms 4.603 ms 4.593 ms
An IP host accessing itself is not (usually) subject to a firewall. It's traversing inward from the public internet via the ISP network that's possibly problematic or is being blocked here, from what I can understand of this situation.
I'm getting a completely different IP address translation of the DDNS domain mentioned earlier, too. I don't know why that is.
I think the IP has changed after a day or so, new result:
traceroute to tomandjerry.ddns.net (125.34.221.59), 64 hops max, 52 byte packets
1 125.34.221.59 (125.34.221.59) 29.802 ms 37.057 ms 188.386 ms
2 125.34.221.59 (125.34.221.59) 49.807 ms 37.656 ms 39.503 ms
I'd expect to see different IP addresses in the list, and a longer trace — it does not appear that the traceroute is being checked remotely.
Dynamic addresses and servers don't mix very well. Some stuff will work, other stuff either won't work or will require setting up relays.
I'll assume that there is an external firewall box here that's dealing with the dynamic addresses, and that port forwarding is enabled. Check the port forwarding for TCP port 80, if you've not already done so.
Also check with your ISP, and ask if they even allow HTTP connections on dynamic addresses. Some don't. Some ISPs will firewall server-oriented connections.
My ISP is No-IP, I am not very sure about whether they allow HTTP or not, but I did setup a port forwarding with the TCP protocol on port 80 of my router. Also my firewall for the server machine is off, so they local firewall shouldn't be blocking it.
AFAIK, No-IP is not your Internet Service Provider. The No-IP folks are a Dynamic DNS (DDNS) provider for folks that have dynamic IP addresses from some other Internet Service Provider.
Dynamic DNS is useful for reaching some services remotely, such as establishing an ssh or VPN connection into some client-oriented computer systems. Dynamic DNS doesn't work all that well with some server-oriented protocols, and it's also a source of confusion for setting up local DNS — local DNS is necessary for OS X Server, and dynamic DNS doesn't work for that.
When it comes to running servers, there are unfortunately some differences between using static IP and dynamic IP — in this case, the firewall is probably with whoever is providing your IP address; with your ISP.
Check your ISP FAQ or contact your ISP directly for information on whether they are blocking server-oriented protocols such as HTTP TCP port 80. Based on one of the IP addresses shown, your ISP appears to be China Unicom.
OS X Server HTTP is only available on local network
