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