IP address being blocked somewhere...please help! Free hosting account if you can diagnose this or help me to diagnose!

[meanpc]

Here's one I really need help with. Maybe someone will know what to do with this.

I have a dedicated server at managed.com. It runs fine, 100% uptime so far.

I have one client who cannot access the server. The DNS info IS resolving. He cannot get to my server at the datacenter.

I have a system administrator running the box. He is not blocking the IP with the software firewall and there are no bans setup in Cpanel anywhere.

I got my client to do a traceroute to the server. The tracert makes about 18 hops, then gets to the switch at the managed.com NOC. The last IP address on the tracert below is the managed.com switch. On a successful tracert, my server would be the next and last IP listed. I left out the first 5 hops.


quote:
--------------------------------------------------------------------------------

6 18 ms 17 ms 18 ms so0-0-0.chcgilL3-rtr1.kc.rr.com [24.94.160.5]
7 18 ms 19 ms 19 ms pop1-chi-P7-0.atdn.net [66.185.136.109]
8 18 ms 17 ms 17 ms bb1-chi-P0-0.atdn.net [66.185.141.84]
9 20 ms 19 ms 19 ms pop2-chi-P0-0.atdn.net [66.185.148.65]
10 20 ms 17 ms 20 ms XO.atdn.net [66.185.132.106]
11 19 ms 19 ms 20 ms p5-0-0.RAR1.Chicago-IL.us.xo.net [65.106.6.133]

12 57 ms 44 ms 43 ms p6-0-0.RAR2.Denver-CO.us.xo.net [65.106.0.25]
13 60 ms 43 ms 52 ms p0-0-0-2.RAR1.Denver-CO.us.xo.net [65.106.1.81]

14 75 ms 74 ms 73 ms p6-0-0.RAR1.SanJose-CA.us.xo.net [65.106.0.21]
15 75 ms 75 ms 91 ms p0-0-0.MAR1.Fremont-CA.us.xo.net [65.106.5.134]

16 75 ms 75 ms 75 ms p0-0.CHR1.Fremont-CA.us.xo.net [207.88.80.178]
17 112 ms 95 ms 66 ms 67.104.60.222.ptr.us.xo.net [67.104.60.222]
18 66 ms 67 ms 66 ms 66.79.175.2
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
--------------------------------------------------------------------------------



I have been in touch with managed.com's tech support and they claim there are no blocks/bans on IP addresses in that switch.

I got my client to do a tracert to the domain 'managed.com'. That tracert was successful, and goes through the very same switch - 66.79.175.2.

Some more info - my client cannot access the site through the connection at his house, his friend's house, or his mother's house. They are all on RoadRunner cable in Kansas City, MO.

What other steps can I take to determine exactly where this problem is happening? I'm not quite sure how to read the results of the tracert. Does the tracert show that it is getting to the 66.79.175.2 switch getting routed to the next server, and the next server is not responding? Or is it showing that the signal is not getting all the way through the switch?

Any help would be greatly appreciated.

Lonnie
lonnie@meanpc.com

 

[Boscoh]

Can your other clients hit the server?

All the tracert says is that the next hop is unreachable, whether it be because the server is misconfigured, there is an ACL on the switch, there is a cabling problem, or the server is just down is unknown. It just says you cant get there.

 

[meanpc]

All other clients have no trouble reaching the server. He has checked with his ISP for problems there, and even used different DNS servers instead of theirs.

Are there any other tools that I can use either from the Windows client side or the Linux server side that will provide more information regarding the nature of the problem?

 

[Boscoh]

One thing you might be able to try....do a tracert from your server to the clients IP address. Does it work?

 

[CTR]

When you say your customer can't access the server, what type of access are you referring to? Just ping/traceroute (ICMP)? Or have you also tried HTTP, FTP, or whatever services you are offering on this box?

I have seen something similar where ICMP was blocked for certain netblocks/ISP's due to virus traffic, but the management interface on the switch or load balancer did not have the ACL applied to it.

 

[meanpc]

Referring to traceroute, http, ftp access. Ports 80/21/2086....

Will try the tracert to the client's IP tonight and report back the results.

Thanks

 

[bex0rs]

Also, run 'netstat -r' on your remote box and paste the output here.

 

[meanpc]

Ok, here is the netstat -r output. Still working on getting the tracert...need to get my admin to install it.

Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
65.75.158.12 * 255.255.255.255 UH 0 0 0 eth0
65.75.158.11 * 255.255.255.255 UH 0 0 0 eth0
65.75.158.0 * 255.255.255.0 U 0 0 0 eth0
169.254.0.0 * 255.255.0.0 U 0 0 0 eth0
65.0.0.0 * 255.0.0.0 U 0 0 0 eth0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default 65.75.158.1 0.0.0.0 UG 0 0 0 eth0

I'll post the tracert soon.

Thanks

 

[meanpc]

Ok, the tracert from my server to the client:

