I have never even been able to ping my outside IP from on the LAN. And I have also heard of other poepl having the same type of problem. My external IP is actually a sisco router, then there is a 3com hardwarre firewall behind that and then my webserver behind the firewall

Now I'm confused.

If your webserver has a public and a private ip address it's *inside* your firewall, yes?

I can understand not being able to ping a machine, 'cos it might be configured to drop icmp (ping), but you can still *get* to it. Especially if it's on your side of the LAN.

What happens if you traceroute to the public IP address of the web server from a LAN machine?

If I'm understanding the above correctly it should look like this :

LAN Machine ---> Web server internal / Webserver External --> 3Com --> Cisco --> Internet

In which case you should be able to get to the webserver's external address by going through the internal one...

Slick

The webserver itself doesnt have an external address. I only have one external IP and my firewall is configured to forwart http traffic that hits that IP on to the private IP of my web server. And I can "get" to the web server from inside the lan by using its private IP, There are multiple sites on the server and using the private IP only shows me the first virtual host. I went ahead and added each site name with the private IP to the hosts file on my local machine here and it works like a charm. It would be nice if it was domain wide but I can just add the host file to all the machines on the lan that need to access those sites. Not real sure why that didnt work when I tried to add them to the DNS server though.

....and tracert only times out

Oky.. So, you have a private IP address, a redirector (this is the 3com firewall?), and an internal DNS machine.

The reasons it doesn't work when you added the site names to the internal DNS is :

>Now when I do NSLOOKUP, I see my ISP's DNS server as the default

Your machines are configured to look at your ISP's dns, not your internal one. Ideally you would configure your LAN machines to look at your internal DNS, and have your internal DNS forward unresolved lookups to your ISP's dns.

LAN Machine -- dns query --> LOCAL DNS --> ISP DNS.

There's an option if you right click the dns administration on Windows NT Server to 'forward' queries, and you can slap your isp's dns servers in there. I do exactly this at home (although not using NT) to make machines which are inaccessable from the internet (private ips') have nice domain names which are accessible from internal machines, but not external. (My ISP doesn't know about them, only my internal DNS).

Bob's your uncle.

All this is becoming rather involved though, and I would suggest perhaps talking to your LAN administrator about it. We've done a whole lot of 'working around' issues, when actually it could be easily resolved with a little configuration on a network admin's part.

Glad it's working now though.


Slick.

Actually, my DHCP server is configured to assign the DNS servers to all my clients and the primary DNS server is my internal DNS server and then second and third are set to my ISP's DNS servers. so basically any host that the local DNS server cant resolve it then should look to the the ISP's servers. So I am confused as to why the nslookup is not listing the local server. Aparently I have kicked up an underlying problem that I wasnt aware of before. And as for talking to the LAN administrator, you are talking to the LAN administrator. Sad as that may seem

Thanks for all the help

now it makes since, the external ip from inside is not redirected to the webserver. Only the traffic on the external interface is forwarded to the webserver.

Uh... no.

The traffic is getting there. The web server doesn't care where it comes from, and it *is* getting there.

The problem is that Screamin' was accessing it via ip, and not via dns. So, her virtual hosts aren't kicking in, because the *name* isn't coming through. It therefore serves up the default site, and no others.

By inserting the name into local DNS (or hosts file as was reported to work) the webserver is able to access the *name* being accessed and therefore serve up the correct site.

The issue is a dns one, not a network path..

Slick.