This is Lynn's HOWTO: http://leaf.sourceforge.net/devel/guitarlynn/ipsec.txt
> -----Original Message----- > From: Chad Carr [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, July 09, 2002 10:49 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: [leaf-user] IPSEC Howto for LRP > > > On Tue, 9 Jul 2002 22:42:47 +1000 > "Matthew Pozzi" <[EMAIL PROTECTED]> wrote: > > > A while ago I saw a HOWTO on implementing IPSEC on LRP with > 4 different > > scenario's, may have been on Jacques' web site on sourceforge. > > > > Now I cannot find it for the life of me, there is plenty of other > > documentation around but it was the easiest read. I have > IPSEC up and > > going sort of, but I want to add road warrior support (as > it is called) > > as well. > > I think the doc you are talking about is this ipsec howto, courtesy of > Lynn Avants, which describes four different scenarios for > ipsec setup. I > cannot, however, find it anywhere on the site. Lynn? Have a > link for us > to the current version? > > Also, perhaps we should consider merging the documents, since > mine is a > little light on actual ipsec configuration, but has some > pretty good stuff > on certificates and Windows 2000 configuration. > > Or we can just steal each other's good parts and have two docs in > different places! > > Thanks, > Chad > > > > ############# 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 > > > > -- > -------------------------------------------------------------- > ---------- > Chad Carr > [EMAIL PROTECTED] > -------------------------------------------------------------- > ---------- > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Stuff, things, and much much more. > http://thinkgeek.com/sf > -------------------------------------------------------------- > ---------- > leaf-user mailing list: [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/leaf-user > SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Stuff, things, and much much more. http://thinkgeek.com/sf ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
