Tricks, tips, hacks (and other funky stuff) for your BT Voyager 205 router modem..

The main 205 page remains the spiritual centre of the Voyager 205 universe, of course, but this page has evolved as a place to drop all those neat wee tricks this router is capable of.

The BT Voyager 205 (or any Viking Chipset-based router) has some limits, and you probably wouldn't want to use the it as your gateway box for, say, a busy internet café, or medium business, but for the home/SOHO user looking for a capable free solution with a few tricks up its sleeve, the Voyager 205 is just the ticket. Here's some of the funky things you can do with it..
These tricks assume you have setup the router as described on the main page, and that you are comfortable working in a telnet session, although, for most of the tricks, I've provided Javascript buttons to open a windoid (or perhaps a tab) with the corresponding (generally hidden) web pages from the router's built-in webserver. Obviously you will need to have Javascript enabled in your browser to make use of these.

Have fun!

Dynamic DNS

If you run your own webserver, ftp server, host a radio show, or whatever, you've likely got yourself dynamic domain name where folk can always find you, regardless of your current IP. Very useful! If you happen to use the services of either DynDNS, or TZO, you're in luck! You can throw away your DUC and have the router do it all for you, automatically, every time you reconnect! Here's how.. first create the host entries (three maximum, sadly).. create ddns hostname ifname ppp-0 name my.ath.cx
create ddns hostname ifname ppp-0 name my.dyndns.org
create ddns hostname ifname ppp-0 name my.serveftp.org
then setup the service.. create ddns intf ifname ppp-0 srvcname dyndns username "username" passwd PaSSWoRD system dynamic wildcard enable The instant you enter that command, the router will login to DynDNS/TZO and update your dynamic host records. Now, whenever you reconnect to your ISP, or reboot the router (power-cycle), these records will be automatically syncronised with your real  IP. neat! You can check they are functioning as expected at any time in the future, in a telenet session, by doing..

get ddns intf  and  get ddns hostname

To be really sure, you can do delete ddns intf ifname ppp-0 and re-enter the service setup line from above. You should get an error telling you that the IP is unchanged. All systems go!

