Cannot access a single site on my home network
December 16, 2019 6:38 AM Subscribe
There is a single site that I cannot access from my home network (timeout), but can access from any other internet connection (e.g. it's not down). My ISP is baffled. Any help?
Symptoms:
No device connected to my home router can connect to a particular website (nma.art). Devices are connected both using wired (Ethernet) and Wifi connections. The router is a TP LINK.
Attempts I have made to resolve this:
-Connect via IP (failed; works for my ISP, as well as connecting via domain name)
-Pinging by domain name (failed)
-Pinging via IP (failed)
-Trying other browsers (failed)
-Trying other devices connected to the network (failed)
-Changing PC DNS (Google, OpenDNS; failed)
-Changing Router DNS (Google, OpenDNS; failed)
-Checked hosts file (empty)
-Checked Restricted Sites (empty)
-Rebooted Router
-Factory reset router
-Contacted ISP; he's on the same upstream as I am and can happily connect
-My public IP doesn't conflict with the site's IP
-My router's firewalls have never been enabled
So what's I've got is this is a home-network-wide issue that is somehow caused by neither my modem/router nor my ISP upstream. What. Whaaat.
Symptoms:
No device connected to my home router can connect to a particular website (nma.art). Devices are connected both using wired (Ethernet) and Wifi connections. The router is a TP LINK.
Attempts I have made to resolve this:
-Connect via IP (failed; works for my ISP, as well as connecting via domain name)
-Pinging by domain name (failed)
-Pinging via IP (failed)
-Trying other browsers (failed)
-Trying other devices connected to the network (failed)
-Changing PC DNS (Google, OpenDNS; failed)
-Changing Router DNS (Google, OpenDNS; failed)
-Checked hosts file (empty)
-Checked Restricted Sites (empty)
-Rebooted Router
-Factory reset router
-Contacted ISP; he's on the same upstream as I am and can happily connect
-My public IP doesn't conflict with the site's IP
-My router's firewalls have never been enabled
So what's I've got is this is a home-network-wide issue that is somehow caused by neither my modem/router nor my ISP upstream. What. Whaaat.
Best answer: Did you receive the same public IP when you reboot the router? Is this a new ISP connection to you?
If that IP has remained the same throughout your testing its *possible*, but unlikely, that either the site administrator or an upstream router has blocked your public IP for some perceived abuse or malfeasance. Possible that it's totally erroneous, or maybe related to whoever had that IP before you.
On preview, what enfa said.
posted by pilot pirx at 7:01 AM on December 16, 2019
If that IP has remained the same throughout your testing its *possible*, but unlikely, that either the site administrator or an upstream router has blocked your public IP for some perceived abuse or malfeasance. Possible that it's totally erroneous, or maybe related to whoever had that IP before you.
On preview, what enfa said.
posted by pilot pirx at 7:01 AM on December 16, 2019
I once had a network card that started going bad and the observable effect was that packets would drop in such a way that some sites were consistently usable and some were consistently not. Maybe there's a problem with your router hardware?
Also, I assume `nslookup nma.art` works, but I didn't see it on your list.
posted by Horselover Fat at 7:01 AM on December 16, 2019
Also, I assume `nslookup nma.art` works, but I didn't see it on your list.
posted by Horselover Fat at 7:01 AM on December 16, 2019
There's plenty of pernicious behaviour that can survive a reboot, unfortunately.
Usually these things are ISP-modem -> Router -> household computers, so if you've got a laptop with a wired connection, take the router out of the loop and plug the laptop directly into the ISP's modem and see what happens. That will, at least, confirm whether or not the router is the problem. It's also possible that the problem is not at your end, and that the site you're mentioning (or some step in the chain from here to there) is dropping your packets because of bad behaviour from whoever had your IP in the past, or somebody who's been spoofing your IP address recently. In most cases you'll need your ISP's help to change your IP address, they're usually not assigned purely-randomly-on-DSL-restart these days.
posted by mhoye at 7:02 AM on December 16, 2019
Usually these things are ISP-modem -> Router -> household computers, so if you've got a laptop with a wired connection, take the router out of the loop and plug the laptop directly into the ISP's modem and see what happens. That will, at least, confirm whether or not the router is the problem. It's also possible that the problem is not at your end, and that the site you're mentioning (or some step in the chain from here to there) is dropping your packets because of bad behaviour from whoever had your IP in the past, or somebody who's been spoofing your IP address recently. In most cases you'll need your ISP's help to change your IP address, they're usually not assigned purely-randomly-on-DSL-restart these days.
posted by mhoye at 7:02 AM on December 16, 2019
Best answer: Most likely solution: The remote site (or somewhere along the way (cough: cloudflare)) is blocking you.
Moderately likely; your site (your router or computer/device) is doing the blocking, unbenknownst to you. You can eliminate a computer by booting under a recovery CD and attempting to connect. A device (non-router) may be able to be checked by factory resetting. Many routers that I've come across however a factory reset only clears the config. If the compromise involved reflashing your router, the only fix would be to buy a new router.
Moderately likely; your ISP has a routing issue going on. I've seen instances where the switch/NAS serving your IP pool can route to the destination site properly. In an example we came across, we had to assign an additional virtual IP to the switch from the IP pool, and then attempt to connect from the new source interface, and that's when the wackyness was revealed to our network admins. I don't see any comment about comparing a traceroute from your system with that of your ISP.
Less likely, but I've seen it happen twice: your ISP gave you an IP where the last octet is .255 . In a subnet larger than 256 addresses (I.E. a /23 or larger) this is a valid address. However, lots of poor networking/sysadmins don't consider anything other than /24's or smaller where the .255 address would always be a broadcast address, and thus "only come from forged packets, so it's safe to drop." Somewhere along the line, or the destination host/server/service (one example I saw was some private VPN software which didn't allow the client to connect if it was a .255 IP), is dropping packets with a source/dest IP of .255 .
---
Do you have a static or dynamic IP? If dynamic, how often does it change? I.E. did you get a new IP when you rebooted your router? If you don't know how to display the static, you can visit whatsmyip.net. If you got a new IP, how drastically did it change? I.E. was it only from A.B.C.D to A.B.C.E ? Was it the same subnet (run the IP into whois tools and you'll get one of an NetRange (E.G. 142.184.176.0 - 142.184.191.255 ) or CIDR block (142.184.176.0/20). NetRange is easier for amateurs to read, but a google for "convert CIDR notation to net range" should get you the range if only the CIDR is offered.
If your IP's are always on the same range/subnet, then a remote block against your subnet for abuse, or a routing issue (likely on your ISP's side) would be expected to behave exactly the same for all IP's. Large services like google are unlikely to block a CIDR because of abuse, but midsize or smaller are often content to write off a subnet to avoid the abuse popping back up when they dynamically get a new IP.
posted by nobeagle at 7:11 AM on December 16, 2019 [1 favorite]
Moderately likely; your site (your router or computer/device) is doing the blocking, unbenknownst to you. You can eliminate a computer by booting under a recovery CD and attempting to connect. A device (non-router) may be able to be checked by factory resetting. Many routers that I've come across however a factory reset only clears the config. If the compromise involved reflashing your router, the only fix would be to buy a new router.
Moderately likely; your ISP has a routing issue going on. I've seen instances where the switch/NAS serving your IP pool can route to the destination site properly. In an example we came across, we had to assign an additional virtual IP to the switch from the IP pool, and then attempt to connect from the new source interface, and that's when the wackyness was revealed to our network admins. I don't see any comment about comparing a traceroute from your system with that of your ISP.
Less likely, but I've seen it happen twice: your ISP gave you an IP where the last octet is .255 . In a subnet larger than 256 addresses (I.E. a /23 or larger) this is a valid address. However, lots of poor networking/sysadmins don't consider anything other than /24's or smaller where the .255 address would always be a broadcast address, and thus "only come from forged packets, so it's safe to drop." Somewhere along the line, or the destination host/server/service (one example I saw was some private VPN software which didn't allow the client to connect if it was a .255 IP), is dropping packets with a source/dest IP of .255 .
---
Do you have a static or dynamic IP? If dynamic, how often does it change? I.E. did you get a new IP when you rebooted your router? If you don't know how to display the static, you can visit whatsmyip.net. If you got a new IP, how drastically did it change? I.E. was it only from A.B.C.D to A.B.C.E ? Was it the same subnet (run the IP into whois tools and you'll get one of an NetRange (E.G. 142.184.176.0 - 142.184.191.255 ) or CIDR block (142.184.176.0/20). NetRange is easier for amateurs to read, but a google for "convert CIDR notation to net range" should get you the range if only the CIDR is offered.
If your IP's are always on the same range/subnet, then a remote block against your subnet for abuse, or a routing issue (likely on your ISP's side) would be expected to behave exactly the same for all IP's. Large services like google are unlikely to block a CIDR because of abuse, but midsize or smaller are often content to write off a subnet to avoid the abuse popping back up when they dynamically get a new IP.
posted by nobeagle at 7:11 AM on December 16, 2019 [1 favorite]
Best answer: Do a traceroute / tracepath / traceproto (whatever is available on your machine). Google up a web based traceroute program and run a trace from there as well. Compare.
# traceproto nma.art
traceroute to nma.art (23.253.102.197), 30 hops max, 60 byte packets
1 HG6Box (192.168.1.1) 0.871 ms 0.734 ms 0.681 ms
2 * * *
3 96-34-62-244.static.unas.mo.charter.com (96.34.62.244) 15.772 ms 22.646 ms 11.725 ms
4 96-34-62-192.static.unas.mo.charter.com (96.34.62.192) 13.522 ms 13.844 ms 16.826 ms
5 bbr02atlnga-tge-0-3-0-3.atln.ga.charter.com (96.34.1.194) 24.076 ms 19.505 ms 18.540 ms
6 bbr01dllstx-bue-6.dlls.tx.charter.com (96.34.0.20) 56.053 ms 58.250 ms 53.164 ms
7 prr02dllstx-bue-1.dlls.tx.charter.com (96.34.3.247) 50.438 ms 50.699 ms 50.543 ms
8 eq-dfw.rackspace.net (206.223.118.7) 50.349 ms 50.749 ms 50.751 ms
9 * * *
10 corec-dcpe3.dfw1.rackspace.net (148.62.41.97) 50.857 ms 51.692 ms corec-dcpe4.dfw1.rackspace.net (148.62.41.103) 50.098 ms
11 core9-corec.dfw1.rackspace.net (148.62.41.125) 50.465 ms core10-corec.dfw1.rackspace.net (148.62.41.123) 50.526 ms 51.841 ms
12 core10-aggr160a-5.dfw2.rackspace.net (98.129.84.135) 51.254 ms core9-aggr160a-5.dfw2.rackspace.net (98.129.84.131) 53.522 ms core10-aggr160b-5.dfw2.rackspace.net (98.129.84.161) 50.006 ms
13 23.253.102.197 (23.253.102.197) 50.476 ms 50.945 ms 50.652 ms
Use this information to determine just how far outside your network and/or how close you are getting to nma.art. See if you can at least get through your ISP, or all the way to Rackspace.
posted by zengargoyle at 7:28 AM on December 16, 2019 [2 favorites]
# traceproto nma.art
traceroute to nma.art (23.253.102.197), 30 hops max, 60 byte packets
1 HG6Box (192.168.1.1) 0.871 ms 0.734 ms 0.681 ms
2 * * *
3 96-34-62-244.static.unas.mo.charter.com (96.34.62.244) 15.772 ms 22.646 ms 11.725 ms
4 96-34-62-192.static.unas.mo.charter.com (96.34.62.192) 13.522 ms 13.844 ms 16.826 ms
5 bbr02atlnga-tge-0-3-0-3.atln.ga.charter.com (96.34.1.194) 24.076 ms 19.505 ms 18.540 ms
6 bbr01dllstx-bue-6.dlls.tx.charter.com (96.34.0.20) 56.053 ms 58.250 ms 53.164 ms
7 prr02dllstx-bue-1.dlls.tx.charter.com (96.34.3.247) 50.438 ms 50.699 ms 50.543 ms
8 eq-dfw.rackspace.net (206.223.118.7) 50.349 ms 50.749 ms 50.751 ms
9 * * *
10 corec-dcpe3.dfw1.rackspace.net (148.62.41.97) 50.857 ms 51.692 ms corec-dcpe4.dfw1.rackspace.net (148.62.41.103) 50.098 ms
11 core9-corec.dfw1.rackspace.net (148.62.41.125) 50.465 ms core10-corec.dfw1.rackspace.net (148.62.41.123) 50.526 ms 51.841 ms
12 core10-aggr160a-5.dfw2.rackspace.net (98.129.84.135) 51.254 ms core9-aggr160a-5.dfw2.rackspace.net (98.129.84.131) 53.522 ms core10-aggr160b-5.dfw2.rackspace.net (98.129.84.161) 50.006 ms
13 23.253.102.197 (23.253.102.197) 50.476 ms 50.945 ms 50.652 ms
Use this information to determine just how far outside your network and/or how close you are getting to nma.art. See if you can at least get through your ISP, or all the way to Rackspace.
posted by zengargoyle at 7:28 AM on December 16, 2019 [2 favorites]
Response by poster: I get all the way to your 12th hop but fail 100% of the time on the 13th and final hop.
I'm working under the assumption I've been erroneously IP banned (I swear, all I did was watch anatomy videos :( ), used mobile data to send a support request and will work on IP flushing overnight (I suspect my ISP has a long flush time but I've emailed to confirm). Thanks, all!
posted by flibbertigibbet at 8:34 AM on December 16, 2019 [1 favorite]
I'm working under the assumption I've been erroneously IP banned (I swear, all I did was watch anatomy videos :( ), used mobile data to send a support request and will work on IP flushing overnight (I suspect my ISP has a long flush time but I've emailed to confirm). Thanks, all!
posted by flibbertigibbet at 8:34 AM on December 16, 2019 [1 favorite]
Response by poster: And I'm in (not due to any action on my or my ISP's part -- still have the same IP). Thanks, all!
posted by flibbertigibbet at 3:28 PM on December 16, 2019
posted by flibbertigibbet at 3:28 PM on December 16, 2019
This thread is closed to new comments.
Can you connect a laptop directly to the modem via Ethernet to get the router out of the picture?
posted by enfa at 6:59 AM on December 16, 2019 [2 favorites]