As David pointed out again...not DNS....

This time ;)

Having an MS in Cybersecurity and IA, CISSP, GPEN, GCFA, I was able to piece together that the IP address is IP of the server :rolleyes:. I simply didn't see post 6. Having said that you are correct. If he's unable to get to the site via the IP address then it's likely being filtered.

To the OP - I would recommend giving your internet provider a call and see if they can resolve for you. That tracert screenshot should point them in the right direction as to where it's getting blocked.

^^^ LOL....I know what IP and OP mean....so there ;)!

No virtual web server can respond appropriately if you simply hit it via the IP address, as they need the name of the site encoded in the URL in order to decide what content to serve.

The traceroute output doesn't show that he can't hit it with a web browser; what it demonstrates that network hops after a certain point are having ICMP (either requests or replies) filtered, or a router is choosing to drop packets with the ICMP_TIME_EXCEEDED flag set. Very common across network boundaries.

Also, ICMP != TCP. So a failure to get an ICMP response from an IP tells you zip about the state of TCP connections you may (or may not) be able to establish to that same IP or port - the only way is to try to connect using the appropriate protocol and/or ports - eg TCP/80 or TCP/443.

For example: Broadly speaking, "connected" means you can reach it fine via TCP; any error after that is either a server-side configuration issue or a problem with the URL you provided.

A firewall filtering connections most often just times out w/ no handshake.

"connection refused" means a TCP reset was issued; usually means nothing listening on that port at the far end (so issued by the hosts' TCP stack), although sometimes a firewall is configured to reset instead of just quietly dropping packet(s).

[QUOTE=spuggy;10687194]No virtual web server can respond appropriately if you simply hit it via the IP address, as they need the name of the site encoded in the URL in order to decide what content to serve.

At a minimum using just the IP we would have expected an invalid certificate warning. Indicating that he could at least reach the web server and something else was the issue (possibly DNS). The OP got a server timeout using just the IP. The OP also states that all the other websites he goes to work just fine.

Still standing on not DNS.

As stomachmonkey already said - the fact it works on one route and not another indicates a problem specific to the communication path. It looks to me that broadband is Cox address space - so as it works over cell (stated to be also Cox), likely they're messed up in some way for broadband (both networks would typically be almost entirely separate).

Could be any number of things - from name servers caching values from when the DNS *was* screwed up (eg long TTL on either the RR or SOA), to bad routing/filtering.

Bad filtering, bad or asymmetric routing seems much more likely than a cached "bad" DNS response from October, but there's a reason customer satisfaction ratings for cable companies are so low - they're often pretty poor ISP/NSPs.

Agreed. Unfortunately the next step for the OP is to spend 2 hours on hold waiting for a 1st tier support rep to tell him that everything's is fine and it's his DNS. :)

This is true. Although I can hit it using IP address from my network. (comcast)


This is also correct. However, i can tracert to the server and the OP cannot. Since he is the one having the problem that is a good indicator that something is being blocked/filtered or there's some routing issue.

All of this is also correct. However, when the OP tries connecting he gets a server timeout error.

Looking at OP tracert output, his trace route is getting bounced around Zayo network.

OP - try visiting http://69.63.128.6 (I got lucky) and https://www.woodmenlife.org. If you have the same problem with these websites then that's a pretty good indicator there's a routing issue to that network. Then you can tell COX that you cannot access any websites in the range 69.63.128.0/19.

^^^^ (David's DNS post) LOL....I lived in the world of corporate/carrier grade Intranets....at least it was MY mess to figure out :D. I knew I had a DNS issue before anyone back then....

I wuz a busy Pelican so I knew when DNS issues stopped me from browsing forums ...damn....gotta work ;)

Agreed. I'm thinking he may also try calling motorsportreg.org and let them know he cannot access their site from COX network. The issue means more to them than it does to COX as it's less visibility to their site, thus they would be more motivated to have the issue rectified.

Looks like there are others ...

https://forums.cox.com/forum_home/internet_forum/f/internet-forum/24517/website-not-found---only-on-cox

930addict:

I was able to reach the site woodmenlife.org, a life insurance company, thru my SP using Cox internet service in my condo. I was not able to reach the IP address 69.63.128.6.

However, I googled "what website is IP 69.63.128.6?" and got a site and with some sleuthing found that the only domain with this address is getcadrplus.com. I clicked on that link and it opened a website with some info about that domain. However, if I try to put getcadrplus.com in the browser address bar it times out just like MSR.

