tracert doesn't lie - but someone is?

Here's my problem. From work, users cannot access a website for work related activities. About a month ago the site just goes off line, no big deal happens all the time. Weeks go by and still not on line (ECommerce) That's strange. I call the company rep and he assures me the site is, and has been, up and running fine.

So I trace the site and the trace bombs at the companies isp. I contact the ISP and they say that the last address I hit is the public side of the eCommerce site.

So I contact the site rep and have him forward the tracert and other conversations I've had with their ISP to his tech department.

Now they can ping me fine and we can send and receive email fine, so besides some sort of black list, what else can be blocking this traffic?

Traceroute is a really unreliable way to debug connectivity problems, especially in an era where service based filtering is so common (either through ACLs or stateful firewalls). If you are able to send email but not reach a web server, in my mind, the first thing I would do is go to nslookup and query the webserver and their mail server (set q=mx) and see if they are in the same address space. If they are not, then it could be an IP based problem (like you network is blocked), if they are, then it could be a service based problem. Have you tried maybe connecting to another web server in the same range or tried using a different service than HTTP?

Does the site redirect traffic to an "uncommon port" and does your firewall block that "uncommon" port?

[RANT]
I'm finding this more and more.... Idiots out on the net who think they can secure themselves by obscurity are foxxing up the rest of us by forcing us to open ports for thier site and their site only because they think they are safer by putting SSL on port 1987 rather than 443 and it peeves the crap outta me........ If this is what they are doing tell them they are ****wits from me please and tell them to get with the program - if they can only secure their server by using the old "obscurity trick" you will find another outlet for your cash.... Then do so..... They deserve it.
[/RANT]

Tiger:

Yes I block EVERYTHING! Except what's needed.

I'm just a bastard at heart.

But to your question No - there's no redirection going on. So I'm told.

Now Today I'm asked if I can browse the site, different address. Yes I can. I ask, What's different between the two addresses, and am told that both addresses are on the same box. Now this has to be a service blocking issue on their end correct? As I've never seen this, I am second guessing myself?

If they are using nat on the Address that works and pat on the address that doesn't...

I'm just looking for a logical starting point. Any ideas would be helpful at this point, as I currently have jello for brains.

The way I would tackle this situation (and you might not be able to depending on resources), is to take a laptop and place it on the network like the other desktops. This should have the same result. Then take the laptop (which hopefully is secured and should then have a software firewall), and drop it directly on the internet connection, in front of any hardware firewall you have. If you firewall is not causing the problem, then you should have the same result. If you can get to it now, the problem is related to your firewall (or something else behind it). Now take that laptop to another location, say you house and connect it to your internet connection. Try again. If you can only get to it from here, then I would say the problem is outside of your network. I don't think you can tackle the problem until you find out where it is.

Yea - did that. Kind of. My laptop can't connect. for the sake of argument direct (cable) connect to firewall - can't connect. Again direct connect to router - can't connect.

It could be a DNS problem. Different addresses may be returned based on different queries, or your local DNS server may be improperly caching one of those addresses. However, since a traceroute will resolve the address and try to get there (but fail), the problem would be more complicated than one of the addresses failing to resolve.

I would check the DNS records with nslookup or dig and see if you can find any noticeable differences between the different addresses you have tried. Beyond that, try connecting directly with the IP address of the server instead of the URL. If you cannot connect with an IP address directly, then DNS is not likely the problem. Even with a traceroute, DNS responses may be different depending on the address you request, despite the fact that they all point to the same box. If you can connect directly with an IP address instead of a URL, then it is very likely that a DNS server somewhere is doing some fance footwork and screwing you up.

That's one idea, or perhaps a router in between you and them has a messed up routing table somewhere and is not routing connection attempts from your network properly.

If you post these addresses (assuming you can and are so inclined), people may be able to help a bit more.

Well it's fixed. The host installed a new nic on the box and assigned it a public address. Now I had people here use the ip address of the new nic as a temporary fix. I come in this morning and the host name resolves and I think Hummm.... So I check out my local DNS server and the new ip address is listed. Strange, so I check out www.dnsstuff.com and sure as s**t, there's the new address.

Don't know if their isp was filtering or if their DMZ had a glitch, either way they changed their public address over the weekend.

They finally figured out it wasn't an issue on my end. And I'm done second guessing myself.

Thanks all for the replies.