how-to block ads
|
| | | | FAQ Revisions | Editors: Lanik  , sortofageek
Last modified on 2008-10-13 00:11:41
| |
|
|
1.5 Filesharing·Practically Networked Web Site Links
·Why is FTP so unpredictable behind my router?
·Why not to forward lots of ports (Port forwarding/Loopback bug)
·My email doesn't send or very slow, what's wrong?
·Why are Yahoo/MSN IM's dropped after 10 minutes?
·Why doesn't AIM work through the router?
·My P2P file transfers are slow or hang, why?
·uTorrent port forwarding doesn't work how do I fix it?
| | | 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.
 feedback form
 feedback form
by lev edited by Lanik
last modified: 2005-06-22 00:17:52 | | | 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.
feedback form
feedback form
by Bill_MI edited by Lanik
last modified: 2005-06-22 00:18:07 | | | 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 form
feedback form
by lev edited by Lanik
last modified: 2005-06-22 00:18:39 | | | Go to Triggering Page (assuming your router is 192.168.1.1 if not adjust URL accordingly)
Trigger port range 25 - 25
Incoming port range 113 - 113
Give at any name you like.
feedback form
feedback form
by Lanik
last modified: 2005-06-22 00:18:51 | | | Lots of people are seeing disconnects from Yahoo and MSN instant messengers after 10 minutes of inactivity. I started noticing this after replacing a Netgear RT314 with a Linksys BEFW11S4.
See this forum thread.
feedback form
feedback form
by invalidname edited by Lanik
last modified: 2005-06-22 00:19:01 | | | A lot of people been having problem with AIM Direct Connect and/or file transfer. Unfortunately AIM isn't NAT friendly at all. When your computer sends a request for a file transfer or direct connect through the router it goes through the AIM server. AIM will report your LAN IP or 192.168.1.xxx, or whatever it happens to be, instead of the WAN IP to the other party you're connecting to. Now when AIM tries to connect to that IP of course the connection can't be made since the public address space isn't reachable from outside. Now what it should be doing is reporting your WAN IP and the port number that's associated with your PC you're on. There is nothing that Linksys can do the change this behavior unless AIM fixes the problem and makes their software NAT friendly. Some people have had mixed results with Trillian, if Direct Connect and file transfer is vital I suggest you try this software out.
Here is a thread that has more detailed information on the problem: Technical details about AIM file transfer.
UPDATE: AIM file transfer might be fixed. For those who are having trouble check out this thread it might be of some help.
feedback form
feedback form
by Lanik
last modified: 2005-06-22 00:19:19 | | | 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.
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)
feedback form
feedback form
by Lanik
last modified: 2005-09-04 13:57:53 | | | 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
feedback form
feedback form
by Lanik
last modified: 2008-08-01 10:24:05 |
|
