IPSEC Guide
From Buici
With the 2.6.x Linux kernel, IPSEC is directly supported by the kernel maintainers. This guide does two things with IPSEC. It explains some of the details of IPSEC that will help you understand what's going on. This is important when solving your own problems. Second, it builds several solutions, explaining the changes as it goes.
- TODO
- Troubleshooting
- Further study: iptables
- Further study: more on access control
- Further study: IPv6
Contents |
Other Sources of Information
These notes derive from reading some online sources as well as my own experimentation. Many details of the IP protocols are not covered as they do not pertain to these implementations. Aside from searching the Internet for terms such as VPN and IPSEC, I recommend the following sites.
- http://www.kame.net, the source of the tools for configuring IPSEC as managing ISAKMP.
- http://www.ipsec-howto.org, a good place to look for more information.
- http://www.freeswan.org, another implementation of IPSEC which is usually used with 2.4.x Linux kernels.
- RFC1918 reserved network numbers
- RFC2451
- RFC2403
Introduction
Configuring IPSEC is not really as simple as reading a HOWTO guide and entering the right commands. There are details of IP routing, security, and access control that are important for the overall solution to be complete. In this guide, the aim is to help fill-in the details that are specific to IPSEC as these protocols define some concepts that may be new to network administrators.
Some of the material here may be too basic for some people. If the scripts and configuration files make perfect sense, you can probably skip the text without missing much. I recommend that you read the Kame Tools section anyway as there is some information there that isn't obvious from reading the man pages.
Using IPSEC as described herein is not analagous to Microsoft VPN solution, L2TP over IPSEC. Microsoft's solution is really for client to server connectivity. The VPN is authenticated at setup time using a Domain password. IPSEC as described herein uses the core IPSEC protocols to provide secure communication, but it doesn't authenticate the setup of the encryption tunnel. There is more on the ramifications of this setup in the section on Security Considerations.
There is one more thing to note. The term message used within is a synonym for packet.
The Basics
IPSEC is a suite of IP protocols that authenticated and encrypts traffic at the network layer. It was originally developed for the next version of the Internet Protocol, IPv6, and then revised to support IPv4 when it became apparent that the need for it exists and that IPv6 is still a few years from widespread deployment.
IPSEC consists of three elements, two of them change the way the packets are formed: AH and ESP. AH is an Authentication Header. The AH permits the receiver to verify that the data received is bona fide and from the intended sender. ESP stands for Encapsulated Security Payload. ESP packets are encypted such that only the intended receiver may view the data. AH and ESP may be used individually or together depending on the application. The third element is the Internet Key Exchange (IKE) protocol. IKE allows for encryption keys to be exchanged when initiating IPSEC communication channel.
For more details on the details of the IPSEC protocols, refer to the cited web sites as well as the IETF RFC's. Suffice here to understand that these protocols work by using modern cryptographic techniques to change the way that IP packets are conveyed across a network.
What came before IPSEC? Existing solutions for securing network communications come in two categories. There are the application layer protocols such as Secure Socket Layer (SSL) and Secure Shell (SSH) that depend either on an application being modified to perform the encryption or on tunneling data on a secure channel created by the application. Application-level solutions never require operating system changes.
Second, there are the protocols like L2TP that depend on a special IP protocol, in this case Generalized Routing Encapsulation (GRE), to carry the data. These special IP protocols may require changes to the operating system.
Solutions exist. Why use IPSEC?
There are two answers to this question. The fundamental reason for securing inter-computer communication comes from the needs of application at hand. Most networks are operated without any encryption at all and with good reason. Few people need their web pages to be secret. However, a visitor who attaches a computer to the network may be able to snoop email and documents and passwords without being detected. Network traffic that travels the Internet is less susceptible to snooping, but there will always be cases of abuse when the potential gains are great enough. The introduction of wireless networks brings the newest and the quickly growing reasons for securing network traffic. The encryption provided by the wireless networking standards (802.11) has been shown to be inadequate...in two revisions. [Reference?]
There is a more compelling reasons to move to IPSEC. The most important one is that by using IPSEC, an enhancement to the standard IP protocol suite, all inter-host traffic can be protected. Applications need never be modified to implement authentication or encryption. As a standard, it means that all compliant networking devices will interoperate. Finally, ubiquitous deployment of IPSEC means that all network traffic can be encrypted as a matter of network policy, eliminating the chance of haphazard compliance.
Simply put, IPSEC is the correct way to solve the problems of authentication and encryption of network data.
More IPSEC Details
Some additional detail for IPSEC is necessary in order to illustrate how to use the tools to solve practical problems.
IPSEC defines a concept called a Security Association, SA, that identifies a secured conversation between exactly two computers, routers, or other network attached devices. While configuring for IPSEC, we will create entries for SA policy (SAP) and SA descriptors (SAD). Policy determines what network traffic can or must be IPSEC secured. Descriptors describe actively secured conversations. Network traffic for a given SA bear a common identifier called a Security Parameter Index, SPI.
Encryption relies on kept secrets. In some cases, these secrets are shared by manually delivering it to the communicating parties. This is called a pre-shared key and it is akin to giving each a code book ahead of time. As long as no one else discovers the code book, their telephone conversations will not be understood by eavesdroppers. Pre-shared keys rapidly become unmanageable as the number of machines increases.
IKE enables another method for trading secrets, public key cryptography using X.509 certificates. In this case, the communicators create two related keys. One is public and the other is kept private. Messages encrypted with one key may be decrypted with the other. The public key is freely distributed while the private key is held in confidence. Each party uses both public keys as well as their own private key to exchange a secret before securing communcation. In other words, they make-up a code book every time they start a conversation. The public and private keys allow them to share a code book while knowing that no one else can know their secret.
IKE also introduces the idea of identities. There are several ways that identities may be established. It can be by the IP address of the host requesting secure communication; it can be an arbitrary string such as an email address or host name; it can also be a Distinguished Name (DN) as is the case when public key certificates are used.
There are three kinds of algorithms used in IPSEC. Cryptographic hashes, also known as one-way hashes or message digests, accept a sequence of data and return a fixed size number that is unique for that sequence. The hash returns the same number given the same original sequence of data. Any change to the original sequence will cause the hash to return a different result. Hashes are used to authenticate a sequence of data. Some hash algorithms are MD5 and SHA1.
IPSEC also uses symmetric ciphers which take a sequence of data and a key and return another sequence of data. From this final sequence it is impossible (aka computationally very difficult) to guess the original without the key. However, given the same key the encrypted data, the original data may be recovered. Symmetric ciphers use a single key for encryption and decryption. Symmetric ciphers include DES, triple DES (3DES), Blowfish, and AES.
With X.509 certificates, IPSEC also uses public key cryptography. Public key ciphers are similar to symmetric key ciphers in that it is impossible to guess the original data from the encrypted sequence of data. Unlike symmetric ciphers, public key ciphers use one key for encryption and another for decryption. Public key algorithms include RSA and ElGamal [algorithm names].
Installation
Before configuring IPSEC, make sure that you're running a 2.6.x kernel and that the IPSEC features were either compiled in or loaded as modules.
This is a fragment from a kernel configurations script that puts the IPSEC protocol elements into modules. This will compile more than is required.
# # Networking options # CONFIG_NET_KEY=m CONFIG_INET_AH=m CONFIG_INET_ESP=m CONFIG_INET_IPCOMP=m # # Cryptographic options # CONFIG_CRYPTO=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_MD5=m CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_AES=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_DEFLATE=m
Once this kernel is running, load the required modules.
modprobe af_key md5 des deflate
...and the optional modules.
modprobe sha1 sha256 blowfish aes
For Debian systems, make sure that the necessary tools are installed by running apt-get. Note that ipsec-tools conflicts with freeswan. We install host to support hostname lookup in the configuration scripts. You may use either host, or bind9-host. Similarly, iproute is installed to help automate some of the scripts.
apt-get install ipsec-tools host iproute
KAME Tools
There is only one required tool for configuring the Linux 2.6.x kernel for IPSEC, setkey. A second application, racoon, implements the IKE protocol for exchanging keys. We'll start with a simple example and show how to use tools.
setkey manipulates the SA policies and descriptors. A couple of useful forms of the command are as follows.
Show the SA descriptors
setkey -D
Show the SA policies
setkey -DP
Erase (flush) the SA descriptors
setkey -F
Erase (flush) the SA policies
setkey -FP
Read directives from standard input
setkey -c
Read directives from a file
setkey -f sa_config
There are two directives that will be used, add and spdadd. The former adds SA descriptors and the later adds SA policy. There are a few of things to know about using these commands. As usual, refer to the man page for greater detail.
- When adding descriptors, the order of the source and destination addresses is not important. It is the SPI that identifies which entry goes with which packet. The scripts do change the order of these addresses as a matter of course.
- The addresses in these descriptors are the routable addresses used by the gateways.
- The address ranges used when adding policy entries are the addresses of the packets being protected by IPSEC. This will be addressed in more detail in one of the examples.
- The source and destination addresses used in tunneling policy entries are the routable addresses of the machines that execute the policy, the machines where the policy is defined.
racoon is a user-space daemon that negotiates key exchange and, to a lesser extent, the setup of IPSEC SAs. It communicates via UDP packets and port 500.
On Debian, the racoon configuration files are in /etc/racoon. The main configuration file is /etc/racoon/racoon.conf, pre-shared keys are stored in /etc/racoon/psk.txt, and X.509 certificates reside in /etc/cert. It is a good idea to make /etc/racoon/psk.txt unreadable by anyone except the superuser.
Racoon configurations have two primary clauses. The remote clause is used first. It matches the IP address of the remote gateway. It establishes the method for exchanging credentials and keys.
The sainfo clause describes the policy for communication. The addresses are for the communicating parties and may be private.
A Simple Example
George has two computers, Astro and Elroy. George is paranoid and wants to secure the data that passed between these machines. His network, 192.168.1.0/24, is private and inaccessible from the Internet. I know. He's paranoid.
192.168.1.0/24
+-------+ +-------+
| Astro |----------------| Elroy |
+-------+ +-------+
.11 .12
In George's network, the computers are connected by a hub, not shown, and are in the same logical network 192.168.1.0/24. In the first implementation, the machine will use pre-shared keys.
Generate 128 bit hmac-md5 key for AH--the last line is the key.
# dd if=/dev/random bs=8 count=2 | od -An -tx1 -w24 | sed -e "s/ //g" 2+0 records in 2+0 records out 16 bytes transferred in 0.000275 seconds (58200 bytes/sec) d4b2c1cdc95859e8eae92fb9652d526d
Generate 192 bit 3des-cbc key for ESP--the last line is the key.
# dd if=/dev/random bs=8 count=3 | od -An -tx1 -w24 | sed -e "s/ //g" 3+0 records in 3+0 records out 24 bytes transferred in 0.000325 seconds (73849 bytes/sec) cfa4a07ba20c81172df8e4793ee7ac3c4437914be3019974
#!/bin/sh # Point-to-point transport mode. # # Run this script on Astro with no switches. # Run this script on Elroy with the '-r' (right) switch. # IP addresses for communicating machines ip_left=192.168.1.11 ip_right=192.168.1.12 if [ "$1" = "-r" ] ;then ip=$ip_left ; ip_left=$ip_right ; ip_right=$ip; fi # Replace these keys with freshly generated random ones key_ah1=0x0123456789abcdef0123456789abcdef key_ah2=0x0123456789abcdef0123456789abcdef key_esp1=0x0123456789abcdef0123456789abcdef0123456789abcdef key_esp2=0x0123456789abcdef0123456789abcdef0123456789abcdef setkey -c <<EOF # Flush the descriptors and the policy flush; spdflush; # Descriptors add $ip_left $ip_right ah 0x1000 -A hmac-md5 $key_ah1; add $ip_right $ip_left ah 0x1001 -A hmac-md5 $key_ah2; add $ip_left $ip_right esp 0x1002 -E 3des-cbc $key_esp1; add $ip_right $ip_left esp 0x1003 -E 3des-cbc $key_esp2; # Policies spdadd $ip_left $ip_right any -P out ipsec esp/transport//require ah/transport//require; spdadd $ip_right $ip_left any -P in ipsec esp/transport//require ah/transport//require; EOF
George's Second Effort
George decides that he want to use tunneling mode instead of transport mode. There is no advantage for him--he's just bored. The configuration is similar.
#!/bin/sh # Point-to-point tunneling mode. # # Run this script on Astro with no switches. # Run this script on Elroy with the '-r' (right) switch. # IP addresses for communicating machines ip_left=192.168.1.11 ip_right=192.168.1.12 if [ "$1" = "-r" ] ;then ip=$ip_left ; ip_left=$ip_right ; ip_right=$ip; fi # Replace these keys with freshly generated random ones key_ah1=0x0123456789abcdef0123456789abcdef key_ah2=0x0123456789abcdef0123456789abcdef key_esp1=0x0123456789abcdef0123456789abcdef0123456789abcdef key_esp2=0x0123456789abcdef0123456789abcdef0123456789abcdef setkey -c <<EOF # Flush the descriptors and the policy flush; spdflush; # Descriptors add $ip_left $ip_right esp 0x1000 -m tunnel -E 3des-cbc $key_esp1 -A hmac-md5 $key_ah1; add $ip_right $ip_left esp 0x1001 -m tunnel -E 3des-cbc $key_esp2 -A hmac-md5 $key_ah2; # Policies spdadd $ip_left $ip_right any -P out ipsec esp/tunnel/$ip_left-$ip_right/require; spdadd $ip_right $ip_left any -P in ipsec esp/tunnel/$ip_right-$ip_left/require; EOF
Cogswell's Campaign
The word is out about George's success with IPSEC. His boss, Cogswell, wants to secure his company's network traffic between the warehouse and headquarters. The IT staff has shown George how the network is layed out. So, George shows them how to configure IPSEC.
At Cogswell's Cogs, the setup is more complicated than was George's home network. The HQ and warehouse each have a GNU/Linux machine that acts as a router. Internally, the HQ uses the network 172.16.10/24 and the warehouse uses the network 172.16.20/24. Each of the routers answers to address .1 on these networks as well as Internet routable addresses 10.10.10.10 and 10.20.20.20 respectively--these aren't valid Internet addresses, but assume they are for this example. The picture below shows how the pieces fit together.
10.10.10.10 10.20.20.20
+-------+ +--------------+
| GW-HQ |------Internet------| GW-Warehouse |
+-------+ +--------------+
172.16.10.1 | | 172.16.20.1
| |
------+------- ------+-------
/ \ / \
| 172.16.10/24 | | 172.16.20/24 |
| HQ | | Warehouse |
| Network | | Network |
\ / \ /
-------------- --------------
| |
172.16.10.7 | | 172.16.20.100
+----------+ +-----------+
| Cogswell | | Inventory |
+----------+ +-----------+
The gateways are configured to pass inter-network traffic through an encrypted tunnel over the Internet. The important change is in the policy that directs traffic for the two private networks (HQ and Warehouse) through the tunnel.
#!/bin/sh # Network-to-network tunneling mode. # # Run this script on GW-HQ with no switches. # Run this script on GW-Warehouse with the '-r' (right) switch. # IP addresses for communicating machines ip_left=10.10.10.10 net_left=172.16.10.0/24 ip_right=10.20.20.20 net_right=172.16.20.0/24 if [ "$1" = "-r" ] ;then ip=$ip_left ; ip_left=$ip_right ; ip_right=$ip; fi if [ "$1" = "-r" ] ;then net=$net_left ; net_left=$net_right ; net_right=$net; fi # Replace these keys with freshly generated random ones key_ah1=0x0123456789abcdef0123456789abcdef key_ah2=0x0123456789abcdef0123456789abcdef key_esp1=0x0123456789abcdef0123456789abcdef0123456789abcdef key_esp2=0x0123456789abcdef0123456789abcdef0123456789abcdef setkey -c <<EOF # Flush the descriptors and the policy flush; spdflush; # Descriptors add $ip_left $ip_right esp 0x1000 -m tunnel -E 3des-cbc $key_esp1 -A hmac-md5 $key_ah1; add $ip_right $ip_left esp 0x1001 -m tunnel -E 3des-cbc $key_esp2 -A hmac-md5 $key_ah2; # Policies spdadd $net_left $net_right any -P out ipsec esp/tunnel/$ip_left-$ip_right/require; spdadd $net_right $net_left any -P in ipsec esp/tunnel/$ip_right-$ip_left/require; EOF
What may not be obvious is how this network operates in practice. When Cogswell wants to talk to the Inventory computer, he sends a message to address 172.16.20.100. This message leaves his computer and goes to his gateway, 172.16.10.1. The IPSEC policy indicates that the 172.16.20/24 network is reached by sending the message through an encrypted tunnel to the GW-Warehouse computer at 10.20.20.20, so it is wrapped in an envelope and sent over the Internet. Once it arrives, GW-Warehouse removed the envelope and forwards the message to the Inventory computer.
George Works from Home
George finds an ISP willing to give him a static IP address, 10.30.30.30 (not a real, routable Internet address but is for this example). He assigns that address to his computer Astro and configures IPSEC so he can talk directly to the Email server at work.
10.30.30.30 10.10.10.10
+-------+ +-------+
| Astro |------Internet------| GW-HQ |
+-------+ +-------+
| 172.16.10.1
|
------+-------
/ \
| 172.16.20/24 |
| Warehouse |
| Network |
\ /
--------------
|
| 172.16.10.12
+-----------+
| EMail |
+-----------+
#!/bin/sh # George working from using an IPSEC tunnel mode. # # Run this script on Astro with no switches. # Run this script on GW-HQ with the '-r' (right) switch. # IP addresses for communicating machines ip_left=10.30.30.30 net_left=10.30.30.30 ip_right=10.20.20.20 net_right=172.16.10.0/24 if [ "$1" = "-r" ] ;then ip=$ip_left ; ip_left=$ip_right ; ip_right=$ip; fi if [ "$1" = "-r" ] ;then net=$net_left ; net_left=$net_right ; net_right=$net; fi # Replace these keys with freshly generated random ones key_ah1=0x0123456789abcdef0123456789abcdef key_ah2=0x0123456789abcdef0123456789abcdef key_esp1=0x0123456789abcdef0123456789abcdef0123456789abcdef key_esp2=0x0123456789abcdef0123456789abcdef0123456789abcdef setkey -c <<EOF # Flush the descriptors and the policy flush; spdflush; # Descriptors add $ip_left $ip_right esp 0x1000 -m tunnel -E 3des-cbc $key_esp1 -A hmac-md5 $key_ah1; add $ip_right $ip_left esp 0x1001 -m tunnel -E 3des-cbc $key_esp2 -A hmac-md5 $key_ah2; # Policies spdadd $net_left $net_right any -P out ipsec esp/tunnel/$ip_left-$ip_right/require; spdadd $net_right $net_left any -P in ipsec esp/tunnel/$ip_right-$ip_left/require; EOF
Without this tunnel, a message from George's computer to 172.16.1.12 would be undeliverable because the company's private network is not routable over the Internet. George's ISP, being a good network citizen, blocks those messages without sending them out.
Once the ISPEC tunnel is configured, George's computer encrypts messages to the Email server and forwards them to the company gateway GW-HQ which does have a valid, routable Internet address. The gateway unwraps the messages before forwarding them to the Email server. Likewise, when the Email server or any computer on headquarter's network sends a message to George, the gateway machine encrypts it before sending it to the computer Astro.
George Works from Kay's Koffee Klatch Pretending to be at Home
He doesn't think anyone would mind if he were to work from the coffee shop down the street since they offer free wireless Internet access with the purchase of a 16 ounce beverage and a bagle,
While George thinks that this will be as easy as his previous efforts, he is deceiving himself. For one thing, static keys won't work because he does not want to let on what he is doing by putting Kay's IP address in the GW-HQ configuration. He needs to setup racoon with X.509 certificates so that GW-HQ can accept IPSEC connections from him wherever he goes. Creating a Certificate Authority is described elsewhere [link to CA howto].
George starts by allowing his script to lookup hostnames.
function lookuphost () {
a=`host $1 | sed -e "/CNAME/d" | head -1 | sed -e "s/.* \([0-9.]\+\)$/\1/"`
if [ "$a" = "" ] ; then echo "No address for hostname $1."; exit 1 ; fi
$a
}
He then creates certificates for his computer as well as the GW-HQ computer. On his machine, he puts the CA certificate, his computer certificate, and his computer's key in /etc/certs. He adds symbolic links for each certificates' subject hash. The subject of a certificate is the Distinguished Name, or purpose of the certificate. To view the subject of a certificate, use the command openssl x509 -in certificate.pem -subject.
Install certificates and the local certificate key.
mv cacert.pem ipsec_astro_cert.pem ipsec_astro_key.pem /etc/cert
Create hash links.
cd /etc/cert ln -s cacert.pem `openssl x509 -in cacert.pem -noout -hash`.0 ln -s ipsec_astro_cert.pem `openssl x509 -in ipsec_astro_cert.pem -noout -hash`.0
Remove passphrase from the key.
openssl rsa -in ipsec_astro_key.pem -out ipsec_astro_key.pem
He goes through the same steps on the gateway.
Install certificates and the local certificate key.
mv cacert.pem ipsec_gwhq_cert.pem ipsec_gwhq_key.pem /etc/cert
Create hash links.
cd /etc/cert ln -s cacert.pem `openssl x509 -in cacert.pem -noout -hash`.0 ln -s ipsec_gwhq_cert.pem `openssl x509 -in ipsec_gwhq_cert.pem -noout -hash`.0
Remove passphrase from the key.
openssl rsa -in ipsec_gwhq_key.pem -out ipsec_gwhq_key.pem
Next, George configures Racoon. Here's the configuration for Astro.
# /etc/racoon/racoon.conf
# Configuration for Astro so that it can roam
path certificate "/etc/cert";
remote anonymous
{
exchange_mode main;
# generate_policy on;
# passive on;
certificate_type x509 "ipsec_astro_cert.pem" "ipsec_astro_key.pem";
verify_cert on;
my_identifier asn1dn;
peers_identifier asn1dn;
lifetime time 10 min;
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method rsasig;
dh_group modp1024;
}
}
sainfo anonymous
{
pfs_group modp768;
encryption_algorithm 3des;
authentication_algorithm hmac_md5;
compression_algorithm deflate;
}
And, here's the configuration for the gateway. The important changes are the inclusion of the generate_policy and passive clauses which permit the gateway to receive IPSEC connections without knowing the IP address of the remote computer.
# /etc/racoon/racoon.conf
# Configuration for GW-HQ
path certificate "/etc/cert";
remote anonymous
{
exchange_mode main;
generate_policy on;
passive on;
certificate_type x509 "ipsec_gwhq_cert.pem" "ipsec_gqhq_key.pem";
verify_cert on;
my_identifier asn1dn;
peers_identifier asn1dn;
lifetime time 10 min;
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method rsasig;
dh_group modp1024;
}
}
sainfo anonymous
{
pfs_group modp768;
encryption_algorithm 3des;
authentication_algorithm hmac_md5;
compression_algorithm deflate;
}
A closer look at these configurations is warranted. Because these configurations use the anonymous keyword, both clauses apply to any exchange that racoon makes. The verify-cert option requires that racoon have a CA certificate that matches the remote computer's host certificate. It's a form of access control. The access policy is wide open since there are no IP address restrictions. However, only computers with certificates from known CAs are allowed to connect to GW-HQ. In this case, we installed the file cacert.pem on both computers.
So, here's the network setup.
+--------+ +-------+
| GW-Kay |------Internet------| GW-HQ |
+--------+ +-------+
192.168.100.1 | | 172.16.10.1
| |
| ------+-------
192.168.100.9 | / \
+-------+ | 172.16.20/24 |
| Astro | | Warehouse |
+-------+ | Network |
\ /
--------------
|
| 172.16.10.12
+-----------+
| EMail |
+-----------+
When George goes to the Koffee Klatch, he connects to Kay's wireless gateway and gets an IP address. This IP address is different every time he goes. The gateway uses NAT [a problematic hack] to convey his packets to the Internet. With the new racoon configuration, GW-HQ doesn't need to know George's IP address. In fact, there is no IPSEC configuration script for GW-HQ. This time, only Astro is configured with setkey.
#!/bin/sh
# George working from using an IPSEC tunnel mode.
#
# Run this script on Astro with no switches.
# Convert hostnames to IP addresses
function lookuphost () {
a=`host $1 | sed -e "/CNAME/d" | head -1 | sed -e "s/.* \([0-9.]\+\)$/\1/"`
if [ "$a" = "" ] ; then echo "No address for hostname $1."; exit 1 ; fi
$a
}
# Device name for device handling IPSEC traffic
dev=eth0
# IP addresses for communicating machines
ip_left=`ip -4 addr list dev ath0 primary | grep inet | head -1\
| sed -e "s/ *inet *//" | sed -e "s/\([0-9.]\+\).*/\1/"`
net_left=$ip_left
ip_right=lookuphost("gwhq.cogwellcogs.co.mars")
net_right=172.16.10.0/24
setkey -c <<EOF
# Flush the descriptors and the policy
flush;
spdflush;
# Policies
spdadd $net_left $net_right any -P out ipsec
esp/tunnel/$ip_left-$ip_right/require;
spdadd $net_right $net_left any -P in ipsec
esp/tunnel/$ip_right-$ip_left/require;
EOF
I've done my best to make sure that this script properly handles the outputs of host and ip. Your mileage may vary.
What is most important to notice is that the IP address for $ip_right is not routable. In the past, the addresses on the tunnel had to be routable, but that is not the case here because Astro is operating behind a gateway that uses NAT. As long as Kay's gateway allows for IPSEC passthrough, GW-HQ will accept the tunnel. How does this work? The racoon daemon on GW-HQ will configure the tunnel with an endpoint matching the routable address of GW-Kay.
--Elf 16:38, 6 April 2006 (PDT)
