Trying to revive an old website from about 6months ago. As far as I know the only update I should have needed was to let the update client get the new WAN IP. I've double checked the settings on my web server, router and dyndns account and must be overlooking something.
The ports you have forwarded:
The make, model and version of your router:
The LAN IP address, netmask and default gateway for the device you're trying to reach: web server internal IP 192.168.1.201 - netmask 255.255.255.0 - default gateway 192.168.1.1
The WAN IP address of the ISP connected device (modem or router) (as shown in the modem or router's management pages, not what any web site shows): 22.214.171.124
If you're forwarding to a computer the operating system and patch level (for example Windows XP Pro SP2, MacOS X 10.6.5 or Ubuntu 10.04.2): Windows Server 2008 STND SP2
I'm using Dyn Updater to update IP.
Everything worked great 6 months ago. Currently I can reach the website internally, however externally I get a timeout error. Using the open port utility it says my WAN IP on port 8000 is working. I can ping my A-record and it resolves the IP for my WAN IP (request time out) and the webhop resolves to an IP for dynDNS.
dyndns settings: zone - knicedesigns.com
mx.knicedesigns.com A-record 126.96.36.199
production.knicedesigns.com A-record 188.8.131.52
For some reason it seems like even with requests through the webhop they aren't hitting my router on port 8000?
Any help would be appreciated. I'm sure I'm just making some boneheaded mistake. Thanks.
asked Mar 13 '12 at 08:29 PM in DNS & Domains
Hmm interesting. I was actually testing from work and was using logmein to the web server to get/check the settings. After your response though I tested hitting the website from one of our GoDaddy virtual servers and it came right up.
Not sure why the connection from work would time out but something I'll probably need to (or at least should) figure out and certainly not an issue with DynDNS.
answered Mar 13 '12 at 11:41 PM
Let me guess what your "boneheaded mistake" could be: you test from within the network your webserver is located too, right? That won't work with many routers, these not supporting loopback connections / NAT reflection.
If this is the case, then there is a workaround to add entries to your hosts files on the client machines like:
Because most work networks have non-standard ports outbound blocked.