Docs/vpn/practical-vpns.xml

   1 <?xml version="1.0"?>
   2 <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
   3     "http://docbook.org/xml/4.4/docbookx.dtd">
   4
   5 <article>
   6   <articleinfo>
   7     <title>Practical VPNs</title>
   8     <subtitle>Implementing Full-scale VPNs</subtitle>
   9
  10     <author>
  11       <firstname>Liran</firstname>
  12       <surname>Tal</surname>
  13       <affiliation>
  14         <address>
  15           <email>liran@enginx.com</email>
  16         </address>
  17       </affiliation>
  18     </author>
  19
  20     <othercredit>
  21       <firstname>Yakov</firstname>
  22       <surname>Shtutz</surname>
  23       <contrib>Special thanks</contrib>
  24     </othercredit>
  25
  26     <othercredit>
  27       <firstname>Shahar</firstname>
  28       <surname>Fermon</surname>
  29       <contrib>Testing and feedback</contrib>
  30     </othercredit>
  31
  32     <abstract>
  33       <para>
  34         This document was compiled from the administrator's point of
  35         view, to explain what are VPNs, how they are deployed today
  36         and to detail the necessary steps and tools to achieve and
  37         create a fully working VPN solution, integrated with RADIUS
  38         systems for AAA.
  39       </para>
  40
  41       <para>
  42         I will not dwell in this document on how to compile source
  43         packages or kernel patching, and with the same tone I'm
  44         assuming the reader is an exprerienced Linux user.
  45       </para>
  46
  47       <para>
  48         VPNs have their share amount of gossip for being a very
  49         complex thing, and in some cases this may be true as they tend
  50         to be more security intenssive which require adding more and
  51         more layers to the scheme.  With this said, we'll take a look
  52         at how fairly straight-forward it is to setup VPNs and
  53         maintain them with varius Open-Source tools.
  54       </para>
  55     </abstract>
  56   </articleinfo>
  57
  58   <sect1 id="overview">
  59     <title>Overview of VPNs and IPsec</title>
  60     <sect2 id="vpns">
  61       <title>Virtual Private Networks</title>
  62       <para>
  63         The purpose of a VPN is to create a secure channel ontop of an
  64         un-secure medium, where a computer or a device are put in each
  65         end-point in order to establish communication, each of these
  66         end-points are often reffered to as Point of Presense, or POP.
  67         This kind of a communication allows the capability of creating
  68         a Virtual Private Network, which is accesable over a medium
  69         such as the Internet and thus, extend the physical boundaries
  70         of an existing local network.
  71       </para>
  72
  73       <para>
  74         VPNs have three forms:
  75         <variablelist>
  76           <varlistentry>
  77             <term>Site-To-Site VPNs</term>
  78             <listitem>
  79               <para>
  80                 these setups exist in order to extend the local network
  81                 to create a much bigger LAN over the Internet.
  82               </para>
  83             </listitem>
  84           </varlistentry>
  85
  86           <varlistentry>
  87             <term>Network-To-Host or Remote access VPNs</term>
  88             <listitem>
  89               <para>
  90                 where a central VPN server is able to achieve multiple
  91                 connections, often reffered to as RoadWarrior VPNs.
  92                 (This setup is very common among ISPs)
  93               </para>
  94             </listitem>
  95           </varlistentry>
  96
  97           <varlistentry>
  98             <term>Network-To-Network</term>
  99             <listitem>
 100               <para>
 101                 extranet VPNs allow secure connections within branches
 102                 and business partners, they are an extension of a
 103                 Site-To-Site VPNs.
 104               </para>
 105             </listitem>
 106           </varlistentry>
 107         </variablelist>
 108       </para>
 109
 110       <para>
 111         <xref linkend="site-to-site"/> shows a Site-To-Site VPN diagram.
 112         <figure id="site-to-site">
 113           <title>Site to Site VPN</title>
 114           <mediaobject>
 115             <imageobject>
 116               <imagedata fileref="site-to-site-vpn.png"/>
 117             </imageobject>
 118           </mediaobject>
 119         </figure>
 120       </para>
 121
 122       <para>
 123         IP/VPNs are connections which are based upon IP tunnels.  A
 124         tunnel is a way to encapsulate an IP packet inside another IP
 125         packet or some other type of packet.  Why do we need
 126         tunneling?  A Virtual Private Network is identified by IANA's
 127         private IP assignments and so such packet can not go beyond
 128         the uplink Internet interface.
 129       </para>
 130
 131       <para>
 132         <xref linkend="tunneling-process"/> shows the tunneling process.
 133         <figure id="tunneling-process">
 134           <title>Tunneling Process</title>
 135           <mediaobject>
 136             <imageobject>
 137               <imagedata fileref="tunneling-process.png"/>
 138             </imageobject>
 139           </mediaobject>
 140         </figure>
 141       </para>
 142
 143       <para>
 144         Several tunneling protocols are available for manifesting
 145         VPNs.
 146
 147         <variablelist>
 148           <varlistentry>
 149             <term>L2F</term>
 150             <listitem>
 151               <para>
 152                 Layer 2 Forwarding, an older implementation which
 153                 assume position at the link layer of the OSI.  It has
 154                 no encryption capabilities and hence, deprecated.
 155               </para>
 156             </listitem>
 157           </varlistentry>
 158
 159           <varlistentry>
 160             <term>L2TP</term>
 161             <listitem>
 162               <para>
 163                 Layer 2 Tunneling Protocol, still no encryption
 164                 capabilities.
 165               </para>
 166             </listitem>
 167           </varlistentry>
 168
 169           <varlistentry>
 170             <term>PPTP</term>
 171             <listitem>
 172               <para>
 173                 Point-to-Point Tunneling Protocol, and yet again, no
 174                 encryption.
 175               </para>
 176             </listitem>
 177           </varlistentry>
 178         </variablelist>
 179       </para>
 180
 181       <para>
 182         As seen, the requirement of encryption enhancement is urgent
 183         in order to assure authentication, data integrity and privacy.
 184         IPsec solves this by providing a suite of security measures
 185         implemented at layer 3.
 186       </para>
 187     </sect2>
 188
 189     <sect2 id="ipsec">
 190       <title>IP Security Suite (IPsec)</title>
 191       <para>
 192         VPN Security is now appearing, this complex things.  How so?
 193         VPN tunnels by themselves are easily maintained by
 194         single-standalone tools like pppd, l2tpns, stunnel and others.
 195         Involving security with VPNs though requires more:
 196
 197         <itemizedlist>
 198           <listitem>
 199             <para>authentication, data integrity and privacy</para>
 200           </listitem>
 201
 202           <listitem>
 203             <para>keying management</para>
 204           </listitem>
 205         </itemizedlist>
 206       </para>
 207
 208       <note>
 209         <para>
 210           Keys are secrets being shared by two end-points to provide a
 211           secure mean of communication against a third-party
 212           connection from sniffing the actual data.
 213         </para>
 214       </note>
 215
 216       <para>
 217         Different ways to handle key management include RADIUS (Remote
 218         Authentication Dial In User Service) systems which provide AAA
 219         (Authentication, Authorization and Accounting).  Another
 220         solution is ISAKMP/Oackly - Internet Security Association and
 221         Key Management Protocol.  This solution requires you to posess
 222         one of the following:
 223
 224         <itemizedlist>
 225           <listitem>
 226             <para>something you have</para>
 227           </listitem>
 228
 229           <listitem>
 230             <para>something you know</para>
 231           </listitem>
 232
 233           <listitem>
 234             <para>something you are</para>
 235           </listitem>
 236         </itemizedlist>
 237       </para>
 238
 239       <para>
 240         The more requirements you meet the more secure is the medium,
 241         once established.  Let's review, something we have is like a
 242         certificate, it proves who we are.  Something we know, is a
 243         key, a secret password which we were told in a whisper, and
 244         something we are is our-fingerprint which identifies ourselves
 245         from other individuals.
 246       </para>
 247
 248       <sect3 id="ipsec-in-depth">
 249         <title>IPsec in Depth</title>
 250         <para>
 251           IPsec consists of two main protocols, an Authentication
 252           Header and Encapsulation Security Payload, also known as AH
 253           and ESP.  Although it is not bound to these and can be
 254           extended (and often is) to other standarts such as
 255
 256           <itemizedlist>
 257             <listitem>
 258               <para>Data Encryption Standart (DES and 3DES)</para>
 259             </listitem>
 260
 261             <listitem>
 262               <para>Diffie-Hellman (DH)</para>
 263             </listitem>
 264
 265             <listitem>
 266               <para>Secure Hash Algorithm-1 (SHA1)</para>
 267             </listitem>
 268
 269             <listitem>
 270               <para>Message Digest 5 (MD5)</para>
 271             </listitem>
 272
 273             <listitem>
 274               <para>Internet Key Exchange (IKE)</para>
 275             </listitem>
 276
 277             <listitem>
 278               <para>Certification Authorities (CA)</para>
 279             </listitem>
 280           </itemizedlist>
 281         </para>
 282
 283         <para>
 284           We'll be deploying an IKE daemon to handle the key
 285           management, which uses the Diffie- Hellman cryptography
 286           protocol in order to allow two parties to establish a
 287           connection based upon a shared secret key that both parties
 288           posess.  (Authentication within IKE is handled by MD5
 289           hashing)
 290         </para>
 291
 292         <para>
 293           IKE is responsible for authentication of two IPsec parties,
 294           negotiation of keys for encryption algorithms and security
 295           associations.  This process is commonly regarded as two
 296           phases:
 297
 298           <variablelist>
 299             <varlistentry>
 300               <term>Phase 1: IKE Security Association</term>
 301               <listitem>
 302                 <para>
 303                   The IKE daemon authenticates against the peers in
 304                   order to achieve a secure channel, according to the
 305                   Diffie-Hellman key agreement.
 306                 </para>
 307               </listitem>
 308             </varlistentry>
 309
 310             <varlistentry>
 311               <term>Phase 2: IKE IPsec Negotiation</term>
 312               <listitem>
 313                 <para>
 314                   After achieving an authenticated channel, the
 315                   parties now negotiate a secure transform (the way to
 316                   encrypt and secure the medium) where the sender is
 317                   offering his/hers transform set after which the
 318                   receiver decides upon one.  An IPsec session can now
 319                   safely begin.
 320                 </para>
 321               </listitem>
 322             </varlistentry>
 323           </variablelist>
 324         </para>
 325
 326         <para>
 327           Just to be clear, a Security Association is an agreed
 328           relation between two parties which describes how they will
 329           use security services (from IPsec) to communicate.
 330         </para>
 331       </sect3>
 332
 333       <sect3 id="ipsec-modes">
 334         <title>IPsec Modes</title>
 335         <para>
 336           IPsec can operate in two different modes:
 337
 338           <variablelist>
 339             <varlistentry>
 340               <term>Transport mode</term>
 341               <listitem>
 342                 <para>
 343                   takes place when two devices (like a station and a
 344                   gateway (now considered a host)) are establishing a
 345                   connection which upon they both support IPsec.
 346                 </para>
 347               </listitem>
 348             </varlistentry>
 349
 350             <varlistentry>
 351               <term>Tunnel mode</term>
 352               <listitem>
 353                 <para>
 354                   we require tunnel mode when we proxy IPsec
 355                   connetions between two stations behind the IPsec
 356                   gateway.  For example, in a Site-to-Site VPN a
 357                   tunnel mode lives, since it exists in order to
 358                   provide the stations behind these gateways runing
 359                   the VPN/IPsec to communicate securely.  In this
 360                   situation, both end-points are runing an IPsec
 361                   software.
 362                 </para>
 363               </listitem>
 364             </varlistentry>
 365           </variablelist>
 366         </para>
 367
 368         <para>
 369           In definition, a tunnel mode IPsec is better secured than
 370           transport.  Without going too deep into the ins-and-outs of
 371           the technical side, transport mode doesn't encapsulate the
 372           actual IP layer but only the tcp/udp (Transport layer of the
 373           OSI) where-as a tunnel mode encapsulate both the Transport
 374           layer and the IP layer into a new IP packet.
 375         </para>
 376
 377         <para>
 378           To summarize, we need VPNs for data-exchange methods and a
 379           set of IPsec tools for security reasons.
 380         </para>
 381       </sect3>
 382     </sect2>
 383   </sect1>
 384
 385   <sect1 id="deployment">
 386     <title>VPN Deployment</title>
 387     <para>
 388       I've assembled another diagram to view the actual VPN setup.
 389       <xref linkend="vpn-deployment"/> gives a general description of
 390       how the network will be layed out in real-world scenario.
 391
 392       <figure id="vpn-deployment">
 393         <title>VPN Deployment</title>
 394         <mediaobject>
 395           <imageobject>
 396             <imagedata fileref="vpn-deployment.png"/>
 397           </imageobject>
 398         </mediaobject>
 399       </figure>
 400     </para>
 401
 402     <para>
 403       We notice that a single Linux box is acting as a Gateway and has
 404       all the services included with it.  This is a bad idea from a
 405       security prespective but it's easy to just deploy the FreeRADIUS
 406       and MySQL servers on another machine.  Of course the L2TPns and
 407       the rest of the IPsec tools suite would have to remain on the
 408       Gateway box (not necessarily the Firewall).
 409     </para>
 410
 411     <para>
 412       <xref linkend="vpn-process"/> attempts to explain the actual
 413       process that the VPN takes and to detail the place that each of
 414       that application-in-charge takes place.
 415
 416       <figure id="vpn-process">
 417         <title>VPN Process</title>
 418         <mediaobject>
 419           <imageobject>
 420             <imagedata fileref="vpn-process.png"/>
 421           </imageobject>
 422         </mediaobject>
 423       </figure>
 424     </para>
 425
 426     <sect2 id="deployment-requirements">
 427       <title>Requirements</title>
 428       <sect3 id="deployment-requirements-toolbox">
 429         <title>The Toolbox</title>
 430         <para>
 431           Following is a description of the requirements you will
 432           have to meet:
 433
 434           <variablelist>
 435             <varlistentry>
 436               <term>A Linux box</term>
 437               <listitem>
 438                 <para>preferably a 2.4.27 kernel or higher.</para>
 439                 <para>
 440                   Debian is the chosen distribution which means we'll
 441                   be using apt-get for installation, but I'll also
 442                   focus on basic source tarballs installation.
 443                 </para>
 444
 445                 <para>
 446                   Dependencies:
 447
 448                   <itemizedlist>
 449                     <listitem>
 450                       <para>ipsec configuration in the kernel</para>
 451                     </listitem>
 452                   </itemizedlist>
 453                 </para>
 454               </listitem>
 455             </varlistentry>
 456
 457             <varlistentry>
 458               <term>L2TPns</term>
 459               <listitem>
 460                 <para>an L2TP PPP Termination tool.</para>
 461                 <para>
 462                   Dependencies:
 463
 464                   <itemizedlist>
 465                     <listitem>
 466                       <para>libcli 1.8.0 or greater</para>
 467                     </listitem>
 468
 469                     <listitem>
 470                       <para>
 471                         tun/tap interface compiled in the kernel or as
 472                         a module
 473                       </para>
 474                     </listitem>
 475                   </itemizedlist>
 476                 </para>
 477               </listitem>
 478             </varlistentry>
 479
 480             <varlistentry>
 481               <term>FreeRADIUS</term>
 482               <listitem>
 483                 <para>For authentication, and accounting.</para>
 484               </listitem>
 485             </varlistentry>
 486
 487             <varlistentry>
 488               <term>MySQL</term>
 489               <listitem>
 490                 <para>To act as a back-end database for the RADIUS.</para>
 491               </listitem>
 492             </varlistentry>
 493
 494             <varlistentry>
 495               <term>OpenSwan</term>
 496               <listitem>
 497                 <para>Provides the ipsec suite package.</para>
 498               </listitem>
 499             </varlistentry>
 500           </variablelist>
 501         </para>
 502       </sect3>
 503
 504       <sect3 id="deployment-requirements-kernel">
 505         <title>Kernel Support</title>
 506         <para>
 507           Debian stock kernel 2.4.27 and up are ipsec compatible
 508           although if you think otherwise check for the
 509           kernel-patch-openswan package.
 510         </para>
 511       </sect3>
 512     </sect2>
 513
 514     <sect2 id="deployment-installation">
 515       <title>Installation</title>
 516       <sect3 id="deployment-installation-l2tpns">
 517         <title>L2TPns</title>
 518         <sect4 id="deployment-installation-l2tpns-install">
 519           <title>Installation</title>
 520           <blockquote>
 521             <para>
 522               L2TPns is a layer 2 tunneling protocol network server
 523               (LNS).  It supports up to 65535 concurrent sessions per
 524               server/cluster plus ISP features such as rate limiting,
 525               walled garden, usage accounting, and more.
 526             </para>
 527           </blockquote>
 528
 529           <para>
 530             In a personal note - L2TPns is highly configurable for
 531             many cases, and extremely reliable for
 532             production/commerical use.
 533           </para>
 534
 535           <para>
 536             <variablelist>
 537               <varlistentry>
 538                 <term>Step 1:</term>
 539                 <listitem>
 540                   <para>
 541                     Make sure you have libcli-1.8 development package
 542                     installed:
 543 <screen>
 544 # apt-cache search libcli
 545 libcli-dev - emulates a cisco style telnet command-line interface (dev files)
 546 libcli1 - emulates a cisco style telnet command-line interface
 547 # apt-get install libcli-dev
 548 </screen>
 549                   </para>
 550                 </listitem>
 551               </varlistentry>
 552
 553               <varlistentry>
 554                 <term>Step 2:</term>
 555                 <listitem>
 556                   <para>
 557                     Download the source from
 558                     <ulink url="http://sourceforge.net/projects/l2tpns/">
 559                     SourceForge</ulink>.
 560                   </para>
 561                 </listitem>
 562               </varlistentry>
 563
 564               <varlistentry>
 565                 <term>Step 3:</term>
 566                 <listitem>
 567                   <para>
 568                     Build and install:
 569                     <code>make &amp;&amp; make install</code>
 570                   </para>
 571                 </listitem>
 572               </varlistentry>
 573             </variablelist>
 574           </para>
 575
 576           <note>
 577             <para>
 578               Alternately, you can skip these steps and simply
 579               <code>apt-get install l2tpns</code>.
 580             </para>
 581           </note>
 582
 583           <note>
 584             <para>
 585               On RPM-based distributions, you should be able to make
 586               packages from the libcli and l2tpns source tarballs with
 587               <code>rpmbuild -ta</code>.
 588             </para>
 589           </note>
 590
 591           <para>
 592             Once compiliation is done you will have l2tpns in
 593             <filename>/usr/sbin/l2tpns</filename>, and all
 594             configuration files can be found in
 595             <filename>/etc/l2tpns/</filename>.
 596           </para>
 597         </sect4>
 598
 599         <sect4 id="deployment-installation-l2tpns-config">
 600           <title>Configuration</title>
 601           <para>
 602             The only configuration that L2TPns takes is centralized in
 603             the configuration file
 604             <filename>/etc/l2tpns/startup-config</filename>.
 605 <programlisting>
 606 set debug 2                               # Debugging level
 607 set log_file "/var/log/l2tpns"            # Log file: comment out to use stderr, use
 608                                           # "syslog:facility" for syslog
 609 set pid_file "/var/run/l2tpns.pid"        # Write pid to this file
 610 set l2tp_secret <emphasis>"secret"</emphasis>                  # shared secret
 611 set primary_dns <emphasis>212.117.128.6</emphasis>             # Only 2 DNS server entries are allowed
 612 set secondary_dns <emphasis>212.117.129.3</emphasis>
 613 set primary_radius <emphasis>192.168.0.1</emphasis>            # Can have multiple radius server entries,
 614                                           # but ony one radius secret
 615 set primary_radius_port 1812
 616 set radius_secret <emphasis>"radius_secret"</emphasis>
 617 set radius_accounting yes
 618 set radius_dae_port 3799
 619 set accounting_dir "/var/run/l2tpns/acct" # Write usage accounting files into specified
 620                                           # directory
 621 set peer_address <emphasis>192.168.0.1</emphasis>              # Gateway address given to clients
 622 load plugin "sessionctl"                  # Drop/kill sessions
 623 load plugin "autothrottle"                # Throttle/snoop based on RADIUS
 624 load plugin "throttlectl"                 # Control throttle/snoop with nsctl
 625 load plugin "snoopctl"
 626 </programlisting>
 627           </para>
 628
 629           <para>
 630             This is the trimmed down version of probably most of
 631             the common configuration and even some extra options.
 632           </para>
 633
 634           <para>
 635             Important configuration options are highlited and you
 636             should adjust these to meet your network needs.  We can
 637             deploy all of the environment into one box which is of
 638             course not a very good idea from a security point of view,
 639             but will function just fine.  Moreover, we will be using
 640             aliased IP addresses so once you've decided to move the
 641             FreeRADIUS daemon to another computer on the LAN it will
 642             be fairly easy and won't take too much configuration into
 643             it.
 644           </para>
 645
 646           <para>
 647             Next, we need to setup the IP pool that L2TPns will
 648             provide to each VPN client.  The configuration file is
 649             located at <filename>/etc/l2tpns/ip_pool</filename> and
 650             should look like the following:
 651             <programlisting>172.16.21.0/24</programlisting>
 652           </para>
 653
 654           <important>
 655             <para>
 656               Of course you can change this pool to anything else
 657               (IANA IPs assigned for private internets only) just make
 658               sure it is not conflicting with your current LAN network
 659               addresses.  This means that if you've assigned addresses
 660               of 192.168.0.1 and 192.168.0.2 to your LAN boxes you
 661               can't have a pool of 192.168.0.1/24 defined since L2TPns
 662               will try to route those addresses from the tun device,
 663               which is needless to say a bad idea...
 664             </para>
 665           </important>
 666
 667           <para>Next up, creating the access-list for L2TPns.</para>
 668
 669           <para>
 670             Add a username and password into
 671             <filename>/etc/l2tpns/users</filename>:
 672             <programlisting>admin:12345</programlisting>
 673
 674             The password may either be plain-text as above, or
 675             encrypted with MD5 or DES (to distinguish DES from
 676             plain-text passwords, prefix the value with
 677             <code>{crypt}</code>).
 678           </para>
 679
 680           <para>
 681             L2TPns utilizes a terminal connection on port 23 which you
 682             would feel very comfortable in if you have worked with
 683             routers and switches devices before.  The terminal
 684             provides control over the ppp termination which is why
 685             we've created an account to log on to.
 686           </para>
 687         </sect4>
 688       </sect3>
 689
 690       <sect3 id="deployment-installation-ipsec">
 691         <title>IPsec</title>
 692         <sect4 id="deployment-installation-ipsec-install">
 693           <title>Installation</title>
 694           <para>
 695             User-space IPsec tools for various IPsec implementations
 696             exist for linux, among them is the port of KAME's
 697             libipsec, setkey, and racoon.  Others are the OpenSWAN (a
 698             successor to the FreeSWAN project).
 699           </para>
 700
 701           <para>
 702             Getting IPsec installed is fairly easy with Debian:
 703             <screen># apt-get install openswan</screen>
 704           </para>
 705
 706           <para>
 707             The OpenSWAN project provides packages for RPM-based
 708             distributions.
 709           </para>
 710
 711           <para>
 712             Alternately, you may download the
 713             <ulink url="http://www.openswan.org/code/">source</ulink>
 714             from the OpenSWAN project:
 715 <screen>
 716 # tar xvzf openswan-2.4.4.tar.gz
 717 # cd openswan-2.4.4
 718 # ./configure &amp;&amp; make &amp;&amp; make install
 719 </screen>
 720           </para>
 721         </sect4>
 722
 723         <sect4 id="deployment-installation-ipsec-config">
 724           <title>Configuration</title>
 725           <para>
 726             OpenSWAN acts as the IKE daemon (remember IKE?  it's job
 727             is to authenticate between the two peers and negotiate a
 728             secure medium).  We will be setting up the IKE daemon as a
 729             RoadWarrior configuration, a term for remote access
 730             VPNs.
 731           </para>
 732
 733           <para>
 734             We desire this approach for compatibilty because after our
 735             VPN solution will be complete any user from a Windows
 736             machine will be easily ready to connect without any 3rd
 737             party applications, same for Linux.
 738           </para>
 739
 740           <para>
 741             Configuration files are placed in
 742             <filename>/etc/ipsec.d/</filename>,
 743             <filename>/etc/ipsec.conf</filename> and
 744             <filename>/etc/ipsec.secrets</filename>.
 745           </para>
 746
 747           <para>
 748             Let's start by choosing the remote client and it's PSK
 749             (Private Shared Key) <filename>/etc/ipsec.secrets</filename>:
 750 <programlisting>
 751 hostname_or_ipaddress %any : PSK "mysecretkeyisverylong"
 752 </programlisting>
 753           </para>
 754
 755           <para>
 756             This is an IP/key pair.  The IP or FQDN defines the local
 757             peer (like a SOHO branch), then the remote host.  Here we
 758             defined %any for all hosts, though it's possible to define
 759             only a specific IP.  At last, we define the key associated
 760             with it.
 761           </para>
 762
 763           <para>
 764             A better way to create a key is to utilize /dev/random for
 765             creating a unique key.
 766             <screen># dd if=/dev/random count=16 bs=1 2>/dev/null | xxd -ps</screen>
 767           </para>
 768
 769           <para>
 770             Next, let's prepare the configuration file
 771             <filename>/etc/ipsec.conf</filename>:
 772 <programlisting>
 773 version 2.0
 774 config setup
 775      nat_traversal=yes
 776
 777 conn l2tp
 778      authby=secret
 779      pfs=no
 780      keyingtries=3
 781      left=real_ip_address
 782      leftnexthop=%defaultroute
 783      leftprotoport=17/%any
 784      right=%any
 785      rightprotoport=17/%any
 786      auto=add
 787
 788 include /etc/ipsec.d/examples/no_oe.conf
 789 </programlisting>
 790           </para>
 791
 792           <para>
 793             In this file we have first defined version 2 which is a
 794             must, then enabled NAT Traversal.  To understand the
 795             importance of this feature think of the following
 796             scenario:  A remote user attempts to connect while he's
 797             behind a router and therefore NATed.  The router has to
 798             de-encapsulate the packet, change things and then build it
 799             up again and send it.  IPsec doesn't like other people
 800             messing with it's packet.  That's why we solve this issue
 801             with NAT Traversal.
 802           </para>
 803
 804           <para>
 805             Next up we configure authentication type (certificates,
 806             psk, rsa keys, etc) then the left and right peers.  The
 807             default mode OpenSWAN takes is tunnel unless told
 808             otherwise.  I won't go into in-depth explanation of every
 809             method, you can take a quick look at
 810             <filename>/etc/ipsec.d/examples</filename> for more
 811             explanation and other variations of working with RSA keys,
 812             Certificates, host-to-host, and more.
 813           </para>
 814
 815           <para>
 816             In summary:
 817             <itemizedlist>
 818               <listitem>
 819                 <para>
 820                   We've configured an almost complete IPsec VPN setup.
 821                 </para>
 822               </listitem>
 823
 824               <listitem>
 825                 <para>
 826                   We've installed and configured a VPN server (L2TPns)
 827                   and our IPsec security suite.
 828                 </para>
 829               </listitem>
 830
 831               <listitem>
 832                 <para>
 833                   To control both of them we use:
 834                   <filename>/etc/init.d/l2tpns</filename> and
 835                   <filename>/etc/init.d/racoon</filename> (location
 836                   of start-up scripts may vary on non-Debian systems,
 837                   or if you've installed from
 838                   source).
 839                 </para>
 840               </listitem>
 841             </itemizedlist>
 842           </para>
 843         </sect4>
 844       </sect3>
 845
 846       <sect3 id="deployment-installation-freeradius">
 847         <title>FreeRADIUS</title>
 848         <para>
 849           The VPN setup needs to authenticate against something, that
 850           is the users database which we chose to be a FreeRADIUS
 851           server backed with a MySQL database.
 852         </para>
 853
 854         <sect4 id="deployment-installation-freeradius-install">
 855           <title>Installation</title>
 856           <blockquote>
 857             <para>
 858               FreeRADIUS is the premiere open source RADIUS server.
 859               While detailed statistics are not available, we believe
 860               that FreeRADIUS is well within the top 5 RADIUS servers
 861               world-wide, in terms of the number of people who use it
 862               daily for authentication.  It scales from embedded
 863               systems with small amounts of memory, to systems with
 864               millions of users.  It is fast, flexible, configurable,
 865               and supports more authentication protocols than many
 866               commercial servers.
 867             </para>
 868           </blockquote>
 869
 870           <para>
 871             Installing on Debian:
 872             <screen># apt-get install freeradius freeradius-mysql</screen>
 873           </para>
 874
 875           <para>
 876             From source:  Download the latest freeradius package from
 877             <ulink url="http://freeradius.org/getting.html">freeradius.org
 878             </ulink>
 879 <screen>
 880 # tar xvzf freeradius.tar.gz
 881 # cd freeradius
 882 # ./configure &amp;&amp; make &amp;&amp; make install
 883 </screen>
 884           </para>
 885         </sect4>
 886
 887         <sect4 id="deployment-installation-freeradius-config">
 888           <title>Configuration</title>
 889           <para>
 890             This will appear a bit complex but it isn't, it's just a
 891             lot of configuration.
 892           </para>
 893
 894           <para>
 895             Following are the configurations you need to have in your
 896             <filename>/etc/freeradius/</filename> files.
 897           </para>
 898
 899           <para>
 900             In this section I will not give you a dump of the
 901             configuration since they are very long and mostly default.
 902             I'll just post which changes to make.
 903           </para>
 904
 905           <para>
 906             We haven't yet configured MySQL, but it'll come
 907             afterwards, don't worry.
 908           </para>
 909
 910           <para>
 911             Make the following changes to the file
 912             <filename>/etc/freeradius/sql.conf</filename>:
 913 <programlisting>
 914 server = "192.168.0.1"
 915 login = "radius"
 916 password = "12345678"
 917 </programlisting>
 918           </para>
 919
 920           <para>
 921             Add the following to the file
 922             <filename>/etc/freeradius/clients.conf</filename>:
 923 <programlisting>
 924 client 192.168.0.1 {
 925         secret    = my_secret
 926         shortname = localhost
 927         nastype   = other
 928 }
 929 </programlisting>
 930           </para>
 931
 932           <para>
 933             Don't confuse the secret directive there with IPsec.
 934             RADIUS server are using secret keys also to identify their
 935             allowed NAS (Network Access Servers), these are the
 936             clients that talk to the RADIUS server.
 937           </para>
 938
 939           <para>
 940             Also, change the <code>client 127.0.0.1 {}</code>
 941             directive to hold the secret "my_secret" like we
 942             configured for 192.168.0.1 to avoid conflicts.
 943           </para>
 944
 945           <para>
 946             Uncomment the <code>sql</code> directive in the
 947             <code>authorize</code>, <code>accounting</code>, and
 948             <code>session</code> sections of
 949             <filename>/etc/freeradius/radiusd.conf</filename>.
 950           </para>
 951
 952           <para>
 953             Now for populating FreeRADIUS with MySQL.  If you don't
 954             know or haven't set root password for MySQL you can do it
 955             now with:
 956             <screen># mysqladmin -u root password password_here</screen>
 957
 958             Then add the following to
 959             <filename>/root/.my.cnf</filename>:
 960
 961 <programlisting>
 962 [mysqladmin]
 963 user = root
 964 password = password_here
 965 </programlisting>
 966           </para>
 967
 968           <para>
 969             Create the <code>radius</code> database, using the
 970             schema given in
 971             <filename>/usr/share/doc/freeradius/examples/db_mysql.sql.gz
 972             </filename>.
 973           </para>
 974
 975           <note>
 976             <para>
 977               It may be necessary to modify the column definition of
 978               <code>id</code> in the <code>nas</code> table, removing
 979               <code>DEFAULT '0'</code> such that the definition reads:
 980
 981               <programlisting>id int(10) NOT NULL auto_increment,</programlisting>
 982             </para>
 983           </note>
 984
 985           <screen>
 986 # mysqladmin create radius
 987 # mysql radius
 988 mysql> source db_mysql.sql
 989 mysql> GRANT ALL ON * TO 'radius'@'localhost' IDENTIFIED BY 'radius_password';
 990 </screen>
 991           <para>
 992             All the configuration is now done.  Let's add a user to
 993             our VPN database.
 994 <screen>
 995 # mysql radius
 996 mysql> INSERT INTO radcheck values (0, "test", "User-Password", "==", "1234");
 997 </screen>
 998           </para>
 999
