DD-WRT
dd-wrt is an alternative firmware for a variety of routers. The most popular (and one of the first) that can be used with dd-wrt is the Linksys-Cisco WRT54GL Wireless-G Broadband Router
So, why would you want alternative firmware on your router? The stability can be improved for one, but there are also a large number of features that you can enable and configure through alternative firmware. The device that was originally just a wireless router can become a repeater, a client bridge, can serve separate subnets from each port, can broadcast multiple SSID (and BSSID’s) with different encryption levels, can act as a captive portal/hotspot system. This is… just a few of the really interesting features that you can get from v24 of dd-wrt.
Here’s another take on why you should consider an option like dd-wrt:
I’ve been buying and installing consumer grade routers from Linksys, Dlink, netgear and others for about 10 years. Every new purchase usually means a new model number, a new version of proprietary firmware, and a new package deal of features, bugs and limitations.
Every couple of years, the hardware gets more capable. In the consumer market, the hardware features and not the software differentiate one product from another. Within a feature set, these products are commodities. If Linksys is out of stock at officemax, then dlink or netgear is in. One is not preferred over another because of its software. Every manufacture has bugs. If you read the product reviews, -every- manufacturer has reviews that read: “worked on the first try” – followed by “couldn’t make it work.” The criteria is not “who is best”. It is – “can I make this model work, FOR ME?” and, which manufacturer’s software has been the most annoying…lately?
Here is the problem. EVERY manufacturer has bugs in their firmware, which are gradually reduced over time with upgrades and workarounds. Those firmware bugs ALWAYS RETURN in the next –hardware- generation. It is as though each hardware design commissions a blank slate rewrite of the proprietary operating system software. The user interface may have cosmetic consistency across the product family – but features that worked in the last generation of hardware have been seen to fail in the version -1- software of the replacement equipment.
This is why I am ready to make the jump to Linux based open source routers for the next and forseeable future generations. I will standardize on a router –software- platform. The platform will continue to mature over time, regardless of the hardware that it runs on. New features wil be integrated into the stable code base as hardware becomes more powerful, and the configuration and management of these routers will (at last) be something that can be simplified.
Ron Parker
Operation Improvement Inc.
Are you looking to use the Linksys WRT54GL with a dual lan connection? This page in the dd-wrt wiki explains how to setup dual wan with failover. This may well be my next dd-wrt and wrt54gl project!
So far I have configured a number of linksys wrt54gl boxes with dd-wrt.
1) Router/captive portal for a large wireless installation. Modified with scripts to monitor the devices status and send daily email reports. (Used v23sp2) (NOT serving wireless directly – just captive portal via the LAN ports. Other devices deal with the wireless. As many as 20-30 users/day maximum. (NOT WIRELESS – JUST ROUTER))
2) Simple Encrypted (WPA) router with QOS bandwidth limitation on one port of the LAN switch (to cascade to a second open access point.) (Additional firewalling rules on selected LAN port as well to prevent access from 2nd open ap into protected wpa network.) (v23sp2) (3-5 users/day)
3) Open captive portal for public use (nocatsplash) light use public hotspot (averages a couple visitors a day.) (v23sp2)
4) Dual SSID broadcast (one WEP for legacy support/one WPA2(TKIP)). (V24)
5) Repeater/client bridge for one WPA encrypted network (V24)
6) Test bed duplicate of #1 above
7) Spare on hand replacement of #1 above
8) Openvpn server box to be placed directly a network and serve up openvpn for the outside world. (So remote clients can vpn into the internal LAN.)
One issue I’ve run into with dd-wrt running on the linksys wrt54gl is with the nocatsplash process. It seems that the two boxes I have will occasionally find a way that the splash process dies and it leaves the box up and running but not able to handle new clients. (The splash process is a way of authenticating users in our situation, getting people to click on a terms/agreements acceptance.) So, we get sporadic reports of the internet being down when the splash process (splashd) has simply been overwhelmed. (Our best guess at this point is that this can happen when one machine opens up a gazillion internet connection attempts at once, but I don’t have any proof of that yet.)
So, I scripted a way to monitor the nocatsplash manager once a minute and if it’s no longer running restart the splash process. That’s taken care of the biggest stability problem I’ve seen in the field with a dd-wrt box. (Both implementations I have in the field with nocatsplash are using dd-wrt v. 23-sp2 because at the time of the solution build nocatsplash was not working in newer releases (v. 24 was still in the RC process.))
Anyway- here are some of the scripts I’ve used. One system I use I have enough space on the jffs that I’ve been able to put the scripts there permanently with the requisite path changes in the script below. In another installation I didn’t have /jffs space free so I had to save it as a startup script. For what I’ve detailed here you can copy and paste into the web interface on the command page and then click save startup or you can login via telnet/ssh and paste these after typing nvram set rc_startup=”
after pasting the text, type another ” to close the quotes and press enter. Then you can type nvram get rc_startup to verify that everything copied as desired and if so, type nvram commit. I have added several backwards leaning slashes to “escape” out certain things that I found I could not get to paste otherwise via ssh. Instead of pasting directly they substituted. So, when you verify what is pasted you should NOT see those backwards leaning slashes \ …
What the following does is create a /tmp/myscripts directory, then it echos a bunch of text into a file we call monitor_splash that checks to see if there are 1 or more instances of splashd running. If there are 0 instances of the splashd process running then it restarts it. After writing the script, we need to make it executable. Then, we echo a line into our crontab to tell the scheduler to run this script every minute to check the presence of splashd. Finally, we tidy things up with a restart of the cron service. It’s not much, but it’s saved us several service calls and several reboots of the box over the course of a few months.
mkdir /tmp/myscripts
/bin/echo ‘#!/bin/sh
status=`/bin/ps | /bin/grep splashd | /bin/grep -v grep | /bin/wc -l`
#echo $statusif [ $status = 0 ];
then
/usr/sbin/splashd >> /tmp/nocat.log 2>&1 &
else
exit
fi’ >> /tmp/myscripts/monitor_splash
/bin/chmod +x /tmp/myscripts/monitor_splash/bin/echo ‘ * * * * * root /tmp/myscripts/monitor_splash’ >> /tmp/crontab
# restart cron daemon
stopservice cron && startservice cron
Here’s another of my dd-wrt recipes: I have found much of the setup for this from the dd-wrt wiki which is a MUST read if you’re setting up dd-wrt on a router. This formula…. is a startup script to allow the router to act as an internal openvpn server. Basically you need to create all your keys on another machine (client and server and ca keys as well as your secret and your dh key.) If all of this is making your eyes glaze over you need to read about setting up openvpn with full blown certificate based encryption.
Anyway, the box is given an ip address on the local network and a port is forwarded from the firewall. Clients can then connect in and browse the internet through the tunnel. So… to the internet they look as though they are on the network that the vpn box is on. (They also have an ip address in the local net.) Make sure you change addressing to your local subnet for this.
192.168.100.9 is the address that the box is configured on and I’ve used the vpn version of dd-wrt v. 24. The settings below could be changed to allow connections on port 53 UDP (default is 1194) as that could be more likely to pass by more draconian firewalls when you’re out in the world. Another good idea is to change it to tcp-server and use port 443. you’ll need to make sure to forward the appropriate port on the firewall. I actually prefer using tcp port 443 because most firewalls would expect encrypted data to be going to port 443 (https). This is the setup I use when I have my laptop out at a hotspot. It puts me on my home network and allows me to browse the internet through my HOME connection while I’m out in the world.
cd /tmp
openvpn –mktun –dev tap0
brctl addif br0 tap0
ifconfig tap0 0.0.0.0 promisc upecho ”
# Tunnel options
mode server # Set OpenVPN major mode
ifconfig-pool 192.168.100.190 192.168.100.199 255.255.255.0
push \”route-gateway 192.168.100.9\”
push \”dhcp-option DNS 192.168.100.1\”
proto udp # Setup the protocol (server)
port 1194 # TCP/UDP port number
dev tap0 # TUN/TAP virtual network device
keepalive 15 60 # Simplify the expression of –ping
daemon # Become a daemon after all initialization
verb 3 # Set output verbosity to n
comp-lzo # Use fast LZO compression# OpenVPN server mode options
client-to-client # tells OpenVPN to internally route client-to-client traffic
duplicate-cn # Allow multiple clients with the same common name# TLS Mode Options
tls-server # Enable TLS and assume server role during TLS handshake
ca ca.crt # Certificate authority (CA) file
dh dh1024.pem # File containing Diffie Hellman parameters
cert server.crt # Local peer’s signed certificate
key server.key # Local peer’s private key
tls-auth statickey 0 #used for a bit of extra security during the handshake – clients substitute 0 for 1
” > openvpn.confecho ”
—–BEGIN CERTIFICATE—–
this space is where the CA certificate should go.
—–END CERTIFICATE—–
” > ca.crt
echo ”
—–BEGIN RSA PRIVATE KEY—–
your private key for the server
—–END RSA PRIVATE KEY—–
” > server.key
chmod 600 server.key
echo ”
—–BEGIN CERTIFICATE—–
here’s where your server cert goes.
—–END CERTIFICATE—–
” > server.crt
echo ”
—–BEGIN DH PARAMETERS—–
insert the contents of your DH here…
—–END DH PARAMETERS—–
” > dh1024.pem
echo “—–BEGIN OpenVPN Static key V1—–
Insert your key here
—–END OpenVPN Static key V1—–
” > statickey
sleep 5
ln -s /usr/sbin/openvpn /tmp/myvpn
/tmp/myvpn –config openvpn.conf
The firewall requires a small change to make this work as well. Make sure to change this to reflect the correct destination port and protocol.
/usr/sbin/iptables -I INPUT -p udp –dport 1194 -j ACCEPT
You can see that there is some overlap in these items. I haven’t used anything but the wrt54gl for this, but there are some devices with host usb support which allows for much more interesting things (network storage/print serving/etc.) This page will be updated as time permits.
Update 7-24-09 —-
There is a remote exploitable root access vulnerability with dd-wrt – see here for details and workarounds/fixes.
Update 6-17-10 ….
Big openvpn/dd-wrt project lately that has taken a lot of time, but it has solved an issue that I’m sure a lot of network admins have run into. When designing networks and looking to bridge offices with openvpn network admins are advised to pick unique subnets so that 192.168.1.1 in one office can route well over the vpn to 192.168.2.1 in the other office. If both networks (or multiple) use 192.168.1.0/24 there is network address collision – packets get lost and things don’t work. Well, it is possible with the right setup to do NAT on the packets that are traveling over the vpn. Why? Well, let’s say you’re a client of this 192.168.1.0 office network and are out at a wifi hotspot that also happens to be a 192.168.1.0 – you can’t exactly make them change their addressing to avoid conflicts with your business network and migrating an established business network can be a big task. Of course, you could start out your network design by choosing a different subnet and I’ve used this approach several times, but it’s really just a matter of time until you stumble across someone else with the same subnet that needs to vpn into the network and you run into the hairy address conflict problem.
So, we’ve designed a box based on dd-wrt openvpn edition…. This box has a vpn “personality” (client key and configuration to connect to a server out in the internet (a linux vps is the hub of the wheel for our topology and our openvpn server.) That server identifies the box by it’s certificate and gives it an address at 10.111.1.254. It also pushes routes to 10.111.2.0/24 with 10.111.2.254 as the gateway and 10.111.1.0/24 with gw of 10.111.1.254 to our second box which is given a 10.111.2.254 address. On each device in addition to the vpn personality there is a special brew of firewall rules which handles the packet rewriting such that any device that is attached to our two vpn boxes are accessible from the other side even though internally they can share the same 192.168.2.0/24 network. So, each client has it’s own network address (192.168.34.1) and it’s vpn address 10.111.1.1 This has worked well – it did take a lot of time to initially design but we’ve now rolled out two initial installs of it. (Not bad considering that it’s all done with ~$60 dollar router hardware.) In the future I may provide more details on the setup here because as I researched this I found NO ONE explaining step by step how to design this kind of a setup. At this point the only negative with our setup is that two devices behind the same box will not see each other via their vpn address(10.111.1.1/10.111.1.2), but their lan address (192.168.34.1/192.168.34.2) Of course, this plan also allows for mobile vpn clients that aren’t “behind the box” and they register in the 10.111.0.0/24 subnet and they are all screened with the wider subnet via the server so that anything in the 10.111.0.0/16 is pingable from each vpn subnet.
As I said, it’s been a big project and I may be detailing it here, but want to wait until all the dust settles on our setup.