Port Forwarding
Recipes for the BT Voyager 205 adsl router modem

The main 205 page has lots of this info in it, but higgeldy-piggeldy, weaved into the whole story, as it were. So this page exists to provide you with a few ready-made solutions. I do recommend reading that document, though, especially the comments section at the foot.

The recipes should work for all the viking based routers; BT Voyager 205, of course, CastleNet AR502, Dynalink RTA100, RTA500-D51, GlobespanVirata, Netgear DM602, Solwise SAR100 & SAR130 and probably many others.

These recipes assume you have Stealthed your router. If not, go do that now. They also assume you have removed all other firewalls from the data path, especially the Windows® XP's built-in firewall, which lives inside the properties for the "Local Area Connection" (advanced tab).

So far we have recipes for BitTorrent (especially Azureus), eMule, WinMX, Direct Connect, Gnutella (Limewire, BearShare, Morpheus, etc), thewire, and a webserver, FTP server, plus a few generic rules you can alter to suit your specific needs. (to be continued) ..

If you hit a snag, you'll probably want to run some tests. I put together a simple tcp port probe which might help you. it doubles up as a handy "what is my IP" page, too. fire away!

note: in every recipe, replace the private address (the one that begins 192.168.) with the real private address of the computer running the server/p2p application. If your computer doesn't have a static IP address, give it one! On Windows®, that information is here..

control panel >> Network Connections >> Local Area Connection >> Properties >> TCP/IP >> Properties

*phew*. for more details, see here.

also note, all the telnet commands on this page are entered on one single line, even if they may appear split into two here in your browser.

BitTorrent

I'll start with the popular, and incredibly speedy BitTorrent protocol. BitTorrent can use any port at all (although using ports below 1024 would require you to run the client with "root" privileges, not smart).

single bittorrent machine using standard ports..

firewall:
create ipf rule entry ruleid 6881 ifname public dir in act accept transprot eq tcp destport range 6881 6889 seclevel high medium low nat:create nat rule entry ruleid 6881 rdr lcladdrfrom 192.168.1.3 lcladdrto 192.168.1.3 destportfrom num 6881 destportto num 6889

If your desktop machine lives at some other address, simply alter the IP to suit. perhaps 192.168.1.4, or whatever.