1000           <para>
1001             We have now created a user in the database of username
1002             <code>test</code> and password <code>1234</code>.
1003           </para>
1004
1005           <para>
1006             Testing the RADIUS setup is simple using the radtest
1007             utility provided with it.
1008 <screen>
1009 # radtest
1010 Usage: radtest user passwd radius-server[:port] nas-port-number secret [ppphint] [nasname]
1011 # radtest test 1234 192.168.0.1 1812 my_secret
1012 </screen>
1013           </para>
1014
1015           <para>
1016             radtest sends an Access-Request to the RADIUS server and
1017             expects an Access-Accept back from it.  If you're not
1018             getting an Access-Accept from the RADIUS you're advised to
1019             check the configuration again and see what you might have
1020             missed.
1021           </para>
1022         </sect4>
1023       </sect3>
1024
1025       <sect3 id="deployment-installation-firewall">
1026         <title>Firewall Configuration</title>
1027         <para>
1028           We need to apply a few things to iptables configuration and
1029           kernel networking.
1030         </para>
1031
1032         <para>
1033           First off, we need to accept VPN-specific packets through
1034           the firewall.  Of course you will have to adjust the rules
1035           to fits you needs, in this case, ppp0 is the Internet
1036           interface.
1037 <screen>
1038 # iptables --append INPUT --in-interface  ppp0 -p udp --dport 1701 -j ACCEPT
1039 # iptables --append INPUT --in-interface  ppp0 -p udp --dport 500 -j ACCEPT
1040 # iptables --append INPUT --in-interface  ppp0 -p udp --dport 4500 -j ACCEPT
1041 # iptables --append INPUT --in-interface  ppp0 -p 50 -j ACCEPT
1042 </screen>
1043         </para>
1044
1045         <para>
1046           If you haven't setup your Linux box as a gateway yet then
1047           you have to allow forwarding/masqing for the boxes on
1048           the LAN (and therefore for the VPN clients):
1049 <screen>
1050 # iptables --table nat --append POSTROUTING --out-interface ppp0 -j MASQUERADE
1051 # iptables --append FORWARD --in-interface eth0 -j ACCEPT
1052 # echo 1 > /proc/sys/net/ipv4/ip_forward
1053 </screen>
1054         </para>
1055       </sect3>
1056     </sect2>
1057   </sect1>
1058
1059   <sect1 id="references">
1060     <title>References</title>
1061     <variablelist>
1062       <varlistentry>
1063         <term>VPN Reference</term>
1064         <listitem>
1065           <para>
1066             <ulink url="http://www.jacco2.dds.nl/networking/freeswan-l2tp.html"></ulink>
1067           </para>
1068         </listitem>
1069       </varlistentry>
1070
1071       <varlistentry>
1072         <term>L2TPns Project</term>
1073         <listitem>
1074           <para><ulink url="http://l2tpns.sourceforge.net"></ulink></para>
1075         </listitem>
1076       </varlistentry>
1077
1078       <varlistentry>
1079         <term>OpenSWAN Project</term>
1080         <listitem>
1081           <para><ulink url="http://www.openswan.org"></ulink></para>
1082         </listitem>
1083       </varlistentry>
1084     </variablelist>
1085   </sect1>
1086 </article>