initial converion of liran's "Practical VPNs" to docbook
authorBrendan O'Dea <bod@optus.net>
Mon, 24 Apr 2006 15:19:41 +0000 (15:19 +0000)
committerBrendan O'Dea <bod@optus.net>
Mon, 24 Apr 2006 15:19:41 +0000 (15:19 +0000)
Changes
Docs/vpn/practical-vpns.xml [new file with mode: 0644]
Docs/vpn/site-to-site-vpn.png [new file with mode: 0644]
Docs/vpn/tunneling-process.png [new file with mode: 0644]
Docs/vpn/vpn-deployment.png [new file with mode: 0644]
Docs/vpn/vpn-process.png [new file with mode: 0644]
l2tpns.spec

diff --git a/Changes b/Changes
index 36a1d11..ce33fe5 100644 (file)
--- a/Changes
+++ b/Changes
@@ -1,5 +1,6 @@
-* Mon Apr 24 2006 Brendan O'Dea <bod@optus.net> 2.1.19
+* Tue Apr 25 2006 Brendan O'Dea <bod@optus.net> 2.1.19
 - Only poll clifd if successfully bound.
+- Add "Practical VPNs" document from Liran Tal as Docs/vpn .
 
 * Tue Apr 18 2006 Brendan O'Dea <bod@optus.net> 2.1.18
 - Don't shutdown on TerminateReq, wait for CDN.
diff --git a/Docs/vpn/practical-vpns.xml b/Docs/vpn/practical-vpns.xml
new file mode 100644 (file)
index 0000000..808a79f
--- /dev/null
@@ -0,0 +1,912 @@
+<?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>Testing and feedback</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" float="1">
+         <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" float="1">
+         <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" float="1">
+       <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" float="1">
+       <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 &amp;&amp; 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 &amp;&amp; make &amp;&amp; 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 there-fore 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 &amp;&amp; make &amp;&amp; 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>
diff --git a/Docs/vpn/site-to-site-vpn.png b/Docs/vpn/site-to-site-vpn.png
new file mode 100644 (file)
index 0000000..46908c9
Binary files /dev/null and b/Docs/vpn/site-to-site-vpn.png differ
diff --git a/Docs/vpn/tunneling-process.png b/Docs/vpn/tunneling-process.png
new file mode 100644 (file)
index 0000000..0b24062
Binary files /dev/null and b/Docs/vpn/tunneling-process.png differ
diff --git a/Docs/vpn/vpn-deployment.png b/Docs/vpn/vpn-deployment.png
new file mode 100644 (file)
index 0000000..b49505e
Binary files /dev/null and b/Docs/vpn/vpn-deployment.png differ
diff --git a/Docs/vpn/vpn-process.png b/Docs/vpn/vpn-process.png
new file mode 100644 (file)
index 0000000..b83e344
Binary files /dev/null and b/Docs/vpn/vpn-process.png differ
index cf493ff..da52c9a 100644 (file)
@@ -43,5 +43,5 @@ rm -rf %{buildroot}
 %attr(644,root,root) /usr/share/man/man[58]/*
 
 %changelog
-* Mon Apr 24 2006 Brendan O'Dea <bod@optus.net> 2.1.19-1
+* Tue Apr 25 2006 Brendan O'Dea <bod@optus.net> 2.1.19-1
 - 2.1.19 release, see /usr/share/doc/l2tpns-2.1.19/Changes