Unexpected and Uncofingured Port Forwarding from Netgear Switch/Router

May 20, 2006 1:09 PM

On my XP system, the recently installed Norton anti-worm app told me that my Netgear RP614v2 NAT-enabled router attempted to udp connect to my port number 2061 from its port 12024. However, there is no port fowarding or triggering enabled, nor is there a DMZ address configured at all.

There is some port forwarding configured via UPnP...but not that one or to this IP. UPnP config in the Netgear does say one address/port is mapped to a different IP and it was configured by the Azureus bittorrent client via its UPnP plug-in. But, again, this is only one port and to a different IP than my XP machine (whose IP is static via DHPP). SPI is on, ping reply is off.

Also, remote configuration is not enabled on the Netgear. The router firmware is 29 2004.

How could this happen? Any ideas?

I know that UPnP is supposedly insecure, but I confess I've never researched the matter nor worried about it very much. Immediately after this incident, I've turned off UPnP in the Netgear config and switched the XP machine running Azureus to use a fixed IP address and configured port forwarding for that one port and IP.

posted by Ethereal Bligh to computers & internet (8 comments total)

It's not UPNP -- that connects on TCP 5000, not UDP 2061

UDP 2061 is the NetMount port. If a machine on your network attempted a NetMount call through the router, you'd see UDP 2061 from the router.
posted by eriko at 1:25 PM on May 20, 2006

UPnP on the router and the Azureus plugin allows dynamic port forwarding. And it was controlling the forwarding of one port...but not 2061.
posted by Ethereal Bligh at 1:48 PM on May 20, 2006

This is just NAT doing its port mapping best to forward UDP packets from the Internet to your XP machine. Generally, not much that is good and holy happens on UDP ports above 1024; for security, you can kill UDP at the router's firewall, for everything (or, if you can be more selective, kill just 1024 and above) and hardly have a look back, as most services will automatically fall back to TCP anyway if they can't make a UDP link.

UDP is faster and lower overhead than TCP, because UDP is guaranteed to be lossless and flow controlled. But because UDP is easily spoofed, and doesn't call for handshaking, it's also traditionally looked upon as very insecure.

NAT works by building and maintaining dynamic address tables using the port descriptors of incoming and outgoing packets to re-address packets destined for and coming from the Internet through a single common gateway. The router sees a UDP broadcast packet from the Internet for any machine on any network, looks up all machines that are active on your network, and rewrites the address and port number for the packet for all machines on your network. Thus a UDP packet addressed for broadcast on the Internet becomes a valid and forwarded entry on your router's NAT table, and shows up at your machine. 99.99999% chance its digital junk at the packet level, and you can toss it, and all its evil siblings, without regard.
posted by paulsc at 1:58 PM on May 20, 2006

Uh, sorry:

"because UDP is not guaranteed to be lossless and flow controlled."
posted by paulsc at 1:59 PM on May 20, 2006

That's some pretty bizarre advice.

UDP is very commonly used for gaming and VOIP applications. In some cases they will fall back to TCP mode, but will function suboptimally. If ALL you do is browse websites and download files, you could disable UDP, but if you do anything vaguely interesting with your Net connection, that's not such a good idea.

A GOOD firewall will track UDP connections for you, and will only allow UDP replies to packets you have sent. If your Netgear router is accepting and forwarding all UDP packets by default, and you can't disable that functionality, it's time for a better firewall, not time to kill off a useful protocol.

The Linksys WRT54GL is pretty good.... note the L. That's the Linux model, which does a good job of firewalling. You'll very rarely run into compatibility issues running one of those... only with the oldest and stupidest programs.
posted by Malor at 3:36 PM on May 20, 2006

"... UDP is very commonly used for gaming and VOIP applications. ..."
posted by Malor at 6:36 PM EST on May 20 [+fave] [!]

VoIP is one of those "vaguely interesting" applications that is rapidly dumping UDP as its transport protocol. And other protocols such as SDP, RTSP, and SIP for multimedia streaming are coming into play, because of the millions of firewalls and routers that dump UDP traffic routinely.

In the days of broadband connectivity, most of the performance advantages of UDP have become moot, and its drawbacks for anything beyond LAN services are so widely known, that most users not only never miss it, but are better off without it.

If old games require UDP, the preferable strategy on a home network is just to activate UDP on the router during the times the user is gaming, and turn it back off otherwise. At the very least, set a firewall rule to automatically drop all UDP packets from outside the LAN with broadcast addresses.
posted by paulsc at 4:29 PM on May 20, 2006

I just realized that another computer on this LAN using "netmount" to try to connect to this IP would trigger the Norton firewall. For some reason I jumped to the assumption that this connection from the router represented something from the Internet outside my LAN.
posted by Ethereal Bligh at 8:27 PM on May 20, 2006

No sane firewall is going to forward broadcast-address UDP packets.

UDP is important and it's not going to go away. TCP is just not well-suited for many applications, particularly audio data, because the extra overhead of retransmission and resequencing is useless... if the packet will arrive late, it's no good.

The articles you mention do NOT support your position. The first one doesn't even MENTION TCP or UDP. The RTSP and SIP links both explicitly say that UDP is part of the protocol, and nothing about it being deprecated.

As a matter of fact, the RTSP link that YOU POSTED says:

Applications using RTP are less sensitive to packet loss, but typically very sensitive to delays, so UDP is a better choice than TCP for such applications.

I don't know what planet you're on, but here on Earth, UDP is a great protocol and highly useful. You may have run into braindead firewalls that don't know how to properly handle states in UDP. The correct answer is to fix the firewall, not throw away a useful protocol.
posted by Malor at 12:22 PM on May 21, 2006