Re: Internal routing

2010-06-09 Thread Richard Stovall
Can you post the output from "route print"? On Tue, Jun 8, 2010 at 9:19 AM, mqcarp wrote: > 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

Re: Internal routing

2010-06-08 Thread mqcarp
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 differe

Re: Internal routing

2010-05-28 Thread Richard Stovall
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 telne

Re: Internal routing

2010-05-28 Thread mqcarp
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 re

Re: Internal routing

2010-05-27 Thread Richard Stovall
How did you determine that "it is trying to route to the public IP address." By running netstat one one of the clients? If you do an nslookup pointed to an internal DNS server on one of the clients having the problem, it resolves the correct DMZ ip, right? On Thu, May 27, 2010 at 3:44 PM, mqcarp

Re: Internal routing

2010-05-27 Thread mqcarp
OK here is what is happening. When you go to one of the internal sites through a browser, it stalls, and then says it can not be reached, but what I noticed is that it is trying to route to the public IP address, not the DMZ address, which is what the internal DNS should be doing. So for some reaso

Re: Internal routing

2010-05-26 Thread Ben N
problem with MTU frame size with some >> Routers/Proxies. Do some packet captures and see if you are getting resets >> or sequencing failures. >> > >> > -Original Message- >> > From: Kurt Buff [mailto:kurt.b...@gmail.com] >> > Sent: Monday,

Re: Internal routing

2010-05-26 Thread ahmad hafiz
> > > -Original Message- > > From: Kurt Buff [mailto:kurt.b...@gmail.com] > > Sent: Monday, May 24, 2010 11:04 AM > > To: NT System Admin Issues > > Subject: Re: Internal routing > > > > On Mon, May 24, 2010 at 10:50, mqcarp wrote: > >> Has anyon

Re: Internal routing

2010-05-24 Thread mqcarp
failures. > > -Original Message- > From: Kurt Buff [mailto:kurt.b...@gmail.com] > Sent: Monday, May 24, 2010 11:04 AM > To: NT System Admin Issues > Subject: Re: Internal routing > > On Mon, May 24, 2010 at 10:50, mqcarp wrote: >> Has anyone seen an issue where you can route

RE: Internal routing

2010-05-24 Thread Blackman, Woody
Admin Issues Subject: Re: Internal routing On Mon, May 24, 2010 at 10:50, mqcarp wrote: > Has anyone seen an issue where you can route to an internal web site > by https but not http? > > nslookup resolves correctly, IIS is running fine, site is accessible > externally with no issue

Re: Internal routing

2010-05-24 Thread Kurt Buff
On Mon, May 24, 2010 at 10:50, mqcarp wrote: > Has anyone seen an issue where you can route to an internal web site > by https but not http? > > nslookup resolves correctly, IIS is running fine, site is accessible > externally with no issue. I can not see where access to port 80 is > different tha

Internal routing

2010-05-24 Thread mqcarp
Has anyone seen an issue where you can route to an internal web site by https but not http? nslookup resolves correctly, IIS is running fine, site is accessible externally with no issue. I can not see where access to port 80 is different than access over 443. If you only use http it times out. I w