http://permalink.gmane.org/gmane.network.openswan.user hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.network.openswan.user/21120 <pre>I did an upgrade of my Ubuntu system which included an upgrade of the kernel to 3.2.0. Since then, my l2tp tunnels seem to be timing out and being destroyed, at which point I have to manually restart it. On the 3.2.0 end, the following is logged when this happens: May 23 08:07:03 brian-laptop pluto[14651]: "nm-ipsec-l2tpd-14325" #80: IPsec SA expired (LATEST!) May 23 08:07:07 brian-laptop pluto[14651]: initiate on demand from 10.75.22.228:55728 to 2.1.21.22:1701 proto=17 state: fos_start because: acquire May 23 08:07:39 brian-laptop pluto[14651]: initiate on demand from 10.75.22.228:55728 to 2.1.21.22:1701 proto=17 state: fos_start because: acquire May 23 08:07:41 brian-laptop dbus[1536]: [system] Rejected send message, 2 matched rules; type="error", sender=":1.479" (uid=0 pid=14325 comm="/usr/lib/NetworkManager/nm-l2tp-service ") interface="(unset)" member="(unset)" error name="org.freedesktop.DBus.Error.UnknownMethod" requested_reply="0" destination=":1.480" (uid=0 pid=14382 comm="/usr/sbin/pppd passive</pre> Brian J. Murrell 2012-05-23T12:35:30 http://permalink.gmane.org/gmane.network.openswan.user/21119 <pre> Jivin Ozai lays it down ... You have 2 options for HW accelerating Openswan. If there are native linux drivers for your HW crypto accelerator, then just use the netkey stack in linux with openswan. Otherwise you can use ocf-linux + klips to get HW acceleration. Cheers, Davidm </pre> David McCullough 2012-05-22T22:27:22 http://permalink.gmane.org/gmane.network.openswan.user/21118 <pre>Dear Sirs, I merged the openswan 2.6.38 into embedded linux(2.6.30 mips).protostack is klips.Does openswan support the hardware acceleration?If yes,How could I enable it?thank's. Best Regards, Ozai _______________________________________________ Users&lt; at &gt;lists.openswan.org https://lists.openswan.org/mailman/listinfo/users Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy Building and Integrating Virtual Private Networks with Openswan: http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155 </pre> Ozai 2012-05-22T09:41:58 http://permalink.gmane.org/gmane.network.openswan.user/21117 <pre> That's very cool. Thank you Paul! Regards, Patrick _______________________________________________ Users&lt; at &gt;lists.openswan.org https://lists.openswan.org/mailman/listinfo/users Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy Building and Integrating Virtual Private Networks with Openswan: http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155 </pre> Patrick Lists 2012-05-21T09:02:16 http://permalink.gmane.org/gmane.network.openswan.user/21116 <pre>Hi, we have openswan running on our network's gateway and correctly negotiating the tunnels. Here's how we are configuring it: conn csq type=tunnel left=90.45.241.242 # left is our side leftsubnets={90.45.241.242/32,90.45.110.60/32} right=33.99.102.36 rightsubnet=192.168.1.6/32 authby=secret keyexchange=ike ikelifetime=24h ike=3des-md5;modp1024 phase2=esp phase2alg=3des-md5;modp1024 salifetime=24h auto=add The gateway has two interfaces(90.45.110.1 and 90.45.241.242) configured to do IP forwarding and there are no related iptables rules. All IPs on the network are publicly accessible. Our problem is that, while we can ping the machine on the other side from our gateway just fine, the other machine in our subnet(90.45.110.60) is apparently not being routed through one of the established tunnels but is instead provoking the negotiation of a new tunnel in it's name. This fails because on the other side, on</pre> Paul Goldbaum 2012-05-21T08:09:36 http://permalink.gmane.org/gmane.network.openswan.user/21115 <pre>On Sat, 19 May 2012 22:55:25 +0300 Tuomo Soini &lt;tis&lt; at &gt;foobar.fi&gt; wrote: Paul was able to generate a patch to work-around the problem at openswan end. http://people.redhat.com/pwouters/openswan-android-ics-natoa.patch </pre> Tuomo Soini 2012-05-21T04:57:40 http://permalink.gmane.org/gmane.network.openswan.user/21114 <pre>[snip] At least Google is aware of the issue: http://code.google.com/p/android/issues/detail?id=23124 Regards, Patrick _______________________________________________ Users&lt; at &gt;lists.openswan.org https://lists.openswan.org/mailman/listinfo/users Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy Building and Integrating Virtual Private Networks with Openswan: http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155 </pre> Patrick Lists 2012-05-20T12:05:57 http://permalink.gmane.org/gmane.network.openswan.user/21113 <pre>Ouch! I do hope someone has reported it to the ipsec-tools maintainer - John _______________________________________________ Users&lt; at &gt;lists.openswan.org https://lists.openswan.org/mailman/listinfo/users Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy Building and Integrating Virtual Private Networks with Openswan: http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155 </pre> John A. Sullivan III 2012-05-19T20:32:18 http://permalink.gmane.org/gmane.network.openswan.user/21112 <pre> Thanks for that info Tuomo. Hopefully Google will soon provide an update that fixes this issue. I tried to connect my Nexus S with ICS 4.0.4 to a CentOS 6.2 x86_64 box with Openswan 2.6.38 and only got the previously reported error. Regards, Patrick _______________________________________________ Users&lt; at &gt;lists.openswan.org https://lists.openswan.org/mailman/listinfo/users Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy Building and Integrating Virtual Private Networks with Openswan: http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155 </pre> Patrick Lists 2012-05-19T20:28:30 http://permalink.gmane.org/gmane.network.openswan.user/21111 <pre>On Fri, 18 May 2012 14:35:59 +0100 Robert Laverick &lt;robert+vpn&lt; at &gt;scabserver.com&gt; wrote: The problem can't be fixed in openswan - ipsec-tools do have a bug where it behaves against spec. </pre> Tuomo Soini 2012-05-19T19:55:25 http://permalink.gmane.org/gmane.network.openswan.user/21110 <pre> I have tried Paul's test server from Android 4.0.4 and see the same failure to connect behaviour as on my local Fedora based VPN running the older 2.6.37 F16 RPM, tho obviously I can't see what his logs say it "feels" the same in terms of time to failure on my android device. Rob _______________________________________________ Users&lt; at &gt;lists.openswan.org https://lists.openswan.org/mailman/listinfo/users Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy Building and Integrating Virtual Private Networks with Openswan: http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155 </pre> Robert Laverick 2012-05-18T13:35:59 http://permalink.gmane.org/gmane.network.openswan.user/21108 <pre> Actually the problem from the originally linked bug report appears to have only been introduced with Android 4.0.x and above when they moved to ipsec-tools 0.8.0 so a test from 2.3.6 doesn't actually test if this is resolved http://code.google.com/p/android/issues/detail?id=23124 I've attempted to connect to the test VPN you mentioned from my Android 4.0.4 device and I get timeout failures which mirror the ones I get using openswan-2.6.37-1.fc16.x86_64 on my own server. I'm more than happy to help test this, but I'm a beginner at this VPN stuff, all I know is that I've got it configured to that my Windows 7 laptop can connect to the VPN just fine. Here's an example of what I see in the logs from when I was trying to get this working last night on my own fedora 16 box from Android 4.0.4 on my Nexus S: May 17 00:13:27 gozer pluto[5124]: "home-ipsec"[7] 149.254.180.87 #6: responding to Main Mode from unknown peer 149.254.180.87 May 17 00:13:27 gozer pluto[5124]: "home-ipsec"[7] 149.254.180.87 #6:</pre> Robert Laverick 2012-05-18T11:44:19 http://permalink.gmane.org/gmane.network.openswan.user/21107 <pre>Hello friends I'm configuring a site-to-site VPN for a client but have problems with the routes, my tunnel is up and everything seems to be ok, but i have no communication between my two networks. If the openswan service is down and i try to do a "traceroute" against the subnet i'm trying to connect the package is send trough the default route an jump until didn't find the route, this is obviously a normal behaviour: $ traceroute 192.168.202.22 traceroute to 192.168.202.22 (192.168.202.22), 30 hops max, 60 byte packets 1 * * * 2 172.31.250.46 (172.31.250.46) 14.903 ms 14.916 ms 16.554 ms 3 190.157.7.149 (190.157.7.149) 17.566 ms 17.568 ms 17.570 ms 4 10.14.14.126 (10.14.14.126) 79.087 ms 79.102 ms 79.106 ms 5 64.86.28.41 (64.86.28.41) 73.006 ms !H * * But if the service is up and the tunnel established, the package doesn't route: $ traceroute 192.168.202.22 traceroute to 192.168.202.22 (192.168.202.22), 30 hops max, 60 byte packets 1 * * * 2 * * * 3 * * * 4 * * </pre> Wilfredo I. Pachón López 2012-05-16T15:21:47 http://permalink.gmane.org/gmane.network.openswan.user/21106 <pre> Hm... but, maybe I wasn't right... _______________________________________________ Users&lt; at &gt;lists.openswan.org https://lists.openswan.org/mailman/listinfo/users Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy Building and Integrating Virtual Private Networks with Openswan: http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155 </pre> SVM 2012-05-13T21:29:01 http://permalink.gmane.org/gmane.network.openswan.user/21105 <pre> There is no problem with IPSec/Openswan at all. You have ip range, left and right in the same subnet 192.168.0.0/24 Change your ip range to the other subnet, 192.168.1.0/24, for example. _______________________________________________ Users&lt; at &gt;lists.openswan.org https://lists.openswan.org/mailman/listinfo/users Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy Building and Integrating Virtual Private Networks with Openswan: http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155 </pre> SVM 2012-05-13T21:07:55 http://permalink.gmane.org/gmane.network.openswan.user/21104 <pre>Welcome, I configuring an IPsec tunnel with Openswan and l2tpd anhand howto on site: http://www.natecarlson.com/2006/07/10/configuring-an-ipsec-tunnel-with-openswan-and-l2tpd. But i have problems with establishing conection. This is my ipsec.conf config setup nat_traversal=yes protostack=netkey virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12 interfaces=%none conn dupa type=transport #authby=secret left=192.168.0.149 leftid=%fromcert #leftrsasigkey=%cert leftcert=server.pem right=192.168.0.212 rightid=%fromcert #rightrsasigkey=%cert rightcert=dupa1.pem rightca=%same #keyingtries=3 #rekey=no #ikelifetime=8h #keylife=1h leftprotoport=17/1701 rightprotoport=17/%any auto=add pfs=no #xl2tpd.conf [global] port = 1701 auth file = /etc/l2tpd/l2tp-secrets [lns default] ip range = 192.168.0.1-192.168.0.250 local ip = 192.168.1.149 require chap = yes refuse pap = yes</pre> Jarek Joachimiak 2012-05-13T15:53:02 http://permalink.gmane.org/gmane.network.openswan.user/21103 <pre>Hello friends i'm trying to configure a VPN openswan + Cisco, everything seems ok, even ping with remote machines is working, but if i try to communicate with TCP to a open port, it doesn't work. Even "traceroute" isn't working, you can please give me a help? I'm sure that the connection was or anything is happening because if if stop the ipsec daemon the ping stop to function. My configuration is: config setup plutodebug=none klipsdebug=none plutoopts="--perpeerlog" nat_traversal=yes #virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12 #interfaces=%defaultroute oe = off protostack=netkey nhelpers = 0 plutostderrlog=/var/log/vpn conn net-super type=tunnel authby=secret # Key exchange method left=240.125.229.25 # Public Internet IP address of the leftsubnet=192.168.0.0/24 # Subnet protected by the LEFT VPN device leftnexthop</pre> Wilfredo I. Pachón López 2012-05-11T18:13:26 http://permalink.gmane.org/gmane.network.openswan.user/21102 <pre> You may be a little fuzzy on the networking concept. Unless you are using a specialized one-way connectionless protocol, all TCP/IP networking is two-way. In fact, the TCP protocol cannot work without two-way communication. So yes, you need only one connection definition to allow traffic to flow both ways. Both ends must use similar configs. Grossly oversimplified, the determining factor is (left subnet, right subnet). When IPSEC on whichever side is 'right' sees traffic sourced from the 10.108.3.0/24 LAN and destined to the 130.30.0.0/16 LAN, it grabs the taffic, encrypts it, puts it in ESP packet, and sends it to A.B.C.D. If right's leftsubnet were 0.0.0.0/0, then right would send *all* traffic from 10.108.3.0/24 through IPSEC. Stated a little differently, the subnets specified in leftsubnet and rightsubnet determine which traffic is encrypted and sent through the VPN. Check the logs. If you see it sending 'STATE_MAIN_I1' (and the like), then it can initiate the conn. If it only sends 'ST</pre> Neal Murphy 2012-05-11T17:26:56 http://permalink.gmane.org/gmane.network.openswan.user/21101 <pre>We recently did a security audit against the latest .38 release. The only thing that failed the Ernest &amp;&amp; Young test was that they were able to insert a MIM agent and grab one of our transactions which was encrypted with AES_128 DH5. We use NETKEY and PSK. While they couldn't decrypt the transaction they were able to flood the concentrator with enough transactions that eventually due to over load some of those old transaction did manage to show up on our inside network and began to consume bandwidth. So my question is (Paul or Tuomo) do you think that a change to RSA keys will prevent this brute force MIM attack? Thanks CONFIDENTIALITY NOTICE: The information contained in this email message is intended only for use of the intended recipient. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately delete it from your </pre> Goffe, Don 2012-05-11T15:54:07 http://permalink.gmane.org/gmane.network.openswan.user/21100 <pre> Thanks Roel, those were two basic points that I wasn't sure whay they mean. If I want to comunicate "bank" to "cars" and "cars" to "bank" -both ways- is it only necessary one definition like the first one?: conn bank-cars        right=W.X.Y.Z        rightsubnet=10.108.3.0/24        left=A.B.C.D        leftid=172.31.64.41        leftsubnet=130.30.0.0/16        aggrmode=no        auto=start What determines if traffic from "bank" to "cars" subnet or viceversa is allowed or not? Is it maybe an firewall/ACL/iptable rule? How can I know if Juniper is configured to start the connection? It could be letting my connection in "add" status and just wait to be connected by the Juniper appliance? According to your previous explanation I can suspect that those two error messages are being caused by the duplicated connection. I'll try and see if the same error it keeps appearing. thanks _______________________________________________ Users&lt; at &gt;lists.openswan.org https://lists.openswan.org/mai</pre> Jason Voorhees 2012-05-11T14:57:18 http://permalink.gmane.org/gmane.network.openswan.user/21099 <pre> First: you need to specify a connection only once. The 'left' and 'right' parameters are interchangable, so your bank-cars and cars-bank definitions are effectively identical. You can use the 'auto' parameter to define which side will initiate the connection. With auto=start openswan will initiate a connection, with auto=add openswan will set everything up and then wait for the other end to initiate. Same here: the last two lines are identical. I don't have a 100% correct technical answer, but this message means that the remote end doesn't want to establish a tunnel with you. Of course, that might be the result of you already having a tunnel.. This, I think, is caused by the duplicate tunnel definition you have. If the second tunnel is started, openswan tries to route the remote net through that tunnel, but it can't because it is already routed through the first tunnel. I'd start with removing one of the definitions; that should certainly help. Good luck, Roel ___________________</pre> Roel van Meer 2012-05-11T05:58:08 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.network.openswan.user