The independent technical support site for all things networking!

VPN Server

January 30th, 2011 by Kieran in Articles

So you’ve got a well secured LAN but want to work on “local things” while out on the road. What do you do? Get a home VPN! This is surprisingly easy to get configured, especially given that your average Windows machine will have all the software you need to connect to a VPN by default.

Getting Started

So, first things first, to get started you need:

  • Linux box that is always on
  • A static IP or domain name that tracks your dynamic IP

We’re going to assuming you’re running Debian Linux at home and thus these instructions will also cover Deibian-like distributions such as Ubuntu. Please note that all commands and actions are to be carried out as root

Install and configure PPTPD

Firstly, install the PPTP VPN server

apt-get install pptpd

Once installed, we need to modify the configuration files

nano /etc/pptpd.conf

Then ensure that the following is present in the file. Some entries may be present already, some may be missing, or some may be present but not the same as below. Be sure to change the file carefully.

# Options path
option /etc/ppp/pptpd-options
# Relay
bcrelay eth0
# IP addresses

This configuration makes use of the following assumptions

  • Your router has IP and that your LAN uses IPs in the range
  • Your always on home Linux server has IP
  • That IP address has not being allocated out to a machine on your LAN

This configuration, withstanding these assumptions, will provide the connecting VPN user with an IP of, thus giving them a LAN-like presence on your network.

Configure PPP

Now edit the following config file

nano /etc/ppp/pptpd-options

Then ensure that the following is present in the file. Some entries may be present already, some may be missing, or some may be present but not the same as below. Be sure to change the file carefully.

# Authentication name
name pptpd
# Encryption
# DNS servers
# Routing
# Compression
# MTU and MRU settings
mtu 1500
mru 1500

Ensure correct MTU

If you plan on connecting to your VPN from Windows XP, or you think you might ever want to do this, you’ll want to tweak the MTU that is doled out to VPN clients.

When a PPP link is setup, pppd allows the client to request it’s own MTU. This is all well and good except where the MTU your client chooses is completely unsuitable and causes some websites, particularly those using SSL, to not load at all.

With this in mind, we force a fixed MTU, irrespective of client choice. This will ensure all normal client connections will have full connectivity.

nano /etc/ppp/ip-up

Then ensure the follwing lines are added, after export PATH, near the top of the file

ifconfig $1 mtu 1500
ifconfig $1 mru 1500

Configure Login Details

In order to login to your VPN remotely, you’ll want to configure a permitted user. Do this by editing the following file

nano /etc/ppp/chap-secrets

Into this file, place a user who can gain access, obviously don’t use “password” as the password!

# Secrets for authentication using CHAP
# client server secret IP addresses
user pptpd password *

Permit Forwarding

Packet forwarding must be enabled in order to pass VPN traffic between the connected client, the VPN server and the outside world. We enable this by modifying the following file

nano /etc/sysctl.conf

Into this file, ensure the following variable is set


Restart PPTPD

We need to pick up our settings so we restart the PPTPD service

/etc/init.d/pptpd restart

Restart the Server

Due to the fact we modified sysctl.conf we need to restart the whole server too. Issue the following command as root.


Firewall Settings

That’s about it for server configuration but if you want to connect to your VPN server from outside the LAN you’ll need to make sure that the appropriate ports are open to the outside world.

Incoming, TCP, 1723, forward to
Incoming, GRE, Protocol 47, forward to

Consult your router manual for specifics on how to do this or ask in our forums stating your router model.


You can test your server by attempting a connection from a Windows machine. Set up a VPN connection from the network wizard, use the IP address of your server,, and the username and password you set in chap-secrets. You should be able to access the internet as normal once connected and also machines on your LAN.

In Use

In reality you won’t want to connect using as this is an internal IP accessible only on your LAN. You’ll want to port forward to this IP from your WAN IP as per the firewall rules mentioned above and use your WAN side IP in the networking wizard to connect.

If you don’t have a static WAN IP then you can use a service like DynDNS to provide a fixed domain name that always points to your dynamic IP.

