<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 06/08/2012 12:17 PM, Martin Lambev wrote:
    <blockquote
      cite="mid:A1D4B948-95A5-47C8-892E-634C828CBF76@gmail.com"
      type="cite">Hi Rick, 
      <div><br>
      </div>
      <div>I'm into the exact same problem as you describe in your
        openswan mailing list. </div>
      <div><br>
      </div>
      <div>Reference: </div>
      <h1><span class="Apple-style-span" style="font-weight: normal; "><font
            class="Apple-style-span" size="3">My post:</font></span></h1>
      <h1><span class="Apple-style-span" style="font-weight: normal; "><font
            class="Apple-style-span" size="3">[Openswan Users] ERROR:
            netlink XFRM_MSG_DELPOLICY response for flow
            eroute_connection delete included errno 2: No such file or
            directory</font></span></h1>
      <div><a moz-do-not-send="true"
          href="https://lists.openswan.org/pipermail/users/2012-June/021668.html">https://lists.openswan.org/pipermail/users/2012-June/021668.html</a> ,
        I'm not going to any tech details, but the main problem remains
        even in openswan 2.6.38 </div>
      <div><br>
      </div>
      <div>Your post:</div>
      <div>
        <h1><font class="Apple-style-span" style="font-weight: normal;"
            size="3">[Openswan Users] IP XFRM/Netkey/Stale Routes/%pass</font></h1>
      </div>
      <div><a moz-do-not-send="true"
