Overview

The Linksys WRT54G series are killer little boxes. With the DD-WRT (and others) firmware, the little routers can be made to do so much. My current setup to encrypt the wireless network is a few P1 and P2 boxes running FreeS/WAN. It works, but the boxes eat power and FreeS/WAN is no longer supported.

Looking for something to replace the aging setup for encryption over wireless, I setup an WRT54GL? box as a OpenVPN client configured to pass all traffic across the VPN. A Linux box running Slack works as the OpenVPN server. The big question in all this is if the WRT45GL? little CPU can handle doing the OpenVPN encryption faster then the wifi. See below for results.

This setup can be quite handy if you have an OpenVPN server setup on the Internet somewhere to connect to. In affect, one can plug the WRT54GL into any Internet connection, even wireless, and it will take all data to/from the computers plugged into it, encrypt, tunnel and send it across the Internet. Handy for wireless or hotel use when you need a secure Internet connection for multiple computers.

OpenVPN Config

Client side (WRT54GL)

For this setup, I used the latest firmware dd-wrt.v24-12476_NEWD_openvpn. OpenVPN is still in development on dd-wrt and does not seem to function correctly on the normal V24 version of the firmware. But even the above has bugs, but they can be worked around.

Bug1

OpenVPN now requires "--script-security 3 system" to run external commands like the two route shell scripts. At this time DD-WRT does not provide this.

Bug2

No OpenVPN status shows up in DD-WRT GUI. DD-WRT requires "management localhost 5001" to be added to the OpenVPN config, but DD-WRT does not provide a way to edit the config when running in client mode.

Fix it in the startup script.

The way to solve the above bugs is to create the below startup script using the GUI.

killall openvpn

echo "
management localhost 5001
" >> /tmp/openvpncl/openvpn.conf

openvpn --config /tmp/openvpncl/openvpn.conf --route-up /tmp/openvpncl/route-up.sh --down /tmp/openvpncl/route-down.sh --script-security 3 system --daemon

This will kill openvpn, add the correct line to the openvpn config, and reload it with the correct --script-security option.

Add the normal certs in the OpenVPN client option in the GUI and and the WRT54GL? will connect at boot.

Server side

For this test, I used a P4 box running Slackware 11 as the OpenVPN server.

OpenVPN config (2.0.9)

 
port 1194
proto udp
dev tun
ca ca.crt  #replace this with the ca cert
cert [server].crt #replace this with the server cert
dh dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1 bypass-dhcp" #this is to make the vpn the default gateway
keepalive 10 120
#comp-lzo #turned this off to save cpu resources on the wrt54gl
persist-key
persist-tun
status openvpn-status.log
verb 3

IPTables config

By default, I use iptables on the OpenVPN server to do NAT to/from the VPN to the Internet. All of the below is not needed, but is a good/simple config.

#default policy.
iptables -F
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

#drop packets going to port 0 and 1. 
iptables -A INPUT -p tcp --dport 0 -j DROP
iptables -A INPUT -p tcp --dport 1 -j DROP

#Allow pings                                                                                                                                             
iptables -A INPUT -p icmp --icmp-type 8 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT                                                               
 
#Allow SSH in
iptables -A INPUT -p tcp --destination-port 22  -j ACCEPT

#Allow OpenVPN in
iptables -A INPUT -p udp --destination-port 1194 -j ACCEPT

#nat for OpenVPN
/sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
/sbin/iptables -A FORWARD -i eth0 -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT
/sbin/iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
echo 1 > /proc/sys/net/ipv4/ip_forward

#SYN Cookie Protection
/bin/echo "1" > /proc/sys/net/ipv4/tcp_syncookies

#Disable response to broadcasts
/bin/echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

#Don't accesp source routed packets
/bin/echo "0"> /proc/sys/net/ipv4/conf/all/accept_source_route
/bin/echo "0"> /proc/sys/net/ipv4/conf/all/send_redirects

#Disable ICMP redirect acceptance
/bin/echo "0"> /proc/sys/net/ipv4/conf/all/accept_redirects

#Enable bad error message protection
/bin/echo "1"> /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses

#Turn on reverse path filtering
for interface in /proc/sys/net/ipv4/conf/*/rp_filter;do
/bin/echo "1" > ${interface}
done

#Log spoofed packets, source routed packets, redirect packets
/bin/echo "1"> /proc/sys/net/ipv4/conf/all/log_martians 

# Log the rest of the incoming messages (all of which are dropped)
# with a maximum of 15 log entries per minute
/sbin/iptables -A INPUT -j LOG --log-level 7 --log-prefix "Dropped by firewall: "
/sbin/iptables -A OUTPUT -m limit --limit 15/minute -j LOG --log-level 7 --log-prefix "Dropped by firewall: "

Notes

• The lzo compression option needs to be the same on both side. If not, the vpn tunnel will connect and be all happy, but no data will pass thru.

OpenVPN Speed test

The test are done by transferring a 60MB file using scp, across the WRT54GL as an OpenVPN client, to a Linux box running as a OpenVPN server. In the below test, the CPU in the WRT is maxed out making it the bottleneck in the system. I tried overclocking the CPU at several different rates.

CPU Speed	speed	MBps
183	460.8KB/s	3.686
200	483.1KB/s	3.865
233	538.6KB/s	4.308
250	584.9KB/s	4.679
no vpn tunnel	5.3MB/s	42.400

The above test shows that the WRT54GL can encrypt data at a max of 4.6MBps over-clocked. Clocked at a normal rate, it can handle 3.8MBps. So with a 3MBps Internet connection, the little WRT54GL can handle the encryption as a client. Sadly, I need something that can handle in the 6MBps range, so this will not work out for me.

-- PorchLight - 16 Jul 2009