Happy VPN’ing!

We’re sure these settings will work for you but if you encounter any issues, please head over to the networking area of our forum and ask one of the experts.

RouterTech Firmware 2.92

January 10th, 2010 by Kieran in Announcements

With over 25 new features and bug fixes, the RouterTech team is proud to announce the release of version 2.92 of it’s firmware. Details of all changes and fixes are shown in the list below.

1. New shell script: (wireless firmwares only) – restarts the wireless access point.

2. Busybox “sync” has been replaced with a stand-alone sync utility (wireless firmwares only).

3. Fixed a display issue with the printenv command (problem with printing newlines).

4. Fixed a display issue for pppoe on the Status menu.

5. Following a poll on the forum, the bwbasic interpreter has been removed.

6. Following a poll and other discussions on the forum, the default DSP driver for the standard firmwares has been set to dsp75.

7. New feature: udpxy added to the wireless firmwares. The program allows you to relay multicast UDP traffic to a client’s TCP (HTTP) connection (unicast). This allows you to use IP TV (UDP multicast) services via wifi. Example: “udpxy -m br1 -p 88 -S”
where: m – interface (LAN group) where the IP-TV bridge connection added.
-p – the port to listen on… here, it is port 88
-S – enable the bandwidth statistics. The status page is available at (router ip and 88 port from the -p 88 option). Also the -B option can be used to setup udpxy’s cache size, e.g: “udpxy -m br1 -p 88 -B 1024K -S”
After this you can use the IP-TV as unicast by ethernet and wi-fi, for example if the udp multicast url is udp://@ – you can access it as

8. The darkstat feature has been removed from the firmwares for routers with 2mb flash.

9. The rt_commands.html file has been removed from the binary firmwares.

10. Busybox has been upgraded to v1.15.3.

11. New shell script: – to start the firmware’s http server, optionally specifying the http server’s port (the default port is 80). This script runs during the boot-up process to start the http server for the web configuration.

12. New environment variable: http_port – to specify a port for the http server. If this is set to “none”, then the http server will not be started during the bootup process – this can save significant memory on low memory routers – but you will not be able to open the web configuration with this setting. If you thereafter wish to configure the router from its web interface in such a case, you will need to run from the command line, either with no parameters, or with the desired port number.

13. Slight change to the syntax of to: –threshold=<number> (note the “=” sign).

14. The dnsproxy server has been upgraded from dproxy-nexgen to dnsmasq v2.51 (still masquerading as “dproxy”) for its up-to-date caching dns proxy functions only (NOT lan dhcp). The code has been patched, to reduce size by disabling unused options and functions, to ignore command line parameters, and to do all configuration by configuration file. Additional conf files can be added to /tmp/dns.d/. dnsmasq supports many options and enables additional functions such as auto selection of the fastest responding dns server from all configured, and domain blocking – exploited by the extra_dns and adblock functions below.

15. New shell scripts: and – to assist in blocking popup adverts by means of “dns poisoning”. It is basically obsolete if you can use Firefox and adblock plus – but otherwise (e.g., if using IE) it is very useful. Advantages (a) it only needs to be implemented once – on the router – and all clients would benefit from the ad blocking, etc (b) it works with all browsers such such as IE which don’t have adblock (c) some of the hosts in the hosts block lists do some of what tinyproxy could have achieved, re: parental control. For this purpose, downloads and converts one of a number of common internet resources (“small”, “medium”, “large”, or “xlarge”) of ad servers to be blocked. The largest of these uses a lot of cpu cycles on the router (about 20%) – but since the router’s cpu is largely idle most of the time, this is not a major issue. The smallest consumes only about 5% cpu cycles. Run with no parameters to see the syntax. is a shell to, allowing it to download more than one of the internet lists at once (e.g., “ exit small large”). Note that, for routers with low memory (i.e., 8mb RAM), you should never use “large” or “xlarge”. In fact, “small” might be the only one that such routers will be able to cope with. If you try to download more lists than your free memory can cope with, your router WILL crash!
NOTE: you MUST always run “ exit” to remove the adblock features from memory, before any attempt to upgrade the firmware.

