This page is about racoon. The new strongswan documentation can be found here.

In the last years SSL VPN Networks made a good job in replacing classic IPsec road warrior clients. Although having some drawbacks a combination of the free ShrewSoft VPN client with an IPsec central site getway still does a good job. As a matter of form this article expands the possible VPN setups to a new scope. Once again you should have some know how of the basic and firewall setup.

Contrary to the previous articles about site to site neworks we want to allow different computers with a locally installed IPsec client access to the network behind the OpenWrt router. A picture will give a helpful overview.

The most important facts are:

• To make it not too easy we once again want to provide access to two different company networks. ACME LAN with addresses 10.1.2.0/24 and ACME DMZ with 66.77.88.192/26.
• A laptop that connects to a VPN network is assigned a “secondary VPN inside IP” on a virtual VPN adapter. Our roadwarriors should get IP addresses from the range 192.0.2.0/24. This way they can reach the normal outside network when using the primary network adapter and the company network through their virtual address 192.0.2.X. (*NOTE* that this is inherently INSECURE, because it opens up the possibility of using the laptop as a bridge from the wild to your internal network. A more secure practice is to pass ALL traffic through the VPN when connected, thus giving the laptop the benefit of any firewall/proxy support on the other side.) In case you are not familiar with private IP address ranges you should have look in Wikipedia. If you are in the wild your laptop very often gets DHCP addresses from the most common private networks (10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16). To avoid routing conflicts between the locally connected and the VPN network this special test network has proven to be the best choice for VPN configurations.

We already learned that site to site IPsec tunnels use authentication based on preshared keys or certificates. Both of them share a small imperfection when used for roadwarriors - they have no user related secret. When the administrator installs the VPN client he stores the preshared key or the certificate on the road warrior laptop. So any user that has access to the laptop and the stored data can connect to the company network. This encourages a two way authentication process. After phase 1 has completed the user should be asked for a password. The hybrid IPsec authentication process (also called Xauth) provides what we need.

Let us start with the user road warrior database that is stored in UCI file /etc/config/users. Have look over there for further details. As an example we create user otto and enable him for IPsec.

config 'user'
  option 'enabled' '1'
  option 'name' 'otto'
  option 'password' 'this_is_ottos_password'
  option 'xauth' '1'

Attention: This user database combined with preshared key authentication depends on three prerequisites:

• racoon user database patch not yet in trunk. It allows racoon to read users and their passwords from a plain file.
• racoon start script of at least version 13. Generates a user/password file from /etc/config/users.
• racoon patch that allows racoon to accept road warrior connections with one single preshared key.

If you cannot compile racoon with those patches yourself you have to wait until both of them are in trunk. A workaround could be users stored in /etc/passwd but this is something that we normally do not want. Other ways are LDAP or Radius.

Until now we always had defined tunnel endpoints for site to site IPsec connections. So we could generate security policies in advance. With a road warrior setup this is no longer possible. But that is no problem at all. Pre loaded security policies in the kernel are only important to open VPN tunnels from the OpenWrt router to a remote VPN router. If they are not available the device will simply send packets into the internet without encryption. In our case the tunnel will be established by a remote laptop. After the tunnel is active racoon can generate the required policies.

Or to explain it the other way round. All laptops will be assigned IP addresses of a predefined range. If we would create a security policy that routes all of the traffic of this range into one tunnel we cannot have more than one connected machine. Instead each tunnel will only route traffic for a single IP address. This is the simple difference between a site to site and a road warrior configuration.

What is important for us? Nothing - just a little background information. Our racoon start script will take care of the different variants.

Split tunnel describes the fact, that a connected laptop will only send VPN related traffic through the tunnel. All other request will go directly to the internet. This may be a potential security risk and very often VPN laptop clients will route all traffic into the tunnel. At the current development state only a split tunnel setup is possible. The two main reasons are:

• Split tunnel will save bandwidth of the central side OpenWrt gateway. Otherwise each packet from the laptop to the internet has to pass the tunnel before the gateway will sent it to the outside world.
• It requires less routing and firewall policies on the gateway.

But we just have started. Maybe someone has time to implement and document it.

Being connected to the company network it is helpful to have a working name resolution for internal hostnames. We want to use a central configuration and free the road warriors from manual DNS setup. Racoon allows to push the DNS configuration to the IPsec client after connection has been established. Our /etc/init.d/racoon start script takes care of that if we make a proper configuration. Therefore insert the dns and domain options into the racoon secion of /etc/config/racoon.

config 'racoon'
  option 'dns' '10.1.2.99'
  option 'domain' 'acme.inc'

