I am posting a first draft of a "Basic IPSec HowTo" for consideration
and advice. It should be compatible with any IPSec-enabled LEAF
release. I would like to add some "Dia" .jpg's to it for clarity, if the
docmanager will allow it (???).
Thoughts?
############# start of HowTo ###########################
##### Basic IPSec VPN HowTo ######
By Lynn Avants
Virtual Private Networking (aka "VPN") is very popular for low-cost
connections
between remote offices, employees that need a connection to the company
LAN from home,
and mobile users that need to access a private LAN while on the run.
This document
covers several different connection types that are commonly used with a
LEAF
firewall or router running the IPSec VPN program. IPSec is known to
integrate with Windows
2000 VPN, Cisco VPN, UNIX IPSec, the SSH Sentinal, and many other
commercial VPN
solutions. Hopefully this will answer many questions regarding VPN
setup and use.
TABLE OF CONTENTS
1) General Information
2) Connection Types
3) Firewall Considerations
4) Firewall Pass-Through
5) Host to Host Connections
6) Host to Subnet Connections
7) Subnet to Subnet Connections
8) Gateway to Gateway Connections
9) /etc/ipsec.conf
10) /etc/ipsec.secrets
11) Bringing up the Connection
12) Troubleshooting
13) Links
1) GENERAL INFORMATION
IPSec is an OpenSource program for VPN connections that has been
packaged
for LEAF use. This document is based off of my custom Dachstein-IPSec
enabled
floppy image, but is totally compliant to the Dachstein CDROM release
and is
configurable to any LEAF or Linux system using IPSec.
I will describe using Preshared Secret Keys (PSK) and RSA Key
authentication
within the scope of this document. 509 certificates may be used with
IPSec,
but additional licensing may be needed to create the certificates.
Certificate
type authentication is described thoroughly in other documents, and
explained
better by someone that has more experience than myself.
A "Pre-shared Secret Key" (PSK) is a secret alpha-numeric key that is
created by the
person setting up the IPSec configuration. This "secret password" is
the exactly the
same on all the computers authenticating the connection and
case-sensitive.
A "RSA Key" is an authentication method that uses a program to generate
a set of
authentication keys. This program is built into IPSec. Each computer
should generate
its own set of keys. The private key is kept secret by the computer
that generated it,
and the public key is copied to the remote computer(s) for use to
authenticate the connection.
A basic way of describing this is accessing a safe-deposit box at a
post office or bank. The
post office or bank keeps one key and the person renting the box keeps
a different key. To
gain access to the box, both keys must be used to open the door. RSA is
an electronic
equivalent of this. This authentication method is also used with other
programs,
such as "ssh" and "cvs". This is the suggested method for
authentication.
There are several different encryption alogarthims that can be used for
closed source
versions of IPSec, however the strongest one available for the open
source version of
IPSec at this time is the "3DES" alogarthim. This is the only one that
I suggest using.
Required packages for connections (other than Firewall-Pass-Through):
an IPSec-patched kernel for your distribution/version
ipsec.lrp
ifconfig.lrp
mawk.lrp
ipsec509.lrp (if using 509 authentication certificates instead of PSK
or RSA Keys)
2) CONNECTION TYPES
Firewall-pass-through: This connection is for an individual computer
behind a
firewall to make a connection to a remote computer or network. The
firewall that is protecting the individual computer does not
participate in the
VPN connection or authenticate it, but rather allows the connection
"through"
the firewall. A home connection that is protected to an company network
is an
example of this type of connection.
Host to Subnet: This connection is for a single computer to connect to
a remote
network. This is typically known as the "Road Warrior" connection and
the remote
computer is not behind a firewall. The ip address that the remote
computer will
be using is normally not known for configuration.
Subnet to Subnet: This connection is for remote offices to connect
their respective
private networks to each other. The IPSec Gateway boxes do NOT
participate in the
actual network tunnel, but rather only setup the connection and forward
the traffic
between the locations.
Gateway to Gateway: This connection is very similar to the
Subnet-to-Subnet connection
but differs in that the IPSec Gateway boxes themselves participate in
the tunneled
connection. The Gateways may be used for WINS and/or DNS services
through the tunnel.
3) FIREWALL CONSIDERATIONS
IPSec uses protocols 50 and 51 and port 500 for communication. You will
need to
allow these protocols and ports through any firewall you are using. If
you sepecify
"leftfirewall=yes" or "rightfirewall=yes" in your "/etc/ipsec.conf",
the protocols
50 and 51 are allowed through the firewall by the IPSec program and you
will not need
to set these protocols manually for the specified firewall(s). IPSec
will not open
port 500.... you will need to do this yourself. My IPSec floppy image
already has
these modifications to the firewall.
4) FIREWALL PASS-THROUGH
This type of connection is very often the most confusing. This is used
where a
remote computer behind a firewall connects to a remote network or
computer. The
firewall is configured to allow the connection, but does not
participate or authenticate.
To setup this type of connection:
1) open the protocols 50 and 51 on your firewall
2) open port 500 on your firewall
3) load the ip_masq_ipsec.o module and add it to /etc/modules
4) use the "ipfwd" utility to forward the port to the internal
network. Ipmasq will not forward the necessary protocol.
NOTE: Do NOT use an IPSec-patched kernel. This kernel will not work
with the helper
module you will use. Use a non-IPSec-patched kernel instead. All
Dachstein kernels
can be found at http://leaf.sourceforge.net/devel/cstein/files/kernels/
. The IPSec-patched
kernels will be labeled, use one that does not have "ipsec" in the
filename.
5) HOST TO HOST CONNECTIONS
This type of connection is use to connect two individual computers
together across a
wide area network like the internet. This terminology/connection is
generally not used
with LEAF since the private network(s) are not connected by definition.
More commonly
when a connection is described as this, both remote computers will use
the Firewall-pass-through
method on both ends of the connection.
If you are intending for both the LEAF IPSec gateway machines and the
private networks
behind the IPSec gateways to participate in the VPN connection, please
see the "Gateway-to-Gateway"
section for instructions.
6) HOST TO SUBNET CONNECTIONS (Road Warrior Configuration)
This type of connection is commonly known as the "Road Warrior"
configuration. It is used
where you have one or more remote users that will need to connect to a
private network.
In this connection, the remote computer(s) will not have a subnet
declared. Only the
remote computer will connect, because there is not a network behind it.
If this
remote computer will be connecting via DHCP (dial-up or any other
connection) and you
will not know its ip address, use the IPSec variable "%any" instead of
the ip address of the
remote computer. The "%any" variable will allow any computer that can
successfully authenticate
to connect.
7) SUBNET TO SUBNET CONNECTIONS
This type of connection is used to connect private networks to each
other that are separated
by a Wide Area Network, such as the Internet. This is commonly used to
connect remote office
LAN's to each other.
Each private network has its own IPSec Gateway machine which
establishes the VPN connection and
routes the information through the VPN tunnel. The Gateway machine may
or may not use firewalling
capabilities. It should be noted that using the Gateway machine for a
firewall is not suggested
for companies and is not as secure as having a Gateway machine behind a
separate firewall. The
Gateway machine at each end does not participate in the file-sharing
through the established tunnel,
but as the name implies, simply acts as the Gateway for the connection.
You cannot use the Gateway
machine for WINS or DNS name resolution services "across" the tunnel,
but you can use it for these
services on the private network it is physically attached to. The
suggested method for name resolution
using this common connection type is to have the nameserver on a
machine other than the Gateway in the
network.
Each connected private network must use a different subnet, such as
192.168.0.0/24, 192.168.1.0/24,
192.168.2.0/24, etc.... IPSec will not work if the remote networks use
the same subnet.
8) GATEWAY TO GATEWAY CONNECTIONS
This type of connection is very similar to the Subnet-To-Subnet
connection. It can be used to
connect remote networks, but the network subnets are NOT declared and
the Gateways must
participate in the tunnel connection. You will have to manually setup
the subnet routes since
they are not declared in /etc/ipsec.conf, however one or more of the
Gateways can be used
for name resolution such as WINS and DNS across the VPN tunnel.
This is not a commonly used connection type and I suggest using the
Subnet-To-Subnet connection
(with a nameserver on a separate LAN machine) instead of the
Gateway-To-Gateway connection.
9) /etc/ipsec.conf
The file /etc/ipsec.conf file is where you configure your IPSec. This
particular sample uses
a Preshared Secret Key (PSK) for authentication. The RSA Key with x509
certificate authentication
options are commented out with a "#" character at the beginning of the
appropriate lines.
In the configuration files, use the "%any" variable to allow any ip
address that you will not know for
sure (like a roadwarrior or Gateway machine using an external DHCP
connection). This will allow "any"
ip address to connect that can successfully authenticate.
You can have IPSec generate a Pre-shared Secret Key for you with the
"ipsec ranbits --quick --bytes 50" command.
You can have IPSec generate a RSA Key with the command "ipsec
rsasigkey" Then you will need to extract
the public key and copy it to the remote Gateway machine. The "ipsec
showhostkey" command will show the
machine's "public" RSA key. Remember to backup the IPSec package after
doing this, or the RSA keys will
be lost if you reboot the computer.
----------------------
SAMPLE ipsec.conf file
----------------------
# basic configuration
config setup
# THIS SETTING MUST BE CORRECT or almost nothing will work;
# %defaultroute is okay for most simple cases.
interfaces=%defaultroute
# Debug-logging controls: "none" for (almost) none, "all" for
lots.
klipsdebug=none
plutodebug=none
# Use auto= parameters in conn descriptions to control startup
actions.
plutoload=%search
plutostart=%search
# Close down old connection when new one using same ID shows up.
uniqueids=yes
# defaults for subsequent connection descriptions
conn %default
keyingtries=1
disablearrivalcheck=no
#authby=rsa
authby=secret
keylife=2h
conn roadwarrior
left=%any
leftsubnet=
leftnexthop=
#leftrsasigkey={rsa-key}
#leftrsasigkey=%cert
right=192.168.1.254
rightsubnet=192.168.1.0/24
rightnexthop=192.168.1.1
pfs=yes
auto=add
#rightrsasigkey={rsa-key}
#rightrsasigkey=%cert
conn subnet-to-subnet
[EMAIL PROTECTED]
left={the remote Gateway machine's external ip address}
leftsubnet={subnet address of the remote network}
leftnexthop={default gateway for the remote Gateway machine}
#leftrsasigkey={rsa-key}
#leftrsasigkey=%cert
[EMAIL PROTECTED]
right={local Gateway machine's external ip address}
rightsubnet=192.168.1.0/24 {the local subnet address}
rightnexthop={the default gateway for the local Gateway
machines external ip address}
pfs=yes
auto=add
#rightrsasigkey={rsa-key}
#rightrsasigkey=%cert
10) /etc/ipsec.secrets
The /etc/ipsec.secrets file contains the Pre-shared Secret Keys, RSA
Keys, and other authentication
information for an IPSec connection. In the sample below, the first
line is for a Pre-shared Secret Key
and the second is for a RSA key. You should use one method or the
other, but not both. IPSec is
very picky about white-space, so make sure you have not added any extra
spaces or tabs in editing this file.
RSA users should also not that there are no line-breaks (return key)
within the key itself; the RSA key itself
should be on one continuous line. You can list the RSA key in the
"right/leftrsasigkey=0x...." line(s) of
/etc/ipsec.conf; do not list the key in "ipsec.secrets" if it is listed
in "ipsec.conf".
-------------------------
SAMPLE ipsec.secrets file
-------------------------
# Use this for a "preshared secret key"
{the ip address of your external interface on the local Gateway
machine} %any: PSK "{your secret shared key}"
# Use this for a "RSA" Key.
# If the RSA key is listed in /etc/ipsec.conf, you do not need to list
this in this file.
: rsa {
<rsa-key-stuff>
}
11) BRINGING UP THE CONNECTION
After you have configured your /etc/ipsec.conf and /etc/ipsec.secrets
files as needed, you will
need to reboot the machine to update the entire running IPSec
configuration. A certain portion
of the running configuration is setup during the INIT boot process and
will not be reconfigured
through the "svi ipsec restart" command.
After the reboot, there are several different options for starting the
IPSec connection; depending
on the particular configuration.
The connection initiation options in /etc/ipsec.conf are as follows:
auto=add # This starts ipsec, but does NOT initiate a connection,
it WAITS for initiation.
auto=start # This starts ipsec and initiates the connection.
With this in mind, you cannot have two machines attempt to initiate
(start) a connection, only one
machine can be configured this way per connection. With a
Host-To-Subnet (Road Warrior) type connection,
the Road Warrior would be the machine that would initiate the
connection. With a Subnet-To-Subnet
connection, normally NEITHER of the Gateway machines are set to
initiate the connection since both
of them are normally on 24/7. Instead, when the VPN tunnel is known to
be down, one of the machines is
manually used to initiate the connection with the command "ipsec auto
--up {connection-name}".
The connection names in the sample /etc/ipsec.conf used earlier would
be "roadwarrior" and "subnet-to-subnet".
12) TROUBLESHOOTING
The output of a few commands can be the best source of information if
your VPN connection does not work.
The results of: Tell you:
-----------------------------------------------------
"ipsec barf" Virtually everything about
what is happening and what has happened with ipsec.
"cat /var/log/auth.log" Authentication success and
failure messages.
"ipsec look", "route -n", and "ifconfig" Shows a connected tunnel
through interface "ipsecX".
"ipsec auto --status" Shows the status of the
connection.
Look for authentication failure or success with "ipsec barf" and/or the
/var/log/auth.log file. A failure
in these files usually indicate that port 500 and/or protocols 50 and
51 aren't making it through the
firewall or your authentication key is not setup properly. If the
authentication was successful, check
"ipsec look", "ifconfig", and/or "route -n". You should have an
interface "ipsec0" up with the external
interface's ip address and a route showing the remote subnet/host via
the local default gateway or your
ISP. Failure at this point would indicate improper ipsec.conf
configuration or port 500 not allowing
traffic. The contents of /var/log/messages will show denied packets at
the firewall .... check for any
denied packets at port 500.
If these commands do not help you locate the problem, monitoring the
firewall activity will be the
next source of information. Use the command "ipchains --zero" and note
the output that refers to port 500 and
protocols 50 and 51 ....or use a packet sniffer, while attempting to
initiate a VPN connection.
13) LINKS
######## LINKS TO BE ENTERED HERE ###########
############# end of HowTo ###########################
--
~Lynn Avants
aka Guitarlynn
guitarlynn at users.sourceforge.net
http://leaf.sourceforge.net
If linux isn't the answer, you've probably got the wrong question!
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