16. New environment variable: adblock – use this to schedule to run when a WAN connection is made. The values should be the parameters that you wish to pass to (e.g., setenv adblock “exit medium xlarge”). On routers with 8mb RAM, you should only supply “small” – do NOT try to use the medium/large/xlarge lists on such routers.

17. New utility: pixelserv – a tiny webserver that serves up a single pixel to any request. It can be used in conjunction with the adblock features.

18. New shell script: uptime – parses and displays the system uptime information.

19. New shell script: memavail – reports the amount of RAM that is available to be used.

20. New environment variable: extra_dns – to add DNS servers from a selection (“All”, “OpenDNS”, “Google”, “UltraDNS”, “DNSResolvers”, or “BT”) in dnsmasq format. You can set “extra_dns” to any of these, to a combination of them, or to “All”, and you can use either their full names, or the first letter of their names – e.g., setenv extra_dns “O U D B” – will select DNS servers from OpenDNS, UltraDNS, DNSResolvers, and BT; setenv extra_dns “A” or setenv extra_dns “1” will select all of them.

21. New environment variable: extra_resolvers – to add ALL the DNS servers specified above, in resolv.conf format. These servers are prepended to /etc/resolv.conf. In the TWNETW1350A firmware, only the first three will be used.

22. New environment variable: static_dns – this is useful mainly for those with DHCP (as opposed to pppoa/pppoe) connections, who do not have the “Use Peer DNS” button in the firmware’s web interface. Set it to 1 to prevent the dhcp server from overwriting your static DNS entries.

22. The ssh server (dropbear) has been upgraded from v0.51 to v0.52 in line with upstream package source. A default idle timeout of 120s has also been enabled, to prevent disconnected instances of dropbear from hanging around wasting memory and preventing further logins (maximum 2 simultaneous allowed). To avoid the timeout please enable a keepalive of say 30s in your ssh client (supported by putty and winscp, for example). The dropbear code has been patched to accept this null packet keepalive – the default code acts only on data transfer.

23. The upnp daemon has been upgraded to v1.4 20091102 in line with upstream. Additional optional configuration items include the ability to not show the Internet server in Windows “My network places”, by specifying a null presentation_url.

