Comments on: Verizon DSL traffic blocking explained

As is so often the case, this Internet access problem was firewall related

[The_Decider]

Lots of misunderstandings on your part. But it boils down to PEBCAK, and you should issue an apology for rushing out such mindless accusations like the other post did.

The issue is a config issue that is your problem and not Verizons. Could they document it better, of course, but your unprofessional, half-cocked accusation about Verizon blocking outgoing ports is not only embarrassing, but likely actionable. If you worked for a legitimate house of journalism would you likely be out of a job right now.

A few corrections:

"Some port numbers are reserved for specific types of traffic, others can be used by any networking software for any purpose. "

The reservation is not enforced. if CNET wanted to they could bind HTTP to any port they want. I can bind FTP or one of my custom network applications on port 80 if I like.

From a security standpoint you can not make any assumptions about the type of traffic with only the port number. Anyone claiming to be a security expert should know this.
"For example, you requested this web page using port 80. When you request a secure web page you are using port 443"

Wrong, the client doesn't use port 80 request a web page. I am sure you know this but your wording is a little off.

"What's the difference, in terms of ports being blocked, between Medium and Low? Even Verizon doesn't know."

Um, the previous paragraph explained a difference.

"Each port is either:
-- inbound or outbound
-- used by TCP or UDP or both (low level protocols)
-- open, closed or stealthed (stealth is the best)"

A port can run traffic inbound and outbound, it is not an exclusive or

TCP and UDP are not low level protocol. They are below the application layer but above the physical, datalink and network layers. By definition TCP and UDP are not

Stealth is best? Between closed and stealth, stealth is better but if you have even 1 open port it doesn't matter since you can not stealth a open port, which should be obvious to you. Again, if you have 1 open port(and if you run a publicly accessible web service you do), putting the rest of the ports in stealth mode have no value. The point of stealth is to hide the fact that there is a machine bound to that IP address, and it is a trivial task to write a port scanner, much less download an existing one like Nessus. You have an outbound port open, guess what? Anyone can find out that a machine exists at that address.

[Bronx_Bomber]

Hi you seem to know what you are talking about, a quick question, I have a Westell 7500 (verizon) and I need to get to a DVR via the internet, that has port 80 as it's default port (it cannot be changed). I am having a hard time trying to port forward 80 so i can connect. do you have any idea how I can get this to work?

[The_Decider]

Also, it is possible to ping a host and run a traceroute on it using TCP or UDP instead of ICMP. Quite often it will get around blocking ICMP since many routers will send back a TTL time exceeded message for non-ICMP traffic.

[errorhelp]

verizon provided details here:

http://onlinehelp.verizon.net/consumer/bin/pdf/ActiontecMI1424WRUserManual.pdf

check it out......

i had peerguardian updates blocked at medium security but instead of switching to low.. i looked in security logs and unblocked what was blocked.

[errorhelp]

around page 70 btw

[adeptevolution]

Thanks for the information but it does not answer the problem in my case. While I can ping servers that allow it, I cannot get past 192.168.1.1 (my DSL modem's internal LAN address) when I try a traceroute to any server. Going into the firewall settings of the modem, it was actually set to No Security by default.
This is the only way I can run a traceroute:
--In the modem-admin UI, click Advanced in the top-level navbar and answer the "Do you want to proceed" warning with Yes.
--click on Diagnostics, enter the server address in the traceroute field and click Trace.
The page will reload when the trace is complete, and I find in Firefox on my computer (Mac) this blanks out the information you've been waiting for. Works fine in Safari.

Whether the inability to run a traceroute directly from my computer is a flag that I may run into some problems when attempting to collaborate with others over the Web, or to remotely administer a server, etc., remains to be seen. Very strange that a traceroute cannot get outside of my LAN with no firewall option set on the Westell piece o'junk

[adeptevolution]

as a follow-up to the above, I got traceroute working through my Verizon DSL Westell modem by doing this:

log into the DSL modem.

click on Firewall Settings in top-level nav

click on DMZ Host in the sidebar, answer Yes

your public IP address is displayed. Click the Enable button


traceroutes from LAN clients will now work fine.

NOTE: I don't know much about security, there may be implications of enabling your modem as a DMZ host. In our case we use an Apple Airport Express as the bridge between the DSL modem and our LAN, and the Airport handles NAT addressing. Our Macs have their OS firewalls turned on. This is plenty good for our purposes, but enabling DMZ hosting on a Win network without a serious firewall outsize the DMZ might be quite risky (as I understand it, this is jsut lightweight book knowledge!)