Thanks for your help. Here are the current results: http://fqdn TIMES OUT https://fqdn SUCCESS https://dmz-ip SUCCESS http://dmz-ip SUCCESS
tracert -d www.domain.com RESOLVES CORRECTLY; ALL HOPS TIME OUT route print: This is interesting. If you look at the destination dmz-ip, it lists a different gateway than the default. It lists a core switch as the gateway. telnet fails to that by dmz-ip. that port is closed On Fri, May 28, 2010 at 2:02 PM, Richard Stovall <rich...@gmail.com> wrote: > Can you post the results of a 'route print' command, and a "tracert -d fqdn' > from one of the affected machines? > Going back over the thread, you initially said that https is working. Is > that still true in each of the following cases? > https://dmz-ip > https://fqdn > What about the suggestion to telnet to the site on port 80? Have you had a > chance to try that? > On Fri, May 28, 2010 at 1:32 PM, mqcarp <mqcarpen...@gmail.com> wrote: >> >> I see the public IP address route in the browser. Firefox is doing >> this. I put the exact error below. On the same machine, the nslookup >> is correct to the internal IP >> >> The following error was encountered: Connection to 66.xxx.xxx.51 Failed >> >> The system returned: (110) Connection timed out >> >> The remote host or network may be down. Please try the request again. >> >> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ >> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
