Got a notebook user who can use a global roaming client and VPN to get into their corporate LAN.

They dial-up fine, authenticate with their token and can then access e-mail. They can browse external web sites but can't get to their Intranet site.

From their notebook on the dial-up, I can ping the Intranet by name and IP. I can telnet to port 80 and get a response from IIS.

However, with or without a proxy enabled in IE, you still can't view the site. Given I can manually talk to the HTTP server on port 80 via Telnet, I'm :confused: as to why IE can't get there as well.

Thoughts?

Chris

Err....

Web site isn't up (I guess you've checked that)
Firewall is blocking HTTP Traffic to the Intranet
NAT issues somewhere

Strange as it might seem it could be a routing issue

As you say....thoughts

[Edited by Jeff Wiltshire - 19/06/2003 16:31:03]

Erm, if you're sure you can resolve the host
Ping it.
Connect to it.
And no bogus proxy settings...


No idea! :D

Seriously though, guessing would have been, in no particular order:

DNS - using external DNS servers from net connection not VPN and not resolving the name or resolving it to something else.

Proxy - Possibly proxy settings from ISP causing IE to go via that than directly, of course not working.

Network - Firewalling or routing stopping traffic to/or from the machine(s) in question.


Tried using netstat -ano and looking for connections IE is making and see if it really is trying to connection to the right server?

(not sure -o might be an XP only option, but you should still be able to see the IP for the server anyhow)

Can ping by name and IP when going through the VPN.

Server is up as clients inside the LAN can view to it.

If a firewall lets you Telnet to port 80 on a server, how could it stop IE going to port 80?

UDP & TCP.....

As I say check with netstat to see if IE is actually attempting to establish a TCP connection on port 80 to the IP of the server (netstat -ano from cmd on the client).

If it isn't something funny is going on with IE, which seems to be the most likely answer right now. If it is, well it should be working from the TCP test you've tried with telnet.

To be sure it's completely working with telnet, telnet to port 80, then enter "GET /" and press return twice, you should see the index page scrolling past you. If you don't then for some reason the web server is not serving pages to that client ip.