Update of /cvsroot/leaf/doc/guide/user-bering-uclibc
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv30540
Modified Files:
book.xml bucu-upnpd.xml bucu-zebra.xml
Added Files:
bucu-openswan.xml bucu-tinyca.xml
Log Message:
- small fix to zebra chapter (make multiple lines out of one in config example)
- added openswan chapter
- added tinyca chapter
- added images for new chapters
--- NEW FILE: bucu-tinyca.xml ---
<?xml version="1.0" encoding="UTF-8"?>
<chapter id="bucu-tinyca">
<chapterinfo>
<authorgroup>
<author>
<firstname>Arne</firstname>
<surname>Bernin</surname>
<affiliation>
<address><email>arneb at users.sourceforge.net</email></address>
</affiliation>
</author>
</authorgroup>
<revhistory>
<revision>
<revnumber>0.1</revnumber>
<date>2005-11-18</date>
<authorinitials>AB</authorinitials>
<revremark>Initial document</revremark>
</revision>
</revhistory>
</chapterinfo>
<title>Managing Certs with tinyca</title>
<section>
<title>Introduction</title>
<para>Managing your certificates on your router is possible,
but might be not a good idea regarding security. You also
might want to have a graphical frontend for easy creating
and managing your keys and certs. In this chapter you will
find information on how to do this all with <ulink
url="http://tinyca.sm-zone.net/"; >tinyca.</ulink></para>
<para>Tinyca is a GTK based Frontend for creating and maintaining
certificates with openssl. It is written in perl, to be able
to use it, you need a Unix Machine. If you don't have one,
download yourself a Linux Live CD (e.g. Knoppix) and use a
USB Stick to save your certs and keys.</para>
<para>This Documentation assumes that you already have a copy
of tinyca installed. If your distribution does not contain
a version of tinyca, get it from the <ulink
url="http://tinyca.sm-zone.net/"; >tinyca homepage.</ulink></para>
</section>
<section>
<title>Getting started</title>
<para>After starting tinyca you should get a screen like this:
<graphic align="center" fileref="images/tinyca1.png" ></graphic></para>
<para>We now start creating a new CA for ourself</para>
<para>Press the <emphasis>New CA</emphasis> button and enter
the needed information (an example follows), please note
that choosing a key length of 2048 should be enough.
<graphic align="center" fileref="images/tinyca2.png" ></graphic></para>
<para>After that you will be presented a window showing the possible
CA options. You should not need to change anything.
<graphic align="center" fileref="images/tinyca3.png" ></graphic></para>
<para>When the program has finished creating the CA, the main window
will look like this. You are now ready to create the needed certificates.
<graphic align="center" fileref="images/tinyca4.png" ></graphic></para>
</section>
<section>
<title>Create a Certificate</title>
<para>change to the certificates View in the main window.
<graphic align="center" fileref="images/tinyca5.png" ></graphic></para>
<para>Start creation by pressing the <emphasis>New</emphasis> button,
a new window will open. The screens hot should give you an example.
<graphic align="center" fileref="images/tinyca6.png" ></graphic></para>
<para>After the certificate request has been created, you need to sign
it with the CA certificate. Please note that the Valid for (Days) value
means that after this period of time you are not able to use it anymore.
If you don't plan to change your certs often, 365 days is rather short,
you better choose 730 or 1095 (which will be 3 years). Not adding
the email Address to the Subject might prevent you from running into
trouble with some software that has problem with the @ in the email
address. It is not needed, anyway.
<graphic align="center" fileref="images/tinyca7.png" ></graphic></para>
<para>After creating your cert, the main window looks like this:
<graphic align="center" fileref="images/tinyca8.png" ></graphic></para>
<para>Create as much certificates as you need, for a 2 host VPN you normally
need 2.</para>
</section>
<section>
<title>Exporting everything</title>
<para>To be able to use the certs for open vpn or openswan, you need to
export them in the correct format. This is normally PEM. Now choose
the certificate you want to export and press <emphasis>Export</emphasis>.
You will get a window asking for some options:
<graphic align="center" fileref="images/tinyca9.png" ></graphic></para>
<para>After you exported all required certs, change to the key view of
the main window.
<graphic align="center" fileref="images/tinyca10.png" ></graphic></para>
<para>Choose the key, press <emphasis>Export</emphasis> and you will get
a similar window as before. With one difference, you will be asked
if you want to export the key with or without a passphrase. Choose
no, so you will export it with a passphrase securing the private key.
<graphic align="center" fileref="images/tinyca11.png" ></graphic></para>
<para>After exporting all your keys, go to the CA view of the main window
and choose <emphasis>Export Ca</emphasis> which will get you another
export window. Choose PEM Format, too.
<graphic align="center" fileref="images/tinyca12.png" ></graphic></para>
<para>The Last thing to export is the CRL (Certificate revocation list),
to do this, choose <emphasis>Export CRL</emphasis> from the CA view.
You might set the value of how long this list is valid to a value
greater than 30 days. If this matters at all changes with the software
you want to use this cert with. You can , for example, configure openswan
to reject connections when the crl is not up to date. Choosing a value
of 90 days means that you have to export a new crl in the next 90 days
regardless whether you revoke a cert or not...
<graphic align="center" fileref="images/tinyca13.png" ></graphic></para>
</section>
</chapter>
--- NEW FILE: bucu-openswan.xml ---
<?xml version="1.0" encoding="UTF-8"?>
<chapter id="bucu-openswan">
<chapterinfo>
<authorgroup>
<author>
<firstname>Arne</firstname>
<surname>Bernin</surname>
<affiliation>
<address><email>arneb at users.sourceforge.net</email></address>
</affiliation>
</author>
</authorgroup>
<revhistory>
<revision>
<revnumber>0.1</revnumber>
<date>2005-11-19</date>
<authorinitials>AB</authorinitials>
<revremark>Initial document</revremark>
</revision>
</revhistory>
</chapterinfo>
<title>Configuring openswan(ipsec)</title>
<section>
<title>Introduction</title>
<section>
<title>Objectives</title>
<para>This chapter describes how to configure your LEAF system(s) to
build Virtual Private Networks (VPN) with <ulink
url="http://www.openswan.org";>Openswan</ulink>.</para>
</section>
<section>
<title>Overview of the setup described here</title>
<para>The setup described here assumes you are using openswan 2.4.x with
KLIPS (virtual interface support) Furthermore the setup used for this
chapter is based on LEAF systems connected to the internet via
static IP's. If you don't have a fixed ip, use the <filename>ezipupd.lrp
</filename> package and a dynamic DNS service like <ulink
url="www.dyndns.org">www.dyndns.org</ulink>.</para>
<para>In the following sections we describe a setup for
connecting subnets behind 2 LEAF systems. For the example, these
systems are called west and east, and both have a DNS name like
west.dyndns.org and east.dyndns.org. Please remember that
these names are only examples, use real ones instead!</para>
<para><inlinegraphic fileref="images/ipsec1.png"
format="png"></inlinegraphic>Example Setup</para>
</section>
<section>
<title>About openswan</title>
<para>Openswan implements the IPSec Internet Standard for Linux. It is
not the only solution but it is based on the oldest implementation
of IPSec for Linux called FreeSwan. The FreeSwan project ended some
years ago and their code base was used to create openswan. The feature
list includes X.509 Certificates, support for nat-t and aggressive mode.
It might be a good idea to take a look at the <ulink
url="www.openswan.org">
openswan Homepage</ulink> for a brief description of the features of
this software.</para>
</section>
</section>
<section>
<title>Loading the packages</title>
<para>Edit the <filename>leaf.cfg</filename> (Bering-uClibc-2.2.0 onwards)
file and add <filename>openswan.lrp, libpthread.lrp</filename> and
<filename>mawk.lrp</filename>
to the list of packages to be loaded at boot. Check the Bering-uClibc
<ulink
url="http://leaf.sourceforge.net/doc/guide/buci-install.html";>Installation
Guide</ulink> to learn how to do that.</para>
</section>
<section>
<title>Loading the modules</title>
<para>You need to load the tun module <filename>ipsec.o</filename> to have a
virtual tunnel interface and kernel support for ipsec.</para>
<para>To accomplish this, you need the appropriate modules tarball for
your LEAF Bering-uClibc. It's usually available for download in our FRS,
older versions are available in our cvs repository.</para>
<para>Unpack the modules tarball and copy
<filename>2.4.32/kernel/net/ipsec/ipsec.o</filename> to
<filename>/lib/modules</filename> on your router.</para>
<para>You don't need to put it in <filename>/etc/modules</filename>
as the ipsec init script loads and unloads the module on demand.</para>
<para>Save modules.lrp</para>
</section>
<section>
<title>Generating keys</title>
<para>To start with you will need to generate the necessary certificates,
keys and a crl file. The easiest way to do this is to use a frontend
like tinyca.</para>
<para>For this example we would need the following files (remember that
our systems are called west and east):</para>
<itemizedlist>
<listitem>
<para><filename>west-cert.pem</filename></para>
</listitem>
<listitem>
<para><filename>east-cert.pem</filename></para>
</listitem>
<listitem>
<para><filename>testca-cert.pem</filename></para>
</listitem>
<listitem>
<para><filename>west-key.pem</filename></para>
</listitem>
<listitem>
<para><filename>east-key.pem</filename></para>
</listitem>
<listitem>
<para><filename>crl.pem</filename></para>
</listitem>
</itemizedlist>
<para>The first two files contain the public keys for the leaf systems.
copy them to <filename>/etc/ipsec.d/certs/</filename> on both machines.
<filename>testca-cert.pem</filename> is the public key of the CA. This
file goes onto both machines into
<filename>/etc/ipsec.d/cacerts/</filename>.
<filename>crl.pem</filename> is the certificate revoke list for the CA,
which contains a list of disabled certificates. It is normally empty,
you
would add a cert to this list in case it is stolen, or otherwise
compromised.
The key files need only to be present on the router they belong to, so
<filename>west-key.pem</filename>would only go to
<filename>/etc/ipsec.d/private/
</filename> on router west.</para>
<para> These keys are sensitive information, you should
<emphasis role="bold">NOT</emphasis> put them all on all machines as
breaking
into this one would compromise them all!</para>
</section>
<section>
<title>Configuration</title>
<section>
<title>ipsec.secrets</title>
<para>Edit /etc/ipsec.secrets.</para>
<para>Change it to look like this (of course use the real password for
this key and not "password".
<programlisting>
# This file holds shared secrets or RSA private keys for inter-Pluto
# authentication. See ipsec_pluto(8) manpage, and HTML documentation.
# RSA private key for this host, authenticating it to any other host
# which knows the public part. Suitable public keys, for ipsec.conf, DNS,
# or configuration of other implementations, can be extracted conveniently
# with "ipsec showhostkey".
: west-key.pem "password"
# do not change the indenting of that "}"</programlisting></para>
</section>
<section>
<title>ipsec.conf</title>
<para><filename>/etc/ipsec.conf</filename> is the main configuration
file for openswan ipsec. For our example, it would look like this
for router west:</para>
<para><programlisting># /etc/ipsec.conf - Openswan IPSec configuration
file
# RCSID $Id: bucu-openswan.xml,v 1.1 2005/11/19 11:11:37 arneb Exp $
# This file: /usr/share/doc/openswan/ipsec.conf-sample
#
# Manual: ipsec.conf.5
version 2.0 # conforms to second version of ipsec.conf specification
# basic configuration
config setup
# plutodebug / klipsdebug = "all", "none" or a combation from below:
# "raw crypt parsing emitting control klips pfkey natt x509 private"
# eg:
# plutodebug="control parsing"
#
# Only enable klipsdebug=all if you are a developer
#
# NAT-TRAVERSAL support, see README.NAT-Traversal
# nat_traversal=yes
# virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%4:172.16.0.0/12
interfaces=%defaultroute
# Add connections here
# sample VPN connection
conn sample
# Left security gateway, subnet behind it, nexthop toward right.
left=%defaultroute
leftsubnet=192.168.1.0/24
leftcert=west-cert.pem
# Right security gateway, subnet behind it, nexthop toward left.
right=east.dyndns.org
rightsubnet=192.168.2.0/24
rightcert=east-cert.pem
# To authorize this connection, but not actually start it,
# at startup, uncomment this.
auto=start
#Disable Opportunistic Encryption
include /etc/ipsec.d/examples/no_oe.conf</programlisting></para>
<para>The %defaultroute entry in interfaces and as left
causes openswan to get the corresponding entries by looking
at which interface the default route of the system is on.
This is normally ok for dynamic connections (DSL, Cable, DHCP).
If you have a static IP and are connected to a router via eth1
the interfaces and left entries might look like this (172.16.0.1
is the IP of this router, 172.16.0.2 the IP of router west.
Please note that in this case the leftnexthop entry is mandatory!.
</para>
<para><programlisting> interfaces="ipsec0=eth1"
left=172.16.0.2
leftnexthop=172.16.0.1</programlisting></para>
<para>For router east, you take the same file, put it onto that
machine and exchange the left and right values, to look like:</para>
<para><programlisting># /etc/ipsec.conf - Openswan IPSec configuration
file
# RCSID $Id: bucu-openswan.xml,v 1.1 2005/11/19 11:11:37 arneb Exp $
# This file: /usr/share/doc/openswan/ipsec.conf-sample
#
# Manual: ipsec.conf.5
version 2.0 # conforms to second version of ipsec.conf specification
# basic configuration
config setup
# plutodebug / klipsdebug = "all", "none" or a combation from below:
# "raw crypt parsing emitting control klips pfkey natt x509 private"
# eg:
# plutodebug="control parsing"
#
# Only enable klipsdebug=all if you are a developer
#
# NAT-TRAVERSAL support, see README.NAT-Traversal
# nat_traversal=yes
# virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%4:172.16.0.0/12
interfaces=%defaultroute
# Add connections here
# sample VPN connection
conn sample
# Left security gateway, subnet behind it, nexthop toward right.
left=west.dyndns.org
leftsubnet=192.168.1.0/24
leftcert=west-cert.pem
# Right security gateway, subnet behind it, nexthop toward left.
right=%defaultroute
rightsubnet=192.168.2.0/24
rightcert=east-cert.pem
# To authorize this connection, but not actually start it,
# at startup, uncomment this.
auto=start
#Disable Opportunistic Encryption
include /etc/ipsec.d/examples/no_oe.conf</programlisting></para>
<para>You do not need to be consistent in what you call left and right
at both machines. But it makes things a lot easier if you do
keep that naming.</para>
<section>
<title>Configure shorewall</title>
<para>Add a new zone to /etc/shorewall/zones:</para>
<para><screen>vpn VPN Remote Subnet</screen></para>
<para>Add the ipsec interface to /etc/shorewall/interfaces:</para>
<para><screen>vpn ipsec+</screen></para>
<para>Note that we added a wildcard ("+") to the tun interface so the
vpn zone applies to all tun interfaces - important if you want to
support more than one IPSec enabled interface.</para>
<para>You can either open the traffic between the vpn zone and the local
net completely with adding</para>
<para><screen>loc vpn ACCEPT
vpn loc ACCEPT</screen></para>
<para>to /etc/shorewall/policy - or just add the ports you want to open
in /etc/shorewall/rules.</para>
<para>As last step add your vpn to the shorewall tunnel definitions
(/etc/shorewall/tunnels)</para>
<para><screen>ipsec net 0.0.0.0/0</screen></para>
<para>Note: The gateway is defined as "0.0.0.0/0" to
support remote hosts with dynamic ip addresses.</para>
</section>
</section>
<section>
<title>Starting Openswan</title>
<section>
<title>Manual</title>
<para>To test the server configuration you can manually start
Openswan with the command</para>
<para><command># /etc/init.d/ipsec start</command></para>
</section>
<section>
<title>Automatic</title>
<para>After a (re)boot the <filename>/etc/init.d/ipsec</filename>
script starts all tunnels that have a definition file in
<filename>/etc/ipsec.conf</filename> and are marked with a
<programlisting>auto=start</programlisting> in the definition
of the connection.</para>
</section>
<section>
<title>Checking</title>
<para>Check <filename>/var/log/daemon.log</filename> and <filename>
/var/log/auth.log</filename> for the status of your
ipsec tunnels. You can also use <command>ipsec auto
--status</command></para>
</section>
</section>
</section>
<section>
<title>Links</title>
<section>
<title>Openswan links</title>
<para><ulink url="http://openswan.org";>Openswan main page</ulink></para>
</section>
</section>
</chapter>
Index: bucu-upnpd.xml
===================================================================
RCS file: /cvsroot/leaf/doc/guide/user-bering-uclibc/bucu-upnpd.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -C2 -d -r1.3 -r1.4
*** bucu-upnpd.xml 4 Aug 2005 11:25:47 -0000 1.3
--- bucu-upnpd.xml 19 Nov 2005 11:11:37 -0000 1.4
***************
*** 206,210 ****
Bering-uClibc kernel modules distribution. Add it to
<filename>/lib/modules</filename> and make sure it is loaded in
! <filename><filename>/etc/modules</filename></filename> at system startup.
If you see an error message when Shorewall runs trying to add an iptables
rule with the <code>--cmd-owner</code> option,
--- 206,210 ----
Bering-uClibc kernel modules distribution. Add it to
<filename>/lib/modules</filename> and make sure it is loaded in
! <filename>/etc/modules</filename> at system startup.
If you see an error message when Shorewall runs trying to add an iptables
rule with the <code>--cmd-owner</code> option,
Index: book.xml
===================================================================
RCS file: /cvsroot/leaf/doc/guide/user-bering-uclibc/book.xml,v
retrieving revision 1.23
retrieving revision 1.24
diff -C2 -d -r1.23 -r1.24
*** book.xml 8 Nov 2005 09:23:38 -0000 1.23
--- book.xml 19 Nov 2005 11:11:36 -0000 1.24
***************
*** 8,12 ****
<!ENTITY freenet6 SYSTEM "bucu-freenet6.xml">
<!ENTITY zebra SYSTEM "bucu-zebra.xml">
! <!ENTITY openvpn SYSTEM "bucu-openvpn.xml">
<!ENTITY rrdtool SYSTEM "bucu-rrdtool.xml">
<!ENTITY keepalived SYSTEM "bucu-keepalived.xml">
--- 8,14 ----
<!ENTITY freenet6 SYSTEM "bucu-freenet6.xml">
<!ENTITY zebra SYSTEM "bucu-zebra.xml">
! <!ENTITY openvpn SYSTEM "bucu-openvpn.xml">
! <!ENTITY openswan SYSTEM "bucu-openswan.xml">
! <!ENTITY tinyca SYSTEM "bucu-tinyca.xml">
<!ENTITY rrdtool SYSTEM "bucu-rrdtool.xml">
<!ENTITY keepalived SYSTEM "bucu-keepalived.xml">
***************
*** 22,26 ****
--- 24,30 ----
&ipv6;
&freenet6;
+ &tinyca;
&openvpn;
+ &openswan;
&zebra;
&rrdtool;
Index: bucu-zebra.xml
===================================================================
RCS file: /cvsroot/leaf/doc/guide/user-bering-uclibc/bucu-zebra.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -d -r1.2 -r1.3
*** bucu-zebra.xml 18 Jan 2004 17:14:25 -0000 1.2
--- bucu-zebra.xml 19 Nov 2005 11:11:37 -0000 1.3
***************
*** 12,15 ****
--- 12,24 ----
</affiliation>
</author>
+ <author>
+ <firstname>Arne</firstname>
+
+ <surname>Bernin</surname>
+
+ <affiliation>
+ <address><email>arneb at users.sf.net</email></address>
+ </affiliation>
+ </author>
</authorgroup>
***************
*** 23,26 ****
--- 32,44 ----
<revremark>Initial version</revremark>
+ </revision>
+ <revision>
+ <revnumber>0.2</revnumber>
+
+ <date>2005-11-19</date>
+
+ <authorinitials>ab</authorinitials>
+
+ <revremark>make bgpd.conf more readable</revremark>
</revision>
</revhistory>
***************
*** 82,87 ****
following lines :</para>
! <para>router bgp ASN bgp router-id ROUTERID network 192.168.A.B/M network
! 192.168.C.D/N neighbor 192.168.P.Q remote-as REMOTEASN</para>
<para>Where ASN is your Autonomous System Number (it will look like a
--- 100,109 ----
following lines :</para>
! <para><programlisting>router bgp ASN
! bgp router-id ROUTERID
! network 192.168.A.B/M
! network 192.168.C.D/N
! neighbor 192.168.P.Q
! remote-as REMOTEASN</programlisting></para>
<para>Where ASN is your Autonomous System Number (it will look like a
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
leaf-cvs-commits mailing list
leaf-cvs-commits@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-cvs-commits
