487 lines
22 KiB
HTML
487 lines
22 KiB
HTML
<h1 id="overview">Overview of VPNs and IPsec</h1>
|
|
<h2 id="vpns">Virtual Private Networks</h2>
|
|
<p>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.</p>
|
|
<p>VPNs have three forms:</p>
|
|
<dl>
|
|
<dt>Site-To-Site VPNs</dt>
|
|
<dd>
|
|
<p>these setups exist in order to extend the local network to create a
|
|
much bigger LAN over the Internet.</p>
|
|
</dd>
|
|
<dt>Network-To-Host or Remote access VPNs</dt>
|
|
<dd>
|
|
<p>where a central VPN server is able to achieve multiple connections,
|
|
often reffered to as RoadWarrior VPNs. (This setup is very common among
|
|
ISPs)</p>
|
|
</dd>
|
|
<dt>Network-To-Network</dt>
|
|
<dd>
|
|
<p>extranet VPNs allow secure connections within branches and business
|
|
partners, they are an extension of a Site-To-Site VPNs.</p>
|
|
</dd>
|
|
</dl>
|
|
<p><img src="./images/site-to-site-vpn.png" alt="site to site" /><br />
|
|
shows a Site-To-Site VPN diagram.</p>
|
|
<p>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.</p>
|
|
<p><img src="./images/tunneling-process.png"
|
|
alt="tunneling process" /><br />
|
|
shows the tunneling process.</p>
|
|
<p>Several tunneling protocols are available for manifesting VPNs.</p>
|
|
<dl>
|
|
<dt>L2F</dt>
|
|
<dd>
|
|
<p>Layer 2 Forwarding, an older implementation which assume position at
|
|
the link layer of the OSI. It has no encryption capabilities and hence,
|
|
deprecated.</p>
|
|
</dd>
|
|
<dt>L2TP</dt>
|
|
<dd>
|
|
<p>Layer 2 Tunneling Protocol, still no encryption capabilities.</p>
|
|
</dd>
|
|
<dt>PPTP</dt>
|
|
<dd>
|
|
<p>Point-to-Point Tunneling Protocol, and yet again, no encryption.</p>
|
|
</dd>
|
|
</dl>
|
|
<p>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.</p>
|
|
<h2 id="ipsec">IP Security Suite (IPsec)</h2>
|
|
<p>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:</p>
|
|
<ul>
|
|
<li><p>authentication, data integrity and privacy</p></li>
|
|
<li><p>keying management</p></li>
|
|
</ul>
|
|
<div class="note">
|
|
<p>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.</p>
|
|
</div>
|
|
<p>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:</p>
|
|
<ul>
|
|
<li><p>something you have</p></li>
|
|
<li><p>something you know</p></li>
|
|
<li><p>something you are</p></li>
|
|
</ul>
|
|
<p>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.</p>
|
|
<h3 id="ipsec-in-depth">IPsec in Depth</h3>
|
|
<p>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</p>
|
|
<ul>
|
|
<li><p>Data Encryption Standart (DES and 3DES)</p></li>
|
|
<li><p>Diffie-Hellman (DH)</p></li>
|
|
<li><p>Secure Hash Algorithm-1 (SHA1)</p></li>
|
|
<li><p>Message Digest 5 (MD5)</p></li>
|
|
<li><p>Internet Key Exchange (IKE)</p></li>
|
|
<li><p>Certification Authorities (CA)</p></li>
|
|
</ul>
|
|
<p>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)</p>
|
|
<p>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:</p>
|
|
<dl>
|
|
<dt>Phase 1: IKE Security Association</dt>
|
|
<dd>
|
|
<p>The IKE daemon authenticates against the peers in order to achieve a
|
|
secure channel, according to the Diffie-Hellman key agreement.</p>
|
|
</dd>
|
|
<dt>Phase 2: IKE IPsec Negotiation</dt>
|
|
<dd>
|
|
<p>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.</p>
|
|
</dd>
|
|
</dl>
|
|
<p>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.</p>
|
|
<h3 id="ipsec-modes">IPsec Modes</h3>
|
|
<p>IPsec can operate in two different modes:</p>
|
|
<dl>
|
|
<dt>Transport mode</dt>
|
|
<dd>
|
|
<p>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.</p>
|
|
</dd>
|
|
<dt>Tunnel mode</dt>
|
|
<dd>
|
|
<p>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.</p>
|
|
</dd>
|
|
</dl>
|
|
<p>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.</p>
|
|
<p>To summarize, we need VPNs for data-exchange methods and a set of
|
|
IPsec tools for security reasons.</p>
|
|
<h1 id="deployment">VPN Deployment</h1>
|
|
<p>I've assembled another diagram to view the actual VPN setup.<br />
|
|
<img src="./images/vpn-deployment.png" alt="vpn deployment" /><br />
|
|
gives a general description of how the network will be layed out in
|
|
real-world scenario.</p>
|
|
<p>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).</p>
|
|
<p><img src="./images/vpn-process.png" alt="vpn process" /><br />
|
|
attempts to explain the actual process that the VPN takes and to detail
|
|
the place that each of that application-in-charge takes place.</p>
|
|
<h2 id="deployment-requirements">Requirements</h2>
|
|
<h3 id="deployment-requirements-toolbox">The Toolbox</h3>
|
|
<p>Following is a description of the requirements you will have to
|
|
meet:</p>
|
|
<dl>
|
|
<dt>A Linux box</dt>
|
|
<dd>
|
|
<p>preferably a 2.4.27 kernel or higher.</p>
|
|
<p>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.</p>
|
|
<p>Dependencies:</p>
|
|
<ul>
|
|
<li>ipsec configuration in the kernel</li>
|
|
</ul>
|
|
</dd>
|
|
<dt>L2TPns</dt>
|
|
<dd>
|
|
<p>an L2TP PPP Termination tool.</p>
|
|
<p>Dependencies:</p>
|
|
<ul>
|
|
<li><p>libcli 1.8.0 or greater</p></li>
|
|
<li><p>tun/tap interface compiled in the kernel or as a module</p></li>
|
|
</ul>
|
|
</dd>
|
|
<dt>FreeRADIUS</dt>
|
|
<dd>
|
|
<p>For authentication, and accounting.</p>
|
|
</dd>
|
|
<dt>MySQL</dt>
|
|
<dd>
|
|
<p>To act as a back-end database for the RADIUS.</p>
|
|
</dd>
|
|
<dt>OpenSwan</dt>
|
|
<dd>
|
|
<p>Provides the ipsec suite package.</p>
|
|
</dd>
|
|
</dl>
|
|
<h3 id="deployment-requirements-kernel">Kernel Support</h3>
|
|
<p>Debian stock kernel 2.4.27 and up are ipsec compatible although if
|
|
you think otherwise check for the kernel-patch-openswan package.</p>
|
|
<h2 id="deployment-installation">Installation</h2>
|
|
<h3 id="deployment-installation-l2tpns">L2TPns</h3>
|
|
<h4 id="deployment-installation-l2tpns-install">Installation</h4>
|
|
<blockquote>
|
|
<p>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.</p>
|
|
</blockquote>
|
|
<p>In a personal note - L2TPns is highly configurable for many cases,
|
|
and extremely reliable for production/commerical use.</p>
|
|
<dl>
|
|
<dt>Step 1:</dt>
|
|
<dd>
|
|
<p>Make sure you have libcli-1.8 development package installed:</p>
|
|
<pre><code># 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</code></pre>
|
|
</dd>
|
|
<dt>Step 2:</dt>
|
|
<dd>
|
|
<p>Download the source from <a
|
|
href="http://sourceforge.net/projects/l2tpns/">SourceForge</a>.</p>
|
|
</dd>
|
|
<dt>Step 3:</dt>
|
|
<dd>
|
|
<p>Build and install: <code>make && make install</code></p>
|
|
</dd>
|
|
</dl>
|
|
<div class="note">
|
|
<p>Alternately, you can skip these steps and simply
|
|
<code>apt-get install l2tpns</code>.</p>
|
|
</div>
|
|
<div class="note">
|
|
<p>On RPM-based distributions, you should be able to make packages from
|
|
the libcli and l2tpns source tarballs with
|
|
<code>rpmbuild -ta</code>.</p>
|
|
</div>
|
|
<p>Once compiliation is done you will have l2tpns in
|
|
<code>/usr/sbin/l2tpns</code>, and all configuration files can be found
|
|
in <code>/etc/l2tpns/</code>.</p>
|
|
<h4 id="deployment-installation-l2tpns-config">Configuration</h4>
|
|
<p>The only configuration that L2TPns takes is centralized in the
|
|
configuration file <code>/etc/l2tpns/startup-config</code>.</p>
|
|
<pre><code>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 "secret" # shared secret
|
|
set primary_dns 212.117.128.6 # Only 2 DNS server entries are allowed
|
|
set secondary_dns 212.117.129.3
|
|
set primary_radius 192.168.0.1 # Can have multiple radius server entries,
|
|
# but ony one radius secret
|
|
set primary_radius_port 1812
|
|
set radius_secret "radius_secret"
|
|
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 192.168.0.1 # 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"</code></pre>
|
|
<p>This is the trimmed down version of probably most of the common
|
|
configuration and even some extra options.</p>
|
|
<p>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.</p>
|
|
<p>Next, we need to setup the IP pool that L2TPns will provide to each
|
|
VPN client. The configuration file is located at
|
|
<code>/etc/l2tpns/ip_pool</code> and should look like the following:</p>
|
|
<pre><code>172.16.21.0/24</code></pre>
|
|
<div class="important">
|
|
<p>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...</p>
|
|
</div>
|
|
<p>Next up, creating the access-list for L2TPns.</p>
|
|
<p>Add a username and password into <code>/etc/l2tpns/users</code>:</p>
|
|
<pre><code>admin:12345</code></pre>
|
|
<p>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>).</p>
|
|
<p>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.</p>
|
|
<h3 id="deployment-installation-ipsec">IPsec</h3>
|
|
<h4 id="deployment-installation-ipsec-install">Installation</h4>
|
|
<p>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).</p>
|
|
<p>Getting IPsec installed is fairly easy with Debian:</p>
|
|
<pre><code># apt-get install openswan</code></pre>
|
|
<p>The OpenSWAN project provides packages for RPM-based
|
|
distributions.</p>
|
|
<p>Alternately, you may download the <a
|
|
href="http://www.openswan.org/code/">source</a> from the OpenSWAN
|
|
project:</p>
|
|
<pre><code># tar xvzf openswan-2.4.4.tar.gz
|
|
# cd openswan-2.4.4
|
|
# ./configure && make && make install</code></pre>
|
|
<h4 id="deployment-installation-ipsec-config">Configuration</h4>
|
|
<p>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.</p>
|
|
<p>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.</p>
|
|
<p>Configuration files are placed in <code>/etc/ipsec.d/</code>,
|
|
<code>/etc/ipsec.conf</code> and <code>/etc/ipsec.secrets</code>.</p>
|
|
<p>Let's start by choosing the remote client and it's PSK (Private
|
|
Shared Key) <code>/etc/ipsec.secrets</code>:</p>
|
|
<pre><code>hostname_or_ipaddress %any : PSK "mysecretkeyisverylong"</code></pre>
|
|
<p>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.</p>
|
|
<p>A better way to create a key is to utilize /dev/random for creating a
|
|
unique key.</p>
|
|
<pre><code># dd if=/dev/random count=16 bs=1 2>/dev/null | xxd -ps</code></pre>
|
|
<p>Next, let's prepare the configuration file
|
|
<code>/etc/ipsec.conf</code>:</p>
|
|
<pre><code>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</code></pre>
|
|
<p>In this file we have first defined version 2 which is a must, then
|
|
enabled NAT Traversal. To understand the importance of this feature
|
|
think of the following scenario: A remote user attempts to connect while
|
|
he's behind a router and therefore NATed. The router has to
|
|
de-encapsulate the packet, change things and then build it up again and
|
|
send it. IPsec doesn't like other people messing with it's packet.
|
|
That's why we solve this issue with NAT Traversal.</p>
|
|
<p>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
|
|
<code>/etc/ipsec.d/examples</code> for more explanation and other
|
|
variations of working with RSA keys, Certificates, host-to-host, and
|
|
more.</p>
|
|
<p>In summary:</p>
|
|
<ul>
|
|
<li><p>We've configured an almost complete IPsec VPN setup.</p></li>
|
|
<li><p>We've installed and configured a VPN server (L2TPns) and our
|
|
IPsec security suite.</p></li>
|
|
<li><p>To control both of them we use: <code>/etc/init.d/l2tpns</code>
|
|
and <code>/etc/init.d/racoon</code> (location of start-up scripts may
|
|
vary on non-Debian systems, or if you've installed from
|
|
source).</p></li>
|
|
</ul>
|
|
<h3 id="deployment-installation-freeradius">FreeRADIUS</h3>
|
|
<p>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.</p>
|
|
<h4 id="deployment-installation-freeradius-install">Installation</h4>
|
|
<blockquote>
|
|
<p>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.</p>
|
|
</blockquote>
|
|
<p>Installing on Debian:</p>
|
|
<pre><code># apt-get install freeradius freeradius-mysql</code></pre>
|
|
<p>From source: Download the latest freeradius package from <a
|
|
href="http://freeradius.org/getting.html">freeradius.org</a></p>
|
|
<pre><code># tar xvzf freeradius.tar.gz
|
|
# cd freeradius
|
|
# ./configure && make && make install</code></pre>
|
|
<h4 id="deployment-installation-freeradius-config">Configuration</h4>
|
|
<p>This will appear a bit complex but it isn't, it's just a lot of
|
|
configuration.</p>
|
|
<p>Following are the configurations you need to have in your
|
|
<code>/etc/freeradius/</code> files.</p>
|
|
<p>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.</p>
|
|
<p>We haven't yet configured MySQL, but it'll come afterwards, don't
|
|
worry.</p>
|
|
<p>Make the following changes to the file
|
|
<code>/etc/freeradius/sql.conf</code>:</p>
|
|
<pre><code>server = "192.168.0.1"
|
|
login = "radius"
|
|
password = "12345678"</code></pre>
|
|
<p>Add the following to the file
|
|
<code>/etc/freeradius/clients.conf</code>:</p>
|
|
<pre><code>client 192.168.0.1 {
|
|
secret = my_secret
|
|
shortname = localhost
|
|
nastype = other
|
|
}</code></pre>
|
|
<p>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.</p>
|
|
<p>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.</p>
|
|
<p>Uncomment the <code>sql</code> directive in the
|
|
<code>authorize</code>, <code>accounting</code>, and
|
|
<code>session</code> sections of
|
|
<code>/etc/freeradius/radiusd.conf</code>.</p>
|
|
<p>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:</p>
|
|
<pre><code># mysqladmin -u root password password_here</code></pre>
|
|
<p>Then add the following to <code>/root/.my.cnf</code>:</p>
|
|
<pre><code>[mysqladmin]
|
|
user = root
|
|
password = password_here</code></pre>
|
|
<p>Create the <code>radius</code> database, using the schema given in
|
|
<code>/usr/share/doc/freeradius/examples/db_mysql.sql.gz</code>.</p>
|
|
<div class="note">
|
|
<p>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:</p>
|
|
<pre><code>id int(10) NOT NULL auto_increment,</code></pre>
|
|
</div>
|
|
<pre><code># mysqladmin create radius
|
|
# mysql radius
|
|
mysql> source db_mysql.sql
|
|
mysql> GRANT ALL ON * TO 'radius'@'localhost' IDENTIFIED BY 'radius_password';</code></pre>
|
|
<p>All the configuration is now done. Let's add a user to our VPN
|
|
database.</p>
|
|
<pre><code># mysql radius
|
|
mysql> INSERT INTO radcheck values (0, "test", "User-Password", "==", "1234");</code></pre>
|
|
<p>We have now created a user in the database of username
|
|
<code>test</code> and password <code>1234</code>.</p>
|
|
<p>Testing the RADIUS setup is simple using the radtest utility provided
|
|
with it.</p>
|
|
<pre><code># radtest
|
|
Usage: radtest user passwd radius-server[:port] nas-port-number secret [ppphint] [nasname]
|
|
# radtest test 1234 192.168.0.1 1812 my_secret</code></pre>
|
|
<p>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.</p>
|
|
<h3 id="deployment-installation-firewall">Firewall Configuration</h3>
|
|
<p>We need to apply a few things to iptables configuration and kernel
|
|
networking.</p>
|
|
<p>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.</p>
|
|
<pre><code># 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</code></pre>
|
|
<p>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):</p>
|
|
<pre><code># 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</code></pre>
|
|
<h1 id="references">References</h1>
|
|
<p><a href="http://www.jacco2.dds.nl/networking/freeswan-l2tp.html">VPN
|
|
Reference</a></p>
|
|
<p><a href="https://code.ffdn.org/l2tpns/l2tpns/">L2TPns Project</a></p>
|
|
<p><a href="http://www.openswan.org">OpenSWAN Project</a></p>
|