Android IPSec PSK VPN - Nexus One with OpenSWAN

Looking to secure my internet traffic when on a public network and away from home I decided to set up a VPN between my phone and my Ubuntu server. This would allow all of my phone's traffic to be encrypted and tunneled through my Ubuntu server and home internet connection. Effectively this will make it difficult for people to listen to my traffic and in essence would offer additional security to my browsing and email when on a public network. My phone is an Android Google Nexus One; and unfortunately Android versions up to and including Gingerbread (2.3.4) do not support OpenVPN out of the box, unless you root your device. Read on to see how I set up my Android to Home IPSec VPN...

The built-in Android VPN client allows for a choice of PPTP, L2TP and L2TP IPSec VPN connections. Due to security flaws with PPTP, and L2TP offering no encryption I opted to set up an L2TP IPSec VPN which as you'll discover wasn't the easiest of rides. 
IPSec is a security layer running on top of IP ('Internet Protocol'). My VPN end point again is my Ubuntu 10.04 server running the Openswan VPN suite. My client as already mentioned is an Android Google Nexus One 2.3.4; however, this setup has been tested on Nexus 4 and Nexus 5 across Froyo (2.2 , 2.2.1 and 2.2.2), Gingerbread (2.3.3 and 2.3.4), Icre Cream Sandwich ICS, Jelly Bean, Kitkat (4.41) using this configuration. 

This has also been tested on Ubuntu 12.04.

Trying to comprehend what happens during the creation of an IPSec VPN, I've drafted a novice parody & overview of what I believe happens based on my understanding (please shout in the comments if I've misunderstood).

A VPN Parody
A VPN is formed by encrypting a transport tunnel between two nodes. The nodes usually take the forn of a client-server or srever-server. Think of tunneling as having a computer delivered to you by UPS. The vendor packs the computer (point to point protocol) into a box (encapsulating protocol) which is then put on a UPS truck (transport protocol) which is then locked so bystanders cannot see what the truck contains (IPSec protocol). This all occurs at the vendor's warehouse (entry tunnel interface). The truck (transport protocol) travels over the highways (Internet) to your home (exit tunnel interface) and delivers the computer. The truck is unlocked  (IPSec protocol) so you can see inside the truck, you open the box (encapsulating protocol) and remove the computer (passenger protocol).

My setup 
OS = Ubuntu 10.04 Desktop LTS
Kernel = 2.6.32-31-generic 
L2TP daemon = xl2tpd 1.2.7
IPsec Implementation = Openswan 2.6.28 
IPsec Stack = Netkey ('26sec')   -   (supplied as part of Kernel 2.6)
IKE / Key management daemon = pluto   -   (supplied as part of Openswan)
A good background resource with lots of detail is Using a Linux L2TP/IPsec VPN server .

Overview of the tools involved
xl2tpd: is a Layer 2 Tunneling Protocol (L2TP) used to support virtual private networks (VPNs) (RFC2661). L2TP facilitates the tunneling of Point-to-Point Protocol (PPP) packets across an intervening network in a way that is as transparent as possible to both end-users and applications. The main purpose of this protocol is to tunnel PPP frames through IP networks  using the Link Control Protocol (LCP) which is responsilbe for establishing, maintaining and terminating the PPP connection.  L2TP does not provide any encryption or confidentiality itself; it relies on an encryption protocol encrypts then tunnel to provide privacy, hence L2TP are encrypted by using it with IPSec. xl2tpd is an open source implementation of the L2TP tunneling protocol and is a fork from l2tpd maintained by the Xelerance Corporation. xl2tpd replaces the obsolete and unmaintained l2tpd.

Openswan: is a set of tools for doing IPsec on Linux operating systems. The toolset consists of three major components:
  • configuration tools
  • key management tools (aka pluto ) 
  • kernel components (KLIPS and sec).  
pluto: is the key management daemon, it is an IPsec Key Exchange  (IKE) daemon. IKE's Job is to  to negotiate Security Associations for the node it is deployed on. A Security Association (SA) is an agreement between two network nodes on how to process certain traffic between them. This process involves encapsulation, authentication, encryption, or compression.

Note, IKE implementations can only negotiate with other IKE implementations, so IKE must be on each node that is to be an endpoint of an IKE-negotiated Security Association. No other nodes need to be running IKE.
 
IKE deals with two kinds of Security Associations. The first part of a negotiation between IKE instances is to build an ISAKMP (Internet Security Association and Key Management Protocol) SA. An ISAKMP SA is used to protect communication between the two IKEs. The second part of the security association for the IKEs is to build the IPsec SAs, these are used to carry protected PPP traffic between the systems. The negotiation of the ISAKMP SA is known as Phase 1. Any negotiation under the protection of an ISAKMP SA, including the negotiation of IPsec SAs, is part of Phase 2. 

In short, the IKE instance is prepared to automate the management of Security Associations in an IPsec environment. The actual secure transmission of packets is the responsibility of Netkey. 