So, woodmenlife.org worked but that other IP address doesn't work.

I've had to call cox and have them reset my cable router. Rebooting was not enough to clear the issues.

An ICMP issue does not indicate a TCP/IP problem. IP may have an issue that also affects ICMP - but failure of any external network hop to design to talk ICMP to you is not a problem.

Many network operators won't pass ICMP outside their network. Although many NSPs will.

So, you work(ed) for Zayo, are familiar with the internal device naming nomenclature/topology of their network and can thus definitively identify the routing issue there from some number of unidentified nodes that don't respond to public ICMP?

Oh, that's not right? OK.

While it's entirely possible that there is some issue with Zayo, it's also possible that Cox broadband uses that route incorrectly (whereas Cox cellular doesn't), and so one works while the other fails.

However, what the OP's traceroute actually shows is that it goes via LA, Dallas, Houston and then through DC to Baltimore.

My traceroute traverses Level3, transits their edge in Washington before hitting a Baltimore interface belonging to edgehosting.net. So the OP's traceroute that hits Zayo looks perfectly reasonable, and is not "bouncing around" inside Zoyo at all, as far as anyone can tell from that traceroute.

What is probably happening is that edgehosting either aren't accepting connections from Zoyo, or have a bad route for the return packets.

But nothing can really be inferred from 3 hops that don't respond. The ONLY thing you can tell for certain from external hops that don't belong to you and won't return ICMP information is that (a) they're there and (b) they don't want to talk ICMP to you.

It could be a bad route for Cox on the broadband side of the house, but I suspect an issue with edgewebhosting/Zayo is more likely - given that the packets are getting like, right there to Baltimore and not back...

If it were me, I'd probably ask the folks at motorsportreg.com to contact their webhosting company and tell them that their website is broken for packets transiting Zayo from Cox broadband in SoCal.


www.woodmenlife.org is in Toronto when I try it.

Spuggy, et al: One more piece of info for you. I contacted a fellow PCAer here in the PHX area, who is an organizer of an AZ PCA event, of course, they are using MSR for registration purposes, and asked him today if he was using Cox internet in his home when he successfully connects with MSR and he said, yes.

So, he is using Cox internet service, in his home, successfully to connect to MSR and I am using Cox internet service in my condo in the Scottsdale area and cannot connect to MSR. I will call MSR back and relay this information that you have provided and see what they say. It's interesting that at least some other sites are being blocked by Cox also.

I know that. Traceroute is a good tool to start your troubleshooting with and it's available to the OP. While it has limitations it's not a useless tool. Many operators configure their routers to not respond to icmp traffic but they will forward them to the next hop. That's how you get the broken traceroute returns that ultimately get to the destination. It just depends on the network.

The other tools available that can perform TCP scans (like nmap, Hping) require specialized knowledge and so would not be helpful to him. Not to mention that most system owners don't like people scanning their system.

Why the attitude?

And how did you come up with all of that? I never identified an issue. I simply said it was bouncing around Zayo's network. Perhaps I should've said "it certainly looks like it's bouncing around Zayo's network" - probably would have read better. But that was more of a tongue-in-cheek commentary on the number of hops. I work for a 40k user organization in silicon valley - I'm not used to seeing that many hops on our network.

And just for kicks I did an experiment. I think there were 11 hops on the OP trace route - 6 just inside Zayos network. I was able to do a traceroute to a DNS server in Wandsworth United Kingdom in 13 hops (212.118.241.1) with no breaks between routes.

Anyway - the OP trace route shows it leaving OP's home network. Enters and exit COX network at 68.105.30.150 and 64.125.25.122. Enters Zayos at 64.125.25.122 after which all subsequent hits are Zayos:
64.125.29.52
64.125.28.98
64.125.29.48
64.125.30.247
64.125.25.129

So doesn't seem to be an issue with COX. Seems like an issue between Zayos and whatever comes next.

One thing is certain - none of us know what the issue is and none of us are in a position to fix it.

One other certainty is there are some big ego's here judging by the attitudes in some of these posts. Wow. :eek:

Have you unplugged your cox cable modem for 15 minutes, then plugged it back in?

Are you using a separate wifi router? Reset it.

The process is to kill all routing tables that either or both are storing.
May have stored a bad route then their stuff was not routing correctly.

I just drop in to to watch the bit flinging....with popcorn ;)

LOL....I thought it wuz a prerequisite for communications geeks ....mebbe it's just me tho' :D