Recently, someone at a small business with a Verizon DSL Internet connection couldn't connect to my computer with NetMeeting. I've done this often enough to know that NetMeeting wasn't the problem, so I asked them to ping my computer - and it failed (timed out).
The TCP/IP ping command is a network debugging tool available on any operating system with TCP/IP (which is just about every operating system). It sends a simple command to the target computer which answers with a small amount of data. As the name implies, ping is just a tap on the shoulder to see if the networking is working between two computers on a TCP/IP network. Because pings are so simple, any problem is a networking problem.
In this case, the ping should not have failed. The target computer was one of mine and it was naked on the Internet, without a firewall protecting it. It seemed that Verizon was blocking it at the source, but I couldn't be sure.
A few days later, while working at another small business with a Verizon DSL connection, I couldn't establish a remote control connection using Real VNC. This was a bit more complicated, as it involved port forwarding on the target router and poking a hole in the firewall on the target computer. But here too, my first step in debugging was a ping of the target public IP address - and it failed. The target was a router under my control and it was configured to respond to public pings. Again, it seemed like Verizon was blocking the ping at the source.
To be sure, I tried a more advanced network debugging tool, traceroute. Long story short, traceroute proved that Verizon was blocking things. The trace was able to get from my computer on the LAN to the Verizon Westell 7500 modem/router that connected the LAN to the outside world, but could not get any farther.
A third test provided strike three. Someone I know with a Verizon DSL account, when told about this problem, also tried to ping some public websites and couldn't. The box used in this case was a Westell Wirespeed C90.
Verizon DSL is blocking outgoing ping, traceroute, NetMeeting, Real VNC and probably more.
This is bad. The blocking of outbound remote control software was a real problem to the first businesses as it prevented me from helping them with another problem.
Update August 5, 2008: Pings to websites don't always work. This has nothing to do with an ISP, rather it is an attribute of the website, or more specifically, the routers fronting the site. A website may simply choose not to respond to pings. The examples in this posting do respond to pings. Many consumer grade routers have a configuration option governing whether they respond to pings. However, even if a website opts to not respond to pings, a traceroute (in Windows the command is tracert) should at least show that the request got out to the Internet and bounced around a bit before failing. This was not the case with Verizon DSL.
Update August 5, 2008: I spoke to Verizon tech support and the technician said this is not by design. In fact, the person said they had never had a complaint that a DSL customer couldn't do something as simple as pinging yahoo.com. If this is true, the problem must lie in the configuration of the Westell modem/router. To be continued.
Update August 7, 2008: Verizon's press relations office made it clear they do not block traffic. And, it seems they don't - at least not on purpose. The problem has been resolved with one of the three customers, the issue was with the firewall in the router. More to come soon...
Update August 11, 2008: To see how this played out, see