Hardware NAT: Router Trouble shooting instructions and steps for mIRC, VPN, IPSEC configuration.

Networking: Instructions How to configure a network.

Networking File & Printer Sharing: How to configure Networks for NetBeui & file/printer sharing.

Sharing with ICS: How to configure your modem/network for software internet sharing.

Port Listings: A concise listing of Programs and their port usages/requirements.

FTP should be reliable if you're downloading from an FTP site on standard port 21. Otherwise, FTP is definitely not "NAT-friendly" (especially FTP servers).

Most problems can be traced to the fact FTP uses 2 connections - 1 for control and 1 for data. Plus there's 2 modes for the data channel (PORT/Active and PASV/Passive) and these modes differ by which end "plays server" for this extra data channel. Just forwarding ports or DMZ is NOT the answer because the FTP communication sets up the data channel and addresses will go astray. No wonder there's so many places to fail!

If you plan on using FTP regularly there is actually some hope. More info...

REFERENCE: FTP Modes and Ports
FTP works then it doesn't work. WTF???? (includes BPFTPServer Setup)
FTP Server (includes Serv-U Setup)
MTU, PPPoE, Servers and LinkSys Routers (a special problem for PPPoE users)

Don't miss this great site for setting up BPFTP Server, Serv-U and GuildFTPd with your Linksys router.

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 :-).

By default timeouts on Linksys routers are set too high thus connections don't time out without opening new ones.

This seems to work on most of the 3rd party firmware, add the following to your startup script. Use at your own risk!!.
Only tested with HyperWRT 2.1 b1.

echo 4096 > /proc/sys/net/ipv4/ip_conntrack_max
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
echo 512 > /proc/sys/net/ipv4/neigh/default/gc_thresh1
echo 2048 > /proc/sys/net/ipv4/neigh/default/gc_thresh2
echo 4096 > /proc/sys/net/ipv4/neigh/default/gc_thresh3
echo "600 1800 120 60 120 120 10 60 30 120" > /proc/sys/net/ipv4/ip_conntrack_tcp_timeouts
 

]]>
EXPLANATION:

300 600 120 60 120 120 10 60 30 120
NONE = 300 (5 minutes)
ESTABLISHED = 600 (10 minutes)
SYN_SENT = 120 (2 minutes)
SYN_RECV = 60 (60 seconds)
FIN_WAIT = 120 (2 minutes)
TIME_WAIT = 120 (2 minutes)
CLOSE = 10 (10 seconds)
CLOSE_WAIT = 60 (60 seconds)
LAST_ACK = 30 (30 seconds)
LISTEN = 120 (2 minutes)

I decided to search the Linksys forum for uTorrent and found this post:

»Utorrent and port xxx does not appear to be open fix

Under Linksys Administration, Account Management, you must DISABLE UPnP at bottom of page. Save and then retest under
Utorrent Options, SpeedGuide, test port forwarding. It will now come up GREEN.

Submited by koam