The most simple case: host to host tunnel.

Openswan uses the notion of "left" and "right" when it is talking about the
two hosts. This is done because there is not really one "source" and one 
"destination". Both ends talk to each other. Also, Pluto automatically
determines whether it is "left" or "right" for each connection. This has the
added advantage that you can use the identical configuration at both hosts!

We assume here that "left" is local, and "right" is remote, a handy mnemonic.

The simplest way to authenticate two Openswan machines is with raw RSA keys.
This is the key that was stored in /etc/ipsec.secret. To view the public
key of your keypair, issue the command:

ipsec showhostkey --left

It will show you something like:

# RSA 2192 bits   bofh.xtdnet.nl   Thu Oct 17 12:32:33 2002
        leftrsasigkey=0sAQOkF1Ggd4iFfI2nQxJYbN9HGDhhIAKIXrG3+MCoAPX+z+fNI9j7rxxR9QhThIZZeOx+X9WB4hIa8/8xAnELmcRhkD8CxfznE4tCQ/Ws+9ibXUdD8Wee3JusSMrmLCuIScNUQuBtRe+l+nn16dzvw3/PGB67gid+AvGvJJJnxiFjibd/4ayVebJRj6Bu/FRexpXr3jEgg0TJwxu9y1xBR7i0tRYCdSQPKNClNrgmX7YZTp4bu6gizhil63/sR68eAqUz/DctDFDv7nrYsGDgGnfs03ncbY2m3lyPoiJyRJ34f4SILUBm+V44B5jsNDwFj7qx6wJ+dmXVkM7JGp5yLo93mfAhdKAcm5JkOpek2HszzO13

Now login to the other machine and type: ipsec showhostkey --right
It will show you its RSA public key, but written with "right" instead of
left.

Now all we need to do is combine this information into a single "conn"
section:

conn host-host-example
	left=192.168.1.1
        leftrsasigkey=0sAQOkF1Ggd4iFfI2nQxJYbN9HGDhhIAKIXrG3+MCoAPX+z+fNI9j7rxxR9QhThIZZeOx+X9WB4hIa8/8xAnELmcRhkD8CxfznE4tCQ/Ws+9ibXUdD8Wee3JusSMrmLCuIScNUQuBtRe+l+nn16dzvw3/PGB67gid+AvGvJJJnxiFjibd/4ayVebJRj6Bu/FRexpXr3jEgg0TJwxu9y1xBR7i0tRYCdSQPKNClNrgmX7YZTp4bu6gizhil63/sR68eAqUz/DctDFDv7nrYsGDgGnfs03ncbY2m3lyPoiJyRJ34f4SILUBm+V44B5jsNDwFj7qx6wJ+dmXVkM7JGp5yLo93mfAhdKAcm5JkOpek2HszzO13
	right=10.0.0.1
	rightrsasigkey=0sAQPKOS3m1rn/9GiPrKXKRFQ2U0189YX7god+N5U/Evq8FNZikhfdbJoR+6Ko0kFzTFss7TGpbDuM1NySTfG2X5gU9lKsbHsuDlmobPSHPN7px11GfuL073freT70TG4ytu1NZD46SNQpjp0zCUtt5cOhXQrZFFkmqvDhtro4jnb719eWxM3gfuTR8ttYYbN+4qgI6ZQbwYvjaXf335ZfXy0CCoHCQSJEVDWO+/kKaxPaVnkyLAEMdstfMZ03H0Yvnz4LdifNg8NE4AaQKl5yYkStKPYyKz2dxC10AmKcz9ue+9V4mxvd8dBYB8lwG6LXdGCIOhAsiA6s0nVt+4FScYDm965UnQ0UWqIVaUNIISltYD8F
	auto=start

The last line causes the connection to immediately start. We used IP addresses
in this example, but you can also use hostnames, such as "www.openswan.org".
This is considered slightly less secure though, unless you are using DNSSEC.

Some hardware routers that support IPsec often require using "PSK" mode. 
Instead of using RSA keypairs, the two parties agree on a secret beforehand,
the Pre-Shared Key. This is a string of characters used for the actual
encryption. This is not a very secure method, because people (or software!)
only use very short PSK's, such as "test". Also, PSK's are very unsuitable if
you have roaming users (often called roadwarriors), because they would all
have to share one PSK. One stolen laptop, and all the laptops are suddenly
vulnerable. Only use PSK when the remote host does not support anything else,
and you cannot convince the remote engineer or the management of their
insecure setup.

Our conn using PSK instead of RSA keys would look like:

conn host-host-example
	left=192.168.1.1
	right=10.0.0.1
	auto=start
	authby=secret

And in /etc/ipsec.secrets we add a line:

192.168.1.1 10.0.0.1: PSK "secret"




You should now be able to ping the remote host, and if you are sniffing
packets on a router in the middle, for instance using tcpdump, then you should
just see ESP packets instead of ICMP packets.
Another quick test to see if things work is to do a traceroute. When an IPsec
tunnel is up, the traceroute should only show one hop, since it is now a
"direct" connection to the other host.

If you encounter problems, see our FAQ section