traceroute to 24.94.161.185 (24.94.161.185), 30 hops max, 38 byte packets
1 65.75.158.1 (65.75.158.1) 21.838 ms 1.281 ms 0.425 ms
2 66.79.175.1 (66.79.175.1) 4.975 ms 2.139 ms 1.003 ms
3 66-154-102-49.assertivenetworks.net (66.154.102.49) 0.491 ms 0.453 ms 0.400 ms
4 728.ge-4-1-1.er10b.sjc2.us.above.net (209.133.64.123) 0.469 ms 0.463 ms 0.391 ms
5 so-2-0-0.mpr4.sjc2.us.above.net (64.125.30.101) 0.407 ms 0.444 ms 0.455 ms
6 so-3-0-0.mpr1.sjc7.us.above.net (64.125.30.173) 0.674 ms 0.752 ms 0.670 ms
7 above-oc48.sjc.atdn.net (64.125.12.146) 0.558 ms 0.528 ms 0.485 ms
8 bb1-sjg-P0-0.atdn.net (66.185.150.80) 0.773 ms 0.767 ms 0.732 ms
9 bb1-sun-P4-0.atdn.net (66.185.152.91) 1.364 ms 1.290 ms 1.189 ms
10 bb1-den-P7-0.atdn.net (66.185.152.252) 46.865 ms 46.462 ms 46.418 ms
11 bb2-den-P1-0.atdn.net (66.185.152.137) 46.552 ms 46.634 ms 46.382 ms
12 bb2-kcy-P7-0.atdn.net (66.185.152.189) 46.696 ms 46.763 ms 47.316 ms
13 pop1-kcy-P1-0.atdn.net (66.185.137.227) 46.587 ms 46.588 ms 46.455 ms
14 rr-kansascity.atdn.net (66.185.142.26) 49.413 ms 49.362 ms 49.238 ms
15 pos8-0.kscymordc-rtr4.kc.rr.com (24.94.160.2) 49.826 ms 49.852 ms 49.763 ms
16 srp0-0.kscymordc-rtr2.kc.rr.com (24.94.160.196) 49.617 ms 49.635 ms 49.526 ms
17 srp1-1.kscymoworn-rtr1.kc.rr.com (24.31.239.6) 50.881 ms * 50.907 ms

Anybody see anything from this? Looks like it's getting through fine

 

[Boscoh]

Well...it looks as if YOU can reach the client, but the client cannot reach you. Did you try pinging the client as well, or just do a tracert?

Would you happen to have a dialup account that you can give the client access to so you can test if the dialup account works but the cable connection does not?

 

[cquark]

Some routers will block all incoming traceroutes and pings, but permit outgoing probes. It sounds like you need your client to run a more informative probing tool like nmap, which can scan all of your TCP and UDP ports in a variety of ways, classifying them as open, closed, or filtered (blocked by a firewall.)

 

[meanpc]

I am able to traceroute and ping the server. I'll give nmap a shot.

 

[meanpc]

cquark - thanks for the link. I have downloaded it and it look svery powerful. Can you recommend what scan I should run?

 

[piasabird]

It might be a specific port or address range that is not getting through.

 

[CTR]

Depending on the type of contract you have, your hosting company might not appreciate you running nmap against one of their ip's.

You mentioned you are running a web server, so jack up the logging and see if the customer is making a connection request. That way you can tell if this is a problem with the path to your server or back from your server. If you can't get this information from the log, use the netstat command while the customer is trying to connect. You should be able to see his TCP connect attempts at port 80.

Did you notice that your traceroute from the server to the customer is taking a different path than the traceroute from the customer to the server? This could be part of your problem. Before you contact managed.com, have some fresh traceroutes available from both sides. If there is some port blocking, IP block null-routing due to abuse, misconfigured BGP filters, etc, it could be happening within any of the carriers listed in the traceroute.

Probably the best approach is to have your customer with the RR account call his customer support and complain about not being able to reach your website. Your traceroutes will come in handy again. Be sure to include the results of your logging or netstat, so that RR will know which ISP's to contact first.

 

[cquark]

I'd have your client try the most basic scan first, with pings disabled so you don't have to wait for it to timeout:
nmap -P0 -sT IPaddress
where you replace IPaddress with the address you're scanning. This scan will tell you the status of all commonly used TCP ports, which is probably enough information to diagnose your problem. If they're listed as "filtered" then you know there's a firewall blocking access someone between your client and your server. You can scan in both directions, but it seems that the blocking occurs from the client to your server, so I'd try it from the client's side.

 

[PC Freak]

client side...

from the command prompt

ipconfig /flushdns

can the client get to your server via ip rather than host name?

 

[JustinLerner]

Originally posted by: CTR
Depending on the type of contract you have, your hosting company might not appreciate you running nmap against one of their ip's.

You mentioned you are running a web server, so jack up the logging and see if the customer is making a connection request. That way you can tell if this is a problem with the path to your server or back from your server. If you can't get this information from the log, use the netstat command while the customer is trying to connect. You should be able to see his TCP connect attempts at port 80.

. . .
If there is some port blocking, IP block null-routing due to abuse, misconfigured BGP filters, etc, it could be happening within any of the carriers listed in the traceroute.

Probably the best approach is to have your customer with the RR account call his customer support and complain about not being able to reach your website. Your traceroutes will come in handy again. Be sure to include the results of your logging or netstat, so that RR will know which ISP's to contact first.

This is the right idea. Additionally, there is the significant possibility that your customer has some configuration problems on their NIC's or routers. Sounds like there may be an issue with RoadRunner that is not apparent yet.