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