How To: VPN Between RV082 (or RV042) and WRT54GL (or WRT54G)

Introduction

Using the OpenWrt Linux distribution, you can configure a LinkSys WRT54G (also WRT54GS and WRT54GL) router as an IPSec VPN endpoint. This IPSec VPN functionality is provided by an Openswan package that was built specifically for OpenWrt.

In this How To, I will show you how to create a VPN between a LinkSys WRT54GL and a LinkSys RV082 (RV042 could be used also).

As usual, if the post helps you, please leave me a comment!

Openswan vs Freeswan – What’s the difference?

Openswan is a fork of the Freeswan project. Apparently, Openswan has more features than Freeswan. Anyway, it’s moot because only Openswan has been ported to OpenWrt. Note that much of the Freeswan documentation, tips and how-tos also apply to Openswan.

Software and Hardware Versions

I used the following hardware and software versions for the OpenWrt end of the VPN tunnel:

• LinkSys WRT54GL v1.1 (serial number starts with CL7B).
• OpenWrt firmware version: White Russian RC6
• Openswan 2.4.4-1

On the other end of the VPN tunnel, I used:

• LinkSys RV082
• Stock firmware version: 1.3.3.5
• From skimming the GPL source code for that firmware version, it appears that it uses Freeswan (perhaps version 1.99) for its VPN server.

Network Diagram

This how-to was created in a “lab” environment. To simulate the internet we used private IP addresses. Here is the network diagram:

From the point of view of the WRT54G, the WRT54G side of the tunnel is called the local side or the left side and the RV082 side of the tunnel is called the remote side or the right side.

Here are the relevant IP addresses, as shown in the above network diagram:

• Left WAN interface (”left”) = 192.168.3.2
• Left LAN subnet (”leftsubnet”) = 192.168.2.0/24
• Left LAN interface (”leftsourceip”) = 192.168.2.1
• Right WAN interface (”right”) = 192.168.3.1
• Right LAN subnet (”rightsubnet”) = 192.168.1.0/24
• Right LAN interface (”rightsourceip”) = 192.168.1.1

Step 1: Configure the RV082 Side of the VPN

• Login to the RV082 Web Admin Site
• Browse the VPN page.
• Click the Add New Tunnel button. The following “Mode Choose” screen will appear. Click the Add Now near the top (i.e. in the Gateway to Gateway section).

• Enter the settings as shown on the following two screenshots, then press Save Settings:

Step 2: Configure the WRT54G Side of the VPN

• Install OpenWrt White Russian RC6, if you haven’t done so already.
• If necessary, update OpenWrt’s package list: ipkg update
• Install the openswan package: ipkg install openswan. ipkg should automatically detect and install openswan dependencies like kmod-openswan.
• Create the file /etc/ipsec.secrets, which will hold your preshared key. Here are the contents of my file (note that you can configure keys for specific tunnels or all tunnels):

# PSK for tunnel from specific ip to specific ip
#192.168.3.2 192.168.3.1: PSK "abc123"

# PSK for tunnel from any ip to any ip
: PSK "abc123"

• Edit the file /etc/ipsec.conf. Here are the contents of my file:

version 2.0     # conforms to second version of ipsec.conf specification

# basic configuration
config setup
    plutodebug="none"
    klipsdebug="none"
    nat_traversal=no
    interfaces=%defaultroute

# Add connections here
conn TestVPN
    authby=secret
    keyexchange=ike
    ikelifetime=480m
    keylife=60m
    pfs=yes
    left=192.168.3.2
    leftsubnet=192.168.2.0/24
    leftnexthop=%defaultroute
    right=192.168.3.1
    rightsubnet=192.168.1.0/24
    auto=start
    leftsourceip=192.168.2.1

#Disable Opportunistic Encryption
include /etc/ipsec.d/examples/no_oe.conf

• Edit /etc/firewall.user. Here is what I appended to the end of the file:

### IPSec VPN
# allow IPSEC
iptables -A input_rule -p esp -s 192.168.3.1              -j ACCEPT
# allow ISAKMP
iptables -A input_rule -p udp -s 192.168.3.1 --dport 500  -j ACCEPT
# allow NAT-T
iptables -A input_rule -p udp -s 192.168.3.1 --dport 4500 -j ACCEPT
# disable NAT for communications with remote LAN
iptables -t nat -A postrouting_rule -d 192.168.1.0/24     -j ACCEPT
# Allow any traffic between tunnel LANs
iptables -A forwarding_rule -i $LAN -o ipsec0 -j ACCEPT
iptables -A forwarding_rule -i ipsec0 -o $LAN -j ACCEPT

Step 3: Start up the Tunnel

• If you are starting the tunnel for the first time, you can start it by either rebooting the WRT54G, or by executing: /etc/init.d/S60ipsec --start

Step 4: Verify the Tunnel is Up

There are numerous ways to verify that the tunnel is up and working:

