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