It is worth noting that pluto only implements a subset of IKE, but enough for it to interoperate with other instances of pluto, and many other IKE implementations. pluto uses shared secrets or RSA signatures to authenticate peers with whom it is negotiating. pluto implements ISAKMP SAs itself. After it has negotiated the IPsec SA, it directs Netkey to implement it. When pluto shuts down, it closes all Security Associations (killing the VPN tunnel).

Netkey: is the name of the IPSec 'stack' in the 2.6 kernel used to encrypt the PPP packets over the L2TP tunnel. Netkey is a relatively new IPsec stack is based on the KAME stack from BSD. Netkey is also referred to as '26sec' or 'native' stack. Netkey supports both IPv4 and IPv6.

For Linux kernel 2.6, there is a choice of either KLIPS or Netkey, however, the Netkey components are already included in the 2.6 kernel. Netkey partially replaces KLIPS which was the previous IPSec stack used predominantly before Netkey shipped with kernel 2.6.
 
Users should note that Netkey unlike KLIPS hooks into the kernel networking code differently. With Netkey packets are intercepted by the IPsec stack after they are received on the physical (ethX) interface, this complicates iptables-based firewall rules. This interception also creates problems when using NAT and IPsec on the same machine, since the packet does not traverse through all the iptables as expected. Unencrypted packets never travel the POSTROUTING table.

PPPD: is the Point-to-Point Protocol daemon which is used to manage network connections between two nodes. Specifically pppd sets up the transport for IP traffic within the L2TP tunnel for the VPN. 

