--- /dev/null
+<?xml version="1.0"?>
+<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
+ "http://docbook.org/xml/4.4/docbookx.dtd">
+
+<article>
+ <articleinfo>
+ <title>Practical VPNs</title>
+ <subtitle>Implementing Full-scale VPNs</subtitle>
+
+ <author>
+ <firstname>Liran</firstname>
+ <surname>Tal</surname>
+ <affiliation>
+ <address>
+ <email>liran@enginx.com</email>
+ </address>
+ </affiliation>
+ </author>
+
+ <othercredit>
+ <firstname>Yakov</firstname>
+ <surname>Shtutz</surname>
+ <contrib>Special thanks</contrib>
+ </othercredit>
+
+ <othercredit>
+ <firstname>Shahar</firstname>
+ <surname>Fermon</surname>
+ <contrib>Testing and feedback</contrib>
+ </othercredit>
+
+ <abstract>
+ <para>
+ This document was compiled from the administrator's point of
+ view, to explain what are VPNs, how they are deployed today
+ and to detail the necessary steps and tools to achieve and
+ create a fully working VPN solution, integrated with RADIUS
+ systems for AAA.
+ </para>
+
+ <para>
+ I will not dwell in this document on how to compile source
+ packages or kernel patching, and with the same tone I'm
+ assuming the reader is an exprerienced Linux user.
+ </para>
+
+ <para>
+ VPNs have their share amount of gossip for being a very
+ complex thing, and in some cases this may be true as they tend
+ to be more security intenssive which require adding more and
+ more layers to the scheme. With this said, we'll take a look
+ at how fairly straight-forward it is to setup VPNs and
+ maintain them with varius Open-Source tools.
+ </para>
+ </abstract>
+ </articleinfo>
+
+ <sect1 id="overview">
+ <title>Overview of VPNs and IPsec</title>
+ <sect2 id="vpns">
+ <title>Virtual Private Networks</title>
+ <para>
+ The purpose of a VPN is to create a secure channel ontop of an
+ un-secure medium, where a computer or a device are put in each
+ end-point in order to establish communication, each of these
+ end-points are often reffered to as Point of Presense, or POP.
+ This kind of a communication allows the capability of creating
+ a Virtual Private Network, which is accesable over a medium
+ such as the Internet and thus, extend the physical boundaries
+ of an existing local network.
+ </para>
+
+ <para>
+ VPNs have three forms:
+ <variablelist>
+ <varlistentry>
+ <term>Site-To-Site VPNs</term>
+ <listitem>
+ <para>
+ these setups exist in order to extend the local network
+ to create a much bigger LAN over the Internet.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Network-To-Host or Remote access VPNs</term>
+ <listitem>
+ <para>
+ where a central VPN server is able to achieve multiple
+ connections, often reffered to as RoadWarrior VPNs.
+ (This setup is very common among ISPs)
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Network-To-Network</term>
+ <listitem>
+ <para>
+ extranet VPNs allow secure connections within branches
+ and business partners, they are an extension of a
+ Site-To-Site VPNs.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </para>
+
+ <para>
+ <xref linkend="site-to-site"/> shows a Site-To-Site VPN diagram.
+ <figure id="site-to-site">
+ <title>Site to Site VPN</title>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="site-to-site-vpn.png"/>
+ </imageobject>
+ </mediaobject>
+ </figure>
+ </para>
+
+ <para>
+ IP/VPNs are connections which are based upon IP tunnels. A
+ tunnel is a way to encapsulate an IP packet inside another IP
+ packet or some other type of packet. Why do we need
+ tunneling? A Virtual Private Network is identified by IANA's
+ private IP assignments and so such packet can not go beyond
+ the uplink Internet interface.
+ </para>
+
+ <para>
+ <xref linkend="tunneling-process"/> shows the tunneling process.
+ <figure id="tunneling-process">
+ <title>Tunneling Process</title>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="tunneling-process.png"/>
+ </imageobject>
+ </mediaobject>
+ </figure>
+ </para>
+
+ <para>
+ Several tunneling protocols are available for manifesting
+ VPNs.
+
+ <variablelist>
+ <varlistentry>
+ <term>L2F</term>
+ <listitem>
+ <para>
+ Layer 2 Forwarding, an older implementation which
+ assume position at the link layer of the OSI. It has
+ no encryption capabilities and hence, deprecated.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>L2TP</term>
+ <listitem>
+ <para>
+ Layer 2 Tunneling Protocol, still no encryption
+ capabilities.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>PPTP</term>
+ <listitem>
+ <para>
+ Point-to-Point Tunneling Protocol, and yet again, no
+ encryption.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </para>
+
+ <para>
+ As seen, the requirement of encryption enhancement is urgent
+ in order to assure authentication, data integrity and privacy.
+ IPsec solves this by providing a suite of security measures
+ implemented at layer 3.
+ </para>
+ </sect2>
+
+ <sect2 id="ipsec">
+ <title>IP Security Suite (IPsec)</title>
+ <para>
+ VPN Security is now appearing, this complex things. How so?
+ VPN tunnels by themselves are easily maintained by
+ single-standalone tools like pppd, l2tpns, stunnel and others.
+ Involving security with VPNs though requires more:
+
+ <itemizedlist>
+ <listitem>
+ <para>authentication, data integrity and privacy</para>
+ </listitem>
+
+ <listitem>
+ <para>keying management</para>
+ </listitem>
+ </itemizedlist>
+ </para>
+
+ <note>
+ <para>
+ Keys are secrets being shared by two end-points to provide a
+ secure mean of communication against a third-party
+ connection from sniffing the actual data.
+ </para>
+ </note>
+
+ <para>
+ Different ways to handle key management include RADIUS (Remote
+ Authentication Dial In User Service) systems which provide AAA
+ (Authentication, Authorization and Accounting). Another
+ solution is ISAKMP/Oackly - Internet Security Association and
+ Key Management Protocol. This solution requires you to posess
+ one of the following:
+
+ <itemizedlist>
+ <listitem>
+ <para>something you have</para>
+ </listitem>
+
+ <listitem>
+ <para>something you know</para>
+ </listitem>
+
+ <listitem>
+ <para>something you are</para>
+ </listitem>
+ </itemizedlist>
+ </para>
+
+ <para>
+ The more requirements you meet the more secure is the medium,
+ once established. Let's review, something we have is like a
+ certificate, it proves who we are. Something we know, is a
+ key, a secret password which we were told in a whisper, and
+ something we are is our-fingerprint which identifies ourselves
+ from other individuals.
+ </para>
+
+ <sect3 id="ipsec-in-depth">
+ <title>IPsec in Depth</title>
+ <para>
+ IPsec consists of two main protocols, an Authentication
+ Header and Encapsulation Security Payload, also known as AH
+ and ESP. Although it is not bound to these and can be
+ extended (and often is) to other standarts such as
+
+ <itemizedlist>
+ <listitem>
+ <para>Data Encryption Standart (DES and 3DES)</para>
+ </listitem>
+
+ <listitem>
+ <para>Diffie-Hellman (DH)</para>
+ </listitem>
+
+ <listitem>
+ <para>Secure Hash Algorithm-1 (SHA1)</para>
+ </listitem>
+
+ <listitem>
+ <para>Message Digest 5 (MD5)</para>
+ </listitem>
+
+ <listitem>
+ <para>Internet Key Exchange (IKE)</para>
+ </listitem>
+
+ <listitem>
+ <para>Certification Authorities (CA)</para>
+ </listitem>
+ </itemizedlist>
+ </para>
+
+ <para>
+ We'll be deploying an IKE daemon to handle the key
+ management, which uses the Diffie- Hellman cryptography
+ protocol in order to allow two parties to establish a
+ connection based upon a shared secret key that both parties
+ posess. (Authentication within IKE is handled by MD5
+ hashing)
+ </para>
+
+ <para>
+ IKE is responsible for authentication of two IPsec parties,
+ negotiation of keys for encryption algorithms and security
+ associations. This process is commonly regarded as two
+ phases:
+
+ <variablelist>
+ <varlistentry>
+ <term>Phase 1: IKE Security Association</term>
+ <listitem>
+ <para>
+ The IKE daemon authenticates against the peers in
+ order to achieve a secure channel, according to the
+ Diffie-Hellman key agreement.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Phase 2: IKE IPsec Negotiation</term>
+ <listitem>
+ <para>
+ After achieving an authenticated channel, the
+ parties now negotiate a secure transform (the way to
+ encrypt and secure the medium) where the sender is
+ offering his/hers transform set after which the
+ receiver decides upon one. An IPsec session can now
+ safely begin.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </para>
+
+ <para>
+ Just to be clear, a Security Association is an agreed
+ relation between two parties which describes how they will
+ use security services (from IPsec) to communicate.
+ </para>
+ </sect3>
+
+ <sect3 id="ipsec-modes">
+ <title>IPsec Modes</title>
+ <para>
+ IPsec can operate in two different modes:
+
+ <variablelist>
+ <varlistentry>
+ <term>Transport mode</term>
+ <listitem>
+ <para>
+ takes place when two devices (like a station and a
+ gateway (now considered a host)) are establishing a
+ connection which upon they both support IPsec.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Tunnel mode</term>
+ <listitem>
+ <para>
+ we require tunnel mode when we proxy IPsec
+ connetions between two stations behind the IPsec
+ gateway. For example, in a Site-to-Site VPN a
+ tunnel mode lives, since it exists in order to
+ provide the stations behind these gateways runing
+ the VPN/IPsec to communicate securely. In this
+ situation, both end-points are runing an IPsec
+ software.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </para>
+
+ <para>
+ In definition, a tunnel mode IPsec is better secured than
+ transport. Without going too deep into the ins-and-outs of
+ the technical side, transport mode doesn't encapsulate the
+ actual IP layer but only the tcp/udp (Transport layer of the
+ OSI) where-as a tunnel mode encapsulate both the Transport
+ layer and the IP layer into a new IP packet.
+ </para>
+
+ <para>
+ To summarize, we need VPNs for data-exchange methods and a
+ set of IPsec tools for security reasons.
+ </para>
+ </sect3>
+ </sect2>
+ </sect1>
+
+ <sect1 id="deployment">
+ <title>VPN Deployment</title>
+ <para>
+ I've assembled another diagram to view the actual VPN setup.
+ <xref linkend="vpn-deployment"/> gives a general description of
+ how the network will be layed out in real-world scenario.
+
+ <figure id="vpn-deployment">
+ <title>VPN Deployment</title>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="vpn-deployment.png"/>
+ </imageobject>
+ </mediaobject>
+ </figure>
+ </para>
+
+ <para>
+ We notice that a single Linux box is acting as a Gateway and has
+ all the services included with it. This is a bad idea from a
+ security prespective but it's easy to just deploy the FreeRADIUS
+ and MySQL servers on another machine. Of course the L2TPns and
+ the rest of the IPsec tools suite would have to remain on the
+ Gateway box (not necessarily the Firewall).
+ </para>
+
+ <para>
+ <xref linkend="vpn-process"/> attempts to explain the actual
+ process that the VPN takes and to detail the place that each of
+ that application-in-charge takes place.
+
+ <figure id="vpn-process">
+ <title>VPN Process</title>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="vpn-process.png"/>
+ </imageobject>
+ </mediaobject>
+ </figure>
+ </para>
+
+ <sect2 id="deployment-requirements">
+ <title>Requirements</title>
+ <sect3 id="deployment-requirements-toolbox">
+ <title>The Toolbox</title>
+ <para>
+ Following is a description of the requirements you will
+ have to meet:
+
+ <variablelist>
+ <varlistentry>
+ <term>A Linux box</term>
+ <listitem>
+ <para>preferably a 2.4.27 kernel or higher.</para>
+ <para>
+ Debian is the chosen distribution which means we'll
+ be using apt-get for installation, but I'll also
+ focus on basic source tarballs installation.
+ </para>
+
+ <para>
+ Dependencies:
+
+ <itemizedlist>
+ <listitem>
+ <para>ipsec configuration in the kernel</para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>L2TPns</term>
+ <listitem>
+ <para>an L2TP PPP Termination tool.</para>
+ <para>
+ Dependencies:
+
+ <itemizedlist>
+ <listitem>
+ <para>libcli 1.8.0 or greater</para>
+ </listitem>
+
+ <listitem>
+ <para>
+ tun/tap interface compiled in the kernel or as
+ a module
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>FreeRADIUS</term>
+ <listitem>
+ <para>For authentication, and accounting.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>MySQL</term>
+ <listitem>
+ <para>To act as a back-end database for the RADIUS.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>OpenSwan</term>
+ <listitem>
+ <para>Provides the ipsec suite package.</para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </para>
+ </sect3>
+
+ <sect3 id="deployment-requirements-kernel">
+ <title>Kernel Support</title>
+ <para>
+ Debian stock kernel 2.4.27 and up are ipsec compatible
+ although if you think otherwise check for the
+ kernel-patch-openswan package.
+ </para>
+ </sect3>
+ </sect2>
+
+ <sect2 id="deployment-installation">
+ <title>Installation</title>
+ <sect3 id="deployment-installation-l2tpns">
+ <title>L2TPns</title>
+ <sect4 id="deployment-installation-l2tpns-install">
+ <title>Installation</title>
+ <blockquote>
+ <para>
+ L2TPns is a layer 2 tunneling protocol network server
+ (LNS). It supports up to 65535 concurrent sessions per
+ server/cluster plus ISP features such as rate limiting,
+ walled garden, usage accounting, and more.
+ </para>
+ </blockquote>
+
+ <para>
+ In a personal note - L2TPns is highly configurable for
+ many cases, and extremely reliable for
+ production/commerical use.
+ </para>
+
+ <para>
+ <variablelist>
+ <varlistentry>
+ <term>Step 1:</term>
+ <listitem>
+ <para>
+ Make sure you have libcli-1.8 development package
+ installed:
+<screen>
+# apt-cache search libcli
+libcli-dev - emulates a cisco style telnet command-line interface (dev files)
+libcli1 - emulates a cisco style telnet command-line interface
+# apt-get install libcli-dev
+</screen>
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Step 2:</term>
+ <listitem>
+ <para>
+ Download the source from
+ <ulink url="http://sourceforge.net/projects/l2tpns/">
+ SourceForge</ulink>.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Step 3:</term>
+ <listitem>
+ <para>
+ Build and install:
+ <code>make && make install</code>
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </para>
+
+ <note>
+ <para>
+ Alternately, you can skip these steps and simply
+ <code>apt-get install l2tpns</code>.
+ </para>
+ </note>
+
+ <note>
+ <para>
+ On RPM-based distributions, you should be able to make
+ packages from the libcli and l2tpns source tarballs with
+ <code>rpmbuild -ta</code>.
+ </para>
+ </note>
+
+ <para>
+ Once compiliation is done you will have l2tpns in
+ <filename>/usr/sbin/l2tpns</filename>, and all
+ configuration files can be found in
+ <filename>/etc/l2tpns/</filename>.
+ </para>
+ </sect4>
+
+ <sect4 id="deployment-installation-l2tpns-config">
+ <title>Configuration</title>
+ <para>
+ The only configuration that L2TPns takes is centralized in
+ the configuration file
+ <filename>/etc/l2tpns/startup-config</filename>.
+<programlisting>
+set debug 2 # Debugging level
+set log_file "/var/log/l2tpns" # Log file: comment out to use stderr, use
+ # "syslog:facility" for syslog
+set pid_file "/var/run/l2tpns.pid" # Write pid to this file
+set l2tp_secret <emphasis>"secret"</emphasis> # shared secret
+set primary_dns <emphasis>212.117.128.6</emphasis> # Only 2 DNS server entries are allowed
+set secondary_dns <emphasis>212.117.129.3</emphasis>
+set primary_radius <emphasis>192.168.0.1</emphasis> # Can have multiple radius server entries,
+ # but ony one radius secret
+set primary_radius_port 1812
+set radius_secret <emphasis>"radius_secret"</emphasis>
+set radius_accounting yes
+set radius_dae_port 3799
+set accounting_dir "/var/run/l2tpns/acct" # Write usage accounting files into specified
+ # directory
+set peer_address <emphasis>192.168.0.1</emphasis> # Gateway address given to clients
+load plugin "sessionctl" # Drop/kill sessions
+load plugin "autothrottle" # Throttle/snoop based on RADIUS
+load plugin "throttlectl" # Control throttle/snoop with nsctl
+load plugin "snoopctl"
+</programlisting>
+ </para>
+
+ <para>
+ This is the trimmed down version of probably most of
+ the common configuration and even some extra options.
+ </para>
+
+ <para>
+ Important configuration options are highlited and you
+ should adjust these to meet your network needs. We can
+ deploy all of the environment into one box which is of
+ course not a very good idea from a security point of view,
+ but will function just fine. Moreover, we will be using
+ aliased IP addresses so once you've decided to move the
+ FreeRADIUS daemon to another computer on the LAN it will
+ be fairly easy and won't take too much configuration into
+ it.
+ </para>
+
+ <para>
+ Next, we need to setup the IP pool that L2TPns will
+ provide to each VPN client. The configuration file is
+ located at <filename>/etc/l2tpns/ip_pool</filename> and
+ should look like the following:
+ <programlisting>172.16.21.0/24</programlisting>
+ </para>
+
+ <important>
+ <para>
+ Of course you can change this pool to anything else
+ (IANA IPs assigned for private internets only) just make
+ sure it is not conflicting with your current LAN network
+ addresses. This means that if you've assigned addresses
+ of 192.168.0.1 and 192.168.0.2 to your LAN boxes you
+ can't have a pool of 192.168.0.1/24 defined since L2TPns
+ will try to route those addresses from the tun device,
+ which is needless to say a bad idea...
+ </para>
+ </important>
+
+ <para>Next up, creating the access-list for L2TPns.</para>
+
+ <para>
+ Add a username and password into
+ <filename>/etc/l2tpns/users</filename>:
+ <programlisting>admin:12345</programlisting>
+
+ The password may either be plain-text as above, or
+ encrypted with MD5 or DES (to distinguish DES from
+ plain-text passwords, prefix the value with
+ <code>{crypt}</code>).
+ </para>
+
+ <para>
+ L2TPns utilizes a terminal connection on port 23 which you
+ would feel very comfortable in if you have worked with
+ routers and switches devices before. The terminal
+ provides control over the ppp termination which is why
+ we've created an account to log on to.
+ </para>
+ </sect4>
+ </sect3>
+
+ <sect3 id="deployment-installation-ipsec">
+ <title>IPsec</title>
+ <sect4 id="deployment-installation-ipsec-install">
+ <title>Installation</title>
+ <para>
+ User-space IPsec tools for various IPsec implementations
+ exist for linux, among them is the port of KAME's
+ libipsec, setkey, and racoon. Others are the OpenSWAN (a
+ successor to the FreeSWAN project).
+ </para>
+
+ <para>
+ Getting IPsec installed is fairly easy with Debian:
+ <screen># apt-get install openswan</screen>
+ </para>
+
+ <para>
+ The OpenSWAN project provides packages for RPM-based
+ distributions.
+ </para>
+
+ <para>
+ Alternately, you may download the
+ <ulink url="http://www.openswan.org/code/">source</ulink>
+ from the OpenSWAN project:
+<screen>
+# tar xvzf openswan-2.4.4.tar.gz
+# cd openswan-2.4.4
+# ./configure && make && make install
+</screen>
+ </para>
+ </sect4>
+
+ <sect4 id="deployment-installation-ipsec-config">
+ <title>Configuration</title>
+ <para>
+ OpenSWAN acts as the IKE daemon (remember IKE? it's job
+ is to authenticate between the two peers and negotiate a
+ secure medium). We will be setting up the IKE daemon as a
+ RoadWarrior configuration, a term for remote access
+ VPNs.
+ </para>
+
+ <para>
+ We desire this approach for compatibilty because after our
+ VPN solution will be complete any user from a Windows
+ machine will be easily ready to connect without any 3rd
+ party applications, same for Linux.
+ </para>
+
+ <para>
+ Configuration files are placed in
+ <filename>/etc/ipsec.d/</filename>,
+ <filename>/etc/ipsec.conf</filename> and
+ <filename>/etc/ipsec.secrets</filename>.
+ </para>
+
+ <para>
+ Let's start by choosing the remote client and it's PSK
+ (Private Shared Key) <filename>/etc/ipsec.secrets</filename>:
+<programlisting>
+hostname_or_ipaddress %any : PSK "mysecretkeyisverylong"
+</programlisting>
+ </para>
+
+ <para>
+ This is an IP/key pair. The IP or FQDN defines the local
+ peer (like a SOHO branch), then the remote host. Here we
+ defined %any for all hosts, though it's possible to define
+ only a specific IP. At last, we define the key associated
+ with it.
+ </para>
+
+ <para>
+ A better way to create a key is to utilize /dev/random for
+ creating a unique key.
+ <screen># dd if=/dev/random count=16 bs=1 2>/dev/null | xxd -ps</screen>
+ </para>
+
+ <para>
+ Next, let's prepare the configuration file
+ <filename>/etc/ipsec.conf</filename>:
+<programlisting>
+version 2.0
+config setup
+ nat_traversal=yes
+
+conn l2tp
+ authby=secret
+ pfs=no
+ keyingtries=3
+ left=real_ip_address
+ leftnexthop=%defaultroute
+ leftprotoport=17/%any
+ right=%any
+ rightprotoport=17/%any
+ auto=add
+
+include /etc/ipsec.d/examples/no_oe.conf
+</programlisting>
+ </para>
+
+ <para>
+ In this file we have first defined version 2 which is a
+ must, then enabled NAT Traversal. To understand the
+ importance of this feature think of the following
+ scenario: A remote user attempts to connect while he's
+ behind a router and therefore NATed. The router has to
+ de-encapsulate the packet, change things and then build it
+ up again and send it. IPsec doesn't like other people
+ messing with it's packet. That's why we solve this issue
+ with NAT Traversal.
+ </para>
+
+ <para>
+ Next up we configure authentication type (certificates,
+ psk, rsa keys, etc) then the left and right peers. The
+ default mode OpenSWAN takes is tunnel unless told
+ otherwise. I won't go into in-depth explanation of every
+ method, you can take a quick look at
+ <filename>/etc/ipsec.d/examples</filename> for more
+ explanation and other variations of working with RSA keys,
+ Certificates, host-to-host, and more.
+ </para>
+
+ <para>
+ In summary:
+ <itemizedlist>
+ <listitem>
+ <para>
+ We've configured an almost complete IPsec VPN setup.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ We've installed and configured a VPN server (L2TPns)
+ and our IPsec security suite.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ To control both of them we use:
+ <filename>/etc/init.d/l2tpns</filename> and
+ <filename>/etc/init.d/racoon</filename> (location
+ of start-up scripts may vary on non-Debian systems,
+ or if you've installed from
+ source).
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </sect4>
+ </sect3>
+
+ <sect3 id="deployment-installation-freeradius">
+ <title>FreeRADIUS</title>
+ <para>
+ The VPN setup needs to authenticate against something, that
+ is the users database which we chose to be a FreeRADIUS
+ server backed with a MySQL database.
+ </para>
+
+ <sect4 id="deployment-installation-freeradius-install">
+ <title>Installation</title>
+ <blockquote>
+ <para>
+ FreeRADIUS is the premiere open source RADIUS server.
+ While detailed statistics are not available, we believe
+ that FreeRADIUS is well within the top 5 RADIUS servers
+ world-wide, in terms of the number of people who use it
+ daily for authentication. It scales from embedded
+ systems with small amounts of memory, to systems with
+ millions of users. It is fast, flexible, configurable,
+ and supports more authentication protocols than many
+ commercial servers.
+ </para>
+ </blockquote>
+
+ <para>
+ Installing on Debian:
+ <screen># apt-get install freeradius freeradius-mysql</screen>
+ </para>
+
+ <para>
+ From source: Download the latest freeradius package from
+ <ulink url="http://freeradius.org/getting.html">freeradius.org
+ </ulink>
+<screen>
+# tar xvzf freeradius.tar.gz
+# cd freeradius
+# ./configure && make && make install
+</screen>
+ </para>
+ </sect4>
+
+ <sect4 id="deployment-installation-freeradius-config">
+ <title>Configuration</title>
+ <para>
+ This will appear a bit complex but it isn't, it's just a
+ lot of configuration.
+ </para>
+
+ <para>
+ Following are the configurations you need to have in your
+ <filename>/etc/freeradius/</filename> files.
+ </para>
+
+ <para>
+ In this section I will not give you a dump of the
+ configuration since they are very long and mostly default.
+ I'll just post which changes to make.
+ </para>
+
+ <para>
+ We haven't yet configured MySQL, but it'll come
+ afterwards, don't worry.
+ </para>
+
+ <para>
+ Make the following changes to the file
+ <filename>/etc/freeradius/sql.conf</filename>:
+<programlisting>
+server = "192.168.0.1"
+login = "radius"
+password = "12345678"
+</programlisting>
+ </para>
+
+ <para>
+ Add the following to the file
+ <filename>/etc/freeradius/clients.conf</filename>:
+<programlisting>
+client 192.168.0.1 {
+ secret = my_secret
+ shortname = localhost
+ nastype = other
+}
+</programlisting>
+ </para>
+
+ <para>
+ Don't confuse the secret directive there with IPsec.
+ RADIUS server are using secret keys also to identify their
+ allowed NAS (Network Access Servers), these are the
+ clients that talk to the RADIUS server.
+ </para>
+
+ <para>
+ Also, change the <code>client 127.0.0.1 {}</code>
+ directive to hold the secret "my_secret" like we
+ configured for 192.168.0.1 to avoid conflicts.
+ </para>
+
+ <para>
+ Uncomment the <code>sql</code> directive in the
+ <code>authorize</code>, <code>accounting</code>, and
+ <code>session</code> sections of
+ <filename>/etc/freeradius/radiusd.conf</filename>.
+ </para>
+
+ <para>
+ Now for populating FreeRADIUS with MySQL. If you don't
+ know or haven't set root password for MySQL you can do it
+ now with:
+ <screen># mysqladmin -u root password password_here</screen>
+
+ Then add the following to
+ <filename>/root/.my.cnf</filename>:
+
+<programlisting>
+[mysqladmin]
+user = root
+password = password_here
+</programlisting>
+ </para>
+
+ <para>
+ Create the <code>radius</code> database, using the
+ schema given in
+ <filename>/usr/share/doc/freeradius/examples/db_mysql.sql.gz
+ </filename>.
+ </para>
+
+ <note>
+ <para>
+ It may be necessary to modify the column definition of
+ <code>id</code> in the <code>nas</code> table, removing
+ <code>DEFAULT '0'</code> such that the definition reads:
+
+ <programlisting>id int(10) NOT NULL auto_increment,</programlisting>
+ </para>
+ </note>
+
+ <screen>
+# mysqladmin create radius
+# mysql radius
+mysql> source db_mysql.sql
+mysql> GRANT ALL ON * TO 'radius'@'localhost' IDENTIFIED BY 'radius_password';
+</screen>
+ <para>
+ All the configuration is now done. Let's add a user to
+ our VPN database.
+<screen>
+# mysql radius
+mysql> INSERT INTO radcheck values (0, "test", "User-Password", "==", "1234");
+</screen>
+ </para>
+
+ <para>
+ We have now created a user in the database of username
+ <code>test</code> and password <code>1234</code>.
+ </para>
+
+ <para>
+ Testing the RADIUS setup is simple using the radtest
+ utility provided with it.
+<screen>
+# radtest
+Usage: radtest user passwd radius-server[:port] nas-port-number secret [ppphint] [nasname]
+# radtest test 1234 192.168.0.1 1812 my_secret
+</screen>
+ </para>
+
+ <para>
+ radtest sends an Access-Request to the RADIUS server and
+ expects an Access-Accept back from it. If you're not
+ getting an Access-Accept from the RADIUS you're advised to
+ check the configuration again and see what you might have
+ missed.
+ </para>
+ </sect4>
+ </sect3>
+
+ <sect3 id="deployment-installation-firewall">
+ <title>Firewall Configuration</title>
+ <para>
+ We need to apply a few things to iptables configuration and
+ kernel networking.
+ </para>
+
+ <para>
+ First off, we need to accept VPN-specific packets through
+ the firewall. Of course you will have to adjust the rules
+ to fits you needs, in this case, ppp0 is the Internet
+ interface.
+<screen>
+# iptables --append INPUT --in-interface ppp0 -p udp --dport 1701 -j ACCEPT
+# iptables --append INPUT --in-interface ppp0 -p udp --dport 500 -j ACCEPT
+# iptables --append INPUT --in-interface ppp0 -p udp --dport 4500 -j ACCEPT
+# iptables --append INPUT --in-interface ppp0 -p 50 -j ACCEPT
+</screen>
+ </para>
+
+ <para>
+ If you haven't setup your Linux box as a gateway yet then
+ you have to allow forwarding/masqing for the boxes on
+ the LAN (and therefore for the VPN clients):
+<screen>
+# iptables --table nat --append POSTROUTING --out-interface ppp0 -j MASQUERADE
+# iptables --append FORWARD --in-interface eth0 -j ACCEPT
+# echo 1 > /proc/sys/net/ipv4/ip_forward
+</screen>
+ </para>
+ </sect3>
+ </sect2>
+ </sect1>
+
+ <sect1 id="references">
+ <title>References</title>
+ <variablelist>
+ <varlistentry>
+ <term>VPN Reference</term>
+ <listitem>
+ <para>
+ <ulink url="http://www.jacco2.dds.nl/networking/freeswan-l2tp.html"></ulink>
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>L2TPns Project</term>
+ <listitem>
+ <para><ulink url="http://l2tpns.sourceforge.net"></ulink></para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>OpenSWAN Project</term>
+ <listitem>
+ <para><ulink url="http://www.openswan.org"></ulink></para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </sect1>
+</article>
projects / l2tpns.git / blobdiff