24. New hook to run a user-supplied script (/var/tmp/ when before rebooting or shutting down the router via the reboot or shutdown commands. When either command is executed, it will search for “/var/tmp/”, and, if it is found, it will be executed immediately. After this, the normal house-cleaning on reboot/shutdown will continue.

25. Wide display support enabled for the “ps” command. This is triggered by running “ps -ww”. The downside of this is that “ps aux” will now generate an error. So you can only run “ps” with no parameters (which will behave as it would when you used to run “ps aux”), or run it with “-w” (132 column width) or “-ww” (2048 column width. Users who have written scripts with “ps aux” will need to change their scripts to just call “ps” (busybox ignored the “aux” anyway). The command “ps -ww” will display everything (up to a width of 2048 characters). It would however need to be used with great discretion, because all the username and password, etc., passed to pppd will be displayed in its full glory (i.e., you don’t really want to post the output of “ps ww” on the forum!).

26. Text files with the mtd calculations for each firmware image now added to each firmware release. Each firmware image has a corresponding “_mtd.txt” file, which shows the correct mtd partition settings for that firmware image. The text files are in unix format (for very good reasons), and so to view them under Windows, you will require a text editor that understands unix line endings.

Thanks to all who worked hard on making this release possible

RouterTech Firmware v2.91

September 14th, 2009 by Kieran in Announcements

RouterTech Firmware v2.91 has been released. While only a minor version number increase since our last release, we’ve included over 20 different changes to fix issues and generally make the firmware better.

1. Bug fix: the “Restart Access Point” button in 4-port non-wireless firmwares removed.

2. Busybox upgraded to v1.14.3.

3. Utilities: “insmod” is now a shell to modprobe; use “insmod-bin” for the “real” insmod (this is a result of the busybox upgrade to v1.14.x and higher).

4. Some security improvements.

5. The “RT configurations” feature has been updated to be able to specify Led file and DSP driver. The available ones are shown in brackets. The desired Led or DSP file should be specified as it
appears in the brackets – and their file extensions must NOT be specified.

6. A new shell script: (for routers with the Adam2 bootloader only). It will defragment the Adam2 bootloader environment. The script has to be run from a telnet/ssh login session. Normally, you should not run this command directly. Instead, use setenv DEFRAG DEFRAG (see below).

7. New command for defragmenting the environment – setenv DEFRAG DEFRAG (note the capitals!) – must be run from a telnet/ssh login session (never from the web interface).
NOTE: This command must only be used as a last resort. As with any low-level operation that writes to the router’s flash chip, things can go badly wrong. The recommended way to defragment the Adam2 bootloader environment is to run “fixenv” from the bootloader command prompt. The recommended way to defragment the PSP bootloader environment is to run “defragenv” from the bootloader command prompt. You will need a serial console to run commands from the bootloader command prompt.

8. A new shell script: – allows you to throttle the bandwidths of those who have exceeded a specified transfer bandwidth (default 500mb) to a very very low speed (default 128 bytes-per-sec), and to display current bandwidth usage data. Requires IP Account to be enabled (example: 250 1024 reset – will throttle any client that has exceeded 250mb bandwidth to 1024 bytes per second; the “reset” parameter is optional; if used, then it will first reset the IPAccount statistics – this is useful if your router is not rebooted everyday). Run the command with no parameter to see the syntax.

9. New support for wireless Adam2-based routers with just one ethernet port (e.g., the Actiontec GT701WG).

10. pppd upgraded to v2.4.4.

11. New support for siproxd (wireless routers only) (courtesy of Richard Antony Burton).

12. New environment variable (“siproxd_enable” (wireless routers only)). If set to 1, this will trigger automatic execution of siproxd each time the router boots up, using a default configuration file (/etc/siproxd.conf).

13. Enhancements to the “RT Configurations” page in the “Tools” menu. You can now a) enable/disable Siproxd from this page, and b) select/de-select DSP drivers and Led conf files.

14. DSP/tiatim v6.x has been restored to the AnnexA firmwares.

15. The default DSP driver (other than the 1350A wireless routers) has been changed to DSP/tiatm v6.x. This should free up some memory on low memory routers, and should also be less demanding on the hardware. In the firmwares that allowed for changing the DSP/tiatm drivers, the facility to change the drivers still remains.

16. New DDNS support for dnsomatic (courtesy of Richard Antony Burton).

17. New command: wol_forward (courtesy of Richard Antony Burton). This command is to wake a machine on the LAN from outside the network, via settings in the new wol_forward environment variable. Example: setenv wol_forward “ppp0 br0 7”.

18. Following a poll on the forum, Tinyproxy has been removed from all our firmwares and is no longer a feature of the RouterTech firmwares.

19. A new shell script – – resets the configuration to defaults. Use this command only as a last resort – when everything else fails (e.g., when reset from the web interface fails, or when you are unable to access the web interface).

20. New tool – mtd3_app – this is a low level helper program for some firmware scripts. Do NOT attempt to run it manually!

21. Change in the syntax of – the “size” parameter should now be in kilobytes (multiples of 64) and not in bytes – e.g. mtd5 192 auto_minix. The valid sizes are: 64; 128; 192; 256; 320; 384; 448; 512; 576; 640; 704; 768; 832; or 896. If an invalid/unsupported size parameter is given, the script will simply print an error message and will stop. Be sure to not try to create a new partition that is bigger than the available flash space, or you will trash your router.