VPN client: In this post will be a Google Nexus One with Android 2.2.1-2.3.4 using an IPsec PSK tunnel with the l2tp secret not enabled. The client also support PPTP, basic L2TP and also certificate based authentication (the latter I've yet to get working on the Android side).


VPN Overview in practice 
  1. The VPN client (android phone), connects to the server, specifically the ipsec daemon (Openswan) on port 4500.
  2. The key management daemon (IKE pluto) kicks off and negotiates the Phase 1 ISAKMP Security Association on behalf of IPSec.
  3. With the ISAKMP SA in place the IKE (pluto) is now safe to negotiate the Phase 2 IPSec SA using the pre shared key on behalf of IPSec.
  4. Once authenticated with the pre shared key, encrypted traffic can now pass between the client and server. Authentication can now be initiated for the Point to Point (PPP) tunnel.
  5. xl2tpd kicks in to handle the PPP authentication and PPP Link Establishment using the Link Control Protocol (LCP). LCP creates the tunnel to the destination network and prepares the authentication protocol which is used in step 8.
  6. xl2tpd also negotiates and finds out if the two nodes in the PPP connection agree on any compression or encryption algorithm. If the answer is yes then it is implemented in steps 8 and 9.
  7. xl2tpd now initiates user authentication and will prompt for a username and password.
  8. Because the L2TP secret is disabled in this post, the credentials are sent to pppd (instead of the L2TP daemon) for authentication. There are different methods for secure User Authentication, in this example we use CHAPS to secure the authentication.  Once authenticated  the L2TP tunnel can now be set up encapsulated inside of the IPSec encrypted packets. This is the only time when the user must take care in exchanging credentials to prevent interception i.e. don't use plain text to authenticate user credentials. If for any reason these credentials were captured by an intruder, then the intruder may be able to take control of the connection.
  9. pppd now initiates the PPP tunnel and invokes the Network Layer Protocol(s) that were selected during the link establishment phase (step 6). The Network Layer Protocols include IPCP which assigns the dynamic IP address to the PPP client, and if permitted  compression is also now negotiated.
  10. PPP tunnel now up and IP assigned, with any luck you’re finally on your private network from your smart phone all under the guise of VPN.
Now... how to do this in 12 steps:
   


1. Install Openswan 2.6.28
The version supplied with Ubuntu 10.04 Lucid is version 2.6.23, I had some issues with this build so I manually compiled and install 2.6.28 from the source. See below for the steps:

sudo apt-get install build-essential libgmp3-dev gawk flex bison
wget http://www.openswan.org/download/openswan-2.6.28.tar.gz 
tar -xzvf openswan-2.6.28.tar.gz 
rm openswan-2.6.28.tar.gz 
cd openswan-2.6.28
sudo make programs
sudo make install
sudo /etc/init.d/ipsec restart

2. Install xl2tpd 
The version supplied with Ubuntu 10.04 Lucid is version 1.2.5, this has some bugs so I'll move up to version 1.2.7 which works. This isn't in the repositories for Lucid as it is supplied with Natty (11.04) but you can still download and install the package from: 
http://launchpadlibrarian.net/57806183/xl2tpd_1.2.7%2Bdfsg-1_i386.deb

3. Configure xl2tpd
Open up the xl2pd configuration file:

sudo gedit /etc/xl2tpd/xl2tpd.conf 

Change the xl2tpd.conf according to your setup. My xl2tpd.conf file look something like below. It is a minimal xl2tpd config, the idea is to provide an L2TP daemon to which remote L2TP clients can connect. In my config the internal (protected) network is 192.168.1.0/24. The remote clients connec to 192.168.1.51 to 192.168.1.55, this probably isn't the best approach. You would ideally want your remote clients on a separated IP range such as 10.10.10.0/24 (i.e. 10.10.10.1 … 10.10.10.254). However this reduces any headaches I may experience with routing.
The listen-addr parameter can be used if you want to bind the L2TP daemon to a specific IP address instead of to all interfaces. For instance, you can bind it to the interface of the internal LAN (e.g. 192.168.1.98 in the example below).
 /etc/xl2tpd/xl2ptd.conf :
 
[global] 
listen-addr = 192.168.1.100 ;this is the external network address for the Ubuntu server
ipsec saref = no  ;Netkey which I am using does not support SAref at this time
auth file = /etc/ppp/chap-secrets
port = 1701
debug tunnel = yes
debug avp = yes
debug packet = yes
debug network = yes
debug state = yes

[lns default]
ip range = 192.168.1.51-192.168.1.55
local ip = 192.168.1.50
require chap = yes
refuse pap = yes
require authentication = yes
name = Yourservername
ppp debug = yes
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes 

Save and Close.

4. Configure PPP 
You can modify this file according to your requirement. The entire configuration is completed from xl2tp side, now time to configure the PPP parameters.

sudo gedit /etc/ppp/options.xl2tpd

You can change your dns & wins server IP address in the file. You can also add some other parameters that are supported by your pppd, like
require-mschap-v2, see the man page of your pppd.
/etc/ppp/options.xl2tpd :

ipcp-accept-local
ipcp-accept-remote
noccp
auth
#crtscts
idle 1800
mtu 1410
mru 1410
nodefaultroute
debug
lock
proxyarp
connect-delay 5000
ms-dns 192.168.1.1


Save and Close.

5. Configure CHAPS
The authentification data for L2TP is stored in the file /etc/ppp/chap-secrets. The same chap-secrets file can be used, if you are using mschap protocol in option file. To edit the file:

sudo gedit /etc/ppp/chap-secrets 

The IP address field is showing the remote tunnel static IP address. You can assign the dynamic IP addresses also by using radius server & dhcp-pppd plugin etc. But I don’t know what is the easiest method to do this & how to. Also my requirement is completed by using static IP address.
 
/etc/ppp/chap-secrets

# Secrets for authentication using CHAP
# client server secret IP addresses
# username servername password Assigned IP
username * "yoursecrethere" *


You probably also want to define a username and an IP address for the client above. Create a new line for each additional user you want to authenticate with CHAPS. I only have one client so it's not a big issue.

Save, Close and make sure you set the permissions on your chap-secret file to keep it private.

sudo chown root:root /etc/ppp/chap-secrets
sudo chmod 600 /etc/ppp/chap-secrets 
 
6. Run xl2tpd
After doing the entire above configuration, you can start xl2tpd. First create the l2tp run control, this is a workaround for a bug in xl2tpd 1.2.7

sudo touch /var/log/xl2tpd/l2tp-control

Then start the daemon using this command:
xl2tpd -D
The -D option is opening the debug of xl2tpd. It is recommended to start the application in debugging mode at first time (during testing time). Remove –D option to stop the debugs.

7. Configure IPSec (Pluto / Netkey)
Open up the IPSec configuration file:

sudo gedit /etc/ipsec.conf

This file is sensitive to formatting, ensure you have the appropriate tab indents in place.

/etc/ipsec.conf : 

# /etc/ipsec.conf - Openswan IPsec configuration file
# RCSID $Id: ipsec.conf.in,v 1.16 2005/07/26 12:29:45 ken Exp $

# This file: /usr/share/doc/openswan/ipsec.conf-sample
#
# Manual: ipsec.conf.5

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

# basic configuration
config setup

            # NAT-TRAVERSAL support, see README.NAT-Traversal
            nat_traversal=yes
            # exclude networks used on server side by adding %v4:!a.b.c.0/24
            virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
            # OE is now off by default. Uncomment and change to on, to enable.
            oe=off
            # which IPsec stack to use. netkey,klips,mast,auto or none
            protostack=netkey
            plutostderrlog=/var/log/pluto.log

            # Add connections here
            nhelpers=0
 
conn L2TP
            authby=secret
            auto=add
            pfs=no
            type=transport
            rekey=no
            compress=yes

            left=192.168.1.100
            leftnexthop=192.168.1.1
            leftprotoport=17/1701

            right=%any
            rightsubnet=vhost:%no,%priv
            rightprotoport=17/%any
            forceencaps=yes
            dpddelay=40
            dpdtimeout=130
            dpdaction=clear 
 

Save and Close.

For information....nhelpers: Pluto can also use helper children to off-load cryptographic operations. This behavior can be fine tuned using the --nhelpers. Pluto will start (n-1) of them, where n is the number of CPU's you have (including hypherthreaded CPU's). A value of 0 forces pluto to do all operations in the main process. A value of -1 tells pluto to perform the above calculation. Any other value forces the number to that amount.