• RV082 System Log – You should see a message like this: Tunnel Negotiation Info - Quick Mode Phase 2 SA Established, IPSec Tunnel Connected
• RV082 VPN connection status (in the web admin tool) – The button in the “tunnel test” column should have the caption “Disconnect” and the “status” column should say “connected”. For example:

• ssh to the WRT54G and run the command ipsec auto --status. The output should look something like this:

000 #2: "TestVPN":500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 2514s; newest IPSEC; eroute owner
000 #2: "TestVPN" esp.82fdd248@192.168.3.1 esp.96ea10e4@192.168.3.2 tun.1002@192.168.3.1 tun.1001@192.168.3.2
000 #1: "TestVPN":500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 27519s; newest ISAKMP; lastdpd=0s(seq in:0 out:0)

What you want to see are the phrases are “ISAKMP SA established” and “IPSec SA established”, with the relevant connection name (in this case, “TestVPN”). Note that ipsec auto --status will tell you only what states have been achieved, rather than the current state. Since determining the current state is rather more difficult to do, current state information is not available from Linux FreeS/WAN. If you are actively bringing a connection up, the status report’s last states for that connection likely reflect its current state. Beware, though, of the case where a connection was correctly brought up but is now downed: Linux FreeS/WAN will not notice this until it attempts to rekey. Meanwhile, the last known state indicates that the connection has been established.

• ssh to the WRT54G and run the command logread. The output should look something like this:

