There is no problem running dozens - even hundreds - of web sites on a single IP under IIS6.

Immediate possibilities I can think of:

a) your IP is not enabled for the server - it has to be included in the list of IPs the server "owns" using the Local Area Connection tool.

b) something is set up incorrectly in your IIS manager. Go through it all again.

c) ensure nothing is blocking the domain or IP through any firewall or Policy.

d) run something like intodns.com to see a full report of the domain (don't think it works with sub-domains though).

Traceroutes and Pings do not always work with a server: it depends on how the Policy and firewall are set up.

Thought: I assume the IP belongs to your ISP and is not incorrectly quoted - eg 123.123.123.nnn instead of 213.123.123.nnn.

a) How would I check this?

b) I did check this. Then I rechecked it. Checked it again. And walked someone else through exactly how I set the IIS settings up. Just to be sure.

c) This is possible. However, I can't check it unfortunately.

d) What does that do? It doesn't work on subdomains like you said.

I had to do the tracert and ping through an external web service. Internally it doesn't work because of the way our network is set up.

Yep, the IP is one in a series so I'm pretty sure that is correct.

Thank you for your reply dstiles!

a) Open up IIS, expand the Servername (local computer) node, click on Web Sites, it should then show a list of web sites. This includes a column of IP address.
This will either have * All Unassigned * or may have an list of IP address for each website. If it is an IP address, check that it matches what you expect.
This screen also shows if you have host headers setup.
If you are running multiple sites on the same IP/port then you need to put the domain name in the host header value (Right click web site, properties, select Advanced and edit it and add the host header value).

b) If you browse the site from the IIS server what happens?

c) Telnet is your friend, if you can't connect on the port (80 by default), then there is something blocking your connection.

Jhet:

a) Deep in the Local Area Connection popup there is a list of IPs used by that machine.

c) if you have full control of your server you should be able to view Policies. Programs, Administrator Tools, Local Policy.

d) intodns shows what it can find about your IPs etc - basically a domain name validator showing (eg) A, MX etc records, TTL and so forth. If it's subdomains, though, you will need to use some kind of DNS lookup instead.

If you are running Windows as your local computer then try using the Sam Spade tool (download, not the online version). This can show several useful things apart from ping and traceroute. There are similar tools in linux.

Dijkgraaf:

I realise your advice covers several possibilities but to sound a note of caution to Jhet: I would never set up an All Unassigned nor rely on just the IP. Far too many pitfalls and scum trying to hack into the server via IP. I always assign an IP AND a URL - usually www.example.com with a second record in IIS Manager set to the non-www URL (and any secondary domains) to 301 to the primary www record. Be careful how this is set up: it can sometimes be tricky. Set up as a basic URL (eg example.com) pointing to the web site to begin with, then switch to the 301 redirect.

If a server is set up "safely" then telnet will not work. It certainly won't on my servers. Telnet is just one more exploitable hole.

Thanks for the replies!

Honestly the admin doesn't know what he is doing with IIS. I don't either but I don't pretend too. I reset the domain to point to the original external IP address and the domain resolves correctly. Although it does not resolve correctly if you try and view it through our internal network yet.

> does not resolve correctly ... through our internal network

Cache time would be the reason for that. It can vary from minutes to days. My solution is to check through an external server that has never accessed the site before. Or you could try a proxy.