[Openswan Users] Openswan <-> SonicWall TZ107 Roadwarrior
David L. Cathey
davidc at montagar.com
Thu Nov 29 08:42:21 EST 2007
On the SonicWall RoadWarrior to openswan server using PSK - I gave up.
It seems that the SonicWall would always send Info Exchange packet
unencrypted after the IKE sequence, and openswan didn't seem to think
that was a good idea. After several days of trying things out, I just
gave up on it. Seems there was always something that refused to work.
So, switched to using certificates I created with my own CA. Got it
working in a couple of hours.
Since I wanted the SonicWall to pass all data through the VPN
(everything stays "inside"), I had the SonicWall configured to do that.
This made openswan unable to find the right connection until I set
"leftsubnet=0/0" in the conn settings. Then it worked.
In the SonicWall, you have to set up the DN as "/C=US/ST=Texas..."
rather than the "C=US, ST=Texas..." format you see via OpenSwan, or use
alternate subjects when you generate the CSR's. The SonicWall wants the
certificate in PKCS#12, so create a certificate as normal, then use
openssl to convert it.
Thanks for all the help and suggestions!
________________________________________________________________________
> From: David L. Cathey [mailto:davidc at montagar.com]
> Sent: November 26, 2007 8:41 PM
> To: petermcgill at goco.net
> Subject: RE: [Openswan Users] Openswan <-> SonicWall TZ107
> Roadwarrior
>
>
>
> On Mon, 2007-11-26 at 09:51 -0500, Peter McGill wrote:
> > Can you set the id in the shorewall or does the shorewall have a static ip?
> > The id must match the id used by the shorewall.
> > The default is to set to match the ip address but you can't do that with dynamic ip.
>
> I've set that before, and it correctly finds the PSK. Figured
> out it needs to be aggressive mode to work. However,
> refine_host_connection() is unable to find the matching
> connection to complete the tunnel. From the log (with
> plutodebug=control,controlmore. It's 2.4.9, which a couple of
> DBG() changes so I can see more of what's going on. Namely
> the output of match_id() to display the kind of peer and why
> it's failing the test.
>
> So far, it fails getting the connection right since it's
> confused between the ID types of FQDN (openswan side) and
> USER_FQDN (Sonicwall side).
>
> Nov 26 14:22:21 iptables pluto[4381]: | refine_connection: starting with Sonic168
> Nov 26 14:22:21 iptables pluto[4381]: | started looking for secret for @TSP168->@Sonic168 of kind PPK_PSK
> Nov 26 14:22:21 iptables pluto[4381]: | actually looking for secret for @TSP168->@Sonic168 of kind PPK_PSK
> Nov 26 14:22:21 iptables pluto[4381]: | 1: compared PSK @Sonic168 to @TSP168 / @Sonic168 -> 2
> Nov 26 14:22:21 iptables pluto[4381]: | 2: compared PSK @TSP168 to @TSP168 / @Sonic168 -> 6
> Nov 26 14:22:21 iptables pluto[4381]: | best_match 0>6 best=0x842b0a0 (line=17)
> Nov 26 14:22:21 iptables pluto[4381]: | concluding with best_match=6 best=0x842b0a0 (lineno=17)
> Nov 26 14:22:21 iptables pluto[4381]: | match_id a=@Sonic168, kind=3
> Nov 26 14:22:21 iptables pluto[4381]: | b=@Sonic168, kind=2
> Nov 26 14:22:21 iptables pluto[4381]: | results fail
> Nov 26 14:22:21 iptables pluto[4381]: | trusted_ca called with a=(empty) b=(empty)
> Nov 26 14:22:21 iptables pluto[4381]: | refine_connection: checking Sonic168 against Sonic168, best=(none) with match=0(id=0/ca=1/reqca=1)
> Nov 26 14:22:21 iptables pluto[4381]: | find_host_pair: comparing to xx.xx.79.53:500 xx.xx.118.247:500
> Nov 26 14:22:21 iptables pluto[4381]: | find_host_pair: comparing to xx.xx.79.53:500 0.0.0.0:500
> Nov 26 14:22:21 iptables pluto[4381]: | find_host_pair_conn (refine_host_connection): xx.xx.79.53:500 %any:500 -> hp:Sonic168
> Nov 26 14:22:21 iptables pluto[4381]: | match_id a=@Sonic168, kind=3
> Nov 26 14:22:21 iptables pluto[4381]: | b=@Sonic168, kind=2
> Nov 26 14:22:21 iptables pluto[4381]: | results fail
> Nov 26 14:22:21 iptables pluto[4381]: | trusted_ca called with a=(empty) b=(empty)
> Nov 26 14:22:21 iptables pluto[4381]: | refine_connection: checking Sonic168 against Sonic168, best=(none) with match=0(id=0/ca=1/reqca=1)
> Nov 26 14:22:21 iptables pluto[4381]: "Sonic168"[1] xx.xx.118.247 #898: no suitable connection for peer '@Sonic168'
>
> So, it's in refine_connection, but match_id() is failing since
> the peer kind's aren't the same. I guess I need to Sonicwall
> to use FQDN or convince openswan that the leftid is a user
> FQDN.
>
> > Also if you can turn on pfs on both sides, that will result in a more secure connection.
>
> Agreed - but I'd like to get something working first!
>
> > Peter McGill
> >
> >
> > > -----Original Message-----
> > > From: users-bounces at openswan.org
> > > [mailto:users-bounces at openswan.org] On Behalf Of David L. Cathey
> > > Sent: November 23, 2007 5:59 PM
> > > To: users at openswan.org
> > > Subject: [Openswan Users] Openswan <-> SonicWall TZ107 Roadwarrior
> > >
> > > I'm trying to set up a SonicWall TZ107 as a Roadwarrior against an
> > > openswan server (Fedora 6, openswan 2.4.9 built from source).
> > >
> > > Sonic168.conf:
> > > conn Sonic168
> > > type=tunnel
> > > auto=add
> > > auth=esp
> > > pfs=no
> > > authby=secret
> > > keyingtries=1
> > > left=66.60.79.53 #
> > > leftid=@TSP168 # Local information
> > > leftsubnet=192.168.2.0/24
> > > leftnexthop=%defaultroute
> > > right=%any # Remote information
> > > #rightid=@Sonic168 #
> > > rightsubnet=192.168.168.0/24 #
> > > esp=3des-md5
> > > ike=3des-md5
> > > keyexchange=ike
> > >
> > > ipsec.secrets:
> > > @TSP168 %any : PSK "CominationForMyLuggage" # Not the real PSK!
> > >
> > > This gets me to (several of these from ipsec auto --status):
> > > 000 #nnn: "Sonic168"[1] 72.64.118.247:500 STATE_MAIN_R3 (sent MR3,
> > > ISAKMP SA established); EVENT_SA_REPLACE in 2596s; nodpd
> > >
> > > I end up with openswan sending INVALID_ID_INFORMATION back to the
> > > SonicWall. The SonicWall log also shows this(Start Quick Mode (Phase
> > > 2), followed by Received notify: INVALID_ID_INFO).
> > >
> > > If I change the config to uncomment the rightid, it never gets a
> > > connection (visible with plutodebug="all"):
> > > concluding with best_match=6 best=0x812fb360 (lineno=29)
> > > match_id a=72.64.118.247
> > > b=@Sonic168
> > > results fail
> > > Since it thinks Sonic168 is a of kind ID_FQDN, and will not wildcard
> > > with the connection, even though right=%any. Unless I just hack id.c
> > > and have match_id() return true anyway (but that would be bad).
> > >
> > > Can this work, since I can't see what I'm missing here...
> > >
> > > --
> > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> > > - - - - -
> > > David L. Cathey |Inet: davidc at montagar.com
> > > Montagar Software, Inc. |Fone: (972)-423-5224
> > > P. O. Box 260772, Plano, TX 75026 |http://www.montagar.com
> > >
> > > _______________________________________________
> > > Users at openswan.org
> > > http://lists.openswan.org/mailman/listinfo/users
> > > Building and Integrating Virtual Private Networks with Openswan:
> > > http://www.amazon.com/gp/product/1904811256/104-3099591-294632
> > > 7?n=283155
> >
> >
> --
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> David L. Cathey |Inet: davidc at montagar.com
> Montagar Software, Inc. |Fone: (972)-423-5224
> P. O. Box 260772, Plano, TX 75026 |http://www.montagar.com
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
David L. Cathey |Inet: davidc at montagar.com
Montagar Software, Inc. |Fone: (972)-423-5224
P. O. Box 260772, Plano, TX 75026 |http://www.montagar.com
More information about the Users
mailing list