Hello.
I know that DPD is supposed to be broken under certain
conditions,
especially when working with more than one connection
between two peers.
Some trouble can can be avoided by using 'restart_by_peer'
instead of
'restart' or 'hold'. (This is http://bugs
.xelerance.com/view.php?id=729)
Now we recently stumbled into the following interesting
scenario with
Openswan 1.0.x and 2.4.7. (This might be related to
http://bugs
.xelerance.com/view.php?id=452)
o Set up two VPN tunnels between two Openswan gateways, one
acting as a
responder (does not initiate, X.509 certs and %any as
remote peer),
the other as an initiator (with DPD set to
restart_by_peer).
o After the initiation the ISAKMP SA is shared by both IPsec
SAs.
(Ensure that the ISAKMP SAs on both peers belong to the
same pair of
IPsec SAs. At least that's what I did, it might not be a
requirement.)
o On the responder, terminate the connection owning the
ISAKMP SA.
o The initiator receives a Delete Notification and
terminates the ISAKMP SA
and one of its IPsec SA within 10s. Another IPsec SA
remains active.
o Now kill the pluto daemon on the responder (SIGKILL!) and
start Pluto again
and re-add the two connections.
(This way the IPsec SA is removed on the receiver and the
client receives
no Delete Notification, which is a valid behaviour as
Delete Notifications
are not retransmitted when lost.)
o The initiator will renegotiate the connection which has no
IPsec SA.
=>
o On the initiator DPD will believe that everything is fine
because its
ISAKMP SA is working and it has two IPsec SAs, one being
invalid.
o On the gateway one IPsec SA is missing until the next
rekeying attempt of
the invalid IPsec SA.
>From what I saw in RFC 3706, DPD does not carry
information about the IPsec
SA which is being watched. Is that right or is this
mishandled by Openswan?
>From the logs I see that DPD is started when an IPsec SA
is established, so
I guess one would expect that it also carries information
about the IPsec SA
it is watching.
For a hotfix I solved the issue by restarting all IPsec SA
to the same peer
if on IPsec SA received a Delete Notification, which seems
to work for now.
Bye,
Mark
--
Dipl.-Inf. Mark-André Hopf
Senior Software Engineer
Innominate Security Technologies AG
protecting industrial networks
tel: +49.30.6392-3284
fax: +49.30.6392-3307
Albert-Einstein-Str. 14
D-12489 Berlin, Germany
www.innominate.com
Register Court: AG Charlottenburg, HR B 81603
Management Board: Joachim Fietz, Dirk Seewald
Chairman of the Supervisory Board: Edward M. Stadum
_______________________________________________
Dev mailing list
Dev openswan.org
http:/
/lists.openswan.org/mailman/listinfo/dev
|