[Openswan Users] SA Lifetimes and a couple other things

[Paul Wouters]

On Wed, 30 Sep 2009, JT Edwards wrote:

>  *  I have my SA lifetime set at 3600 (default) so in my securelog I am seeing repeated rekeying and
>     reinitialization from State Main 1 until the tunnel is reestablished. Is this healthy?

There has been a lot of discussion in the past on what is a good lifetime of the ISAKMP (IKE) SA
and what is a good lifetime of the IPsec SA. The RFC's I believe say 8 hours for the IKE SA and 1
hour for the IPsec SA. Openswan uses the reverse, 8 hours for IPsec SA and 1 hour for IKE SA. 
Additionally, some lifetimes can be shorted if there is more that a certain about of traffic
passed over the tunnel in between (not as well supported in openswan yet)

I would say anything between these two values will work. In part tuning might depend on your
user profile. Quick 20 second mobile phone connections might not need to linger for 8 hours.

>  *  I still do not understand the full requirements for setting up iptables. My subnet on the Openswan side goes
>     through a virtual gateway and can talk to the remote subnet just fine when iptables are off. When iptables are
>     on, nothing gets through the tunnel. Can I get a more concise understanding on how to configure iptables. Hours
>     of exhaustive research has tons of different ways. I just need to be pointed to the right way.

The basic rule is "never ever NAT a packet that is 1) meant to go through an IPsec tunnel and 2) is an
ESP packet not encapsulated in a UDP 4500 packet.

Most common scenario: Server A with subnet 10.0.1.0/24 and 192.168.1.0/24
is a NAT router, Server B with subnet 10.0.2.0/24 is a NAT router. Both
setup a tunnel between each other. On server A you'd need:

 	iptables -I POSTROUTING -t nat -s 10.0.1.0/24 -d 10.0.2.0/24 -j RETURN
 	iptables -I POSTROUTING -t nat -s 192.168.1.0/24 -d 10.0.2.0/24 -j RETURN
 	iptables -I POSTROUTING -t nat -s 192.168.1.0/24 -d 0.0.0.0/0 -j MASQUERADE

On the other side you need to do something similar. Only then will your NAT not conflict with your IPsec.

>  *  I am still trying to understand the mystery of using certificates.

See openswan-2.6.x/testing/x509/dist_certs on how to generate them
See openswan-2.6.x/testing/pluto/*x509* on how to configure openswan with them.

In general:
 	The private key to the CA should be offline
 	The public CA cert should be on all ipsec hosts in /etc/ipsec.d/cacerts
 	The private key to an ipsec host should ONLY be on that host in /etc/ipsec.d/private with an
 		entry in /etc/ipsec.secrets to load it.
 	The public cert to an ipsec host needs to only be on that host /etc/ipsec.d/certs/
 	Only use a leftcert/rightcert statement for your OWN endpoint, not for the remote one
 		Do not put the certificate of the remote end on your local end
 	Use left/rightsendcerty=always only on the side where you use left/rightcert=
 	Try to avoid specifying any leftid/rightids, except for left/rightid=%fromcert and only
 		on the side you use left/rightcert=
 	Try to avoid specifying any leftca/rightca other then rightca=%same (where right is remote)
 	Verify your CA cert, host cert, and host private is loaded with "ipsec auto --listall"
 	After attempting to connect, verify you received the remote cert by rerunning "ipsec auto --listall"

 	DO NOT ENABLE plutodebug unless an openswan developer asked you for it!!! Yes really! Really!

Paul