Apply patch from Geoffrey D. Bennett to fix retry of control packets.
[l2tpns.git] / 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>