With these parameters the virtual Shrew VPN network interface will be assigned domain acme.inc and the DNS server 10.1.2.99. If you use OpenWrt DNS and set this option to the internal router IP address do not forget to create a rule VPN→Device UDP 53 and place it on top to the other VPN rules.

If you are already familiar with UCI racoon configuration you will not see many differences for our setup. No rocket science at all. Here the required information for our ACME infrastructure.

...
config 'tunnel' 'roadwarrior'
  option 'enabled' '1'
  option 'remote' 'anonymous'
  option 'exchange_mode' 'aggressive'
  option 'pre_shared_key' 'a_very_secret_key'
  option 'dpd_delay' '300'
  list   'p1_proposal' 'pre_g2_3des_sha1_xauth'
  list   'sainfo' 'acme_dmz'
  list   'sainfo' 'acme_lan'

config 'sainfo' 'acme_lan'
  option 'remote_subnet' '192.0.2.0/24'
  option 'local_subnet' '10.1.2.0/24'
  option 'p2_proposal' 'g2_aes_sha1'

config 'sainfo' 'acme_dmz'
  option 'remote_subnet' '192.0.2.0/24'
  option 'local_subnet' '66.77.88.192/26'
  option 'p2_proposal' 'g2_aes_sha1'

config 'p1_proposal' 'pre_g2_3des_sha1_xauth'
  option 'lifetime' '28800'
  option 'encryption_algorithm' '3des'
  option 'hash_algorithm' 'sha1'
  option 'authentication_method' 'xauth_psk_server'
  option 'dh_group' '2'

config 'p2_proposal' 'g2_aes_sha1'
  option 'pfs_group' '2'
  option 'lifetime' '3600'
  option 'encryption_algorithm' 'aes'
  option 'authentication_algorithm' 'hmac_sha1'
...

A little explanation of the key facts.

• We define a new tunnel, give it the name 'roadwarrior' and enable it. The name is just for readability and has no special meaning.
• With remote=anonymous we tell the start script that this tunnel is for roadwarriors. This declaration can only be used for one enabled tunnel definition in the whole config file.
• As usual the exchange mode, the preshared key, a phase one proposal and at least one sainfo block must be referenced.
• The phase one proposal has to be defined with xauth_psk_server. This activates hybrid preshared key and xauth authentication. The other settings are more or less up to your favourites.
• For each network the road warriors want to reach we define a sainfo block. In our case one for LAN and one for DMZ. The remote_subnet section of the sainfo block defines the laptop IP range. It must be the same for all road warrior sainfo blocks. The racoon start and firewall scripts will evaluate this parameter and will do everything that is required. The local_subnet section defines the network that the remote users can reach through the tunnel.

Like in all previous chapters the firewall configuration is very simple. Our central firewall setup script will make all required settings to add the remote laptops into the VPN zone. So we only need rules to allow VPN traffic from remote laptops into the intranet and the DMZ. As an example we create two rules. One “allow all” for the internal network and one rule for the ACME mailserver that has IP address 66.77.88.195 in the DMZ.

Remark! If you want to use any services on your OpenWrt router through the IPsec tunnel you have to address its interfaces on the local networks. Only those IP addresses can be routed into the VPN due to the auto generated policies. As an example let us assume OpenWrt runs a time service (NTP) and has the internal IP 10.1.2.1. So we need a firewall rule vpn:192.0.2.0/24 → device port 123 UDP. On the road warrior clients we have to set NTP to IP 10.1.2.1.

On the Shrew client side we have to build exactly the same IPsec setup. Add a new connection called “ACME Inc.” and follow the screenshots below. A small explanation for each of the dialogues for the Shrew newbies.

1. The general settings gives the IP address of the central site OpenWrt router. The pull option tells the client to obtain the setup from racoon. The network device will be configured automatically too.
2. The client tab was left with default options.
3. Name resolution will be taken from racoon setup.
4. Authentication is set to PSK + XAuth. Local identifier is not relevant as racoon will accept any client
5. Remote Identity is not checked as we are working with a static VPN gateway IP address.
6. On the credentials page the preshared key is entered
7. Phase 1 is set correspondingly to racoon
8. Phase 2 also matches racoon setup
9. IPsec policies will be pulled from racoon. This gives an automatic split tunnel setup.

A double click on our new ACME Inc. connection will open the connection dialogue. There you have to provide your Xauth user and password and afterwards click on “Connect”. The rest should work automatically. To verify that everything is fine you can have a look at ipconfig /all. It should provide some output like this.

Only one thing left. A road warrior configuration with certificates.