Verizon FiOS site blocking diagnosis...
Sometimes Verizon FiOS customers have problems browsing certain websites. Perhaps the sites are being blocked? Here are some ideas about diagnosing the problem that I've found working as a sysadmin. I hope they help...
On the website/sysadmin end, if I want to check if my servers are blocking a user at a particular IP, I run through this checklist: I check that my load balancers and web servers are up, have network connectivity, have sane routing tables, are running their web server listening on port 80. I ping them from an external IP, like from the open wifi next door. I try browsing web content on port 80 (HTTP) and on port 443 (HTTPS). I check the domain's DNS record global propagation using some external sites. On the Linux servers hosting the site, I check that no iptables firewall rules and PAM configuration are set to block anyone. I'm pretty sure that kernel bogon packet filtering was no longer an issue after 2011. When all those things check out okay, I'm pretty sure the site is available to most of the planet for browsing.
So what about the Verizon FiOS end of the connection? If a site seems blocked, here are some things users can check:
Do a hostname lookup for the website. You should receive one or more IP addresses. Do the same lookup on a public DNS server. Do the IP addresses match? Are all the IP addresses pingable? If the website servers respond, then they are at least answering ICMP echo request packets. See if typing the site's URL in your browser results in either the site webpage or a timeout message. If the page doesn't show up, try browsing the site's port 443 SSL service by typing "https" in the site's URL. If Verizon has given you some sort of content filtering software to run on your computer, check to see if it is blocking either the site or a keyword. If you can log in to your Verizon FiOS router, check to see if it has a content or keyword filtering feature enabled. Sometimes these things are updated remotely by the ISP. Some routers may offer logs of the sites blocked. If you have an online Verizon FiOS customer account that offers some sort of control panel, check that for any filtering options enabled.
If you are more of a power user, you might use a TCP traceroute tool (lft) to reveal where along the path your port 80 packets are getting dropped. There are scanning tools (nmap) to see if ports 80 and 443 on the website are seen as open. There are commandline browsing tools (wget) to examine any response on port 80.
The most useful thing I've found is to do web searches for the problems I'm having; If I confront a problem, often it turns out dozens of others have already encountered it as well.
Any time I can never reach A site ion Fios its because FIOS opened up a new block of IP Address and some companies dont accept new ranges right away.
A new address block is not so common anymore. Last one I've noticed was a bit more than a year ago. When I can't ping an address, I try to ping other addresses in the same block to see if it's the server or the routing. Obviously, I need to verify the size of the block held bythat provider. I've seen some fractured address blocks.
Will birdfeedr if you have some magic, tell me. I have FIOS and oddly enuff I've not been able to hit Veetle.com for more than 3 weeks. From my location, (N.E, eastern MA) port 80 to veetle.com is simply unavailable. DNS/PING is fine; 80 simply fails. All my PCs on my home network; same results. Diff flavors of WIN/LNX, PADs, phones... My RTRs are good; no weirdness. Proved it with my phone, disable the wifi, boom I'm on Veetle, turn WIFI back on, can't connect. VZ tech blamed it on a hop down a trace route provided, I figured. TENIT (hop owner) tech kindly responded wanting me to try "friendlier DNS", been using google numbers for 3 years, that's not it. NMAP shows HTTP is filtered. So....thoughts? and thx in adv.
Have you tried the layer 4 trace that Peter was wanting? Should be available for Debian-based distros (Ubuntu, etc) via "sudo apt-get install lft"
Oh, Opera, what have you done?
|reply to gew1 |said by gew1:
I've not been able to hit Veetle.com for more than 3 weeks. From my location, (N.E, eastern MA) port 80 to veetle.com is simply unavailable.
And you wont be able to until Veetle decides to fix there firewalls so they stop them from blocking TCP port 80 from select IPs.
Additionally, you have to love when a "website/sysadmin" posts things like this. The fact is if veetle2/Peter had any clue how to diagnose issues he would know how to run a trace using a specific port and protocol and not ask for some other program to be used. Case in point:
Normal trace, default settings
traceroute to Veetle.com (188.8.131.52), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 0.294 ms 0.570 ms 0.566 ms
2 L100.BLTMMD-VFTTP-14.verizon-gni.net (184.108.40.206) 2.634 ms 2.716 ms 2.866 ms
3 220.127.116.11 (18.104.22.168) 3.651 ms 3.755 ms 3.755 ms
4 so-6-1-0-0.PHIL-BB-RTR2.verizon-gni.net (22.214.171.124) 6.076 ms ae1-0.PHIL-BB-RTR1.verizon-gni.net (126.96.36.199) 44.140 ms so-6-1-0-0.PHIL-BB-RTR2.verizon-gni.net (188.8.131.52) 5.930 ms
5 0.xe-3-0-2.XL4.IAD8.ALTER.NET (184.108.40.206) 8.309 ms 0.xe-6-1-1.XL3.IAD8.ALTER.NET (220.127.116.11) 8.511 ms 0.xe-3-0-2.XL4.IAD8.ALTER.NET (18.104.22.168) 8.497 ms
6 GigabitEthernet7-0-0.GW8.IAD8.ALTER.NET (22.214.171.124) 12.071 ms GigabitEthernet6-0-0.GW8.IAD8.ALTER.NET (126.96.36.199) 11.719 ms 10.967 ms
7 tinet-gw.customer.alter.net (188.8.131.52) 11.825 ms 11.450 ms 11.309 ms
8 xe-3-0-0.pao10.ip4.tinet.net (184.108.40.206) 79.820 ms xe-1-3-0.pao10.ip4.tinet.net (220.127.116.11) 80.916 ms xe-3-0-0.pao10.ip4.tinet.net (18.104.22.168) 78.348 ms
9 22.214.171.124 (126.96.36.199) 77.410 ms 78.168 ms 76.325 ms
Trace to port TCP/80 (-T --tcp Use TCP SYN for tracerouting (default port is 80))
fw1@core:~$ sudo traceroute -T Veetle.com
traceroute to Veetle.com (188.8.131.52), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 0.180 ms 0.174 ms 0.191 ms
2 L100.BLTMMD-VFTTP-14.verizon-gni.net (184.108.40.206) 1.584 ms 1.695 ms 1.875 ms
3 G0-5-2-4.BLTMMD-LCR-21.verizon-gni.net (220.127.116.11) 4.515 ms 4.643 ms 4.636 ms
4 so-1-1-0-0.RES-BB-RTR1.verizon-gni.net (18.104.22.168) 5.080 ms ae4-0.RES-BB-RTR1.verizon-gni.net (22.214.171.124) 6.925 ms so-1-1-0-0.RES-BB-RTR1.verizon-gni.net (126.96.36.199) 6.902 ms
5 0.so-6-0-2.XL3.IAD8.ALTER.NET (188.8.131.52) 8.202 ms 0.xe-4-1-0.XL4.IAD8.ALTER.NET (184.108.40.206) 9.545 ms 0.so-6-0-2.XL3.IAD8.ALTER.NET (220.127.116.11) 8.622 ms
6 GigabitEthernet6-0-0.GW8.IAD8.ALTER.NET (18.104.22.168) 9.673 ms GigabitEthernet4-0-0.GW8.IAD8.ALTER.NET (22.214.171.124) 7.486 ms GigabitEthernet6-0-0.GW8.IAD8.ALTER.NET (126.96.36.199) 9.332 ms
7 tinet-gw.customer.alter.net (188.8.131.52) 10.207 ms 8.870 ms 8.844 ms
8 xe-3-0-0.pao10.ip4.tinet.net (184.108.40.206) 77.289 ms 78.200 ms xe-5-0-0.pao10.ip4.tinet.net (220.127.116.11) 78.964 ms
9 * * *
10 * * *
11 * * *
12 * * *
Clearly traffic to port TCP/80 is being blocked (Most likely more ports as well) at the edge of there network either by there server or there ISP, why they are blocking it i don't know/care since before this thread i have never visited it and probably wont again in the future.
Now that is sweet zippoboy7. I completely forgot to consider a traceroute switch. You know I really could care less about veetle, just wanted to find the culprit.