A Virtual Visit from Paul Wouters

Soon after posting yesterday’s blog entry, How To: VPN Between RV082 (or RV042) and WRT54GL (or WRT54G), I received a comment from Paul Wouters:

Use dpdaction=restart

btw yout ike/ipsec lifetimes are insanely short. you should not do that. leave them default, and the shortest one of the other device will be used.

Paul, if you’re reading this, thanks for the tips!

I wasn’t sure how I could have missed that useful dpdaction=restart setting so I went back and checked the ipsec.conf man page this morning. Sure enough, the dpdaction=restart setting was missing from the man page. That’s why I missed it! See! I did RTFM!

Anyway, I did some googling to find out more about dpdaction=restart and I came across this Openswan mailing list message, authored by none other than Paul Wouters:

On Thu, 10 Nov 2005, Duncan Reed wrote:

> I was interested in seeing how the new(ish) dpdaction=restart option
> differed from clear and hold. Looking through the ipsec.conf man and
> other docs they don’t appear to have been updated yet.
>
> How does restart differ from hold? And in what situations would I use
> restart instead of the other options.

clear: tear down the broken tunnel. Allow cleartext pckets to the destination
hold: tear down the broken tunnel. Disallow cleartext packets, wait for the remote to re-estbalished a new IPsec SA (responder)
restart: tear down the broken tunnel. Disallow cleartext packets, attempt to restart the IPsec tunnel (initiator)

clear is mostly used for roadwarriors. You likely won’t be talking to that remote IP again, as the roadwarrior might show up elsewhere.

hold is for a connection, usually with a remote subnet defined, that vanished but is on dynamic IP. you cannot restart it, but you also want to prevent
sending cleartext packets for the defined remote subnet.

restart is for a connection to a remote static ip, which you can initiate yourself.

Compare it to rekey=no. If you have right=%any, you need to have rekey=no, and you cannot use dpdaction=restart. If this was a single roadwarrior, you clear, if it was for a subnet, you want to hold it.

Paul

I love finding out about undocumented settings! Hehe!

Now, as for my “insanely short” values for keylife and ikelifetime, where did I come up with those? Well, when I was trying to connect the RV082 to the WRT54G, I figured that if I had any problems with bad settings, the RV082 side would be the pickiest. So, I tried to stick mostly to the RV082’s default values. RV082’s default value for Phase1 SA Life Time is 28800 seconds (8 hours) and the default value for Phase2 SA Life Time is 3600 seconds (1 hour).

My mistake was in my mapping of the RV082’s settings names to the OpenSwan settings names. I incorrectly mapped Phase1 SA Life Time to keylife and Phase2 SA Life Time to ikelifetime. The correct mapping is Phase1 SA Life Time to ikelifetime and Phase2 SA Life Time to keylife. How did I found that out? From another Paul Wouters mailing list message, of course:

On Tue, 27 Sep 2005, Agent Smith wrote:

> ike_life is set by the keyword ikelifetime which is
> phase 1 timeout (maximum supported is 8 hr.)
>
> ipsec_life is set by keylife keyword and that is phase
> 2 timeout.
>
> phase 2 timeout is typically less then phase 1
> timeout.
>
> correct?

Yes

Paul

So what values should you use for ikelifetime (phase1) and keylife (phase2)? I emailed this question to Paul and here is his answer:

The RFC leaves it open. Some people prefer phase 2 to last longer then phase1, some vise versa. I believe using phase2 that is bigger then phase1 is good, since a phase 1 rekey failure won’t immediately blow your tunnel out of the water, since phase2 is still valid for a few more hours.

Based on Paul’s advice, I assume the Openswan default values are appropriate. That is, ikelifetime=1 and keylife=8. Note that the default values on the RV082/RV042 appear to be the exact opposite of this, so you should probably reverse the values on the RV082/RV042.

BTW, I found out that Paul has authored a book about Openswan called Openswan: Building and Integrating Virtual Private Networks. I recall seeing this book at the bookstore when I was attempting to create my VPN. At the time I thought “Great book — I should get it”. However, I didn’t get it because I didn’t feel like begging my boss to buy me yet another book. I probably should have got it…