Jan  1 00:05:13 (none) kern.warn pluto[1646]: "TestVPN" #1: initiating Main Mode
Jan  1 00:05:13 (none) kern.warn pluto[1646]: "TestVPN" #1: received Vendor ID
payload [Dead Peer Detection]
Jan  1 00:05:13 (none) daemon.err ipsec__plutorun: 104 "TestVPN" #1:
STATE_MAIN_I1: initiate
Jan  1 00:05:13 (none) daemon.err ipsec__plutorun: ...could not start conn
"TestVPN"
Jan  1 00:05:13 (none) kern.warn pluto[1646]: "TestVPN" #1: transition from
state STATE_MAIN_I1 to state STATE_MAIN_I2
Jan  1 00:05:13 (none) kern.warn pluto[1646]: "TestVPN" #1: STATE_MAIN_I2: sent
MI2, expecting MR2
Jan  1 00:05:13 (none) kern.warn pluto[1646]: "TestVPN" #1: I did not send a
certificate because I do not have one.
Jan  1 00:05:13 (none) kern.warn pluto[1646]: "TestVPN" #1: transition from
state STATE_MAIN_I2 to state STATE_MAIN_I3
Jan  1 00:05:13 (none) kern.warn pluto[1646]: "TestVPN" #1: STATE_MAIN_I3: sent
MI3, expecting MR3
Jan  1 00:05:13 (none) kern.warn pluto[1646]: "TestVPN" #1: Main mode peer ID is
ID_IPV4_ADDR: '192.168.3.1'
Jan  1 00:05:13 (none) kern.warn pluto[1646]: "TestVPN" #1: transition from
state STATE_MAIN_I3 to state STATE_MAIN_I4
Jan  1 00:05:13 (none) kern.warn pluto[1646]: "TestVPN" #1: STATE_MAIN_I4:
ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192
prf=oakley_md5 group=modp1024}
Jan  1 00:05:13 (none) kern.warn pluto[1646]: "TestVPN" #1: Dead Peer Detection
(RFC 3706): enabled
Jan  1 00:05:13 (none) kern.warn pluto[1646]: "TestVPN" #2: initiating Quick
Mode PSK+ENCRYPT+TUNNEL+PFS+UP {using isakmp#1}
Jan  1 00:05:13 (none) kern.warn pluto[1646]: "TestVPN" #2: Dead Peer Detection
(RFC 3706): enabled
Jan  1 00:05:13 (none) kern.warn pluto[1646]: "TestVPN" #2: transition from
state STATE_QUICK_I1 to state STATE_QUICK_I2
Jan  1 00:05:13 (none) kern.warn pluto[1646]: "TestVPN" #2: STATE_QUICK_I2: sent
QI2, IPsec SA established {ESP=>0x82fdd26a <0x454556ce xfrm="3DES_0-HMAC_MD5" natd="none" dpd="">

Again, what you want to see are the phrases are “ISAKMP SA established” and “IPSec SA established”.

• Ping the RV082’s LAN address from the WRT54G.
• Ping the WRT54G’s LAN address from the RV082.

Troubleshooting

If the connection does not come up:

• Check the VPN Log on the RV082. There might be some useful error messages.
• Check the dmesg log on the WRT54G (ssh to the WRT54G and run the command dmesg). For more verbose messages, try changing the plutodebug and klipsdebug settings in /etc/ipsec.conf from “none” to “all” or another supported log level. HOWEVER, please make sure to change both settings back to “none” when you have finished debugging otherwise the VPN performance will suffer a lot! You have been warned!

How to Get the VPN to Reconnect Automatically

If the WAN link between the two VPN endpoints goes down, the VPN link will go down too. To get the VPN to reconnect when the WAN link comes up again, you have two options:

• Enable the “Keep-Alive” setting on the “advanced” section of the VPN tunnel configuration on the RV082:

Note that this keep-alive setting does not seem to work if the WAN link is down for more than about 4 minutes. After that, you will probably have to manually reconnect the tunnel.

• Enable the “dead peer detection” settings on the WRT54G in the file /etc/ipsec.conf. The relevant settings are dpddelay, dpdtimeout and dpdaction. Please see the Openswan ipsec.conf man page for a description of each setting. According to the man page, those settings should have default values, however, they didn’t seem to work so I added them manually to ipsec.conf. Here are the settings I used:

dpddelay=10
dpdtimeout=30
dpdaction=hold

Note that the RV082 also has dead peer detection (DPD) but it does not seem to work like DPD on the WRT54G. Here is a description of the RV082’s DPD feature:

Dead Peer Detection (DPD): When DPD is enabled, the RV082 will send the periodic HELLO/ACK messages to prove the tunnel liveliness when both peers of VPN tunnel provide DPD mechanism. Once a dead peer detected, the RV082 will disconnect the tunnel so the connection can be re-established. The Interval is the number of seconds between DPD messages. The default is DPD enabled, and default Interval is 10 seconds.

As you can see, RV082 DPD only seems to remove the dead connection. It does not seem to try to reconnect. That’s what the RV082’s keep-alive feature is for, as described here:

Keep-Alive: This mechanism helps to keep up the connection of IPSec tunnels. Whenever a connection is dropped and detected, it will be re-established immediately.

The WRT54G’s DPD feature seems to do both jobs — disconnect the dead connect and reconnect.

I have found that a combination of the above strategies works well for keeping connections up. That is:

• Enable DPD on RV082
• Enable keep-alive on RV082
• Enable DPD on WRT54G

If those strategies don’t work, you can also try pinging each VPN endpoint periodically. This is a “roll your own” keep-alive solution.

How to Manually Reconnect the Tunnel

If the tunnel does not automatically reconnect after a WAN link goes down and comes back up, you can manually reconnect it from either side of the tunnel:

• To reconnect from the WRT54G side, ssh to the WRT54G and run /etc/init.d/S60ipsec restart. (Alternatively, you can reboot the WRT54G but this will bring down all WAN connectivity for a few seconds.)
• To reconnect from the RV082 side, press the tunnel’s Connect button on the VPN Summary page in the web admin tool. (Alternatively, you can reboot the RV082 but this will bring down all WAN connectivity for a few seconds.)

Split DNS on WRT Side of the Tunnel

Let’s say you have an internal DNS server on the RV side of the tunnel and you want all DNS lookups for the internal domain to be delegated to that DNS server but still have the WRT handle other (i.e. internet host) DNS lookups. The solution for this problem is to use a feature called split dns. Split DNS allows a DNS server to delegate lookups to another DNS server for certain domains.

To enable this feature, you need to add a “server” setting to the file /etc/dnsmasq.conf on the WRT (and, of course, you would need to restart dnsmasq). For example:

server=/internal.mydomain.com/192.168.1.145

internal.mydomain.com is the domain that you want to split requests for to the internal DNS server across the VPN. 192.168.1.145 is the address of that DNS server.

Joining a Domain on WRT Side of the Tunnel

Let’s say you have an active directory domain controller on the RV side of the tunnel and you have a computer on the WRT side that you want to join to the domain.

To join a domain across the VPN, you need to add a “srv-host” setting to the file /etc/dnsmasq.conf (and, of course, you would need to restart dnsmasq). For example:

srv-host=_ldap._tcp.dc._msdcs.internal.mydomain.com
,mydomaincontroller.internal.mydomain.com,389,0,100

In this example, mydomaincontroller.internal.mydomain.com is the name of the domain controller and internal.mydomain.com is the domain. I’m not sure if this only works with active directory or if it also works with NT4 domains. I leave that as an exercise to the reader.

Links

Following are some useful how-to and informational links about installing and running Openswan on a WRT54G. Note that none of these links provide a comprehensive how-to. I had to piece together information from all of these links to create this page.

• Openswan
• The VPN Follies (Part 1) — Terminating VPN Connections with Linux and other Stuff — Introduction
• VPN Follies Part 2 — Linux 2.4, OpenSWAN, and WRT54G
• IPSec on OpenWrt – from the OpenWrt Wiki
• Openswan ipsec.conf man page
• Openswan ipsec.secrets man page
• resolv.conf man page
• dnsmasq setup
• Openswan wiki
• Can I use Network Neighborhood (Samba, NetBIOS) over IPsec?
• Configuring Linux VPNs

Addendum

For some corrections and further information about this how-to, please see the following:

• A Virtual Visit from Paul Wouters