I'm eight hours into this and no better off than before.

My customer is a small office in a remote location, about 20 workstations and a Windows '03 server. They have been served by AT&T DSL for years, but AT&T has forced them to move to Uverse.

Because the AT&T guy in this small town just does a "drive by" installation, I showed up while he was onsite to make sure everything went well. After an hour or so everything seemed to be fine. I was able to get the Motorola router to work behind our router, and so that was it.

Next day, we found there was one critical website that could not be access:


No other site seems to be a problem. We're able to access this site with no difficulty on every other Internet connection I've found (including cell networks, our office, and other customers' offices).

I returned to the customer's office, connected the AT&T router directly to a computer (i.e., off of our network) and the site is still inaccessible. After two hours on the phone with AT&T support they've essentially said they have no idea and that it must be a problem with the website -- even though THEY were able to access the site perfectly from their own computers.

So, now, I have Uverse serving the network except for the most important site at the office. AT&T is useless at this point, the customer is looking at me to resolve this and I don't know where to go from here.

NSLookup infoexchnage.relayhealth.com returns, and with that ip address the site is accessible on my in-house network (not uverse). It is as though that particular IP Address is blocked somewhere along the line.

Two tracerts are attached. The first is done from the client's server. enter image description here

The second is done from MY workstation in MY office, which has no trouble accessing the site.

enter image description here

Consistently, whether done from the client's computer or one on a different ISP where the site is accessible, the tracert follows roughly the same pattern -- it times out after about 7-8 hops. AT&T says this shows it is not their problem, but to me it just seems it shows the tracert is not an effective tool for diagnosing the problem, since it looks about the same regardless of whether the site is on an accessible network.

If anyone can suggest ANY approach to resolving this problem I would be deeply appreciative. I'm a programmer who sometimes has to deal with network problems, not particularly well-versed in network engineering issues, so the problem may be more straightforward for those of you who work with this stuff daily. Thanks for looking at my problem.

  • Is there any sort of content filtering going on at the edge? To speed up your resolution time, it may be worthwhile drawing a simple diagram of your network layout. – Ryan Foley Aug 1 '14 at 15:43
  • Thx. I have actually isolated it to the public network by attaching AT&T's router directly to a workstation to replicate the problem. So, the problem exists even when our in-house network isn't in the picture ... – RegularExpression Aug 1 '14 at 15:52
  • I checked from a site I have access to that uses U-Verse as well and it had no issues reaching the site. Although this proves nothing, the problem could very well be outside the AT&T network. It may help to know the subnet of your external IP address? – YLearn Aug 1 '14 at 16:44
  • I actually talked to a neighbor of my customer in this area who is on uVerse and had them try the same site. They couldn't access it. External IP is – RegularExpression Aug 1 '14 at 17:05
  • Saying you "can't access" a site is a nice first step in describing the problem; could we drill down a bit farther and identify whether a TCP SYN is received during these failed attempts to reach from Uverse? If so, is your server responding with a TCP SYN-ACK? – Mike Pennington Aug 10 '14 at 12:29

According to ARIN WHOIS (http://whois.arin.net/rest/net/NET-104-0-0-0-1/pft), the netblock you're in has only been in use since 2014-01-16. Someone along the line might be blocking your traffic because they are filtering bogon networks and their database is out of date. I'd start with contacting Relayhealth first (where filtering bogon networks would be best practice), then Qwest, which is where the traffic is being dropped according to the traceroute (note that you can reach the hop in your network, but can't your customer's network).

| improve this answer | |
  • 1
    Thanks for your reply. We finally gave up. We could never get to Relay's IT people, but found out numerous UVerse customers were having problems. ATT said it wasn't their problem, it was Qwest. Qwest said we can't help you, you don't have an account with us. And my knowledge of networking is limited. At the end of the day, we went back to AT&T and said, "We can't use UVerse." They agreed to put us back on DSL. So that's where we are. – RegularExpression Aug 10 '14 at 17:09

Not the answer you're looking for? Browse other questions tagged or ask your own question.