8. Configure the IPSec secret pre shared key 
Open up the IPSec secrets file:
 
sudo gedit /etc/ipsec.secrets

This file is sensitive to formatting, ensure you have the appropriate tab indents in place.
Add the following line to the file:

/etc/ipsec.secrets :   

: PSK "yourpresharedkey" 

Save and Close.

Make sure you set the permissions on your secrets file to keep it private.

sudo chown root:root /etc/ipsec.secrets
sudo chmod 600 /etc/ipsec.secrets 

9. Configure the Linux Kernel
For Openswan to work icmp redirection must be disabled and IP forwarding also needs to be activated. For persistence these settings should be amended in /etc/sysctl.conf

sudo gedit /etc/sysctl.conf

Add the following lines (adjusting for your network adapters):

net.ipv4.ip_forward=1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.default.secure_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.lo.accept_redirects = 0
net.ipv4.conf.lo.secure_redirects = 0
net.ipv4.conf.lo.send_redirects = 0
net.ipv4.conf.eth0.accept_redirects = 0
net.ipv4.conf.eth0.secure_redirects = 0
net.ipv4.conf.eth0.send_redirects = 0 


Save and Close. Then reload the settings:

sudo sysctl -p /etc/sysctl.conf 

10. Verify the configuration
By now you should be pretty much done, time to check your configuration:

sudo ipsec verify

The output should be along the lines of: 


11. Configuring the firewall

Router side
1. Enable VPN pass through on your router.
2. Forward the following to the Ubuntu server:
  • Protocol 50 
  • Protocol 51
  • 500/UDP IKE
  • 4500/UDP (If you are using NAT-Traversal to tunnel through NAT/other Firewalls)
Ubuntu server side
3. Allow the following ports: 
  • 500/UDP IKE
  • 4500/UDP NAT-T
  • 1701/UDP L2TP
The key rule for this configuration to act as a 'road warrior' setup is the next one; which allows your VPN clients to masquerade through the VPN servers external interface i.e. allowing clients to access to the internet through the VPN servers WAN connection.

First check the ipsec interface using ifconfig, for me this is ppp0. Then modify and add the following rules to enable masquerading:
 
sudo /sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

sudo /sbin/iptables -A FORWARD -i eth0 -o ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT
 
sudo /sbin/iptables -A FORWARD -i ppp0 -o eth0 -j ACCEPT


Update 13/03/2014These iptables rules are not persistent i.e. when you reboot your PC iptables will flush. To make the iptables rules persistent through reboot I have included them in /etc/rc.local .This took me a while to figure out.

The forwarding and NAT rules will of course be specific to the respective configuration The above rules allow authenticated clients to connect to everything that interface eth0 leads to (the Internet in this case). 

12. Start VPN server / IPSec daemon on Ubuntu boot

The easiest option I found here was to add the following line to my rc.local script which is executed at boot time. This script is executed after all of networking bits and bobs which should therefore make it a lot easier to get the IPSec server to start.

sudo vi /etc/rc.local

Add: 

/etc/init.d/ipsec start 

Save and exit. 

13. Setting up Android for the VPN connection (Froyo/Gingerbread)
  1. Settings >
  2. Wireless & networks >
  3. VPN Settings >
  4. Add VPN >
  5. L2TP/IPSec PSK;
  6. Enter your details as below:
  • VPN Name =  your VPN server description can be anything you want
  • Set VPN Server = your server IP address or your dynamic dns hostname
  • Set IPSec preshared key = enter your preshared key as setup
  • Enable L2TP secret = unchecked
  • DNS seach domains = leave blank 
Note: L2TP Secret

Note I don't use an L2TP secret in this blog, here's why... personally I don't think it adds much to the overall process. pppd already authenticates the user using CHAPS authentication to set up the tunnel and pluto authenticates the encryption of the tunnel using the pre shared key. Having yet another gatekeeper to authenticate the tunnel seems a little pointless, offering only another set of credentials to remember and area to troubleshoot hence I don't discuss it in this post mainly to keep are rather complex process as simple as possible.

Note: Certificate based authentication 

Work in progress... on hold until iOS implements certificate based auth for L2TP IPSec.
 

14.  Setting up iPhone iOS  for the VPN connection
The following steps I used on an iPhone 3GS iOS 5.0, 5.01 and 5.1 to connect to the Ubuntu IPSec VPN.

  1. Settings
  2. General
  3. Network
  4. VPN
  5. Add VPN Configuration:
  • Select L2TP
  • Description: any
  • Server: server address
  • Account: ubuntu username
  • RSA SecurID: off
  • Password: as per /etc/ppp/chap-secrets
  • Secret: PSK as per /etc/ipsec.secrets
  • Send All Traffic: on
  • Proxy: off  