href="https://lists.openswan.org/pipermail/users/2010-September/019322.html">https://lists.openswan.org/pipermail/users/2010-September/019322.html</a></div>
      <div><br>
      </div>
      <div><br>
      </div>
      <div>
        <div>#ip xfrm policy</div>
        <div>src 50.50.50.10/32 dst 116.55.126.226/32 proto udp sport
          1701 dport 55103 </div>
        <div><span class="Apple-tab-span" style="white-space:pre"> </span>dir
          out priority 2080 ptype main </div>
        <div><span class="Apple-tab-span" style="white-space:pre"> </span>tmpl
          src 0.0.0.0 dst 0.0.0.0</div>
        <div><span class="Apple-tab-span" style="white-space:pre"> </span>proto
          esp reqid 16401 mode transport</div>
        <div>src 0.0.0.0/0 dst 0.0.0.0/0 </div>
        <div><span class="Apple-tab-span" style="white-space:pre"> </span>dir
          4 priority 0 ptype main </div>
        <div>src 0.0.0.0/0 dst 0.0.0.0/0 </div>
        <div><span class="Apple-tab-span" style="white-space:pre"> </span>dir
          3 priority 0 ptype main </div>
        <div>src 0.0.0.0/0 dst 0.0.0.0/0 </div>
        <div><span class="Apple-tab-span" style="white-space:pre"> </span>dir
          4 priority 0 ptype main </div>
        <div>src 0.0.0.0/0 dst 0.0.0.0/0 </div>
        <div><span class="Apple-tab-span" style="white-space:pre"> </span>dir
          3 priority 0 ptype main </div>
      </div>
      <div><br>
      </div>
      <div>The problem described by you match exactly the trouble that I
        have, I also try to dig it to the code and compare old vs. new
        versions 2.6.26 to 2.6.38 kernel_netlink.c file but because I do
        not understand C I'm lost….</div>
      <div><br>
      </div>
      <div>tested with EPEL Openswan 2.6.32 - same issue… </div>
      <div><br>
      </div>
      <div>pluto try to delete the xfrm dir out policy but because there
        is not exact match ( I think it's client 'dport' is not there at
        all in the delete statement  ) that's why  it yells: "ERROR:
        netlink XFRM_MSG_DELPOLICY response for flow eroute_connection
        delete included errno 2: No such file or directory "</div>
      <div><br>
      </div>
      <div>Especially " No such file or directory " shows up if  only if
        the policy that is left does not match completely. Examlpe could
        be applaied to the policy shown above:</div>
      <div>
        <div>If we try to delete it with this statement Missing is dport
          (clients port) # ip xfrm policy delete dir out
          src 50.50.50.10/32 dst 116.55.126.226/32 proto udp sport 1701</div>
        <div>we get this error: RTNETLINK answers: No such file or
          directory</div>
      </div>
      <div><br>
      </div>
      <div>
        <div>#ip xfrm policy</div>
        <div>src 50.50.50.10/32 dst 116.55.126.226/32 proto udp sport
          1701 dport 55103 </div>
        <div><span class="Apple-tab-span" style="white-space: pre; "> </span>dir
          out priority 2080 ptype main </div>
        <div><span class="Apple-tab-span" style="white-space: pre; "> </span>tmpl
          src 0.0.0.0 dst 0.0.0.0</div>
        <div><span class="Apple-tab-span" style="white-space: pre; "> </span>proto
          esp reqid 16401 mode transport</div>
        <div>src 0.0.0.0/0 dst 0.0.0.0/0 </div>
        <div><span class="Apple-tab-span" style="white-space: pre; "> </span>dir
          4 priority 0 ptype main </div>
        <div>src 0.0.0.0/0 dst 0.0.0.0/0 </div>
        <div><span class="Apple-tab-span" style="white-space: pre; "> </span>dir
          3 priority 0 ptype main </div>
        <div>src 0.0.0.0/0 dst 0.0.0.0/0 </div>
        <div><span class="Apple-tab-span" style="white-space: pre; "> </span>dir
          4 priority 0 ptype main </div>
        <div>src 0.0.0.0/0 dst 0.0.0.0/0 </div>
        <div><span class="Apple-tab-span" style="white-space: pre; "> </span>dir
          3 priority 0 ptype main</div>
      </div>
      <div><br>
      </div>
      <div>but if we do: # ip xfrm policy delete dir out
        src 50.50.50.10/32 dst 116.55.126.226/32 proto udp sport 1701 <b>dport
          55103</b></div>
      <div>we get no error and dir out policy is deleted, so I guess
        that dport either is missed in the pluto xfrm delete code (
        which I could not locate clearly in kernel_netlink.c  if this is
        the correct file) </div>
      <div><br>
      </div>
      <div>
        <div>ip xfrm policy</div>
        <div>src 0.0.0.0/0 dst 0.0.0.0/0 </div>
        <div><span class="Apple-tab-span" style="white-space:pre"> </span>dir
          4 priority 0 ptype main </div>
        <div>src 0.0.0.0/0 dst 0.0.0.0/0 </div>
        <div><span class="Apple-tab-span" style="white-space:pre"> </span>dir
          3 priority 0 ptype main </div>
        <div>src 0.0.0.0/0 dst 0.0.0.0/0 </div>
        <div><span class="Apple-tab-span" style="white-space:pre"> </span>dir
          4 priority 0 ptype main </div>
        <div>src 0.0.0.0/0 dst 0.0.0.0/0 </div>
        <div><span class="Apple-tab-span" style="white-space:pre"> </span>dir
          3 priority 0 ptype main </div>
      </div>
      <div><br>
      </div>
      <div><br>
      </div>
      <div>So can you explain your "dirty hack" with _updown.netkey
        script? Where are you put this script and how you call it? Is
        this full script code?</div>
      <div><br>
      </div>
      <div>Best Regards,</div>
      <div><br>
      </div>
      <div>Martin</div>
      <div><br>
      </div>
    </blockquote>
    <br>
    Hi Martin,<br>
    <br>
    I feel your pain.  Unfortunately, it's been a really long time since
    I have been dealing with this issue, and I no longer maintain L2TP
    VPN setups (and haven't for at least a year now).  While my shell
    script hacks did work for me at the time, with the version I was
    running then, I unfortunately shot myself in the foot by not keeping
    track of which version I was using with the functional workaround. 
    Long story short, I applied several different patches supplied to me
    from the OpenSwan team, but ultimately was never able to get the
    XFRM policies to break down in a workable way again.  The method I
    describe with the shell scripts will _not_ work anymore.  The %pass
    bug was fixed in a patch quite a while ago, so that shouldn't be
    happening anymore.<br>
    <br>
    In the end, I think wrote some lame cron job that looked for XFRM
    policies sitting around that did not have an associated connection
    established with netstat or something.  I don't have this anymore,
    and I don't remember exactly what I was doing... it was a last-ditch
    effort.<br>
    <br>
    If you can locate any places where the connection is terminated, you
    might be able to cobble something together to manually break down
    the XFRM policy.  I don't know what OpenSwan officially suggests on
    this issue, maybe use their kernel module instead of netkey.<br>
    <br>
    I still occasionally get emails from people over this problem, and I
    really wish I could be more help, but because there were
    conversations both on the mailing list and in IRC regarding this
    issue, the details are too scattered.<br>
    <br>
    Good luck,<br>
    <br>
    Rick<br>
  </body>
</html>