Creating a Site to Site Routed VPN using DD-WRT and OpenVPN


I needed to setup a site-to-site VPN between my home and my parent’s home, so that we can back up our stuff offsite – mostly documents and precious digital photos.


  • I wanted it to be a proper routed VPN network, not a bridged one. By that I mean an OpenVPN tun setup, not an OpenVPN tap setup.
  • I did not want to force the client to use the OpenVPN server as the gateway: I want both homes to use their own ISP for internet traffic. This is often referred to as split-tunnelling.
  • Must run both OpenVPN client and server on same DD-WRT router: For maximum flexibility I wanted to run both an OpenVPN server and client on the same DD-WRT router/gateway.


1 x DD-WRT router at my place, acting as an openvpn server
1 x DD-WRT (technically an ASUSWRT) router at the remote location, acting as an openvpn client

Conceptual setup

Local LAN:
Remote LAN:
OpenVPN network:

  • DD-WRT router acts as OpenVPN Server.
    • LAN IP: OpenVPN IP:
  • Remote DD-WRT router acts as an OpenVPN client.
    • LAN IP: OpenVPN IP:

If your LAN/IP setup is different, you should be able to operate a Find/Replace to change all these.

Some technical details

DD-WRT version: DD-WRT v3 – DD-WRT v3.0-r33679 std (11/04/17)

DD-WRT server assigns tunnel device as tun2
DD-WRT client assigns tunnel device as tun1
DD-WRT bridges ethernet and WLAN devices into br0

Considerations and gotchas

Most guides will get you *nearly* there

Most guides I found online for setting up DD-WRT for a site to site VPN with OpenVPN got me almost there, but didn’t quite finish the job. Many were also written over a year ago, and it seems DD-WRT has changed a bit since they were written. In addition, some threads where people were having issues seemed to give up on tun (routed) and switched to using tap (bridged) which wasn’t ideal for me.

Guides I found which may be useful to you include:

  1. Happydaddy post:
  2. D0ug has an interesting setup, including kill switches.
  3. Boogalooz guide:

Note that you’ll need to register for the DD-WRT forums to see the images/attachments alluded to in the posts.

Open the frontdoor

If your DD-WRT device is also your gateway (that is, it has a modem connected to it, and it acts as your internet gateway) you’ll need to open up the port for the OpenVPN server using IPTABLES. Some guides seemed to skip this.

You don’t really need to mess around with IPTABLES with the latest builds of DD-WRT

It looks like in the past you had to do a lot of messing around with IPTABLES on DD-WRT to get OpenVPNs to work – mostly to pass traffic between the OpenVPN tun+ devices and the Bridged device (br0) on the router. Now you can just use the GUI, as it seems to autoconfigure everything for you.

OpenVPN client with PBR and OpenVPN server don’t play nice

If you have a VPN client, using Policy Based Routing (PBR) on the same DDWRT router as your OpenVPN server, you’ll hit this issue: Put the suggested script from pastebin into your Startup Script and all will be well.

Symptoms for this issue are that you can ping from the Client network to computers inside the OpenVPN server’s local network, but not all IPs respond. It’ll turn out that the IPs that don’t respond will be in the PBR list for your OpenVPN client setup.

iroutes are important

One of the most common things I found was this symptom: You can ping from the client network to computers on the server’s network. But you cannot ping from the Server network back through to the Client’s LAN network. You can ping from the server network to the OpenVPN IP on the remote network ( in my case) but not the IP on the other side of the router on the LAN interface ( in my case).

The problem is that some of the guides you’ll find strewn around the internet don’t cover adding iroutes. Without adding an iroute to the OpenVPN client, you won’t be able to ping from the Server LAN to the Client LAN.

General setup

Create server and client keys

Sorting out the keys for the server and client is covered well in this post: This part of the setup is outside the scope of this blog post.

Configure the OpenVPN server

OpenVPN server setup in the DD-WRT GUI

