[Openswan Users] Openswan <-> SonicWall TZ107 Roadwarrior
David L. Cathey
davidc at montagar.com
Tue Nov 27 12:30:01 EST 2007
On Tue, 2007-11-27 at 09:31 -0500, Peter McGill wrote:
>
> Well you turn on aggressive mode by adding this to the conn...
> aggrmode=yes
> It's off by default because it makes the connection less secure, so
> it's better to turn off on both sides.
> I'm forwarding back to the list to see if anyone else knows what's
> happening with your FQDN mismatch.
Since the SonicWall is in Roadwarrior, the openswan server needs
aggrmode=yes in order to find the right PSK. I've got the SonicWall
Unique Identifier set as "Name at Sonic168", with matching Name at Sonic168 in
the conn section, and updated ipsec.secrets to match. Everyone seems to
be using ID_USER_FQDN now and finding the right PSK. For some reason,
the SonicWall really wants to use kind USER_FQDN when it initiates the
connection.
So far, all that appears to work as expected/desired.
Now the problem I get is: "Information Exchange message must be
encrypted" in STATE_AGGR_R1.
I can see an ISAKMP_XCHG_INFO message from the SonicWall, which is
appearently unencrypted, or not encrypted properly.
There appears to be an XAUTH message coming the SonicWall (I can see
that in the pluto debug info), but I don't have XAUTH enabled on the
SonicWall that I can tell, either at the GroupVPN or the specific VPN
definition.
>
> Peter McGill
>
>
>
> ______________________________________________________________
> 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