My Experiences with DD-WRT

I recently set up DD-WRT on my router at my apartment.  While it is quite a bit cheaper to buy a consumer class device and load DD-WRT on it, compared to purchasing a traditional business class device, there were several aspects of DD-WRT that I was disappointed with.  I’m not sure I can really recommend using DD-WRT in a business environment unless your needs are relatively simple.

Hardware

I am using DD-WRT on a Netgear WNR3500L.  I specifically bought this device to use with DD-WRT after researching what devices will work best with DD-WRT.  I was specifically looking for something that had enough memory to be able to use OpenVPN, and that could support multiple SSID’s / VLAN’s.  802.11n support wasn’t crucial for me, but it was a “nice-to-have”.  The WNR3500L does support all of those. 

I had no real problem flashing the firmware to install DD-WRT.  If I recall correctly, there was an interim firmware that has to be used first before you can upload the full version of DD-WRT.  As long as you follow the directions / tutorials from the DD-WRT site you should have too much trouble.

Site to Site VPN

My most important requirement was to set up a site-to-site VPN to another LAN that hosts my servers.  I use OpenVPN for a road warrior style VPN for when I’m working remotely, so I intended to use this as well for the site to site VPN.

The endpoint on my other LAN is a CentOS box.  Unfortunately, DD-WRT makes it difficult to use a custom OpenVPN config on the device.  A lot of things, like TLS Auth or having multiple remote endpoints (for reliability) aren’t really possible to do. 

Furthermore, the OpenVPN software is hard-coded to NAT the connection.  This means that the remote network you are connecting to cannot see your local network – only IP address on the VPN interface on the DD-WRT router.  This was a ridiculously bad decision on the part of the DD-WRT developers / maintainers.  In almost no conceivable circumstance would you want to NAT a site-to-site VPN connection.  It does this by calling the route-up.sh script in the /tmp/openvpncl directory. 

After hours of frustration, I eventually found a solution that works.  I added a startup command that disables the NAT’ing by running the route-down script, and then restarts OpenVPN without running the route-up script.

( sleep 20 ; killall openvpn ; /tmp/openvpncl/route-down.sh ; openvpn –config /tmp/openvpncl/openvpn.conf –daemon ) &

This works, but its still ugly in my opinion.  Due to the way DD-WRT works its not possible to actually edit the OpenVPN configuration file.  The changes won’t persist after a reboot.  This makes it much more difficult to customize and configure than it would be if it were just a normal Linux box with OpenVPN installed on it.

VLAN’s

Configuring the separate VLAN’s turned out to be a lot more difficult than I was expecting.  In my opinion, the naming scheme for interfaces and the web interface to add VLAN’s / associate interfaces with VLAN’s is inconsistent and illogical.  Wireless interfaces are treated completely different than wired interfaces and can’t be added to what DD-WRT considers the VLAN.  The wired interfaces are added to the VLAN, and then that resulting VLAN is bridged with the wireless SSID (s).  Complicating matters it the fact that the LAN port numbers as shown by DD-WRT may or may not be the in the same order as they are on the device. 

Here is a diagram showing how the physical interfaces, VLAN’s and bridges are connected in my example:

image

This screenshot below shows the interface for adding SSID’s.  Note, for SSID’s to be assigned to different VLAN’s each SSID has to be set to be bridged.  The wireless security tab is where you can configure the authentication / encryption mechanism for each SSID. 

image

Here is the interface for adding LAN ports to VLAN’s.  Note the inability to add a wireless SSID to a VLAN.  Also note the “Assigned to Bridge” column – the “bridge” that the VLAN is assigned to here has nothing to do with the bridges configure in the next screenshot.

image

 

This is the place that you connect the wired VLAN’s to the wireless SSID’s.  Then you put an IP on the resulting bridge interface.  (The IP on the default bridge, br0 is configured on the Basic Setup tab).    A couple items of confusion to pay attention to here.  First, the name “Bridge 0” is not related to the interface name “br1”.  Secondly, if the SSID’s are set to be bridged, they will all be bridged to br0 by default.  You only have to add bridge assignments for VLAN’s / SSID’s that you don’t want to be bridged to br0.

image

A little further down on this same page is where the WAN VLAN assignment (VLAN 2 by default) is configured, along with the DHCP service offered for non-default bridge interfaces is setup.

image

Capturing Traffic with tcpdump

The WNR3500L has a USB port.  With a flash drive, you can add some persistent storage to DD-WRT.  After formatting and mounting the flash drive I installed ipkg so I would be able to install additional software on the flash drive.  The DD-WRT site has a good explanation of how to do this here.

From time to time, I find it useful to enable traffic capture on the router for troubleshooting.  I was able to install tcpdump through ipkg on the flash drive.  I can run tcpdump to dump traffic to a file on the flash drive.  Then, I can transfer the resulting file back to my computer via SCP and open it up with Wireshark to analyze it. 

Issues: Routing Daemon

For me this was extremely disappointing.  The quagga routing software that comes with DD-WRT will not function.  I found a post on the DD-WRT forum that explained this was because quagga was compiled incorrectly in this version of DD-WRT.  As far as I know this has not yet been fixed.  To me, the routing software is one of the most important aspects of a router.  This is something that should have been tested before the firmware was rel
eased.  The fact that it was not, makes me question how much I can really rely on DD-WRT.  If something this significant could slip through the cracks, what else have they messed up?

So instead of using OSPF over the site-to-site VPN to easily tell my other LAN how to reach this site, I have to add static routes on both ends.  This is pretty annoying and shouldn’t be necessary.  In a larger environment this would be a show-stopper.

Other Stuff

One feature I do really like is the Wake-On-LAN support.  You can easily add a computer on the network to a list of Wake-On-LAN hosts that you can remotely start with the click of a button.  With this, I can leave my desktop turned off, saving power, but easily start it up if I need to remote in to it. 

image

DD-WRT uses DNSMasq by default for providing DHCP and DNS forwarding service.  In my environment, I need a couple internal domains to be resolved by DNS servers across the site-to-site VPN.  This is easy enough to do with DNSMasq, by specifying additional options in the DNSMasq section of the Service tab.  In the example below, DNS requests for the two domains specified will be forwarded to one of the two servers specified for each. 

server=/internal-domain.com/IP-of-DNS-Server-1
server=/internal-domain.com/IP-of-DNS-Server-2
server=/internal-domain2.com/IP-of-DNS-Server-1
server=/internal-domain2.com/IP-of-DNS-Server-2

I have not tried updating to a newer version of the DD-WRT firmware.  However, from reading the DD-WRT wiki, it sounds like its not possible to upgrading without clearing the configuration settings and starting over.  To me, this seems like a pretty serious issue as well.  It’s taken quite a while to set everything up and find workarounds for some of the limitations of DD-WRT.  To have to do that all over again when I update the firmware would be a nightmare.  On Cisco IOS devices, you can easily use the same configuration on different versions of IOS, provided the new image supports all of the features used in the configuration.

In summary, while I was eventually able to get DD-WRT to work well enough for me, I can’t really recommend it.  It has a lot of potential, but a lot of the features really need to be polished up before a business can rely on them.  The interface for managing VLAN assignments for example, seems to be an afterthought rather than a primary focus of the device.  Businesses that need these features would probably be better off purchasing one of the Cisco 800 series routers.  While the Cisco hardware is more expensive and some of Cisco’s practices are maddening (like charging for access to updated images), it’ll still be cheaper when you factor in the time to get it up and running.  Configuring VLAN’s, site-to-site VPN’s, etc, on a Cisco router will take much less time than it does with the DD-WRT firmware.

One thought on “My Experiences with DD-WRT