After setting up the iPhone to work with this IPSec openswan configuration I experienced the issue that should the iPhone disconnect either intentionally or through a dropped tunnel I was unable to get the iPhone to reconnect to the VPN. The only way to get the phone to reconnect was to restart the IPSec daemon on the Ubunutu  server.             


As Jacco points out one problem is that Apple do not appear to send a “Delete SA” message when the device disconnects. The IPsec connection remains up and the VPN client may not be able to reconnect, and reports an error. He pointed out that the problem is resolved when Dead Peer Detection (DPD) times out, the SA itself times out (if DPD is disabled) or the Openswan daemon is restarted. For this reason it is highly recommended to enable DPD on the Openswan VPN server by adding these parameters to your Openswan configuration (suggested time-out values):

These lines need to be added to /etc/ipsec.conf under the connection configuration and not the daemon configuration from my experience. Putting them in the before the connection configuration will cause openswan to fail when restarting reporting a "confread.c:248: load_setup: Assertion `kw->keyword.keydef->validity & kv_config' failed" error in the terminal.

           dpddelay=40
           dpdtimeout=130
           dpdaction=clear

The example config in the body of this post has already been updated to reflect this addition. 

Other Useful resources

Eclectic Security: Secure IPsec/L2TP VPN for on the road android devices

BrainBlog: Android L2TP/IPSec VPN mini-howto 

Jacco de Leeuw: Using a Linux L2TP/IPsec VPN server




