<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Tamis,<div><br></div><div>Thanks for the patch, first I try first file, and second I sow below that one I tought I try it too, but to bee sure will apply it again and do some testings….</div><div><br></div><div>Okay here is the results:</div><div><br></div><div>first attempt connection ok, but second attempt and third fail on isakmp: phase 1 I ident , </div><div><br></div><div>and there are even more policy left that without it…. and they are not complete.</div><div><br></div><div><div>src 50.50.50.50/32 dst 0.0.0.0/0 </div><div><span class="Apple-tab-span" style="white-space:pre"> </span>dir fwd priority 3104 ptype main </div><div>src 50.50.50.50/32 dst 0.0.0.0/0 </div><div><span class="Apple-tab-span" style="white-space:pre"> </span>dir in priority 3104 ptype main </div><div>src 50.50.50.50/32 dst 0.0.0.0/0 </div><div><span class="Apple-tab-span" style="white-space:pre"> </span>dir out priority 2112 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>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>Thanks, I'm start thinking that this could be CentOS 6.2 related?</div><div><br></div><div>Best regards,</div><div><br></div><div>Martin</div><div><br></div><div><br><div><div>On Jun 9, 2012, at 3:02 PM, Panagiotis Tamtamis wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hello Martin,<br><br>I am the one who submitted bug#1334 and wrote the patch for it.<br>Please try to use the second patch file (<a href="https://www.openswan.org/attachments/508/bug1334.bug" class="icon icon-attachment">bug1334.bug</a>
<span class="size">(894 Bytes)</span>
<span class="author">Panagiotis Tamtamis, 03/19/2012 02:31 pm)<br><br>The first one is not working well.<br><br>Please try it and report if it resolves your issue. For me it worked ok.<br>As far as I now my patch is not included in openswan U2.6.38<br>
<br>Best Regards,<br>Tamis<br></span><div>
<br class="webkit-block-placeholder"></div><br><div class="gmail_quote">2012/6/7 Martin Lambev <span dir="ltr"><<a href="mailto:fsh3mve@gmail.com" target="_blank">fsh3mve@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Hello OpenSwan guys,<br>
Earlier this week I wrote about problem with connection multiply clients with various operating systems (Mac SL, Win 7 and Win XP) that sits behind one real IP address (NATed). I did not try to connect them all together (simultaneously) to L2TP/IPSec-PSK server but, one after another if that matters...<br>
<br>
Linux Openswan U2.6.38/K2.6.32-220.17.1.el6.x86_64 (netkey) (compiled form source) on CentOS 6.2 x64, as L2TP tested with both xl2tpd v.1.3.1 (form EPEL repo) and/or accel-pppd latest git. My server have two real IP addresses assigned to one NIC, example eth0 IP:50.50.50.10 and alias eth0:0 IP:50.50.50.50 (addresses are changed)<br>
<br>
I'm using default conf example shipped with openswan v.2.6.38 /etc/ipsec.d/examples/l2tp-psk.conf and one of the real IP as left=50.50.50.10 ( offtopic: xl2tpd has problems and can't connect if I use ALIASED IP eth0:0 error in the log: "udp_xmit failed to <a href="http://60.161.197.173:52132/" target="_blank">60.161.197.173:52132</a> with err=-1:Operation not permitted , xl2tpd: Maximum retries exceeded for tunnel 62854. Closing" )<br>
Just added to /etc/ipsec.conf , 'listen=' and virtual_private= defaults plus my specific private net behind the router <a href="http://1.1.1.0/24" target="_blank">1.1.1.0/24</a> + excluded !<a href="http://192.168.100.0/24" target="_blank">192.168.100.0/24</a> for the vpn clients.<br>
<br>
<br>
All times IPsec tunnel is established. But in the message log (/var/log/messages) one can see something similar to "l2tp: incorrect tid 0 in tunnel 1" for accel-ppd and "Maximum retries exceeded for tunnel 3561. xl2tpd: Connection 42 closed to 60.161.197.173, port 55650 (Timeout)" for xl2tpd.<br>
<br>
Clients complain that can not connect to xl2tpd...<br>
<br>
I can see in the /var/log/secure that any connection "ERROR: netlink XFRM_MSG_DELPOLICY response for flow eroute_connection delete included errno 2: No such file or directory" when connection is disconnected from the client. When I monitor ip xfrm monitor, Ipsec tries every time to delete the XFRM policy after client disconnect. Mac connection is successfully deleted ( but still in the log file XFRM error appear) but apparently with Windows 7 and XP connections are partly left. That cause the trouble for connections after that...<br>
<br>
Deleting only the partly left XFRM policy that cause the trouble for other clients to connect solve the issue, until that client connects again.<br>
Flushing the XFRM policy also solves the problem, restarting IPSec also solve that problem ( because I assume it make policy flush then it starts? ).<br>
This does not affect clients connecting form different IP address (behind NAT) but only clients that sits behind same IP<br>
<br>
Just quick reminder what is the issue - It depends on order which OS you will connect first.:<br>
1. First Mac OS X, then Windows 7, then XP can't connect! ( there XFRM policy that left form Win7 that blocks XP connection to xl2tpd).<br>
2. First Windows 7, then Mac OS X, then XP can't connect!<br>
3. First Windows XP, then (order is not relevant) Win7 and Mac can't connect! ( there XFRM policy that left form XP that blocks Win7 and Mac connection to xl2tpd).<br>
I have not test with android and iOS to see what is the case…<br>
<br>
Should I file bug report? I've found some similar bug reports but for older versions of openswan. I try to apply Bug1334.patch for version 2.6.37 which I assume is already in 38?, but anyway the result is the same.<br>
<br>
Any solution beside manually deleting left over XFRM policy?<br>
<br>
Best Regards,<br>
<br>
Martin<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
<a href="mailto:Users@lists.openswan.org">Users@lists.openswan.org</a><br>
<a href="https://lists.openswan.org/mailman/listinfo/users" target="_blank">https://lists.openswan.org/mailman/listinfo/users</a><br>
Micropayments: <a href="https://flattr.com/thing/38387/IPsec-for-Linux-made-easy" target="_blank">https://flattr.com/thing/38387/IPsec-for-Linux-made-easy</a><br>
Building and Integrating Virtual Private Networks with Openswan:<br>
<a href="http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155" target="_blank">http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Think simple!<br>
</blockquote></div><br></div></body></html>