[Openswan Users] Corner cases with DPD

[Ken Bantoft]

Thank you for your well written notes on this - it certianly makes things 
easy for me to try and answer.

On Mon, 12 Jul 2004, Michael Smith wrote:

> Hi,
> 
> I'm running Openswan 1.0.6 on a central site with a number of road warrior
> clients. I'm using dead peer detection mainly so the clients can figure
> out if the central site has rebooted and start new tunnels. With about a
> dozen test clients, I'm seeing about one site per day that goes down and
> doesn't come back up because of something related to DPD not doing its
> job. I think I've narrowed it down to a couple of cases.
> 
> The clients are behind ADSL routers doing NAT, so I am using NAT-T. I saw
> a post from March saying DPD + NAT-T may cause problems, but I think
> the problems I'm seeing are not related to that. Most of the clients are
> actually Openswan 1.0.1 but according to CHANGES nothing DPD-related has
> happened since then.

Yea, AFAIK I didn't change DPD between 1.0.1 and 1.0.6.

> I have keyingtries=0, so this continued until the ISAKMP was replaced an
> hour or so later. I think DPD would have figured out the ISAKMP SA was
> invalid but I'm guessing DPD doesn't run until there is an IPsec SA. This
> case shouldn't happen very often, but I don't think there's a workaround.

Correct, DPD won't run until there is a full phase 2 SA setup, and then 
the timers + whatnot are setup to be triggered.  

> Case #2: client has valid (new) ISAKMP SA but invalid IPsec SA
> 
> 04:28:07: client negotiates main mode ISAKMP SA #73
> 04:28:17: client negotiates IPsec SA #74
> 05:12:50: client's ADSL connection goes down
> 05:14:58: central site DPD declares the client dead and deletes its ISAKMP
>    and IPsec SAs. Client doesn't get delete notification because it's
>    still down. Client DPD doesn't declare peer dead.
> 05:15:11: client's ADSL line comes back up
> 05:15:35: client initiates main mode (#75) to replace #73 which is about
>    to expire
> 
> The client now has a valid ISAKMP SA and thinks its IPsec SA is still
> valid for another seven hours. The central site agrees about ISAKMP but
> not IPsec. This happens fairly often, but I think I can work around it by
> setting a very high dpdtimeout (86400 seconds) on the central site.

Or set your keylife to much lower.  I'll see if I can write a test case 
for this later this week, with multiple tunnels using the same phase 1 SA.


-- 
Ken Bantoft			VP Business Development
ken at xelerance.com		Xelerance Corporation
sip://toronto.xelerance.com	http://www.xelerance.com