anyone here?<br><br>
<div><span class="gmail_quote">On 11/23/06, <b class="gmail_sendername"><a href="mailto:users-request@openswan.org">users-request@openswan.org</a></b> <<a href="mailto:users-request@openswan.org">users-request@openswan.org
</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Send Users mailing list submissions to<br> <a href="mailto:users@openswan.org">users@openswan.org</a>
<br><br>To subscribe or unsubscribe via the World Wide Web, visit<br> <a href="http://lists.openswan.org/mailman/listinfo/users">http://lists.openswan.org/mailman/listinfo/users</a><br>or, via email, send a message with subject or body 'help' to
<br> <a href="mailto:users-request@openswan.org">users-request@openswan.org</a><br><br>You can reach the person managing the list at<br> <a href="mailto:users-owner@openswan.org">users-owner@openswan.org</a><br>
<br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of Users digest..."<br><br><br>Today's Topics:<br><br> 1. Re: Another attempt to get connected to a SonicWALL VPN.<br>
(Paul Wouters)<br> 2. Re: Another attempt to get connected to a SonicWALL VPN.<br> (Bas Driessen)<br> 3. Multiple Roadwarrior Connections (kelvin)<br> 4. Re: Ipsec connection doesn't work over PPP (Antony Gelberg)
<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Thu, 23 Nov 2006 07:47:43 +0100 (CET)<br>From: Paul Wouters <<a href="mailto:paul@xelerance.com">paul@xelerance.com
</a>><br>Subject: Re: [Openswan Users] Another attempt to get connected to a<br> SonicWALL VPN.<br>To: Bas Driessen <<a href="mailto:bas.driessen@xobas.com">bas.driessen@xobas.com</a>><br>Cc: <a href="mailto:users@openswan.org">
users@openswan.org</a><br>Message-ID: <<a href="mailto:Pine.LNX.4.63.0611230741530.24824@tla.xelerance.com">Pine.LNX.4.63.0611230741530.24824@tla.xelerance.com</a>><br>Content-Type: TEXT/PLAIN; charset=US-ASCII<br><br>
On Thu, 23 Nov 2006, Bas Driessen wrote:<br><br>> I have a Linux Desktop PC that I need to connect to a SonicWALL VPN. The<br>> linux PC has an ip number of <a href="http://192.168.1.13"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 192.168.1.13</a> and is connected to the
<br>> Internet via gateway <a href="http://192.168.1.1"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 192.168.1.1</a>. The VPN server where I need to connect<br>> to has an IP number of 66.nnn.nnn.nnn (for obvious security reasons I am<br>> using nnn here) and this connects to subnet
<a href="http://192.168.128.0/24"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 192.168.128.0/24</a>. So in<br>> fact, I am just trying to create a VPN client to server connection.<br><br>> The details that I got from the system admin who maintains the VPN is<br>
> that it is using the following:<br>><br>> - SonicWALL VPN<br>> - ESP 3DES HMAC MD5 (IKE)<br>> - XAUTH authentication is not required.<br><br>Did you get a PSK as well?<br><br>> conn sonicwall<br>> type=tunnel
<br>> auto=add<br>> auth=esp<br>> pfs=yes<br>> authby=secret<br>> keyingtries=1<br>> left=<a href="http://192.168.1.13"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 192.168.1.13</a><br>> leftsubnet=<a href="http://192.168.1.13/32"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font>
192.168.1.13/32</a><br><br>That's very likely wrong. Leave out leftsubnet=<br><br>> right=66.nnn.nnn.nnn<br>> rightsubnet=<a href="http://192.168.128.0/24"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 192.168.128.0/24</a><br>> rightid=66.nnn.nnn.nnn
<br>> esp=3des-md5<br>> keyexchange=ike<br>> ike=3des-md5<br><br>Looks ok<br><br>> /etc/ipsec.d/sonicwall.secrets<br>><br>> <a href="http://192.168.1.13"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 192.168.1.13</a> 66.nnn.nnn.nnn : PSK "somesecretkeyphrase"
<br><br>and here too.<br><br>> When starting the ipsec service (/etc/rc.d/init.d/ipsec start), the<br>> output to screen as follows:<br>><br>> [root@ams ipsec.d]# /sbin/service ipsec restart<br>> Shutting down IPsec: Stopping Openswan IPsec...
<br>> [ OK ]<br>> Starting IPsec: Starting Openswan IPsec 2.4.5...<br>> insmod /lib/modules/2.6.18-1.2849.fc6/kernel/net/key/af_key.ko<br>> insmod /lib/modules/2.6.18-
1.2849.fc6/kernel/net/ipv4/xfrm4_tunnel.ko<br> [ OK ]<br>Since you did auto=add, the connection is only loaded, not started.<br>Use auto=start to start it at startup, or run 'ipsec auto --up sonicwall'
<br>at a later time to bring it up.<br><br>> Nov 23 14:06:36 ams pluto[16213]: | inserting event EVENT_LOG_DAILY,<br>> timeout in 35604 seconds<br><br>And do NOT enable plutodebug unless you are a developer or being asked to.
<br><br>> When trying to create the connection, I type:<br>><br>> /usr/sbin/ipsec whack --name sonicwall --initiate<br>><br>> The output to screen is:<br>><br>> [root@ams ipsec.d]# /usr/sbin/ipsec whack --name sonicwall --initiate
<br>> 002 "sonicwall" #1: initiating Main Mode<br>> 104 "sonicwall" #1: STATE_MAIN_I1: initiate<br>> 010 "sonicwall" #1: STATE_MAIN_I1: retransmission; will wait 20s for<br>> response
<br>><br>> (the re-transmission errors are repeating)<br><br>Looks like the other end is rejecting on the first packet, or someone<br>is firewalling your packets.<br><br>> Nov 23 14:09:54 ams pluto[16661]: | *received 92 bytes from
<br>> 66.nnn.nnn.nnn:500 on eth0 (port=500)<br>> Nov 23 14:09:54 ams pluto[16661]: | **parse ISAKMP Message:<br>> Nov 23 14:09:54 ams pluto[16661]: | initiator cookie:<br>> Nov 23 14:09:54 ams pluto[16661]: | b3 fb 6d de b8 44 10 98
<br>> Nov 23 14:09:54 ams pluto[16661]: | responder cookie:<br>> Nov 23 14:09:54 ams pluto[16661]: | 4b c1 9a fa 48 f0 0d 6d<br>> Nov 23 14:09:54 ams pluto[16661]: | next payload type: ISAKMP_NEXT_N<br>> Nov 23 14:09:54 ams pluto[16661]: | ISAKMP version: ISAKMP Version
<br><br>Though this seems like you received something, so I don't think these runs<br>are the same run.<br><br>> Nov 23 14:09:54 ams pluto[16661]: packet from 66.nnn.nnn.nnn:500:<br>> ignoring informational payload, type NO_PROPOSAL_CHOSEN
<br><br>This is a configuration error between the two endpoints. You will have to<br>ask more information from the other end. You can try adding "pfs=no".<br><br>Paul<br><br><br>------------------------------<br>
<br>Message: 2<br>Date: Thu, 23 Nov 2006 17:16:05 +1000<br>From: Bas Driessen <<a href="mailto:bas.driessen@xobas.com">bas.driessen@xobas.com</a>><br>Subject: Re: [Openswan Users] Another attempt to get connected to a
<br> SonicWALL VPN.<br>To: Paul Wouters <<a href="mailto:paul@xelerance.com">paul@xelerance.com</a>><br>Cc: <a href="mailto:users@openswan.org">users@openswan.org</a><br>Message-ID: <<a href="mailto:1164266165.9548.45.camel@ams.xobas.com">
1164266165.9548.45.camel@ams.xobas.com</a>><br>Content-Type: text/plain; charset="us-ascii"<br><br>On Thu, 2006-11-23 at 07:47 +0100, Paul Wouters wrote:<br><br>> On Thu, 23 Nov 2006, Bas Driessen wrote:<br>
><br>> > I have a Linux Desktop PC that I need to connect to a SonicWALL VPN. The<br>> > linux PC has an ip number of <a href="http://192.168.1.13"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 192.168.1.13</a> and is connected to the<br>> > Internet via gateway
<a href="http://192.168.1.1"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 192.168.1.1</a>. The VPN server where I need to connect<br>> > to has an IP number of 66.nnn.nnn.nnn (for obvious security reasons I am<br>> > using nnn here) and this connects to subnet
<a href="http://192.168.128.0/24"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 192.168.128.0/24</a>. So in<br>> > fact, I am just trying to create a VPN client to server connection.<br>><br>> > The details that I got from the system admin who maintains the VPN is
<br>> > that it is using the following:<br>> ><br>> > - SonicWALL VPN<br>> > - ESP 3DES HMAC MD5 (IKE)<br>> > - XAUTH authentication is not required.<br>><br>> Did you get a PSK as well?
<br>><br>> > conn sonicwall<br>> > type=tunnel<br>> > auto=add<br>> > auth=esp<br>> > pfs=yes<br>> > authby=secret<br>> > keyingtries=1<br>> > left=
<a href="http://192.168.1.13"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 192.168.1.13</a><br>> > leftsubnet=<a href="http://192.168.1.13/32"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 192.168.1.13/32</a><br>><br>> That's very likely wrong. Leave out leftsubnet=<br>><br>> > right=
66.nnn.nnn.nnn<br>> > rightsubnet=<a href="http://192.168.128.0/24"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 192.168.128.0/24</a><br>> > rightid=66.nnn.nnn.nnn<br>> > esp=3des-md5<br>> > keyexchange=ike<br>> > ike=3des-md5
<br>><br>> Looks ok<br>><br>> > /etc/ipsec.d/sonicwall.secrets<br>> ><br>> > <a href="http://192.168.1.13"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 192.168.1.13</a> 66.nnn.nnn.nnn : PSK "somesecretkeyphrase"<br>><br>> and here too.
<br>><br>> > When starting the ipsec service (/etc/rc.d/init.d/ipsec start), the<br>> > output to screen as follows:<br>> ><br>> > [root@ams ipsec.d]# /sbin/service ipsec restart<br>> > Shutting down IPsec: Stopping Openswan IPsec...
<br>> > [ OK ]<br>> > Starting IPsec: Starting Openswan IPsec 2.4.5...<br>> > insmod /lib/modules/2.6.18-1.2849.fc6/kernel/net/key/af_key.ko<br>
> > insmod /lib/modules/2.6.18-1.2849.fc6/kernel/net/ipv4/xfrm4_tunnel.ko<br>> [ OK ]<br>> Since you did auto=add, the connection is only loaded, not started.
<br>> Use auto=start to start it at startup, or run 'ipsec auto --up sonicwall'<br>> at a later time to bring it up.<br>><br>> > Nov 23 14:06:36 ams pluto[16213]: | inserting event EVENT_LOG_DAILY,<br>> > timeout in 35604 seconds
<br>><br>> And do NOT enable plutodebug unless you are a developer or being asked to.<br>><br>> > When trying to create the connection, I type:<br>> ><br>> > /usr/sbin/ipsec whack --name sonicwall --initiate
<br>> ><br>> > The output to screen is:<br>> ><br>> > [root@ams ipsec.d]# /usr/sbin/ipsec whack --name sonicwall --initiate<br>> > 002 "sonicwall" #1: initiating Main Mode<br>> > 104 "sonicwall" #1: STATE_MAIN_I1: initiate
<br>> > 010 "sonicwall" #1: STATE_MAIN_I1: retransmission; will wait 20s for<br>> > response<br>> ><br>> > (the re-transmission errors are repeating)<br>><br>> Looks like the other end is rejecting on the first packet, or someone
<br>> is firewalling your packets.<br>><br>> > Nov 23 14:09:54 ams pluto[16661]: | *received 92 bytes from<br>> > 66.nnn.nnn.nnn:500 on eth0 (port=500)<br>> > Nov 23 14:09:54 ams pluto[16661]: | **parse ISAKMP Message:
<br>> > Nov 23 14:09:54 ams pluto[16661]: | initiator cookie:<br>> > Nov 23 14:09:54 ams pluto[16661]: | b3 fb 6d de b8 44 10 98<br>> > Nov 23 14:09:54 ams pluto[16661]: | responder cookie:<br>> > Nov 23 14:09:54 ams pluto[16661]: | 4b c1 9a fa 48 f0 0d 6d
<br>> > Nov 23 14:09:54 ams pluto[16661]: | next payload type: ISAKMP_NEXT_N<br>> > Nov 23 14:09:54 ams pluto[16661]: | ISAKMP version: ISAKMP Version<br>><br>> Though this seems like you received something, so I don't think these runs
<br>> are the same run.<br>><br>> > Nov 23 14:09:54 ams pluto[16661]: packet from 66.nnn.nnn.nnn:500:<br>> > ignoring informational payload, type NO_PROPOSAL_CHOSEN<br>><br>> This is a configuration error between the two endpoints. You will have to
<br>> ask more information from the other end. You can try adding "pfs=no".<br><br><br>Thanks Paul. Applied the changes you suggested, but no luck<br>unfortunately.<br><br>Does the ike= entry require a modp suffix perhaps? (ie
<br>ike=3des-md5-modp1024). If so how would I know which one? I did try the<br>modp1024.<br><br>Any other suggestions you may have are welcome.<br><br>Thanks again,<br>Bas.<br><br>-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>URL: <a href="http://lists.openswan.org/pipermail/users/attachments/20061123/baa6f0ce/attachment-0001.html">http://lists.openswan.org/pipermail/users/attachments/20061123/baa6f0ce/attachment-0001.html
</a><br><br>------------------------------<br><br>Message: 3<br>Date: Thu, 23 Nov 2006 15:31:25 +0800<br>From: kelvin <<a href="mailto:kanava88@gmail.com">kanava88@gmail.com</a>><br>Subject: [Openswan Users] Multiple Roadwarrior Connections
<br>To: <a href="mailto:users@openswan.org">users@openswan.org</a><br>Message-ID:<br> <<a href="mailto:282194e50611222331g43fe876ex55f7e013f429a95b@mail.gmail.com">282194e50611222331g43fe876ex55f7e013f429a95b@mail.gmail.com
</a>><br>Content-Type: text/plain; charset="iso-8859-1"<br><br>Multiple Roadwarrior Connections<br>This mechanism also allows for multiple connections. For instance, if we<br>want a connection from North (also on dynamic IP) to West, we could set up
<br>the following connections:<br>conn west-east<br>left=<a href="http://west.testbed.xelerance.net">west.testbed.xelerance.net</a><br>right=%any<br>rightid=@east<br>leftrsasigkey=0sAQQED1....<br>rightrsasigkey=0sAQV7yV....
<br>auto=add<br>conn west-north<br>left=<a href="http://west.testbed.xelerance.net">west.testbed.xelerance.net</a><br>right=%any<br>rightid=@north<br>leftrsasigkey=0sAQQED1....<br>rightrsasigkey=0sAQ5GP....<br>auto=add<br>
Note that the rightrsasigkey= settings for these two entries are different.<br>The first would contain East's public RSA key, and the second connection<br>would contain North's public RSA key.<br><br>content above is from "publish and building vpn with openswan"
<br>there are two connections ,the parameter "right" of which are %any.<br>Following are MAIN MODE OF Phase 1 exchanges with RSASIG authentication<br>option.<br><br>Initiator Responder<br>
----------- -----------<br> HDR, SA --><br> <-- HDR, SA<br> HDR, KE, Ni --><br> <-- HDR, KE, Nr
<br> HDR*, IDii, [ CERT, ] SIG_I --><br> <-- HDR*, IDir, [ CERT, ] SIG_R<br><br>i see that the id payload(the rightid above) is sent through the last<br>message, then i want to know how can the west determine which connection the
<br>coming roadwarriors belong to when the id payload was not included in the<br>first message .<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <a href="http://lists.openswan.org/pipermail/users/attachments/20061123/6ded2ce2/attachment-0001.html">
http://lists.openswan.org/pipermail/users/attachments/20061123/6ded2ce2/attachment-0001.html</a><br><br>------------------------------<br><br>Message: 4<br>Date: Thu, 23 Nov 2006 13:32:47 -0000 (GMT)<br>From: "Antony Gelberg" <
<a href="mailto:antony@wayforth.co.uk">antony@wayforth.co.uk</a>><br>Subject: Re: [Openswan Users] Ipsec connection doesn't work over PPP<br>To: "Antony Gelberg" <<a href="mailto:antony@wayforth.co.uk">antony@wayforth.co.uk
</a>><br>Cc: <a href="mailto:users@openswan.org">users@openswan.org</a><br>Message-ID:<br> <<a href="mailto:57431.212.183.134.67.1164288767.squirrel@lan.wayforth.co.uk">57431.212.183.134.67.1164288767.squirrel@lan.wayforth.co.uk
</a>><br>Content-Type: text/plain;charset=iso-8859-1<br><br>> Paul Wouters wrote:<br>>> On Thu, 9 Nov 2006, Antony Gelberg wrote:<br>>><br>>>> I have a roadwarrior config on my laptop (roadwarrior-net in the logs),
<br>>>> that works very well from outside the office, via ADSL connections,<br>>>> whether my laptop has a public or static IP.<br>>>><br>>>> However, when I connect to the Internet via my mobile phone (ppp0 in
<br>>>> the<br>>>> logs), everything works apart from openswan. The SA comes up, but I<br>>>> can't ping or do anything else via the gateway.<br>>>><br>>>> I've put a barf at
<a href="http://static.wayforth.co.uk/ipsec_barf">http://static.wayforth.co.uk/ipsec_barf</a>. Hope<br>>><br>>> Some things I see:<br>>> - Enable IP forwarding<br>>> - Disable rp_filter on all interfaces
<br>>> - REcompile kernel with Advanced routing enabled.<br>>><br>><br>> Hi Paul,<br>><br>> Thanks for responding. I don't see why I need to do this when the same<br>> configuration works with another Internet connection
e.g. ADSL via eth0.<br>><br>>> conn roadwarrior-net<br>>> left=<a href="http://82.69.161.254"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 82.69.161.254</a><br>>> leftcert=robert.wayforth.co.uk_cert.pem<br>>> leftsubnet=
<a href="http://192.168.168.0/24"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 192.168.168.0/24</a><br>>> right=%defaultroute<br>>> rightcert=myung.wayforth.local_cert.pem<br>>> auto=start<br>>> pfs=yes<br>>>
<br>>> I am somewhat confused wether I am looking at a client or server barf,<br>>> since you mentioned the client was a phone.<br>>><br>><br>> Little confusion there. The client and server are both Linux-based.
<br>> The phone is used merely for its UMTS modem which manifests as ppp0 on<br>> the client. You are looking at a client barf.<br>><br>>> Can you change left and right. There might be a bug with<br>>> right=%defaultroute
<br>>> does not work as expected.<br><br>No difference.<br><br>>> If this is the server, it would need<br>>> right=%any, not right=%defaultroute.<br>>> You also need auto=add because you cannot initiate to %any, you need to
<br>>> wait<br>>> for them to initiate to you.<br>>><br>>> The logs show no problem, so it could be that ESP packets are being<br>>> filtered.<br>>> Try adding "forceencaps=yes" to roadwarrior-net. It will cause NAT-T to
<br>>> kick<br>>> in and use ESPinUDP packets instead of ESP. Perhaps those are not<br>>> filtered.<br>>><br><br>Unfortunately this didn't help at all.<br><br>Is there any other option than to ask Vodafone? Is anybody using openswan
<br>over a Vodafone data link?<br><br>Antony<br><br><br><br>------------------------------<br><br>_______________________________________________<br>Users mailing list<br><a href="mailto:Users@openswan.org">Users@openswan.org
</a><br><a href="http://lists.openswan.org/mailman/listinfo/users">http://lists.openswan.org/mailman/listinfo/users</a><br><br><br>End of Users Digest, Vol 36, Issue 59<br>*************************************<br></blockquote>
</div><br>