Once setup (and commited to the router's memory, by passing commit in a telnet session) you can completely forget about DDNS; it will always be current.

For a more graphical view, go to the DDNS web interface page..

To create a new DDNS entry, use this web page..

Custom DNS servers

Whenever you establish a new PPP connexion (with your ISP) the addresses of the current nameservers are given to the router as part of the handshake. Without nameservers, you can't translate cute domain names, like corz.org, into their correspoinding "real" addresses, ie. raw IP addresses. Nameservers, aka dns servers, are essential. I wax lyrical about them elsewhere onsite.

However, BT's nameservers are fairly lousy. Fortunately, the Voyager 205 allows us to use a custom pair. There's only space for two, but if you use good ones, two is all you need.

I use the handy, and very reliable plus.net nameservers. If you add priority statements to the commands, you can, theoretically, override the in-built BT nameservers altogether, like this..

create dns servaddr priority 0 212.159.11.150
create dns servaddr priority 1 212.159.13.150

The Priority 0 server is used first, and if it ever fails, dns requests will instead be sent to the second server. DNS servers always come in pairs, in case one fails. You may also want to enable DNS polling, to ensure you are always working with a live server, in this case, every five minutes..

modify dns relay cfg enable
modify dns relay cfg pollinterval 5


If you prefer the web interface, you can configure your custom DNS servers..  

Connectivity Tools

traceroute

You can run traceroutes from the router itself. It's easy. First create a rule to allow inbound traceroute packets..

create ipf rule entry ruleid 11 ifname public dir in transprot eq icmp icmptype eq num 11 act accept seclevel high medium low

then run the trace!

traceroute ping dname google.com

You can run either "ping" or "udp" traces, and they can be to a domain name (prefix with "dname"), or just the raw IP, for instance..

traceroute udp 216.239.39.99

You can use this tool from the web interface too, by clicking..  

Most useful for finding out why your isp or web host is so damn slow! The 205 will run your trace, over a maximum of thirty hops, and report the results live. This is an essential tool, though if you don't have a decent onboard traceroute (windows) you may prefer the faster tracing capabilities provided by a tool like Sam Spade.

ping

You can do regular pings, too, like this.. (both commands do exactly the same thing)

ping 216.239.39.99
ping dname google.com

The web interface version of the ping tool is  

custom logging

I haven't really messed around with this much, but there's certainly some nice possibilities. Briefly, the Voyager 205 router can send its event log output to a different host. What this means is, we can capture this output to a file, which may or not be useful.

All you need is a system running a log daemon, like syslogd, which is available on all unix/Linux/BSD/OS X/etc boxes, and probably exists for windows, too, or something like it. Logging may be enabled on your router, but just to make sure, enter this command..

modify fwl global logdest trace

To find out what can be logged, do..

get trace cfg

in a telnet session, you'll get back a BIG list of lines like this..

$get trace cfg
Module    Flow          Level         Type       Destn              Port
------------------------------------------------------------------------
ADET      0xffffffff    0x25f         Network    0.0.0.0            0
ALG       0xffffffff    0x25f         Network    0.0.0.0            0
ALPS      0xffffffff    0x25f         Network    0.0.0.0            0
ATM       0xffffffff    0x25f         Network    0.0.0.0            0
CDB       0xffffffff    0x25f         Network    0.0.0.0            0
CIN       0xffffffff    0x25f         Network    0.0.0.0            0
CLI       0xffffffff    0x25f         Network    0.0.0.0            0
DCL       0xffffffff    0x25f         Network    0.0.0.0            0
DDNS      0xffffffff    0x25f         Network    0.0.0.0            0
etc..

There are only a few event types that will be of much use to us, primarily, WALL and IPF. These are the only two I've played with, anyway. Here's a couple of router commands to get these two events sent to a logging daemon running on a (Linux) box at 192.168.1.100 ...

modify trace cfg module WALL flow 0x3 syslog dest 192.168.1.100 port 514
modify trace cfg module IPF flow 0x3 syslog dest 192.168.1.100 port 514

The "flow 0x3" switch is optional, I added it as interesting food for thought. Now, whenever a WALL (attack protection) or IPF (loads of stuff) event occurs, so long as the log daemon is listening (note: recent versions of syslogd must be started with the "-r" switch to achieve this) the incoming messages will be logged to the system logs, usually /var/log/messages and /var/log/syslog.

Unfortunately, there's no way to specify a destination file using the usual mechanisms of /etc/syslog.conf, something like WALL.* /var/log/router will just give an error, but there is a wee trick you can do. Add the following to the end of your /etc/syslog.conf..

local0.* /var/log/router

Now, assuming you don't have any other devices sending logging messages over the LAN, /var/log/router will contain only router messages. Sure, they will also appear in the system logs, but who reads these, anyway, thanks to Richard Pruen for pointing out that if you add something like this to your syslog.conf file..

#Log anything warn or higher
#Exclude stuff that is logged elsewhere
*.warn;authpriv.none;cron.none;mail.none;news.none;local0.none -/var/log/syslog

#Router logs from remote router
local0.* -/var/log/router

you no longer get double-logging. neat!

I'll likely fill in more details here when and if I get more time to play around with this, all feedback and findings most welcome in the meantime. For your convenience, a simple log of the recent attacks on your router, is

If you want to view all the blocked incoming connexions (the ones caught by your second stealth rule) you will need to add a logging parameter to that second stealth rule ..

create ipf rule entry ruleid 500000 ifname public dir in act deny log enable seclevel high medium low

Then this is the sort of thing you can expect to see in your actual log..

Mar 14 23:09:35 router WALL;8;55747;Port Scan Detected,Type: ICMP Scan,Src:207.033.111.***,Dst:081.132.075.***,Prot:TCP ,Intf: ppp-0,ScanCnt:0
Mar 14 23:09:59 router WALL;8;55770;FWL Violation,Type, SYN DOS,207.033.111.***->081.132.075.***,Prot:TCP ,SPort: 81,DPort:8080 ,Intf: ppp-0,VltCnt:0,SessDeleted:85
Mar 14 23:17:17 router WALL;8;56208;Port Scan Detected,Type:TCP Session scan,Src:192.168.001.***,Dst:192.168.001.***,Prot:TCP ,DPort:25 ,Intf:(null),ScanCnt:999
Mar 14 23:22:52 router WALL;8;56543;Port Scan Detected,Type: ACK scan,Src:192.168.001.***,Dst:024.000.234.***,Prot:TCP ,DPort:1253 ,Intf: eth-0,ScanCnt:482
Mar 14 23:24:04 router WALL;8;56615;IPF Rule Matched,Type: ,RuleId:500000 ,081.132.207.***->081.132.075.***,Prot:TCP ,SPort: 3562,DPort:135 ,Len:48 ,Intf: ppp-0,Act:DENY ,VltCnt:632
Mar 14 23:33:11 router WALL;8;57162;Port Scan Detected,Type: RST scan,Src:082.041.218.***,Dst:081.132.075.2***1,Prot:TCP ,DPort:49900,Intf: ppp-0,ScanCnt:2
Mar 14 23:47:58 router WALL;8;58049;Port Scan Detected,Type:TCP Session scan,Src:192.168.001.***,Dst:192.168.001.***,Prot:TCP ,DPort:25 ,Intf:(null),ScanCnt:541
Mar 14 23:53:02 router WALL;8;58354;Port Scan Detected,Type: ACK scan,Src:192.168.001.***,Dst:082.182.097.***,Prot:TCP ,DPort:6881 ,Intf: eth-0,ScanCnt:78
Mar 14 23:54:19 router WALL;8;58430;IPF Rule Matched,Type: ,RuleId:500000 ,081.132.015.***->081.132.075.***,Prot:TCP ,SPort: 1883,DPort:445 ,Len:48 ,Intf: ppp-0,Act:DENY ,VltCnt:141

Except with the full IP addresses, of course, and without the confusing word-wrap! If you find any of the other useful router events worth logging (just what is KRON? for instance), then let me know!

One computer has admin access..

As well as creating a solid username/password combination, there is another way to restrict access to the router's administration features, even on your own LAN.

By default, any machine on your LAN can access the web interface, telnet, FTP, etc, which we call "management access". Usually this is only available on the LAN side, but you can also allow WAN (internet) access to these features, which are configured What most folk don't realize ( even though the button is fairly obvious, it took me weeks to spot it! ) is that if you go to , you can also specificy which IP's  get access to the management features. cool! As well as being a neat way to ensure you have exclusive admin access to the router at your home/office/whatever, it makes secure WAN-side remote administration perfectly feasible.

That's all there is to it, you can add up to three separate IP addresses and, of course, you can do all this from a telnet session..

create mctl iplist ip 192.168.1.4

important: the instant you add an IP address to the management control table, management access from all other IP's will cease immediately! telnet sessions will die, web interfaces will fail. It would be wise, then, to apply this setting from the machine who's IP address you are entering.

note: this in no way affects the ability of the other computers on your LAN to access the internet, only the management features of the router are restricted.

Switch ISP..
(but keep your BT Voyager!)

To switch ISP..

• Disconnect the phone line (maybe for a half hour while it "migrates")
  
• Enter the new user/pass right here
  
• Reconnect the phone line, and login!

That's all there is to it.

zipb mode..
(aka. "The Mysterious zipb mode")

zipb mode, (aka. "ZIPB mode", aka. "half bridge mode") is how you turn your super-dooper NAT-enabled, firewall-protected voyager viking router into "just a modem".

With zipb mode you can put a local device directly onto the internet, be it a computer, another router, WiFi Base station, whatever, the voyager will effectively become invisible (at least from the outside), you even get to keep the firewall.

The manual says..

Advantages of the ZIPB mode.

• does not require you to install any software on subscriber PCs [nor does regular ethernet use -ed]
• does not require you to run NAT on the modem
• allows you to manage modem for both LAN and WAN sides, because the modem has an IP address on both LAN as well as WAN interfaces.
• allows you to run Firewall/filtering feature on the modem.
• allows you to use bandwidth efficient PPPoA, on the modem's WAN interface.
• the LAN-side device gets the PPP IP address allocated to the modem using DHCP.

For many, the main advantage of zipb mode is that you get to bypass the Voyager's NAT, and therefore bypass its limit of 511/512 simultaneous connexions which is too small for certain applications. Whether or not this is actually the case, the jury's still out.

Big thanks go to the zipb pioneers.. radiac, Harlander, will and others I've probably forgotten.
Check the (many many) comments on the main page for all the gory details.

Useful sources of information..

The Voyager's built-in help page has a useful step by step guide to setting up ZIPB mode at bottom.

The zipb mode system admin page is ..

https://corz.org/public/docs/comms/router/BT.Voyager.205.ref.guide.pdf

To set up zipb mode, follow these steps..

1. Ensure the Voyager's DHCP server is enabled..

The external IP is given to the Voyager and then passed on to your device via DHCP, so the Voyager must have its DHCP server enabled. Ensure there is an active DHCP server pool with poolid=0, with at least one free local IP for your device.


you may prefer to specify a smaller pool, or a shorter lease time..


Whatever, so long as it works. Now switch the DHCP server on..


This page will state the DHCP Mode as "DHCP Server".

2. Disable NAT

In a telnet session, do..

3. Enable ZIPB mode

The zipb mode admin page will correctly state whether or not zipb mode is enabled, but setting it there doesn't seem to "stick", so in a telnet session, do..

4. Set the PPP interface to "StartOnData"

This will bring up the ppp interface as soon as it detects DHCP requests on the local ethernet. This is generally set when you create the ppp-0 interface, but you can set it separately, just in case..

5. Save settings

The important bit that lots of folk forget. In a telnet session, do..

6. Finally, ensure your device is set to be a DHCP client

The router will dynamically assign the device your external IP address, so you need a DHCP client running on that device. If it's a computer running XP, simply open the properties for your local connection (TCP/IP Properties) and set it to "Obtain an IP address automatically". If it's a router or similar, tell it to "get IP address via DHCP" or some similarly worded option.

You can probably set the machine's alternative IP address to your some static LAN IP address, something like 192.168.1.3

That's it!

If all goes to plan, your device should have been assigned a fresh IP from your ISP's pool, and you are live on the internet, bypassing the voyager's NAT altogether.

If you fancy experimenting with zipb mode, you might find these zipb ON and zipb OFF shell scripts of some use.

real-life zipb setups..

There are a number of ways you can utilise this facility, and what follows are some real-life setups which may provide useful information. hopefully we'll expand these as we go along..

Linux box with two NIC's, acting as NAT and router (by radiac - thanks!)..

Now, my setup. I have a linux server and (for various reasons which I won't bother going into here) I want it to sit on the outside of my network with my external IP, and provide NAT access for my other machines. It has two NICs, one for my LAN and one for my Voyager 205, in the arrangement LAN - eth0:Server:eth1 - Voyager 205. eth0 is the network 10.0.0.0, and eth1 is 10.0.1.0. My Voyager has the IP 10.0.1.1.

The local IP is given to the server if the external IP is not currently available. My personal options are: Start: 10.0.1.3, End: 10.0.1.254, Gateway: 10.0.1.1.

I believe there's a way to plug your voyager into your hub/switch and give one specific machine your external IP and all your other machines local IPs, but since my server has two NICs this wasn't an issue.

To test it, I plugged the Voyager into a Windows XP machine to see what would happen, and, after persuading it to request a new IP address, it worked perfectly. The Voyager sent the external IP (81.x.x.x), the ISP gateway (195.x.x.x) and a subnet mask (255.0.0.0). Although the ISP gateway was outside the network of the interface, Windows didn't seem to care, and the machine was out on the internet.

After rebooting the Voyager to make it forget it had given the external IP to a different MAC address, I swapped the cable over to my linux server, and when I brought up the interface it was given the right IP. However, Linux seems to be a bit more particular about its routing rules, and refused to route out to the ISP gateway. This left me with no routing rules to the internet. Adding a new default route to the interface worked fine though, with the command on my server:

route add default eth1

and I added that to the post-up of the interface definition so it should work next time.

As expected, traceroute into the server does not show the Voyager, although traceroute out does, and the Voyager intercepts traffic destined for its network and is available at 10.0.1.1 from inside my LAN.

It has been working fine now for most of the past couple of weeks. However, when there was a power cut the system didn't come back up properly - the external IP address was not passed to the server correctly, so I had to restart the interface to re-request it. I have not had time to test it again since, but if I find it's repeatable and can find the cause and/or solution, I will post an update here.

Alternatively..

You may find the whole thing unworkable, in which case, try this, from vof..

Interestingly, I too have a Linksys router - a BEFW11S4 - and a Netgear DM602 which is a 205 in a posh frock. I tried for ages to get the pair to work with the DM602 in zipb mode and failed miserably. In the end, I ran the DM602 in normal router mode and just connected it normally to my Linksys' WAN port. When you do this, the Linksys WAN port and the modem ethernet port actually have to be on their own network (subnet).

In my case, I decided it would be 192.168.0.something with a netmask of 255.255.255.0 (technically known as 192.168.0.0/24). The modem ethernet port is 192.168.0.1, the Linksys WAN port is configured to request an IP address (from the modem's DHCP pool), in my case usually 192.168.0.50. As part of the DHCP, the Linksys gets told what its default gateway - essential for internet access to work - is (192.168.0.1 = the modem ethernet port). They thus can talk to each other nicely.

Of course the modem WAN port gets an IP address from the ISP. Now on the LAN side of the Linksys is a completely different network - I chose 192.168.1.0/24 (note the one not zero in there!) whereas you have chosen 10.0.0.0 with a netmask of 255.0.0.0 (i.e. 10.0.0.0/8) which should work just as well. The experts - I'm not one! - tell me my configuration is possibly risky because both the Linksys and the modem are doing NAT, and double-NATting is frowned upon, but it works for me so I'm ignorant but happy.

If you've followed all that, you should be able to get the 205 working with your Linksys, but I suspect you'll need to forego zipb mode on the 205.

vof


Finally..

If you come across some other funky Viking trick, don't forget to tell us about it on the main Voyager 205 page, someone might be looking for exactly your hack!

have fun!

;o) corz.org