November 2, 2010

Fedora as IPSEC/L2TP VPN Server for Mac and Android

Now this is probably one of the most unrelated posts one could think off (considering my other posts about programming) but I just have to write this down because I am almost a 100% certain that other people have exactly the same problem. Recently we reinstalled one of our office servers and we finally wanted to have a IPSEC/L2TP server as both Android, Mac and iPhones support it natively.

The configuration always seemed a bit overwhelming and whenever I tried, I always failed miserably to get it to work. On top of that, I just couldn't find any easy explanation on the web guiding me through a Road Warrior to NATted VPN Server installation.

In the end, I finally give it a good try and was surprised getting it to work. This guide is for Fedora 13 and Fedora 14 (both have the most recent Kernel, OpenSwan and xl2tpd packages that I found are needed).

So, some background. Most of the clients will be "road warriors" (apparently that is what it's called...) with dynamic IPs and often behind NATting firewalls. Also, our server is behind a firewall using NAT and since I am a bit lazy I am going with L2TP with a PSK (pre-shared key) rather than certificates.

Installing the necessary packages

The first step is to install the necessary packages in Fedora.

yum install openswan xl2tpd

Configure Openswan

Now check out the /etc/ipsec.conf, so far it's missing important bits but it already has an incomplete config setup section. Your file should read something like this:

version 2.0

config setup
        protostack=netkey
        nat_traversal=yes
        virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16:,%v4:!{your local subnet}
        oe=off
        nhelpers=0

conn L2TP-PSK
        authby=secret
        pfs=no
        auto=add
        keyingtries=3
        rekey=no
        ikelifetime=8h
        keylife=1h
        type=transport
        left={your server's internal IP}
        leftprotoport=17/1701
        leftnexthop={your network's gateway IP}
        right=%any
        rightprotoport=17/0
        rightsubnet=vhost:%no,%priv

Replace the occurrences of {your xxx} with the correct IP addresses.

Now you also have to add a file in /etc/ipsec.d. You can name it anything you like, however, it needs the extension .secrets and it will contain your pre-shared key. The content of the file should be

{your server's internal IP} %any: "a_key_that_is_at_least_8_characters_long"

Just to make sure that everything is right, type

service ipsec start

followed by

ipsec verify

Everything should be "green" except opportunistic encryption, which should be disabled.

Configure xl2tpd

The default configuration provided by the xl2tpd RPM is actually quite complete; however, you must make sure that ipsec saref = yes is uncommented (remove the semicolon in the beginning of the line) and that the ip range is outside an actively used ip range. I.e. if your DHCP server assigns IPs between 192.168.10.10 and 192.168.10.100 you can use 192.168.10.150-192.168.10.200. Also, xl2tpd needs a local ip which is used for communication with PPP and given that you have the IP-setup from my example you could simply use 192.168.10.101.

Configuring PPP

You can configure PPP to check for passwords with PAM, however, let's keep it very simple for now. Add following to /etc/ppp/chap-secrets

testuser * testpassword *

Also, if you are using Windows VPN clients you should also take a look at /etc/ppp/options.xl2tpd and verify that all ms-dns entries point to the correct nameservers ( your own? ;-) ). I am actually not sure if other clients (other than Windows) care about these entries, but it won't hurt having this set correctly...

Wrapping up

Now start xl2tpd using following command:

service xl2tpd start

Hopefully it'll start just fine and if it does, you are good to fix the final things needed.

First, make sure that clients can connect on port 500 and 4500 (both UDP) on your server (i.e., open those ports in your firewall).

Second, you can make the VPN server start on boot by executing

chkconfig ipsec on

and

chkconfig xl2tpd on

That's basically it, you can now use your L2TP/IPSEC VPN client and try to connect. The username and password will be testuser and testpassword while the pre-shared key will be, well, whatever you've set it to (a_key_that_is_at_least_8_characters_long if you followed the example).

Good luck!

UPDATE

I actually forgot to mention that you should check your /etc/sysctl.conf. If not already present, add following to the file:

net.ipv4.ip_forward = 1
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.default.send_redirects = 0

7 comments:

Anonymous said...

Hi,

Your post is good. However i had to struggleto get my ICP send redirects working. ALso, i am not able to establsh the connection still as no tunnels are running when i do service ipsec status. Could you please let meknow how do i configure my tunnels?

Daniel Pfeifer said...

It seems I forgot to add that you have to add following three lines to the /etc/sysctl.conf:

net.ipv4.ip_forward = 1
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.default.send_redirects = 0

Cheers!

pasan said...

Thanks for the good write up. Other than few hiccups, managed to get IPSec and L2TP setup on Fedora 14. One of the stumbling blocks was if you have selinux enabled, you need to allow Masquerading for your eth device! This gave me some grief until I figured it out.

Anonymous said...

Thanks for the instructions. I am able to setup a VPN connection but I am having problems with the PSK. I seem to be able to establish a VPN connection even if I do not specify a PSK in my connection configuration from the client.

Anonymous said...

In response to my request above. I figured out that I was in fact only making a connection over L2TP as I opened port 1701 on my firewall - my error.
My problems have now progress to seeing an IPSEC connection initiated but receiving errors like "ignoring Vendor ID payload"

Anonymous said...

The "Vendor ID payload" I get, too... at least when connecting with my Mac. It still works, though.

Anonymous said...

seems like I keep getting the

no connection have been authorized with this policy=PSK problem, do you have a solution for it ?