Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


[Tutorial] IPSEC/L2TP VPN on Ubuntu 14.04
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

[Tutorial] IPSEC/L2TP VPN on Ubuntu 14.04

This is a guide on setting up an IPSEC/L2TP vpn server with Ubuntu 14.04 using Openswan as the IPsec server, xl2tpd as the l2tp provider and ppp or local users / PAM for authentication. It has a detailed explanation with every step. We choose the IPSEC/L2TP protocol stack because of recent vulnerabilities found in pptpd VPNs and because it is supported on all major operating systems by default. More than ever, your freedom and privacy when online is under threat. Governments and ISPs want to control what you can and can't see while keeping a record of everything you do, and even the shady-looking guy lurking around your coffee shop or the airport gate can grab your bank details easier than you may think. A self hosted VPN lets you surf the web the way it was intended: anonymously and without oversight.

Why a VPN?

More than ever, your freedom and privacy when online is under threat. Governments and ISPs want to control what you can and can't see while keeping a record of everything you do, and even the shady-looking guy lurking around your coffee shop or the airport gate can grab your bank details easier than you may think. A self hosted VPN lets you surf the web the way it was intended: anonymously and without oversight.

A VPN (virtual private network) creates a secure, encrypted tunnel through which all of your online data passes back and forth. Any application that requires an internet connection works with this self hosted VPN, including your web browser, email client, and instant messaging program, keeping everything you do online hidden from prying eyes while masking your physical location and giving you unfettered access to any website or web service no matter where you happen to live or travel to.

This tutorial is available for the following platforms:

This tutorial was written and tested on a Digital Ocean VPS. They've added Ubuntu 14.04 as a supported image right away when it was released! If you like this tutorial and want to support my website, use this link to order a Digital Ocean VPS: https://www.digitalocean.com/?refcode=7435ae6b8212

IPSec encrypts your IP packets to provide encryption and authentication, so no one can decrypt or forge data between your clients and your server. L2TP provides a tunnel to send data. It does not provide encryption and authentication though, that is why we need to use it together with IPSec.

To work trough this tutorial you should have:

  • 1 Ubuntu 14.04 server with at least 1 public IP address and root access
  • 1 (or more) clients running an OS that support IPsec/L2tp vpns (Ubuntu, Mac OS, Windows, Android).
  • Ports 1701 TCP, 4500 UDP and 500 UDP opened in the firewall.

I do all the steps as the root user. You should do to, but only via * -i* or * su -*. Do not allow root to login via SSH!

Install ppp openswan and xl2tpd

First we will install the required packages:

apt-get install openswan xl2tpd ppp lsof

The openswan installation will ask some questions, this tutorial works with the default answers (just enter through it).

Firewall and sysctl

We are going to set the firewall and make sure the kernel forwards IP packets:

Execute this command to enable the iptables firewall to allow vpn traffic:

iptables --table nat --append POSTROUTING --jump MASQUERADE

Execute the below commands to enable kernel IP packet forwarding and disable ICP redirects.

echo "net.ipv4.ip_forward = 1" |  tee -a /etc/sysctl.conf
echo "net.ipv4.conf.all.accept_redirects = 0" |  tee -a /etc/sysctl.conf
echo "net.ipv4.conf.all.send_redirects = 0" |  tee -a /etc/sysctl.conf
echo "net.ipv4.conf.default.rp_filter = 0" |  tee -a /etc/sysctl.conf
echo "net.ipv4.conf.default.accept_source_route = 0" |  tee -a /etc/sysctl.conf
echo "net.ipv4.conf.default.send_redirects = 0" |  tee -a /etc/sysctl.conf
echo "net.ipv4.icmp_ignore_bogus_error_responses = 1" |  tee -a /etc/sysctl.conf

Set these settings for other network interfaces:

for vpn in /proc/sys/net/ipv4/conf/*; do echo 0 > $vpn/accept_redirects; echo 0 > $vpn/send_redirects; done

Apply them:

sysctl -p
Persistent settings via /etc/rc.local

To make sure this keeps working at boot you might want to add the following to /etc/rc.local:

for vpn in /proc/sys/net/ipv4/conf/*; do echo 0 > $vpn/accept_redirects; echo 0 > $vpn/send_redirects; done
iptables --table nat --append POSTROUTING --jump MASQUERADE

Add it before the exit 0 line.

Read on over at Raymii.org

Comments

  • Thanks for writing this guide! A question bugs my mind though. Some people have advised me to switch from OpenVPN to an IPsec-based VPN - what's the advantage of the latter over the former?

  • GaNiGaNi Member

    @iceTwy said:
    Thanks for writing this guide! A question bugs my mind though. Some people have advised me to switch from OpenVPN to an IPsec-based VPN - what's the advantage of the latter over the former?

    Nicely elaborated at https://www.ivpn.net/pptp-vs-l2tp-vs-openvpn

    Thanked by 1souen
  • iceTwy said: Thanks for writing this guide! A question bugs my mind though. Some people have advised me to switch from OpenVPN to an IPsec-based VPN - what's the advantage of the latter over the former?

    IPSEC/L2TP is supported without extra clients on Windows, OS X, iOS and Android.

    OpenVPN allows an obfuscated VPN, allows other ports (443 for example) and it is (IMHO) easier to set up OpenVPN with certificate based login.

    Thanked by 1souen
  • @GaNi said:

    So LT2P with IPsec is compatible on more platforms than OpenVPN but it's a bit slower, right? Is there any comparison for the performance?

  • GaNiGaNi Member
    edited April 2014

    @iceTwy said:

    I've yet to try L2TP (I couldn't manage to get it work CentOS->MacBook, had been getting authorization error even though I've had it setup correctly), primarily gonna use it as tunnel for gaming purpose so speed/stability is what I was looking for. OpenVPN has connection drops for about few seconds which is a fatal in a mmorpg game. Gonna try this guide on another box and see if it works and observe the performance.

  • @iceTwy said:
    So LT2P with IPsec is compatible on more platforms than OpenVPN but it's a bit slower, right? Is there any comparison for the performance?

    Set both up and do some measurements. It will also depend on your own internet connection.

    GaNi said: I've yet to try L2TP (I couldn't manage to get it work CentOS->MacBook, had been getting authorization error even though I've had it setup correctly), primarily gonna use it as tunnel for gaming purpose so speed/stability is what I was looking for. OpenVPN has connection drops for about few seconds which is a fatal in a mmorpg game. Gonna try this guide on another box and see if it works and observe the performance.

    Here's a tutorial I also wrote for CentOS 6, which works with a Macbook on OS X 10.8 and 10.9 (tested by myself, hehe): https://raymii.org/s/tutorials/IPSEC_L2TP_vpn_on_CentOS_-Red_Hat_Enterprise_Linux_or_Scientific-_Linux_6.html

  • NyrNyr Community Contributor, Veteran

    GaNi said: OpenVPN has connection drops for about few seconds which is a fatal in a mmorpg game

    That's a problem on your end.

    You can even choose between TCP and UDP with OpenVPN, so you got extra means to deal with not-reliable connections vs reliable connections where speed is a priority.

    Not that L2TP with IPsec is a bad election at all, but OpenVPN is more flexible.

  • Is this possible on an OpenVZ VPS?
    If yes, which modules need to be enabled?

  • jimmyvujimmyvu Member
    edited April 2014

    Well, common mistake(serious security hole)

    iptables -t nat -A POSTROUTING -j MASQUERADE

    This works from your LAN, but allows outsiders to masquerade through your firewall.

    Thanked by 1Droidzone
  • GaNiGaNi Member
    edited April 2014

    @Nyr said:
    Not that L2TP with IPsec is a bad election at all, but OpenVPN is more flexible.

    That's the whole reason I am sticking to OpenVPN, in fact I'm using your debian script ;)

    I am pretty sure there's no problem on my end. I have pings running simultaneously to various server just to ensure it's not my connection dropping but the VPN itself.

    PS: I am on UDP since it's more reliable than TCP when it comes to latency (iirc)

  • @jimmyvu said:
    Well, common mistake(serious security hole)

    iptables -t nat -A POSTROUTING -j MASQUERADE

    This works from your LAN, but allows outsiders to masquerade through your firewall.

    Tell me more?

  • NyrNyr Community Contributor, Veteran

    @GaNi said:

    Then maybe there's a problem on the connection between you and the server or between the server and the destination. Maybe a mtr can help you locate some packet loss, but I still don't think it's a software problem.

    UDP is better latency-wise yeah, but TCP is more reliable if you want a stable connection. Since you have reliability issues, I would recommend switching to TCP and testing, even when it will not solve bigger problems (like long network cuts). If you want to try, just edit proto udp to proto tcp in the server.conf and client.conf files and do /etc/init.d/openvpn restart on the server.

  • howardsl2howardsl2 Member
    edited April 2014

    @Raymii said:

    I guess @jimmyvu was saying that it is safer to use SNAT only so that people from the outside world cannot initiate new connections through your VPN server. Here are the relevant IPTables rules in my IPsec/L2TP VPN Auto Setup Script for Ubuntu 12.04. Also see my GitHub Gist here.

    *filter
    :INPUT ACCEPT [0:0]
    :FORWARD ACCEPT [0:0]
    :OUTPUT ACCEPT [0:0]
    ... ...
    -A FORWARD -i eth+ -o ppp+ -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
    -A FORWARD -i ppp+ -o eth+ -j ACCEPT
    -A FORWARD -j DROP
    ... ...
    COMMIT
    *nat
    :PREROUTING ACCEPT [0:0]
    :INPUT ACCEPT [0:0]
    :OUTPUT ACCEPT [0:0]
    :POSTROUTING ACCEPT [0:0]
    -A POSTROUTING -s 192.168.42.0/24 -o eth+ -j SNAT --to-source ${PRIVATE_IP}
    COMMIT
    

    In the rules above 192.168.42.0/24 is the range of your VPN network, and ${PRIVATE_IP} is your server's local IP. If you set up SNAT without DNAT and accepts only established connections from eth+ to ppp+, this ensures that the outside world cannot initiate new connections through your VPN back to your PC or phone, or whatever. Otherwise if you use MASQUERADE, they can attack your device from the outside.

    Thanked by 1souen
  • hwdsl2 said: I guess @jimmyvu was saying that it is safer to use SNAT only so that people from the outside world cannot initiate new connections through your VPN server.

    Explain this a bit more please? How would one do that then? I've got the MASQ rule from Red Hat documentation on iptables...

    I've changed it to SNAT, which also works, however, I'd like to see some more information or sources on MASQ not being secure. My google fuu did not find that much...

  • I'm looking for exactly the same guide but with Strongswan instead of Openswan. Stronswan is leaner (no L2TP required, connection is established instantly) and actively maintained. But I have been unable to set it up using XAUTH in 14.04, the package structure seem to have changed.

  • howardsl2howardsl2 Member
    edited April 2014

    @Raymii said:

    It looks like I did not explain it clearly in my previous post... Actually the problem is NOT with MASQUERADE vs. SNAT. They are basically the same except that MASQUERADE is easier to use with a dynamic server IP (does not require you to specify it).

    Upon searching on Google I finally found out the problem - for security one should ALWAYS specify an out interface (and source subnet, see example below) in a MASQUERADE or SNAT rule. see the following post for reference:
    http://www.linuxquestions.org/questions/linux-security-4/iptables-dnat-snat-and-masquerading-264649/#post1343099

    Quote:
    "WARNING.. MASQ may work in either direction if your rules are too simple BAD EXAMPLE: iptables -t nat -A POSTROUTING -j MASQUERADE. Always specify an (-o) out interface as a minimum guide."

    To fellow LETers - If you have a VPN server, for security, double check your IPTables SNAT or MASQUERADE rule. It should specify the source subnet and out interface (e.g. -s VPN_NETWORK_RANGE -o eth+).

    Thanked by 2Raymii souen
  • I wish that L2TP had a custom port option :(

  • hwdsl2 said: It looks like I did not explain it clearly in my previous post... Actually the problem is NOT with MASQUERADE vs. SNAT. They are basically the same except that MASQUERADE is easier to use with a dynamic server IP (does not require you to specify it).

    Upon searching on Google I finally found out the problem - for security you should ALWAYS specify an outbound interface (e.g. -o eth+) in a MASQUERADE or SNAT rule. see the following post for reference:

    http://www.linuxquestions.org/questions/linux-security-4/iptables-dnat-snat-and-masquerading-264649/#post1343099

    Quote:

    "WARNING.. MASQ may work in either direction if your rules are too simple iptables -t nat -A POSTROUTING -j MASQUERADE. Always specify an (-o) out interface as a minimum guide."

    To fellow LETers - If you have a VPN server, for security, double check your IPTables SNAT or MASQUERADE rule. It should specify the out interface (e.g. -s VPN_NETWORK_RANGE -o eth+).

    Thanks! I've updated the tutorial.

  • arnearne Member

    Hi!
    I have tried to follow this tutorial but can't make it work.
    Any help appreciated.
    My test environment in very easy:

    Windows 8.1 laptop 192.168.10.190 <--> wifi router <--> ubuntu-ipsec-server 192.168.10.14.

    An extract of the ipsec.conf looks like this:

    conn L2TP-PSK-NAT
    rightsubnet=vhost:%priv
    also=L2TP-PSK-noNAT
    
    conn L2TP-PSK-noNAT
    authby=secret
    #shared secret. Use rsasig for certificates.
    ...
    type=transport
    #because we use l2tp as tunnel protocol
    
    left=192.168.10.14
    #fill in server IP above
    
    #leftprotoport=17/1701
    leftprotoport=17/%any
    right=%any
    rightprotoport=17/%any
    

    Note that I have tried both with and without setting the leftprotoport.
    Also note that I have added the L2TP-PSK-NAt block at the top.

    xl2tpd.conf looks like this:

    [global]
    ipsec saref = yes
    saref refinfo = 30
    
    [lns default]
    ip range = 172.16.1.30-172.16.1.100
    local ip = 172.16.1.1
    refuse pap = yes
    require authentication = yes
    ppp debug = yes
    pppoptfile = /etc/ppp/options.xl2tpd
    length bit = yes
    

    When starting up xl2tpd I get the following message in syslog:
    ubuntu-ipsec xl2tpd[2160]: Listening on IP address 0.0.0.0, port 1701
    Is this ok?

    The result of ipsec verify is the same as yours.

    I have made a simple chap setup with password set in chap secrets:

    # client    server  secret          IP addresses
    arne        l2tpd   <cleartextpwd>          *
    

    The firewall has been opened as described in your howto.
    iptables has been setup as described with the -o option added:

    arne@ubuntu-ipsec:/etc/ppp$ sudo iptables -t nat -S
    -P PREROUTING ACCEPT
    -P INPUT ACCEPT
    -P OUTPUT ACCEPT
    -P POSTROUTING ACCEPT
    -A POSTROUTING -o eth+ -j MASQUERADE
    

    When trying to connect from the laptop I get the following error message on the laptop:

    Error 789: The L2TP connection attempt failed because the security layer encoutnered a processing error during initial negotiations with the remote computer.
    

    The auth.log looks like this:

    Jul  8 13:13:34 ubuntu-ipsec pluto[1957]: packet from 192.168.10.190:500: ignoring unknown Vendor ID payload [01528bbbc00696121849ab9a1c5b2a5100000001]
    Jul  8 13:13:34 ubuntu-ipsec pluto[1957]: packet from 192.168.10.190:500: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000009]
    Jul  8 13:13:34 ubuntu-ipsec pluto[1957]: packet from 192.168.10.190:500: received Vendor ID payload [RFC 3947] method set to=115 
    Jul  8 13:13:34 ubuntu-ipsec pluto[1957]: packet from 192.168.10.190:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 115
    Jul  8 13:13:34 ubuntu-ipsec pluto[1957]: packet from 192.168.10.190:500: ignoring Vendor ID payload [FRAGMENTATION]
    Jul  8 13:13:34 ubuntu-ipsec pluto[1957]: packet from 192.168.10.190:500: ignoring Vendor ID payload [MS-Negotiation Discovery Capable]
    Jul  8 13:13:34 ubuntu-ipsec pluto[1957]: packet from 192.168.10.190:500: ignoring Vendor ID payload [Vid-Initial-Contact]
    Jul  8 13:13:34 ubuntu-ipsec pluto[1957]: packet from 192.168.10.190:500: ignoring Vendor ID payload [IKE CGA version 1]
    Jul  8 13:13:34 ubuntu-ipsec pluto[1957]: "L2TP-PSK-NAT"[12] 192.168.10.190 #12: responding to Main Mode from unknown peer 192.168.10.190
    Jul  8 13:13:34 ubuntu-ipsec pluto[1957]: "L2TP-PSK-NAT"[12] 192.168.10.190 #12: OAKLEY_GROUP 20 not supported.  Attribute OAKLEY_GROUP_DESCRIPTION
    Jul  8 13:13:34 ubuntu-ipsec pluto[1957]: "L2TP-PSK-NAT"[12] 192.168.10.190 #12: OAKLEY_GROUP 19 not supported.  Attribute OAKLEY_GROUP_DESCRIPTION
    Jul  8 13:13:34 ubuntu-ipsec pluto[1957]: "L2TP-PSK-NAT"[12] 192.168.10.190 #12: Oakley Transform [OAKLEY_AES_CBC (256), OAKLEY_SHA1, OAKLEY_GROUP_MODP2048] refused due to strict flag
    Jul  8 13:13:34 ubuntu-ipsec pluto[1957]: "L2TP-PSK-NAT"[12] 192.168.10.190 #12: Oakley Transform [OAKLEY_3DES_CBC (192), OAKLEY_SHA1, OAKLEY_GROUP_MODP2048] refused due to strict flag
    Jul  8 13:13:34 ubuntu-ipsec pluto[1957]: "L2TP-PSK-NAT"[12] 192.168.10.190 #12: Oakley Transform [OAKLEY_3DES_CBC (192), OAKLEY_SHA1, OAKLEY_GROUP_MODP1024] refused due to strict flag
    Jul  8 13:13:34 ubuntu-ipsec pluto[1957]: "L2TP-PSK-NAT"[12] 192.168.10.190 #12: no acceptable Oakley Transform
    Jul  8 13:13:34 ubuntu-ipsec pluto[1957]: "L2TP-PSK-NAT"[12] 192.168.10.190 #12: sending notification NO_PROPOSAL_CHOSEN to 192.168.10.190:500
    Jul  8 13:13:34 ubuntu-ipsec pluto[1957]: "L2TP-PSK-NAT"[12] 192.168.10.190: deleting connection "L2TP-PSK-NAT" instance with peer 192.168.10.190 {isakmp=#0/ipsec=#0}
    

    Based on a wireshark dump it looks like the client and server is in connection according to the auth.log above:

     No.    Source            Destination    Protocol    Info
     9     192.168.10.190    192.168.10.14    ISAKMP    Identity Protectoin (Main Mode)
    10     RealtekU....      Axurewav...      ARP       191.168.10.14 is at 52:...
    11     192.168.10.14     192.168.10.190   ISAKMP    Informational
    12     192.168.10.190    192.168.10.14    ISAKMP    Identity Protectoin (Main Mode)
    13     192.168.10.14     192.168.10.190   ISAKMP    Informational
    14     192.168.10.190    192.168.10.14    ISAKMP    Identity Protectoin (Main Mode)
    15     192.168.10.14     192.168.10.190   ISAKMP    Informational
    

    The rest is some ARP messages and BROWSER announcements.

    What am I doing wrong?

    Br,

    Arne

  • arnearne Member

    One step further! :-)

    The clue here is the error messages in the Auth.log where all the Oakley Transforms are rejected.

    In Raymiis Ipsec on Ubuntu 14.04 tutorial he has the following config in ipsec.conf:

    ike=aes256-sha1;modp1024!
    

    After commenting out this and opening the firewal for ESP I got connected! :-)
    So it seems like Windows 8.1 is not happy with this setting.

    Next thing to figure out is how to fix that the client is blocked from DNS lookup through the VPN:

    ubuntu-ipsec kernel: [77585.914784] [UFW BLOCK] IN=ppp0 OUT=eth0 MAC= SRC=172.16.1.30 DST=8.8.8.8 LEN=62 TOS=0x00 PREC=0x00 TTL=127 ID=25801 PROTO=UDP SPT=53997 DPT=53 LEN=42
    

    Arne

  • howardsl2howardsl2 Member
    edited July 2014

    @arne said:

    For the IKE Oakley issue, take a look at:
    https://lists.openswan.org/pipermail/users/2014-April/022947.html

    Regarding the DNS lookup problem try adding a UFW NAT rule to unblock forwarding of UDP port 53.

  • I'd recommend using plain IPSec without L2TP. It's more likely to traverse NAT and just more simple.

    Strongswan is actively maintained, so I would recommend it over openswan. Racoon is another good choice.

    If you're using OpenVZ, you almost never can use IPSec (only on individual providers like BuyVM, who can enable modules for you). You can use user-space IPSec implementations, like SoftEther or RockHopper.

  • RaymiiRaymii Member

    @hwdsl2 said:
    Regarding the DNS lookup problem try adding a UFW NAT rule to unblock forwarding of UDP port 53.

    I'll adapt the tutorials to match this soon.

    @ValdikSS said:
    I'd recommend using plain IPSec without L2TP. It's more likely to traverse NAT and just more simple.

    There is no native client support in windows and OS X.

  • Raymii said: There is no native client support in windows and OS X.

    You're wrong. There is native support in both windows and os x.

    https://wiki.strongswan.org/projects/strongswan/wiki/Win7Config

  • Hi,

    You have said at the beginning, among the other "Ports 1701 TCP, 4500 UDP and 500 UDP opened in the firewall."

    But when I do this, as in the guide, xl2tpd service is running under 1701 UDP not TCP. Also I have no rules in my iptables

    iptables -L

    `Chain INPUT (policy ACCEPT)
    target prot opt source destination

    Chain FORWARD (policy ACCEPT)
    target prot opt source destination

    Chain OUTPUT (policy ACCEPT)
    target prot opt source destination `

    And when I try to connect it says that L2TP server is not available.

    The L2TP-VPN server did not respond. Try reconnecting. If the problem continues, verify your settings and contact your Administrator.

Sign In or Register to comment.