[Openswan Users] SA Lifetimes and a couple other things
paul at xelerance.com
Wed Sep 30 23:27:57 EDT 2009
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.
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!
More information about the Users