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
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
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
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
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
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
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,
>
> > -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
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
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
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
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
12 matches
Mail list logo