Can connect to web site with server 2003 but not with XP workstati

[Guest]

This problem is very unusual. The server the workstations connect to can
resolve a web site, but the individual machines cannot. ICF is disabled on
the individual machines, as is their virus protection. A ping to the host
returns a "server not available message", whether the ping is by FQDN or ip.
nslookup resolves the name, so it is absolutely not a DNS issue. The ip
assigned by Verizon for their DSL connection is on a bogon list, but the host
assures me his firewall blocks no traffic based on ip (He did not share the
name of the firewall he was running), and the server 2003 can bring up the
site with no hesitation in any case, probably demonstrating a firewall isn't
blocking the workstations. Windows 98 machines sharing the same DSL
connection can reach the web site. A test of MTU shows 1492 (the default
packet size on their router) is correct for their system. ipconfig shows
nothing unusual. The hosts files are normal. We have a laptop computer that
can access the site from other locations, but cannot access it through the
Verizon DSL hookup. Spyware and viruses do not appear to be an issue. The
workstations are running SP2 and are updated automatically. The server is
running SP1, and all are using IE6 SP1. All are Pentium 4 class machines
(Dells) of recent purchase. The DSL connection is shared through a Linksys
Router, NOT THE SERVER by the way, as the server has only one NIC present.
Any thoughts?

 

[Robert L [MS-MVP]]

do you have filtering in the router? this step by step troubleshooting page
may help, http://www.howtonetworking.com/Internet/internetaccess0.htm.


Don't send e-mail or reply to me except you need consulting services.
Posting on MS newsgroup will benefit all readers and you may get more help.

Bob Lin, MS-MVP, MCSE & CNE
How to Setup Windows, Network, Remote Access on
http://www.HowToNetworking.com
Networking, Internet, Routing, VPN Troubleshooting on
http://www.ChicagoTech.net
This posting is provided "AS IS" with no warranties.

 

[Guest]

The router features filtering, but it is turned off. The host of the web
site confirmed he has ICMP echo turned off, BTW, which explains the lack of
response to pinging, but makes troubleshooting much more difficult.

 

[Robert Aldwinckle]

This problem is very unusual. The server the workstations connect to can
resolve a web site, but the individual machines cannot. ICF is disabled on
the individual machines, as is their virus protection. A ping to the host
returns a "server not available message", whether the ping is by FQDN or ip.
nslookup resolves the name, so it is absolutely not a DNS issue.

You can't tell that for sure by ping or even by tracert.
E.g. if the very first response to an HTTP connect request is
a redirect to a different site name which your DNS did have
a problem resolving you would see the same symptom.

The best way to diagnose your problem is to get an HTTP packet trace
of it. However, you could at least get some better clues by using
telnet 80 to try to simulate it. If you're lucky you may get enough
response just by entering GET /
(That's GET<space><slash><Enter> and unless you enable
telnet's localecho don't expect to see your typing.)

If you need more help please post a sample public URL to simplify
further discussion.


HTH

Robert Aldwinckle
---

 

[Guest]

telnet to port 80 fails.

You can't tell that for sure by ping or even by tracert.
E.g. if the very first response to an HTTP connect request is
a redirect to a different site name which your DNS did have
a problem resolving you would see the same symptom.

The best way to diagnose your problem is to get an HTTP packet trace
of it. However, you could at least get some better clues by using
telnet 80 to try to simulate it. If you're lucky you may get enough
response just by entering GET /
(That's GET<space><slash><Enter> and unless you enable
telnet's localecho don't expect to see your typing.)

If you need more help please post a sample public URL to simplify
further discussion.


HTH

Robert Aldwinckle

 

[Robert Aldwinckle]

....

....

telnet to port 80 fails.

That could be a useful tack to follow for diagnosis then.

What symptoms are you getting? Did the screen clear?
That would prove that you have connectivity to an HTTP server
of some kind, using the address that you expect IE to be using.

If it is just a case that the server is not replying to GET /
that could just mean that you need to refine your simulation
of the connection attempt.

The fact that you can connect to the desired site using another
machine would allow you to get a packet trace of a successful
connection attempt and help you chose which other pieces
might be needed to make a successful simulation on the problem
machine.



HTH

Robert
---

 

[Guest]

The router is not filtering. I even replaced it. I just added a WAP and an
XP machine can connect through that tp the site. but the WAP is using the
primary router for its access (I created a scope beyond the range of the main
router for the WAP). Since ICMP is turned off on the server I'm trying to
reach, I can't run a trace on any machine. I have turned off DHCP to
simulate the same environment as the server that could reach the foreign
server, but that did no good. The only commonality I can think of now is
that the server and the wireless XP are both out of the scope of the DHCP
range provided by the main router. I may try setting the main router to
provide another DHCP scope and see what that can yield.

 

[Robert Aldwinckle]

....

Since ICMP is turned off on the server I'm trying to reach,
I can't run a trace on any machine.

That's not the type of trace I meant. Use netcap to capture
and Ethereal to format.


BTW in your OP you said:
<quote>
Spyware and viruses do not appear to be an issue.
</quote>

without providing any proof of that assertion.
Be aware that similar symptoms have been attributed
to both malware and other broken third-party extensions,
including popular add-ons such as the Google toolbar
and the Yahoo Companion toolbar.

So another tack you could be taking is checking for
TCP-IP stack corruption and interference.


Good luck

Robert
---