51 comments:

  1. Hello,

    First of all thanks for sharing the nice solution.

    I'm having a problem with my xl2tpd and pppd. When I try to connect with exactly the same configurations you described here I get a 'peer refused to authenticate: terminating link'. Obviously if I disable the authentication it works but thats exactly what I don't want.

    Would appreciate some help here. Thanks for the attention.

    ReplyDelete
    Replies
    1. Have you checked your logs?

      /var/log/messages
      /var/log/syslog
      /var/log/ppp.log
      /var/log/secure

      Delete
  2. This comment has been removed by the author.

    ReplyDelete
  3. Do you know anything about the issue where the Android client will initially connect, but then disconnect after about ten seconds? I can get a VPN working using L2TP alone (though of course it isn't encrypted), but if I want to use IPSEC (either PSK or CRT), whether I use StrongSwan or OpenSwan, on Android 2.2 or 2.3.3, I authenticate, the tunnel starts, and then around ten seconds later I get disconnected with log messages like:

    pppd[26296]: rcvd [LCP TermReq id=0x2 "User request"]
    pppd[26296]: LCP terminated by peer (User request)
    pppd[26296]: Connect time 0.2 minutes.

    It seems to be a fairly common problem, but I have yet to see a solution.

    ReplyDelete
  4. Yes I originally had this problem which from recollection was firewall related. Try your configuration without a firewall, with a dmz first briefly to see if the problem persists. Ensure that your router is set to port forward and pass thru IPSec.

    ReplyDelete
  5. This is the first tutorial of this quality I've been able to find on this -- thank you. I have a server with a few public websites running on it and wanted to add this setup to that just to give me a personal road-warrior connection. I'm concerned about whether this would interfere with normal operations of such a server, particularly the changes in step #9. Have you any comments on this?

    Thanks again for taking the time to illustrate all this.

    ReplyDelete
  6. Thanks for your comment, it took me a fair amount of time to get my head around this all and I thought I'd better write it down to make sure I was clear.

    I don't run any dedicated public webservers on my box, I do however run several services which have web front ends built in i.e. Webmin, XBMC, SABNZB and an FTP server. None of these services have experienced any difficulties through configuring the VPN as described in this guide.

    ReplyDelete
  7. Hey there, thanks for posting this tutorial I have been following it all the way through, I'm kinda of a noob on Ubuntu overall... Where I got stuck is the following:
    When I did ipsec verify, everything was the same as in your screenshot but:
    Checking NAT and MASQUERADEing there it says [N/A]
    Also when I did ifconfig -a I only see eth0 ham0 (hamachi) and lo
    I don't see the ppp0 you are talking about.

    Please helpe me! :)

    Thanks in advance!

    ReplyDelete
    Replies
    1. Have you checked your logs?

      /var/log/messages
      /var/log/syslog
      /var/log/ppp.log
      /var/log/secure

      Delete
  8. This comment has been removed by the author.

    ReplyDelete
  9. Thank you very much for posting such a great how-to. There is indeed little information about the usage of L2TP/IPSec VPNs in the net. Seems like OpenVPN dominates the Linux community.

    I followed your instruction and I have a small problem that is probably due to the IPTABLES. I need to tell you that I am running a Virtual Machine within a data center (so directly in the Internet with a own IP address, I call it 1.2.3.4)

    When using the following command in '/etc/rc.local' I can easily establish a VPN connection but I can't access the Internet (I can only access my VM).

    iptables -t nat -A POSTROUTING -o eth0 -s 10.10.0.0/24 -j SNAT --to 1.2.3.4

    1.2.3.4 is the dedicated IP of my VM
    10.10.0.0 is the IP address range of my L2TP/IPSec VPN

    When replacing the above line with

    iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

    I can't establish a VPN connection. It worked once or twice from an iPhone and then I had access to the internet, however the VPN tunnel was unstable and I was not able to build it up on a regular basis.

    Do you have a good idea what the IPTABLES command needs to be?

    By the way, for the OpenVPN-Server I am running the following command works great:

    iptables -t nat -A POSTROUTING -o eth0 -s 10.8.0.0/24 -j SNAT --to 1.2.3.4

    1.2.3.4 is the dedicated IP of my VM
    10.8.0.0 is the IP address range of my OpenVPN

    ReplyDelete
  10. I don't think the issue is with your iptables. I similarly have an issue whereby after a number of connection the OpenSWAN server no longer allows further reconnections. I have spoken to others with similar issues and I think it is because Apple do not appear to send a “Delete SA” message when a device disconnects. The IPsec connection remains up and the VPN client may not be able to reconnect even with the DPD dead peer detection setting enabled I still have intermittent issues and have to restart OpenSWAN occassionally to reconnect to the VPN this isn't ideal I am hoping that later builds may prove more stable.

    Can you reconnect successively to your VPN albeit without internet?

    ReplyDelete
  11. I must agree with you, it's not a problem of the IPTABLES. I have now set-up my VPN server based on the manual from Phillip Bailey (http://bailey.st/blog/2011/07/06/secure-ipsecl2tp-vpn-for-on-the-road-android-devices/#comment-6896) and the VPN works quite good on my Android 2.2 mobile phone while connected through WiFi (VPN not working through 3G network).

    The iPhone sometimes works but most often doesn't. The problem always starts after the iPhone has been inactive and lost/deactivated the VPN connection. When I disconned manually (using the iPhone's menu) I can reestablish the connection. But when the iPhone loses/deactivate itself I can not reconnect.

    I can also not reconnect after rebooting the server.

    ReplyDelete
  12. Have you tried adding DPD timeout? they still don't fully resolve my issues ymmv.

    ReplyDelete
  13. Yes, I added the three lines mentioned in the tutorial. The VPN works great on my Android 2.2 but not at all on iOS. Even though I restarted the server and the IPSec Service.

    ReplyDelete
  14. Hmmm I still have issues on Android 2.3 with DPD and reconnecting after a period of time. Well good luck with your search for a solution post back with any fix you find.

    ReplyDelete
  15. I would like to try from behind a dd-wrt. I could find much on forwarding the protocol 50 via iptables command. would you have any pointers?

    ReplyDelete
  16. Try in DD-WRT v24:

    Security > VPN > IPSec Passthrough - Enable

    ReplyDelete
  17. Great tutorial and thank you for the effort. I still have some problem with step "12. Start VPN server / IPSec daemon on Ubuntu boot"

    As you described in your manual I did add the line "/etc/init.d/ipsec start" to the file "/etc/rc.local" before the "exit 0" line. However I can not establish the VPN with my iPhone after my machine did a reboot (it is a virtual machine running in a data center).

    Strange enough things work well when I enter manually "sudo /etc/init.d/ipsec restart" after the machine did a reboot. Then my iPhone can without any problem establish the VPN tunnel.

    Do you have any idea what is wrong on my machine? Is there a problem with the boot up script and the order the services are loaded. E.g. is the machine trying to start "ipsec" before the network interface is available? Any idea what I could do or try?

    Thank you for your help and happy New Year

    ReplyDelete
  18. Which version of linux are you running, is your rc.local file definitely executing on boot?

    I suggest putting some additional actions into the rc local file such as output a debug message to a log file to check it is running.

    ReplyDelete
  19. I tried exactly the config posted here, but I cant make my iPad2 5.0.1 connect to the VPN.. is there any tricks for iPad2 5.0.1?

    ReplyDelete
  20. I've not retried it on my iPad since upgrading to 5.0.1 I will have to give this a try and report back, it may be a few weeks though...

    ReplyDelete
    Replies
    1. I've since tested the same configuration with iOS 5.0.1 and 5.1 and have not had to change anything described above, it worked straight away.

      Delete
  21. Thanks a lot for this great tutorial, it's been very useful for setting up my IPSec VPN. The only problem I have is I'm getting lots of asynchronous packets that break the channel everytime I log in from a NATted network, I worked around the problem by accessing the VPN only with 3G, anyway I don't think it's a configuration issue, I'm more for an OpenSwan/CentOS incompatibility...

    ReplyDelete
  22. Tested and works with iOS 5.01 and 5.1.

    ReplyDelete
  23. Have OpenSWAN/xl2tpd set up similarly for iPhone access - which works. This help in getting an Android 2.2 HTC phone to connect. But the phone doesn't properly set up the routing table for the office LAN net. It appears I might be able to us "ip ro add" in a terminal to correct that - haven't fully tested because the connection tends to drop while I'm fumbling around. But that begs the question: what's necessary to have the Android client set the LAN routing properly on connection?

    ReplyDelete
  24. Update: No, ip ro won't let a normal user update the routing table. With iPhones this setup gets the users right into the LAN. Maybe Android's client is just incomplete?

    ReplyDelete
  25. This config should work for 2.2 I've used it. It will be a server side issue with NAT section 11 and IP forward section 9. Check IP tables do not have conflicting rules.

    ReplyDelete
  26. Any idea why Openswan doesn't seem to work with Android ICS?

    ReplyDelete
    Replies
    1. its a bug in android. for workaround, see http://people.redhat.com/pwouters/openswan-android-ics-natoa.patch

      Delete
    2. Thanks, for the note I'll no doubt need that come the fall - I'm looking forward to the next range of Nexus'. As side note what's going on with the comment wrapping blogger!

      Delete
  27. I've not got ICS yet, I'm still rocking Gingerbread on the Nexus One - I like the 3.7" screen. I'm probably going to move to the iPhone 5 when they launch if the screen is smaller than the current SGSIII and the newly announced Nexus' due fall.

    ReplyDelete
  28. i am trying to setup it on a Amazon EC2 Ubuntu 12.04LTS.

    But it seems wont work. These setup is it usable on a amazon ec2 server?

    ReplyDelete
    Replies
    1. Not tried EC2 does this help https://www.openswan.org/projects/openswan/wiki/Amazon_EC2_example ?

      Delete
  29. This comment has been removed by the author.

    ReplyDelete
  30. THANKS FOR THE TUTORIAL. NICE.... but..... what can i do if i want only "some" traffic tunneled".

    for example... i want to realise all the normal operations trhough my -normal-android-defaultroute but i want to connect to my ftp server (as example-10.0.1.3) over the tunnel.

    can i play with default routes....metric .....?

    ReplyDelete
    Replies
    1. this needs to be done on the client side I believe, which depends on your client.

      Delete
  31. I got this error:

    packet from 188.188.86.XX:887: initial Main Mode message received on 193.105.XX.XYZ:500 but no connection has been authorized with policy=PSK

    Any idea what went wrong in my config?

    ReplyDelete
    Replies
    1. Does your PSK match exactly that used in /etc/ipsec.secrets ?

      Delete
  32. Hi!

    First of all thanks for the guide.

    I have a hard time to make L2TP/Ipsec work on a Debian Stable installation.

    From syslog i get the following :

    Oct 4 21:53:23 debian-vb ipsec_setup: ...Openswan IPsec started
    Oct 4 21:53:23 debian-vb ipsec__plutorun: adjusting ipsec.d to /etc/ipsec.d
    Oct 4 21:53:23 debian-vb pluto: adjusting ipsec.d to /etc/ipsec.d
    Oct 4 21:53:23 debian-vb ipsec__plutorun: 002 added connection description "L2TP-PSK-CLIENTS"
    Oct 4 21:53:23 debian-vb ipsec__plutorun: 003 NAT-Traversal: Trying new style NAT-T
    Oct 4 21:53:23 debian-vb ipsec__plutorun: 003 NAT-Traversal: ESPINUDP(1) setup failed for new style NAT-T family IPv4 (errno=19)
    Oct 4 21:53:23 debian-vb ipsec__plutorun: 003 NAT-Traversal: Trying old style NAT-T
    Oct 4 21:54:17 debian-vb xl2tpd[1643]: network_thread: recv packet from 188.73.252.7, size = 69, tunnel = 0, call = 0 ref=0 refhim=0
    Oct 4 21:54:17 debian-vb xl2tpd[1643]: get_call: allocating new tunnel for host 188.73.252.7, port 42964.
    Oct 4 21:54:17 debian-vb xl2tpd[1643]: handle_avps: handling avp's for tunnel 40986, call 0
    Oct 4 21:54:17 debian-vb xl2tpd[1643]: message_type_avp: message type 1 (Start-Control-Connection-Request)
    Oct 4 21:54:17 debian-vb xl2tpd[1643]: protocol_version_avp: peer is using version 1, revision 0.
    Oct 4 21:54:17 debian-vb xl2tpd[1643]: hostname_avp: peer reports hostname 'anonymous'
    Oct 4 21:54:17 debian-vb xl2tpd[1643]: framing_caps_avp: supported peer frames: async sync
    Oct 4 21:54:17 debian-vb xl2tpd[1643]: assigned_tunnel_avp: using peer's tunnel 12792
    Oct 4 21:54:17 debian-vb xl2tpd[1643]: receive_window_size_avp: peer wants RWS of 1. Will use flow control.

    ReplyDelete
    Replies
    1. 1. enable debug in options.l2tpd

      2. add to xl2tpd.conf under
      [global]
      debug tunnel = yes
      debug avp = yes
      debug packet = yes
      debug network = yes
      debug state = yes

      [lns default]
      ppp debug = yes

      3. dump the syslog and /var/log/auth.log to pastebin and post the link here

      4. what are you connecting from?

      5. which version of openswan are you using?

      Delete
    2. 1. I am using options.xl2tpd. Is that wrong? Debug is already enabled.

      2. xl2tpd.conf has already all the necessary debug flags

      3. http://pastebin.com/TKUJMaWX
      http://pastebin.com/N39bcjYM

      4. From an Android smartphone running 4.1.1 version.

      5. 2.6.28

      Delete
    3. looks like you are getting stuck here "STATE_MAIN_R2: sent MR2, expecting MI3" and "max number of retransmissions (2) reached STATE_MAIN_R2".

      Is your client NAT'd?
      Can your try connecting the client using a different network?
      What length is your psk / certificate?

      Delete
    4. do you have nat_traversal set to yes in your ipsec.conf?

      Delete
  33. I am trying to connect though EDGE/GPRS network. So i don't really know if the client is NAT'd or not.

    I tried through another network also, where the client was indeed NAT'd.
    The psk is 8 char long.
    nat_traversal is set to yes.

    ReplyDelete
  34. hello can i use your tutorial in ubuntu 12.10?

    ReplyDelete
    Replies
    1. yes should be entirely possible, I think 12.10 uses KLIPS instead of Netkey. I have used this guide on my 12.10 box, I'll update it at somepoint.

      Delete
    2. where is the point that you update?
      i've got this message in server log
      packet from 10.0.8.1:500: initial Main Mode message received on 192.168.200.194:500 but no connection has been authorized with policy=PSK
      can you help me?

      Delete
    3. this is my server log file :

      Feb 19 13:04:36 unsoed-Aspire-M1610 pluto[5705]: loading secrets from "/etc/ipsec.secrets"
      Feb 19 13:05:25 unsoed-Aspire-M1610 pluto[5705]: packet from 10.0.8.1:500: received Vendor ID payload [RFC 3947] method set to=109
      Feb 19 13:05:25 unsoed-Aspire-M1610 pluto[5705]: packet from 10.0.8.1:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but already using method 109
      Feb 19 13:05:25 unsoed-Aspire-M1610 pluto[5705]: packet from 10.0.8.1:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 109
      Feb 19 13:05:25 unsoed-Aspire-M1610 pluto[5705]: packet from 10.0.8.1:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but already using method 109
      Feb 19 13:05:25 unsoed-Aspire-M1610 pluto[5705]: packet from 10.0.8.1:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
      Feb 19 13:05:25 unsoed-Aspire-M1610 pluto[5705]: packet from 10.0.8.1:500: initial Main Mode message received on 192.168.200.194:500 but no connection has been authorized with policy=PSK
      Feb 19 13:05:45 unsoed-Aspire-M1610 pluto[5705]: packet from 10.0.8.1:500: received Vendor ID payload [Openswan (this version) 2.6.37 ]
      Feb 19 13:05:45 unsoed-Aspire-M1610 pluto[5705]: packet from 10.0.8.1:500: received Vendor ID payload [Dead Peer Detection]
      Feb 19 13:05:45 unsoed-Aspire-M1610 pluto[5705]: packet from 10.0.8.1:500: received Vendor ID payload [RFC 3947] method set to=109
      Feb 19 13:05:45 unsoed-Aspire-M1610 pluto[5705]: packet from 10.0.8.1:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but already using method 109
      Feb 19 13:05:45 unsoed-Aspire-M1610 pluto[5705]: packet from 10.0.8.1:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 109
      Feb 19 13:05:45 unsoed-Aspire-M1610 pluto[5705]: packet from 10.0.8.1:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but already using method 109
      Feb 19 13:05:45 unsoed-Aspire-M1610 pluto[5705]: packet from 10.0.8.1:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
      Feb 19 13:05:45 unsoed-Aspire-M1610 pluto[5705]: packet from 10.0.8.1:500: initial Main Mode message received on 192.168.200.194:500 but no connection has been authorized with policy=PSK

      Delete
  35. hello,

    ihave a problem when windows client try to connect, the ipsec SA established but drop again..

    Mar 5 15:55:02 labpuskom pluto[2618]: "L2TP-PSK-NAT"[11] 10.0.0.16 #50: STATE_QUICK_R2: IPsec SA established transport mode {ESP=>0xd52fefe7 <0x4c8b4372 xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=10.0.0.16:4500 DPD=none}
    Mar 5 15:55:02 labpuskom pluto[2618]: "L2TP-PSK-NAT"[11] 10.0.0.16 #45: received Delete SA(0x62735a16) payload: deleting IPSEC State #49
    Mar 5 15:55:02 labpuskom pluto[2618]: "L2TP-PSK-NAT"[11] 10.0.0.16 #45: received and ignored informational message

    is that problem from windows?
    what should i do?

    thanks before :)

    ReplyDelete
  36. Latest Android Apps are the product that is covering a high range of market and after making a close observation to the increasing demands it can be expected that the future of the industry is really a milestone of success.

    Latest Android Apps

    ReplyDelete