05 Jan, 2010, Zeno wrote in the 1st comment:
Votes: 0
If someone cannot get to my server (zeno.biyg.org) what are some steps to debug this? They can get to other websites just fine and I don't ban anyone from the server.

tracert? ping? what else?

My server can't be pinged, so that's one thing left out we can't use.
05 Jan, 2010, quixadhal wrote in the 2nd comment:
Votes: 0
You might try doing a traceroute to their server and see if they can reach various points along the path.

From my end:
$ traceroute -I zeno.biyg.org
traceroute to zeno.biyg.org (74.67.44.255), 30 hops max, 40 byte packets
1 stalin (192.168.69.1) 0.325 ms 0.281 ms 0.235 ms
2 10.178.64.1 (10.178.64.1) 7.000 ms 5.528 ms 5.813 ms
3 swc02klmzmi-gbe-1-1.klmz.mi.charter.com (96.34.36.40) 6.376 ms 34.566 ms 16.066 ms
4 96-34-32-194.static.unas.mi.charter.com (96.34.32.194) 14.642 ms 8.261 ms 9.524 ms
5 bbr01aldlmi-tge-0-0-1-0.aldl.mi.charter.com (96.34.2.8) 10.226 ms 10.877 ms 9.616 ms
6 bbr01chcgil-tge-0-0-0-6.chcg.il.charter.com (96.34.0.57) 15.649 ms 22.250 ms 16.847 ms
7 prr01chcgil-tge-1-1.chcg.il.charter.com (96.34.3.9) 14.393 ms 13.078 ms 14.243 ms
8 96-34-152-14.static.unas.mo.charter.com (96.34.152.14) 14.481 ms 13.543 ms 14.787 ms
9 ae-1-0.cr0.chi10.tbone.rr.com (66.109.6.152) 13.601 ms 18.352 ms 24.839 ms
10 66.109.6.73 (66.109.6.73) 32.221 ms 30.928 ms 32.488 ms
11 gig12-0-0.albynywav-rtr02.nyroc.rr.com (24.29.39.26) 38.451 ms 36.973 ms 38.121 ms
12 gig2-1-0.albynysat-rtr02.nyroc.rr.com (24.29.37.34) 40.481 ms 41.368 ms 39.778 ms
13 gig16-1.albynysat-ar402.nyroc.rr.com (24.29.39.190) 46.300 ms 47.329 ms 47.367 ms
14 * * *


So, The closest I can get any useful information is Albany, NY. If you were to do a traceroute back to me (shadowlord.org), some of the blanks on your end would probably be filled in.

Of course, you might take an entirely different route too… but the idea is to try and find things "near" you to see if any of those are reachable, so the point of disconnect can be located.

FYI: I can at least connect to your web server without issue, but something upstream from you drops ICMP and UDP packet returns, hence the traceroute failure.
06 Jan, 2010, chaoticus wrote in the 3rd comment:
Votes: 0
They cannot get to your website? // Maybe something within a firewall that they are using, that is adding a restriction to .org addresses.
// What are they using for a browser? I can get there via IE8, mozilla, safari, and google chrome.
They cannot connect to your server via ssh2/sftp?
They cannot telnet to one of your hosted muds?

As with Q, I get the same traceroute info, but, can connect to your website, and a hosted mud.

C
06 Jan, 2010, Zeno wrote in the 4th comment:
Votes: 0
They cannot access it, meaning telnet http IE Firefox etc. They can get to biyg.org (my VPS) but not zeno.biyg.org (my personal server).
06 Jan, 2010, Zeno wrote in the 5th comment:
Votes: 0
Oh and the person can proxy to get to my website, if that says anything.
06 Jan, 2010, quixadhal wrote in the 6th comment:
Votes: 0
Sounds like a problem on their end then. If they can get to a proxy, and that proxy can get to you, that implies that they (or their ISP) is blocking the connection directly for some reason.
06 Jan, 2010, elanthis wrote in the 7th comment:
Votes: 0
It is very most probably their ISP or home configuration (anti-virus package with one of those Internet Security Machine Rapers installed).

However, for completion's sake, there are a couple other possibilities you might try to rule out. Perhaps Zeno is unknowingly doing the blocking. Do you have any weird firewall rules configured on your VPS, or tools like ssh_guard or the like that might be automatically adding/removing firewall rules based on log file activity?

Also, try updating the latest version of the kernel/OS in your VPS (if it's the kind that runs a separate kernel). It could be something as wild (but not unheard of) as a weird incompatibility in the TCP/IP stacks between what your VPS is running and the user is running. There was a brief time in particular when Linux had some hot new awesome TCP congestion control features added that just happened to trigger a bug in a large percentage of personal home routers from Linksys or Netgear or one of those and it caused all traffic to get dropped by the router. It was a large enough percentage of equipment that the feature was later disabled by default in Linux even though it had a beneficial impact in general on the Internet and a simple firmware update would have fixed the routers (unfortunate, but the most practical solution). So it could be something similar to that, if not that exact issue.

Find out what ISP and router/switch/gateway they're using, and then see if you can find anyone using the same ISP or same hardware that has the same issue, after upgrading your VPS and ruling out a firewall configuration issue on your end. If people on the same ISP can connect, it's (probably) not the ISP. Have the user do a firmware upgrade on their network hardware, and check over any weird anti-virus security software they might be running. (On the hand one, running such software is idiotic because it breaks so many legitimate things, slows down the machine, only an dumb-ass actually even needs it. On the other hand, 99% of people who consider themselves experts are in reality in desperate need of software to protect themselves from their own stupidity. These days I just recommend people that probably need it to run the free MSE anti-virus and to stay the hell away from Norton and Symantec and the like.)
28 Jan, 2010, Zeno wrote in the 8th comment:
Votes: 0
Here is the tracert they get:
Quote
Tracing route to zeno.biyg.org [74.67.44.255]
over a maximum of 30 hops:
1 * * * Request timed out.

This pretty much means something on their end, right? (ISP, software, etc)

And as it turns out, someone else has this same problem: http://zeno.biyg.org/newsite/viewtopic.p...
28 Jan, 2010, quixadhal wrote in the 9th comment:
Votes: 0
If every entry in the traceroute is blank, that usually means something locally is throwing away the ICMP packets being used to do the traceroute. Unless you're doing this yourself, you should normally at least see the next hop upstream from you.

If they're using windows (and its firewall), have them enable ICMP packets (might be called "ping") and see if they can get a useful traceroute from there.
27 Apr, 2010, Zeno wrote in the 10th comment:
Votes: 0
So my IP happens to end in 255 and I read that some routers can't handle that. Think that is the cause?
27 Apr, 2010, Dean wrote in the 11th comment:
Votes: 0
Zeno said:
So my IP happens to end in 255 and I read that some routers can't handle that. Think that is the cause?


AFAIK 255 is usually the network broadcast. :thinking:
27 Apr, 2010, kiasyn wrote in the 12th comment:
Votes: 0
Dean said:
Zeno said:
So my IP happens to end in 255 and I read that some routers can't handle that. Think that is the cause?


AFAIK 255 is usually the network broadcast. :thinking:


10.0.0.255 is a perfectly valid address as the subnet would be 255.0.0.0 which makes:

Range of usable ip addresses 10.0.0.1 - 10.255.255.254
Broadcast: 10.255.255.255
Network address: 10.0.0.0
27 Apr, 2010, Zeno wrote in the 13th comment:
Votes: 0
0.0/13