Here’s how my OpenVPN Server config looks [images below]

  1. I’m using WAN up, and configuring as a Server instead of Daemon.
  2. Also using Router server mode instead of Bridge.
  3. Don’t forget to enable “Allow client to client” so that the clients can talk to each other.
  4. In additional config add:

Here’s the server conf file in case it’s useful:

Example Client config ovpn file:

Putting the contents of the ca, cert and key files into the ovpn files makes it much easier to import into an OpenVPN client. In my case, the ASUSWRT openvpn client wouldn’t accept these files individually, so I had to combine them in the ovpn profile file as above.

Additional configuration to make it all work as expected

Below are all the things I had to do in addition to general setup to make things work. That is, that both sides of the VPN could contact each other as expected in a site-to-site VPN.

Open the OpenVPN Port

Administration > Commands > Firewall Script

Add the following to the Firewall Script in DD-WRT.

Startup script to fix routing with OpenVPN client and PBR

Administration > Commands > Startup Script

Go here for the overview: and use the script in the pastebin link to fix the issue. Add it to startup via Administration > Commands.

Client config to provide iroute

Administration > Commands > Startup Script

Add this to the bottom of the PBR fix script text in the Startup Script section

This is what enables you to ping from server network to client network. Without this, you’ll be able to ping from client LAN to server LAN, but not from Server LAN to Client LAN. The script ensures that on each boot of the router, it re-creates the client configuration file in the /tmp/ directory on the DD-WRT router and adds the iroute command to the config file. When the remote client connects, it’ll pick up this iroute.

There’s some really good information on why this works here: but basically, openvpn doesn’t quite behave like it should, so even though you may have all the right routes setup, it won’t work unless you’ve configured an iroute for the client.

Put this in your Startup Script, just after the PBR fix text:


Notes: Cracking WEP on the Windows command line with Aircrack-ng and AirPcap Tx

ARP injection in Windows using AirPcap Tx

Finally, I’ve had time to write down my notes on using aircrack-ng with the Airpcap Tx adapter in Windows. Before you read on, please be aware that this isn’t meant to be a guide or tutorial, it’s just my notes. Thanky 🙂


Start capturing:

Fake auth:

Start attack:

Deauth (if we need ARPs):

aireplay-ng –deauth 3 -a BSSIDMAC -c CLIENTMAC \\.\airpcap00

Start cracking:

Worked example:


I’ve prepared a special release of the aircrack-ng tools originally prepared by CACE Technologies on the AirPcap CDROM. It replaces the new aireplay-ng.exe with an older one which, in my tests, appears to perform better.

Download the release of aircrack-ng for AirPcap Tx

Putty now supports Serial COM connections

This is pretty cool: Whilst searching for an alternative to HyperTerminal that supports Serial Port connections, I discovered that PuTTY now connects to Serial COM ports as well as the usual SSH/Telnet stuff 😀

As a business you can’t use HyperTerminal Private Edition unless you pay a licence fee; and now that Microsoft has removed HyperTerminal from Windows Vista, finding an Open Source, free-for-commercial-use, replacement for HyperTerminal is invaluable for budget constrained IT departments.

Download PuTTY here

It also seems that Poderosa support Serial comms with a plugin, which I wasn’t aware of until reading this blog post.

What do you use instead of HyperTerminal? I’d love to hear about any programs I’ve missed! 🙂

Cracking WEP with aircrack-ptw in Windows with AirPcap and Cain

Every time you deploy a WEP Access Point, a fluffy kitty dies.


Recently a team of German cryptography researchers perfected methods to recover a WEP key faster than ever before. The older Weak IV attacks generally needed between 500,000 and 2,000,000 packets to recover a 128-bit WEP key. In contrast, the new PTW method needs a mere 85,000 packets to have a 95% chance of recovering the WEP key.

Unlike the Weak IV attack, instead of collecting weak IVs, the PTW method collects ARP requests and responses to attack the encryption. ARP requests can either be collected naturally, or can be generated via packet injection. Until recently, packet injection was only possible in Linux. With the advent of the AirPcap USB adapter, and some unsupported beta drivers, it’s possible to inject packets in Windows. Update: CACE have released AirPcap Tx, which features fully supported packet injection, for an added premium.

