<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<blockquote
 cite="mid:Pine.LNX.4.64.0709102249200.6223@newtla.xelerance.com"
 type="cite">
  <pre wrap="">On Tue, 11 Sep 2007, Roland Pl&uuml;ss wrote:

  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">Both ends need to support and enable DPD for it to get enabled on an SA.

      </pre>
    </blockquote>
    <pre wrap="">I did enable it on both ends by copy pasting the three lines over so
they are identical.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Did you reload/restart the connection?
  </pre>
</blockquote>
Yes I did.<br>
<blockquote
 cite="mid:Pine.LNX.4.64.0709102249200.6223@newtla.xelerance.com"
 type="cite">
  <pre wrap="">Show us the logs where the DPD vendorid packets are sent on both ends?
  </pre>
</blockquote>
===<br>
Sep 11 12:53:51 [pluto] "openswan-epserver" #1: received Vendor ID
payload [Openswan (this version) 2.4.7&nbsp; PLUTO_SENDS_VENDORID
PLUTO_USES_KEYRR]<br>
Sep 11 12:53:51 [pluto] "openswan-epserver" #1: received Vendor ID
payload [Dead Peer Detection]<br>
Sep 11 12:53:51 [pluto] "openswan-epserver" #1: transition from state
STATE_MAIN_I1 to state STATE_MAIN_I2<br>
Sep 11 12:53:51 [pluto] "openswan-epserver" #1: STATE_MAIN_I2: sent
MI2, expecting MR2<br>
Sep 11 12:53:51 [pluto] "openswan-epserver" #1: I did not send a
certificate because I do not have one.<br>
Sep 11 12:53:51 [pluto] "openswan-epserver" #1: transition from state
STATE_MAIN_I2 to state STATE_MAIN_I3<br>
Sep 11 12:53:51 [pluto] "openswan-epserver" #1: STATE_MAIN_I3: sent
MI3, expecting MR3<br>
Sep 11 12:53:52 [pluto] "openswan-epserver" #1: Main mode peer ID is
ID_FQDN: '@****'<br>
Sep 11 12:53:52 [pluto] "openswan-epserver" #1: transition from state
STATE_MAIN_I3 to state STATE_MAIN_I4<br>
Sep 11 12:53:52 [pluto] "openswan-epserver" #1: STATE_MAIN_I4: ISAKMP
SA established {auth=OAKLEY_RSA_SIG cipher=oakley_3des_cbc_192
prf=oakley_md5 group=modp1536}<br>
Sep 11 12:53:52 [pluto] "openswan-epserver" #1: Dead Peer Detection
(RFC 3706): enabled<br>
Sep 11 12:53:52 [pluto] "openswan-epserver" #2: initiating Quick Mode
RSASIG+ENCRYPT+COMPRESS+TUNNEL+PFS+UP {using isakmp#1}<br>
Sep 11 12:53:52 [pluto] "openswan-epserver" #2: Dead Peer Detection
(RFC 3706): enabled<br>
Sep 11 12:53:52 [pluto] "openswan-epserver" #2: transition from state
STATE_QUICK_I1 to state STATE_QUICK_I2<br>
Sep 11 12:53:52 [pluto] "openswan-epserver" #2: STATE_QUICK_I2: sent
QI2, IPsec SA established {ESP=&gt;**** &lt;**** xfrm=AES_0-HMAC_SHA1
IPCOMP=&gt;**** &lt;**** NATD=none DPD=enabled}<br>
Sep 11 12:54:10 [pluto] "openswan-epserver" #1: ignoring Delete SA
payload: PROTO_IPSEC_ESP SA(****) not found (maybe expired)<br>
Sep 11 12:54:10 [pluto] "openswan-epserver" #1: received and ignored
informational message<br>
===<br>
<br>
According to this DPD should be enabled. It's a bit random
unfortunately. The last two days the tunnel had been up all time but
before he went down and got stuck. Chances are though this is not DPD
problem. Like mentioned I have a dynamic IP on one end ( for some
unknown time, maybe I can fix this once ) and therefore I had to use an
URL for this end-point.<br>
Can it be that OpenSwan chokes if the IP of one peer in an active
tunnel suddenly changes IP?<br>
Should DPD not detect the tunnel failing and doing a restart?<br>
If so is the "URL" IP retrieved again or is it stuck with the old one?<br>
<br>
<div class="moz-signature">-- <br>
Yours sincerely<br>
Pl&uuml;ss Roland<br>
<br>
</div>
</body>
</html>