22. A new shell script – – returns the number of lines in a text file (or “-1” on error). Empty lines and comment lines (beginning with a “#”) will be ignored. If you want comment lines to be counted as well, then supply the switch: “–with-comments”.

23. A new shell script – check_env – this is a rough-and-ready check for bootloader environment fragmentation (Adam2 routers only). It returns 1 if the bootloader appears to be fragmented, and 0 if it does not appear to be fragmented.

Thanks to all who worked hard developing and testing this release!

Xilo Broadband

September 6th, 2009 by Kieran in Articles

So this is my first proper article on the new RouterTech blog and I want to post about my ADSL provider, Xilo Communications. From the outset let me clarify that I’m not being paid to write this but am doing so because I use the service myself and am more than a bit impressed with it. As you will see in the coming paragraphs the features on offer are numerous and are in amazing positive contrast to other ISPs currently available to home internet users.

Range of Accounts

The range of accounts on offer should provide something for every kind of user but for best value check out the Pro accounts. While sounding grand these are just simple LLU accounts that offer un-metered bandwidth, a rock solid reliable connection and a low monthly cost, which to be honest is all you really need with an ADSL connection. Contention rates are lower on Pro Office than you’ll find on most competing ISPs (25:1) but Pro Home (50:1) will most likely be more than adequate, even for heavy users.

Lead time and Migration

You should expect a lead time of 7 working days. I migrated from my old ISP and provided my MAC when I signed up. When my migration day came around (I was informed what it would be at point of ordering and again by e-mail) my old connection ceased working and my Xilo connection started. This happened in a very short space of time with minimal downtime.

Obviously I can’t speak for everyone’s situation but I would be more than a bit surprised if your experience of getting connected wasn’t smooth and trouble free.


I’m not going to go off on one about how great my connection is, the simple reason is that for everyone this is going to be different and very much dependent on their line quality and distance from the exchange.

My advice here is to check your exchange distance and expected speed on Sam Knows and then be assured that you will get at least this speed with Xilo. My actual speed is higher than indicated and the drop-outs I get are infrequent, brief and cause little to no impact on my network.


So you’ve chosen your package, signed up and been sent your login details by e-mail and have a nice stable connection running. This is where Xilo broadband really starts to come into it’s own – the tools they provide to manage your connection. Below is a screen shot from the broadband control panel. Rather than offer company news and other info upon login (this is available elsewhere if you want it) the panel keeps it simple and to the point – all the broadband tools in one place with no hunting around required.


The first thing you notice about this panel is you’ve got features you wouldn’t get with other ISPs; fault logs, IP settings, notification settings. I’ll get to these later but I point them out as they’re sure to delight any discerning techie who likes to keep an eye on things.

Usage Statistics

Even with unmetered access it can be useful to know how much bandwidth you are using and when, especially if your router doesn’t support stats or if you use more than one machine and want to keep all your stats in the one place. Below are a few screen shots of the various statistics screens. All the graphics are animated (although obviously not on this page) and are updated daily.


If you run home servers this graph allows you to see when remote access peaks during any given 24 hour period and also when the quiet periods are – great for planning essential upgrades and other maintenance.


Current usage is probably of a lot more use to those who have chosen a metered package but it is still nice to see a pie chart breakdown of your upload and download use. I find it useful to indicate if I might have a problem with my home servers; I would for instance expect to have a considerable upload footprint due to remote users requesting files but I can see from this graph that while I was away on holiday my file server may well have fallen over as download use far exceeds upload.


The historic usage graph is without a doubt my favourite as it will let me track over time how my usage habits are changing and act accordingly. For example, if my download usage is going up by only 10Gb per month then I can probably afford to delay the expansion of my hard drive array for a while. If however I notice usage starting to increase by 50Gb or so then I might want to continue with my hardware upgrade plans after all.

Tracking Line Drops

Now onto some of the really juicy bits, after all, plenty of other ISPs provide at least a few stats. Few however will acknowledge to you how often your connection drops and those trying to track it themselves are often faced with lost logs after router restarts and log wrap-arounds on routers with a low memory capacity. With Xilo your monthly session history is logged and you can use this to determine trends in when your connection drops to diagnose interference at home or, if you have a really good connection you can prove to yourself how long it really can stay connected! In addition to simply tracking when drops occur the logs will also provide the reason so you can decide if the issue is line based or if your router may be about to croak.


Before someone points to my stats and exclaims that I seem to have a few drop outs listed, this is my take on ADSL disconnections. In an ideal world we wouldn’t have drop outs but copper wires are fallible and subject to all manner of interference. This means we simply cannot expect to have connections that stay up indefinitely.

My stats in the screen shot reflect a common situation with ADSL. The connection stays up for a good chunk of time, 10 days say, then some interference causes a drop. The connection will be re-established but because the interference is still there the rate at which it re-connects may be too high. This rate is re-negotiated on the next connect and this process continues until the rate at which you are connected is low enough to stop the interference dropping the connection and so another period of good stability resumes.

The better your line the fewer drop outs you will invariably have but you will always have some. Also note that you should not change ISP simply to escape drop outs. Your line isn’t going to change and as such the reason for the drops isn’t going to be banished just because the provider at the other end of the copper has changed.

If you do have issues with you line, drop logs like the ones Xilo provide should serve to both highlight the problem to you and also help you or an engineer to pinpoint the cause.

Proper IP Blocks

Static IPs are an unknown area for many home users and if this is you then you can ignore this option when signing up with Xilo and just have a single IP, but if you have many devices at home and know what you are doing with networking you may very well want a block of IPs for your use.


If you do go for the block, Xilo help you to manage them. You can see a list in the broadband control panel (screen shot above) and see clearly the reserved addresses that you should not assign to equipment. The IP page also provides the option to assign reverse DNS to each IP address although be aware that you must first ensure the host name has an A record for the IP. These features combined with a good home router and a little networking knowledge can help you build up a proper LAN with fully addressable host names for each device on your network and a gateway address through which all your traffic will pass.

Many ISPs, naming no names, make a really rather bad job of this as well as charging an eye watering sum for the privilege so if you are wanting to setup a home network in this way think very carefully before deciding against Xilo!

If the worst should happen

So the unthinkable has happened, you wake up one morning and find your broadband is down. Usually this means a call to your ISP, a patronising conversation with 1st level support and then a ticket raised behind the scenes on your behalf with no way to track it’s progress except when you get tired of waiting and call again or your connection comes back. You are of course rarely told what the actual problem was.

Sound familiar? Well that’s why the Xilo fault log is so useful. Firstly you won’t be patronised by support. Secondly the ticket raised on your behalf is placed in a system with API access which allows it to be presented to you in the broadband control panel – see the screen shot below.


From here you can see as the fault is passed between Xilo and other parties, the names of people dealing with the issue, the time taken for Xilo to receive a response from other parties and most importantly, what the actual problem was and what the resolution was when everything gets sorted.

Obviously you hope you’ll never have an issue and you probably won’t but knowing this kind of transparency is on offer if you do is a great comfort.


If you want a reliable ADSL connection at a reasonable price and with a great customer facing feature set then Xilo Communications is certainly well worth a look. While no ISP will be perfect I’ve used enough of them to know a cut above the rest when I see it.

New Look Website

August 22nd, 2009 by Kieran in Announcements

Welcome to the new look RouterTech website!

It might take a short while to find your way around the new layout if you are a regular but by and large things are laid out in a similar way. If you are a newcomer we hope the site will in fact be easier to use than the old one; we’ve consolidated a lot of content into specific pages and moved things out from the forum that really should have been on pages.

Regulars will be delighted to note that we have embraced the new version of phpBB and so are now packing a huge punch when it comes to user features – we hope you find them as useful from a user perspective as we do as staff.

Small points about the design will probably be in a state of flux over the next few weeks but generally we don’t intend to mess with things too much so we hope your experience will be a trouble free and positive one.

If you’re reading this you will have found our new blog and we encourage you to subscribe to this as a means of quickly finding out what is going on with our software and also in the world of home routing generally.

Powered by phpBB & WordPress     Hosted by Kieran O'Shea     Site Code © 2005-2011 Kieran O'Shea     All site contents © 2005-2011 RouterTech - All rights reserved     Valid HTML     Valid CSS     Graphics by Neo