When you're done, you'll see something like this (at least if you're using BitTornado on a peecee)..

All Systems GO!

A green light means you are happily accepting connexions on your active BitTorrent port. If your client has peer statistics, you should see "remote" connections, usually an "r" next to the peer's address. If you don't see green lights or "r" connexions, wait a while; maybe no one's attempted to connect to you.

If you continually and consistently don't see them with different torrents from different trackers, you must have another firewall somewhere. run some tests. I've heard that certain unscrupulous ISP's block BitTorrent's default ports, so..

single bittorrent machine using custom ports..

firewall:
create ipf rule entry ruleid 49200 ifname public dir in act accept transprot eq tcp destport range 49200 49209 seclevel high medium low

nat:create nat rule entry ruleid 49200 rdr lcladdrfrom 192.168.1.3 lcladdrto 192.168.1.3 destportfrom num 49200 destportto num 49209

Each active torrent uses only one port, so in reality you only need a small range, and that range can be anywhere between 1024 and 65535. Use the above as a template for your own favourite batch of numbers. Remember to set the same range in the preferences of your BitTorrent client software. I recommend 54321; it's easy to remember.

multiple bittorrent machines using standard ports..

In this example, torrent traffic is split between three separate computers. In each of the bittorrent clients running on the computers at IP's 192.168.1.3, 192.168.1.4 and 192.168.1.5, the port range in the preferences will be set for 6881-6885, 6886-6888, and 6889-6893, respectively.

firewall:
create ipf rule entry ruleid 6881 ifname public dir in act accept transprot eq tcp destport range 6881 6899 seclevel high medium low

nat:create nat rule entry ruleid 6881 rdr prot tcp lcladdrfrom 192.168.1.3 lcladdrto 192.168.1.3 destportfrom num 6881 destportto num 6885 create nat rule entry ruleid 6886 rdr prot tcp lcladdrfrom 192.168.1.4 lcladdrto 192.168.1.4 destportfrom num 6886 destportto num 6888 create nat rule entry ruleid 6889 rdr lcladdrfrom 192.168.1.5 lcladdrto 192.168.1.5 destportfrom num 6889 destportto num 6893

Remember you only need one port per torrent. in this example each machine could run five, three, and five torrent each. (the middle machine at 192.168.1.4 is slow, so it only gets to run three torrents at a time!) Mix it up to your requirements, using the real IP's of your own computers, of course.

Azureus (advanced BitTorrent client)

For a start, Azureus cleverly uses one port for all its activity, which simplifies the creation of NAT rules, and is good. Another thing, it can use UDP to aid tracker communication, which complicates the creation of firewall rules, but it's still good!

If you're serious about torrenteering, give Azureus a try, being "queue-based", you can seed-while-you-leech, all in one handy tabbed application. It won't get in your way while you're working, and might stop you being such a hit-and-run merchant! yeah you! lol

In this example, Azureus is running on my Linux box at IP address 192.168.1.100, using port 49210..

firewall:
create ipf rule entry ruleid 49210 ifname public dir in act accept transprot eq tcp destport eq num 49210 seclevel high medium low create ipf rule entry ruleid 49211 ifname public dir in act accept transprot eq udp destport eq num 49210 seclevel high medium low
nat:create nat rule entry ruleid 49210 rdr lcladdrfrom 192.168.1.100 lcladdrto 192.168.1.100 destportfrom num 49210 destportto num 49210

If you're really serious about your torrenteering, you might consider setting up a linux box just to run Azureus, then your seeding is truly a background task. Linux is good, before you know it you'll be running Apache! w00!

Because Linux, like OS X, BSD, (insert all operating systems except windows) doesn't crash and need rebooting every (insert timescale), you can run your torrent queue in perpetuality, completed files dropping off every so often. Coolness. An old £50 Intel box would do the job. You could call it "The Torrent Machine". lol

Addedattheendum: The above rules will also work just fine for µTorrent, which is, in my opinion, the best Windows bittorrent client out there, by a mile. It's small, both in physical size and memory footprint, comprehensive (most things Azzy can do µTorrent can do), and is under continual development - those cutting edge releases are always worth a download. Highly recommended.

eMule

eMule is the excellent successor to eDonkey, with a bright, intuitive GUI, and very large and growing peer network.

As well as connecting to the vast ED2K network, eMule is a KAD client, which is an interesting peer-to-peer network, but something of a strain on many connexion-starved windows machines, and many eMule users disable it altogether, but so long as you keep your maximum connexions within your maximum limit (even half that) KAD works great.

eMule uses one TCP and one UDP port.

Here's the router rules you need to get that two-green-arrow feeling in eMule..

firewall:
create ipf rule entry ruleid 4662 ifname public dir in act accept transprot eq tcp destport eq num 4662 seclevel high medium low create ipf rule entry ruleid 4672 ifname public dir in act accept transprot eq udp destport eq num 4672 seclevel high medium low

nat:
create nat rule entry ruleid 4662 rdr lcladdrfrom 192.168.1.3 lcladdrto 192.168.1.3 destportfrom num 4662 destportto num 4662 create nat rule entry ruleid 4672 rdr lcladdrfrom 192.168.1.3 lcladdrto 192.168.1.3 destportfrom num 4672 destportto num 4672

And you'll see this..

Don't forget to set your maximum connexions to something less than 512 (assuming you have applied the maximum connexions tweak, otherwise 192 is your limit)..

WinMX

WinMX is popular for music downloads, and has a nice installer that runs tests on your ports during the install. this a great idea, ensuring you are setup before you start the application. The UDP test seems to be shakey, as UDP tests often are, and you may just want to bypass it altogether by chosing "manual", but leaving the ports exactly as they are.

Here's the telnet commands you need to get WinMX behaving..

firewall:
create ipf rule entry ruleid 6699 ifname public dir in act accept transprot eq tcp destport eq num 6699 seclevel high medium low create ipf rule entry ruleid 6257 ifname public dir in act accept transprot eq udp destport eq num 6257 seclevel high medium low

nat:
create nat rule entry ruleid 6699 rdr lcladdrfrom 192.168.1.3 lcladdrto 192.168.1.3 destportfrom num 6699 destportto num 6699 create nat rule entry ruleid 6257 rdr lcladdrfrom 192.168.1.3 lcladdrto 192.168.1.3 destportfrom num 6257 destportto num 6257

You should now have a green light in your connexion status, super-fast searches, and blazing downloads (I don't use WinMX much, but all my tests have shown it to very fast.)

Direct Connect

Direct Connect is worth a look if you prefer a more community-orientated sharing network, ideal for school or university campus filesharing. Direct Connect uses a small range of ports..

firewall:
create ipf rule entry ruleid 411 ifname public dir in act accept transprot eq tcp destport range 411 413 seclevel high medium low

nat:
create nat rule entry ruleid 411 rdr lcladdrfrom 192.168.1.3 lcladdrto 192.168.1.3 destportfrom num 411 destportto num 413

Gnutella

ie. Gnutella, Morpheus, LimeWire, BearShare, etc

Gnutella is generic p2p protocol used by many p2p clients, though in my not so humble opinion, the worst of the bunch, though efforts are being made to clean up the network. If you do use it, open its ports (including optional UDP port which some clients also use) like this..

firewall:
create ipf rule entry ruleid 6346 ifname public dir in act accept transprot eq num 6 destport eq num 6346 seclevel high medium low create ipf rule entry ruleid 6347 ifname public dir in act accept transprot eq num 17 destport eq num 6346 seclevel high medium low

nat:
create nat rule entry ruleid 6346 rdr lcladdrfrom 192.168.1.3 lcladdrto 192.168.1.3 destportfrom num 6346 destportto num 6346

the±wire

the±wire is my own wee communication application, use it to chat, share files, run slideshows for people at the other side of the classroom/LAN/world. Has some interesting bugs, but a cool app in many ways, with some truly unique features.

firewall:
create ipf rule entry ruleid 2769 ifname public dir in act accept transprot eq tcp destport eq num 2769 seclevel high medium low

nat:
create nat rule entry ruleid 2769 rdr lcladdrfrom 192.168.1.3 lcladdrto 192.168.1.3 destportfrom num 2769 destportto num 2769

Unless you allow incoming connexions, no one can wire you! though you could still wire someone else. Also file transfers would fail, especially because, with the±wire, the process of sending a file to someone is actually sending a message that you have a file available and opening a server for them to grab the file from you. This has security benefits, of course, but needs a "clear path" if it is to work as expected.

This is also a good generic rule for any tcp communication device, just alter the ports to match whatever you need.

home webserver

With modern fast connexions, there's nothing to stop you running a webserver at home! True, in addition to setting up the router, there are a few other skills to master; apache configuration, webserver security, etc, etc, but it's definitely a worthwhile endevour, especially if you have a cool dynamic DNS so folks (and search engines) can always find you.

This example is for a standard webserver running on a machine at IP 192.168.1.3, using regular www port 80..

firewall:
create ipf rule entry ruleid 808 ifname public dir in act accept transprot eq tcp destport eq num 80 seclevel high medium low

nat:
create nat rule entry ruleid 808 rdr prot tcp lcladdrfrom 192.168.1.3 lcladdrto 192.168.1.3 destportfrom num 80 destportto num 80

I've used id 808 instead of 80 because id 80 is one of the router's built-in rules, and power-cycling the unit would destoy your firewall rule. so 808 it is.

8080

You may, for one reason or another, run your webserver on port 8080, but you'd still like requests to come via the standard www port 80, no problem, just alter the NAT rule slightly..

create nat rule entry ruleid 8080 rdr prot tcp destportfrom num 80 destportto num 80 lcladdrfrom 192.168.1.3 lcladdrto 192.168.1.3 lclport num 8080

It's fairly flexible, check out the PDF's in the public archives for details on all the crazy stuff you can do with NAT!

Of course, when you try to test your web server, you get the router's home page! Why? Simply; you are not "outside", and as far as I know, this router has no "loopback" facility. Stuck? No..

You can test your webserver from "outside", by simply browsing via a proxy! Clever huh! If you don't know what a proxy is, a) consider whether you really should be running a live internet webserver, and b) Google for free proxy servers.

Another trick is to hack your dynamic hostname into your local hosts file, which works well, and you can still go via a proxy if you need that "from outside" experience. For this sort of fun, and more, you might want to take a look at this part of the site.

For other types of servers, ftp, etc., it's trickier. There are fewer proxies that will accept non-web traffic, though they certainly do exist. It generally much easier to use some local (fake) host name for connecting frm inside your LAN. Check out the above link for links to more details. By far the best method of testing the remote connectivity of any server is to borrow someone's remote desktop and login. Few have access to such luxuries, though. ;o)

FTP server (FTPd)

First, although FTP (usually) uses port 21 for the transaction, it also uses another port, for the data, usually port 20, and although not technically necessary, when port 20 is opened, things certainly run smoother. For a regular FTP server, running on a machine at IP address 192.168.1.3, this would work fine..

create ipf rule entry ruleid 2121 ifname public dir in act accept transprot eq tcp destport range 20 21 seclevel high medium low create nat rule entry ruleid 2121 rdr lcladdrfrom 192.168.1.3 lcladdrto 192.168.1.3 destportfrom num 20 destportto num 21

As you can see, I've used a range of port, albeit a very small range (only two ports). Note that I don't use ruleid 21 (as one would expect) because if you ever reboot the router, it will be deleted automatically! Same story for ruleid 80, almost like BT didn't want us running servers at home!

If you want to accept "passive" connexions (as opposed to "active" (aka. "PORT", very confusing!) a very good idea), you will need to define a range of ports in your server software. In bulletproof, this is in the global preferences, folks running ProFTPd can simply add a line to their <global> section..

PassivePorts 50000 50100

Now the server will instruct the client to initiate passive connexions on any port from 50000 - 50100. All we need to do now is open this same range in the router...

create ipf rule entry ruleid 50000 ifname public dir in act accept transprot eq tcp destport range 50000 50100 seclevel high medium low create nat rule entry ruleid 50000 rdr lcladdrfrom 192.168.1.3 lcladdrto 192.168.1.3 destportfrom num 50000 destportto num 50100

And Bob's yer uncle! Your server will now happily accept active OR passive connexions.

generic rules

Here are some generic rules you can use for pretty much anything. Simply alter the port numbers and IP addresses to match what you need for your game/p2p app/server/whatever. Copy the rules into a blank notepad and alter whichever parts you need, then paste them into your router telnet session.

All port forwarding rules have two parts, the first, a firewall rule to allow the incoming traffic, the second, a NAT rule to route that traffic to a particular machine.

We'll start with a basic one-port rule. This example would allow incoming traffic on port 1024 and route it to a machine at 192.168.1.3

single port rules

firewall:
create ipf rule entry ruleid 1024 ifname public dir in act accept transprot eq tcp destport eq num 1024 seclevel high medium low
nat:
create nat rule entry ruleid 1024 rdr lcladdrfrom 192.168.1.3 lcladdrto 192.168.1.3 destportfrom num 1024 destportto num 1024

That was easy! If you need UDP instead of TCP, simply alter "transprot eq tcp" to "transprot eq udp".

port ranges

Now we'll create a ruleset to allow a range of ports, this is also easy. In this example, all ports from 1024 - 2048 will be forwarded to the device at 192.168.1.3

firewall:
create ipf rule entry ruleid 1024 ifname public dir in act accept transprot eq tcp destport range 1024 2048 seclevel high medium low

nat:
create nat rule entry ruleid 1024 rdr lcladdrfrom 192.168.1.3 lcladdrto 192.168.1.3 destportfrom num 1024 destportto num 2048

That's it! Using these generic rules as your "base", you can create any rule whatsoever.

udp note: we don't specify the protocol (tcp/udp) for the nat rules. It's usually best to ommit this and allow the nat to route all types of traffic. Simply add a firewall rule for each protocol you wish to allow.

Testing your router rules

If your p2p app isn't working as you expect, there's only one way to find out if your router rules are working, and that's to run some tests! Ideally you want to open a connexion from outside your LAN, to a machine inside your LAN, replicating the real-world situation we are trying to configure for. Understandably, this is tricky to do from inside your LAN; as far as I know, most routers don't have any kind of loopback facility. This is where grc comes in.

As well as the famous "ShieldsUP!" firewall test, grc now offers user-selectable custom port scan, which is exactly what we need to test our incoming connexion capabilities. Reading any actual text on grc.com is probably a bad idea, but the probe tools are real handy. To use..

Start up the application you want to test. If it's a torrent, check which port it's using for incoming connexions (in the "advanced" page if you have one in your client, or by doing a netstat or some other app(lication) that can display your listening ports), or else follow the other application rules (above) to determine which port you need to test.

enter the port number into the text input between the two silver bars for the "User specified custom probe" and scan! Ideally it will show "open!" Failed! Although in our case of course, it's a success!

Success!!
open_port_success

With no p2p apps/torrents running, and no nat rules created, the grc scan will show these ports not as stealthed (because we have created firewall rules allowing these connexions), but as "closed" (which, techncally, means "Connection Refused", this is a secure state). The router is responding in this case. Adding NAT rules will still give us a "closed", except now it is the private computer that is responding that the port is "closed", or possibly "stealthed" if you are also running a local firewall on your personal computer (that's what "pc" stands for, by the way, many folks don't realize that!)

But the instant you start up your p2p application, or fire up your torrent, you have a "listening" server on that port, awaiting inbound connexions, and the grc scan will show the port as "Open". my own port probe will report "success!!". Unless you get "Open" or "success!!", you've no chance of getting your p2p application to act as a server, and especially with BitTorrent, this is essential if you want to achieve anything like the full download capabilities of the protocol.

tip: If your ports test as "Closed" with no NAT rules in place, but suddenly become "Stealth" the moment you add a NAT rule, then your computer itself must be doing the firewalling, possibly the Operating System's built-in firewall. Windows XP has one built-in, as does Mac OS X (pronouned "Ten") and most other modern OS. If it's running, ensure you have punched a hole through it by creating a rule for whatever ports you need, or simply switch it off! Test again.

The grc custom scan is a useful tool. Use it! my own p2p port probe is a bit handy, too.

that's it!

If things still aren't working out for you, you might want to run through the troubleshooter page. Most of the common FAQ's are there. If you like, you can leave feedback at the main Voyager 205 page. many have. If you have a question, it may already have been asked, and answered. the comments are a good read anyhow.

If you fancy saving yourself some configuration headaches, chances are one of the "ready made" router configuration files would do it all for you. Check them out here. Full instructions on that page, and within the archives themselves.

Better yet, download and install ARSE, which turns the whole lot into a few clicks.

have fun!

;o) corz.org