Joined: 21 Apr 2012
|Posted: Mon Dec 09, 2013 15:34 Post subject: OpenVPN Site-to-Site configuration for ASUS RT-N16
|I recently spent several weeks trying to get a site to site VPN working using two ASUS RT-N16s. Since much of the information on OpenVPN is fairly old and uses a variety of hardware/DD-WRT versions, I thought I would post how I configured my VPN using current (December 2013) DD-WRT builds for an ASUS RT-N16.
I am using two ASUS RT-N16 routers flashed with DD-WRT with one router hosting the VPN server with a LAN subnet behind it and another hosting the VPN client with another LAN subnet behind it. Each router is the gateway for its respective subnet. This is a routed VPN so that each subnet is isolated (for DHCP and other purposes) but traffic can be routed between the subnets over the VPN tunnel. Each site must be on a unique subnet and the VPN tunnel(s) must be on a unique subnet. I used following subnets in this example:
Site 1 (site with server): 192.168.2.0/24
Site 2 (client site): 192.168.3.0/24
VPN tunnel: 10.10.10.0/24
It does not matter which subnet class is used as long it is unique within the organization’s network. I chose to use a 10.x.x.0 subnet for the VPN tunnel so it would be readily apparent that it is not a site/LAN subnet.
I am currently using Brainslayer’s Broadcom_K3x Big build #22118. This latest (22118) K3x build appears to have a properly working OpenVPN Server/Client service.
(from DD-WRT Downloads: others>eko>BrainSlayer-V24-preSP2>2013>07-24-2013-r22118>Broadcom_K3x>dd-wrt.v24-22118_NEWD-2_K3.x_big.bin).
Upgrade to K3.x
This assumes you are on a DD-WRT K2.6 build on your RT-N16. If not, Google how to flash DD-WRT to your ASUS RT-N16. The following instructions are the process I used to transition to K3.x based on reading the forums. I am including pitfalls that I read about. I did this in December 2013 with K3.x 22118 so later builds may be different.
To use K3.x you MUST upgrade from a K2.6 build. Do not try to flash from stock firmware directly to K3.x. Do NOT hard reset (30/30/30 reset) between flashes. On the firmware upgrade page select “Don’t Reset” for the “After flashing, reset to” option. I’ve read that some people have problems when they hard reset; I did not hard reset and it worked fine for me (I have done this on 3 different RT-N16s)
1. Flash K2.6 r22118
2. Flash K3.x 21530 big.bin
3. Flash K3.x 22118 big.bin (or your desired build # and feature set [mega/big])
For step 3, I used the generic .bin files not the RT-N16.trx files. I believe the .trx files are for a direct flash from stock to K3.x which I am led to believe may cause problems.
I've attached the K3.x 21350 build as I can't find it in the download list. Brainslayer attached it to one of his posts in one of K3x threads.
Here are the links to the other build files:
K3.x r22118 builds
I spent a long while working on this setup using the K2.6 builds and I found that there is an issue with K2.6 builds above 18946. I was unable to get the tunnel up (kept getting TLS handshake errors) when using K2.6 Mega 19342. According to various forums, DD-WRT's OpenVPN is broken above 18946. Not sure if it is fixed in the K2.6 builds above 22000 as a few forum posts are conflicted as to whether it is working. Downgrading my routers to K2.6 Mega 18946 resulted in the tunnel connecting properly so if you want to stay on a K2.6 build then use the eko>V24-K26 18946 builds.
K2.6 18946 Mega (generic)
Generate your keys using the OpenVPN guide (easy-rsa). I generated my keys on a windows machine and had no problems.
When you generate your certificates, they are time stamped for the current time in UTC not local time. The certificates do not specify time zones so if you generate your key at 1500 Eastern time (3PM) they are time stamped 20:00 (8PM) and are not valid yet when compared to your local machine time.
Either wait 5 hours (for Eastern time) or change the time zone on your DD-WRT router to UTC (Setup>Basic Setup>Time Zone). You can change it back to the local time zone the next day. This is a common reason the VPN does not authenticate and you will see TLS handshake errors.
VPN Server Configuration
The following screenshot shows my server configuration.
The "Network" field is the VPN subnet (not the VPN server specifically). The VPN server will take the x.1 address automatically (in this case it will take 10.10.10.1)
From your key generation, you will need to paste the certificates/keys from the following files in their configuration fields. Include the ----Begin Certificate/Key/etc---- and ----End Certificate/Key/etc---- in your paste.
Public Server Cert will be the server's certificate (ServerCommonName.crt)
CA Cert will be the ca.crt file.
Private Server Key will be the server's key file (ServerCommonName.key)
DH PEM will be the DH1024.pem file.
In the Additional Config field, you will need to two sets of route commands. Add a Push Route for the server’s LAN Subnet. This will create a routing table entry in the client routers for the server’s subnet.
|push “route 192.168.2.0 255.255.255.0” |
Add a route for each client LAN subnet. This will create a routing table entry in the server's router for the client(s) LAN subnet. The command will take the following format:
| route <client subnet> <client subnetmask> <client VPN endpoint> |
I found that if I did not include the VPN endpoint as a gateway, the route would not always be added to the routing table. The route command for my setup is as follows:
|route 192.168.3.0 255.255.255.0 10.10.10.2 |
Obviously, we'll need a static IP address for our client's VPN endpoint so we set this with a startup script which I'll show in the next section.
The OpenVPN client in the K3.x 22118 build should handle most of the firewall rules.
It automatically inserted the following three rules that other forums reference. (tun1 is the VPN interface. Open at telnet/ssh session and run "ifconfig" to check what your VPN interface is called.)
|IPTABLES -I FORWARD -i tun1 -j ACCEPT
IPTABLES -I FORWARD -o tun1 -j ACCEPT
IPTABLES -I INPUT -i tun1 -j ACCEPT
Thus I did not require any manual firewall modifications on the server end.
Because the RT-N16 is serving as both the gateway and OpenVPN server, a second route command is needed for the OpenVPN server. Add the following to Administration>Commands>Save Startup:
| echo "iroute 192.168.3.0 255.255.255.0" > /tmp/openvpn/ccd/Station_2 |
To set the client's VPN endpoint static IP, use the following:
| echo "ifconfig-push 10.10.10.2 255.255.255.0" >> /tmp/openvpn/ccd/Station_2 |
where "Station_2" will be your client's common name as specified in your client certificate/key files. (Note the use of ">>" to append additional lines to the client ccd file.)
The OpenVPN site HowTo explains why this is necessary here.
The following screenshot shows my client configuration.
The settings up to the "NAT" option should match your server settings.
The "Server IP/Name" should be the public static IP address of the server's gateway as assigned by your ISP and the port we specified on the OpenVPN server.
I required the "NAT" option to be enabled on my setup. This automatically added the following line to my nat table.
|iptables -t nat -A POSTROUTING -o tun1 -j MASQUERADE |
I was not able to ping from my client subnet to the server/server subnet without this nat entry. You can check for this entry using the following command from a telnet/ssh session:
| iptables -t nat -vL |
You can manually add this nat entry by pasting the above POSTROUTING command into Administration>Commands>Save Firewall.
I don't know what the IP Address/Subnet Mask fields do. I tried to set the client's VPN endpoint to a static IP here but it didn't seem to do anything. Maybe someone else can provide further information.
Fill in the CA cert (same one used for the server), Public Client Cert, and Private Client Key the same way we did for the server.
Apply Settings and Reboot and you should have a working VPN. You can check the VPN status by going to Status>OpenVPN. If you have problems, check the VPN logs here for error messages.
To reiterate, when using the K3.x r22118 Big build, I did not have to manually create routing table entries or firewall rules for the server or the client. With the exception of having to create the startup script to add client configuration routes to the OpenVPN server, it automatically created the firewall rules and routing entries.
Hope this helps and may your DD-WRT/OpenVPN endeavours be much less painful than mine have been over the past month.