dslreports logo
site
spacer

spacer
 
    All FAQs Site FAQ DSL FAQ Cable Tech About DSL Distance DSL Hurdles »»
spc

spacer




how-to block ads



Researched and written by Bill_MI. Originally posted in this forum thread.

I want to document this while it's fresh in my mind. I discovered why forwarding a huge port range kills all other LAN machines from WAN access. I suspected this for quite a while but never took the time to look at some actual connections.

How will it show up for you? Well, besides the zillion other things that could prevent connecting to a site you can add "Forwarded Port Conflict" to the list of "Site-Is-Down", "MSIE sucks" and "Oh well, it works later" stuff :-).

BACKGROUND

TCP dominates so I'll only cover that case. I did the testing using TELNET (port 23) to a friend's Linux machine.

Most are familiar TELNET is port 23, FTP is port 21, POP mail is port 110, etc. But in TCP there is *always* 2 ports involved in any connection called the source and destination ports.

The ports you know well are the destination port of the connection. The source port has to be *something* so typical TCPIP networking software assigns them in sequence starting at port 1024 or so. The next connection gets 1025, then 1026, etc.

The source port is ABSOLUTELY needed because it is exactly how your operating system knows how to get what data to which application. Like *this* instance of Internet Explorer vs. *that* instance of Netscape you're using at the same time.

So here's my *very* simplified TELNET connection to my friend with the ports put in.

OUTBOUND FROM ME:
MyTelnetClient(3447) LINKSYS FriendsTelnetServer(23)

INBOUND BACK TO ME:
MyTelnetClient(3447) LINKSYS FriendsTelnetServer(23)

My source port is 3447 in this case. If I disconnect then reconnect to my friend (and nothing else on my machine makes a connection) this is the connection I get...

MyTelnetClient(3448) LINKSYS FriendsTelnetServer(23)
MyTelnetClient(3448) LINKSYS FriendsTelnetServer(23)

Notice the source port incremented +1 to 3448. If I disconnected again, the next time it'll be 3449, etc.

THE TEST

Now, what happens if I connect yet again, the source port will be 3450, right? BUT...
WHAT IF I happen to have PORT 3450 Forwarded to another LAN machine?

Ooooops! That's a big what-if! Well, the LinkSys should see the connection, add it to it's NAT table and everything is ok to connect, right? WRONG!!! Here's what happens if port 3450 is forwarded to "MyOtherMachine"...

MyTelnetClient(3450) LINKSYS FriendsTelnetServer(23)
MyOtherMachine(3450) LINKSYS FriendsTelnetServer(23)
MyTelnetClient(3450) Hangs... it never sees the reply to connect!

My TELNET client CANNOT connect to my friend this time. It hangs trying because the LinkSys has Port Forwarding as a higher priority and sends the reply to the wrong machine.

This is not good. Someone with a lot of ports forwarded runs the risk of failed connections once in a while *just* due to this failure.

I've been thinking there may be a security reason for doing this but I can't think of any. At this time, I think it is pure oversight in the LinkSys design.

HOW TO AVOID THIS PROBLEM
TCPIP comes to the rescue, somewhat. Source ports are almost always assigned numbers starting at 1024 by specification. Source ports should never be below 1024 but notice all the old services have *destination* ports below 1024! FTP, TELNET, SMTP... all low port numbers.

So, for forwarding 21, 23, 25, etc (below port 1024) the problem should never have a conflict because source ports are NEVER this low. Then there's UDP where this could be the case but I'm not about to open this can of worms now :-).

But if you *have* to forward ports above 1024 go very very high... maybe it'll never conflict. Use port 52200 for the IRC DCC range you need to forward - not 2200. It'll be a looong time before apps start getting up there. You have all the way to 65535 so use it!

EDIT: See the "Good News!" below on this. Using ports 5000 and above may greatly reduce the problem.

Last, don't forward a bunch of ports unnecessarily - there's a cost if you do. Be "stingy" - it's more secure, too.

Thoughts? Comments?

EDIT:
ADDITIONAL STUFF
This test is on my LinkSys BEFSR41 V.1 with f/w 1.39.

SPI (Stateful Packet Inspection) can have just the "smarts" to avoid this type of thing. To see if it made a difference I tried it with the SPI option ENABLED but there is no change - the bug still exists.

Good News! I checked my AtGuard connection log to see how high source ports go. Since I constantly check email I might be able to see it wrap - and I did! In my Windows 2000 Professional my email checker only goes to port 4999 before wrapping around to port 1024. This may be the case (maybe even in a specification) on most machines and means the casual problem is only when forwarding ports 1024 - 4999. Although applications don't have to use what the operating system gives them for a source port the chances of conflicts when forwarding ports 5000 and above may be extremely small.

The "NAT" RFCs I've referenced before are below. "PAT" is elusive... am I missing something? I assume that's Port-Address-Translation. The concept we know as "Port Forwarding" is not covered much in these NAT docs but maybe I have the wrong ones.

RFCs rarely go into detailed design but stay at the concept levels. I suspect priorities of an NAT extension like "Port Forwarding" is up to the common sense of the designer. What think?

RFC2663 IP Network Address Translator (NAT) Terminology and Considerations. P. Srisuresh, M. Holdrege. August 1999. (Format: TXT=72265 bytes) (Status: INFORMATIONAL)

RFC3022 Traditional IP Network Address Translator (Traditional NAT). P. Srisuresh, K. Egevang. January 2001. (Format: TXT=37675 bytes) (Obsoletes RFC1631) (Status: INFORMATIONAL)

RFC3027 Protocol Complications with the IP Network Address Translator. M. Holdrege, P. Srisuresh. January 2001. (Format: TXT=48662 bytes) (Status: INFORMATIONAL)

All the "port forwarding" features of the low cost routers are based on PAT. In terms of a spec it appears as elusive as "SPI" - is it one of those things a marketeer could love because it's virtually undefined? :-) Perhaps one company coined the term?

By the way, I found this while looking at something else...

QUESTION: What happens if 2 LAN machines connect to the same host/site with the same source port?

ANSWER: The LinkSys shifts the source port on the WAN transparent to the 2 LAN machines to keep them separated.

Interesting - THAT case is covered quite well :-).

Feedback received on this FAQ entry:
  • the forwarder could simply translate the port to a free one as with the address

    2009-08-02 09:21:50



Expand got feedback?

by lev See Profile edited by Lanik See Profile
last modified: 2005-06-22 00:18:39