In this tutorial, I’ll guide you through the process of recovering a WEP key, via the PTW attack, in Windows. For this you’ll be using the AirPcap USB adapter, Cain, aircrack-ptw, and the aircrack-ng suite.


It’s important to point out that these methods should only be applied with permission from the owner of the target AP. You should either be auditing, penetration testing, or demonstrating the weaknesses of WEP in a Test Lab environment. You should not be using these methods to get “Free internet”!


You’ll need:

Now you’ll need to prepare the environment:

  • Install the beta drivers (or if you have AirPcap Tx, install the drivers from the CD-ROM)
  • Plug in the AirPcap
  • Install Cain
  • Extract aircrack-ng to c:\airpcap\
  • Extract aircrack-ptw to c:\airpcap\
  • Move aircrack-ptw.exe to the bin folder (this is no longer required – see my notes)
  • Optional: To make things easier, move the contents of the bin folder to c:\airpcap\. You’ll then be able to run aircrack-ptw.exe with just c:\airpcap\aircrack-ptw.exe mycapture.cap

Let’s get cracking

I added narration to the video this evening at 20:36. It’s my first attempt at narration, and a little noisy, but I’m sure things will improve as time goes on! 🙂

Get the Flash Player to see the wordTube Media Player.

Youtube Video Link


The primary counter measure to this WEP attack is to cease using WEP and switch your Access Points to WPA encryption. As you’ve seen in this video, WEP is just too easy to crack. For further reading, Wikipedia has an excellent entry on WPA.

Access Points are so cheap now that, if your AP doesn’t support WPA via a firmware upgrade, you can easily afford a new one with full WPA or WPA2 support.


Note 1: After recording this tutorial, I’ve become aware that, as of version 0.9, aircrack-ng.exe natively supports the PTW attack by using the -z switch. For example: aircrack-ng.exe -z mycapturefile.cap. If you want to use this attack, download aircrack-ng from the authors, and replace aircrack-ng.exe in c:\airpcap with the new one.

Note 2: The whole process from starting capture to recovering the WEP key takes about 10 minutes.

Note 3: It is important that you get the Packet Injection drivers and the aircrack-ng release specifically for the AirPcap adapter, or this will not work.

Note 4: Just to summarise the steps in the video:

  1. Run Cain and passively scan for the target AP, making a note of the Channel number.
  2. Using the channel number, tell AirPcap to inject packets once it has collected an ARP request. (You can sometimes force an ARP by sending Deauth. To do that, right click on the client. Otherwise, repair the Wireless connection on the client connected to the AP)
  3. To use the PTW attack, you need to collect all packets. By running airodump-ng you can collect all the packets generated by Cain. The reason we use airodump-ng instead of Cain, is that Cain only collects WEP IVs.
  4. Once you’ve collected enough packets, run aircrack-ptw against the capture file.

Aircrack-PTW for Windows


As of version 0.9, the aircrack-ng suite natively supports the PTW attack. Download it here. To invoke the PTW attack in aircrack-ng, run it with the -z switch: aircrack-ng.exe -z mycapturefile.cap.

A French chap has compiled Aircrack-PTW for Windows. This is great for anyone using the AirPcap adapter to inject packets in Windows, as the new PTW attack dramatically reduces the amount of packets you need to collect before attempting to crack the WEP key. Notice in the screenshot below, only 83,000 packets were needed to break a 128bit key; as opposed to around 400,000 with the KoreK attack.

aircrack-ptw on Windows

The executable is in French but it’s still perfectly usable; All you’re looking for is the WEP key!

Just run it with:

aircrack-ptw.exe yourcapturefile.cap

When I get some time I’ll try to compile a version in English, but for now you can grab the French version: Download Aircrack-PTW for Windows.

I’m in the process of writing up and recording a demonstration of cracking WEP in Windows with AirPcap, Cain, and aircrack-ptw. Expect to see something within a week! Update: Check it out here