<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.12.1">
</HEAD>
<BODY>
On Thu, 2006-11-23 at 09:17 -0500, Peter McGill wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">> > > - SonicWALL VPN</FONT>
<FONT COLOR="#000000">> > > - ESP 3DES HMAC MD5 (IKE)</FONT>
<FONT COLOR="#000000">> > > - XAUTH authentication is not required.</FONT>
<FONT COLOR="#000000">> </FONT>
<FONT COLOR="#000000">> > > esp=3des-md5</FONT>
<FONT COLOR="#000000">> > > ike=3des-md5</FONT>
<FONT COLOR="#000000">> </FONT>
<FONT COLOR="#000000">> > > Nov 23 14:09:54 ams pluto[16661]: packet from 66.nnn.nnn.nnn:500:</FONT>
<FONT COLOR="#000000">> > > ignoring informational payload, type NO_PROPOSAL_CHOSEN</FONT>
<FONT COLOR="#000000">> > </FONT>
<FONT COLOR="#000000">> > This is a configuration error between the two endpoints. You will have to</FONT>
<FONT COLOR="#000000">> > ask more information from the other end. You can try adding "pfs=no".</FONT>
<FONT COLOR="#000000">> </FONT>
<FONT COLOR="#000000">> Does the ike= entry require a modp suffix perhaps? (ie</FONT>
<FONT COLOR="#000000">> ike=3des-md5-modp1024). If so how would I know which one? I did try the modp1024. </FONT>
<FONT COLOR="#000000">Your probably on the right track, keep the pfs=no, as Paul suggested, it will still accept pfs</FONT>
<FONT COLOR="#000000">if the other end requests it, but does not require it, so it's the best compatibility mode.</FONT>
<FONT COLOR="#000000">You could also ask the other admin if he's using it or not. Perfect Forward Secrecy is the</FONT>
<FONT COLOR="#000000">full name.</FONT>
<FONT COLOR="#000000">I would also ask the other admin which modp setting he's using, probably called DH</FONT>
<FONT COLOR="#000000">(or Diffie-Hellman) Group 2 (1024) or 5 (1536), there are other groups, but these two are</FONT>
<FONT COLOR="#000000">the most common ones implemented and therefore probably best for vendor interrop.</FONT>
<FONT COLOR="#000000">If he's using Group 1 (768 I think), he'll have to change it, openswan doesn't support it for</FONT>
<FONT COLOR="#000000">the same reason as Single DES, it's week and insecure.</FONT>
<FONT COLOR="#000000">You would specify them as you did above, ike=3des-md5-modp1024, or ...-modp1536.</FONT>
</PRE>
</BLOCKQUOTE>
Thanks very much Peter. We may have something here. When I tried to setup the connection a couple of weeks for the first time, the VPN server was still set to the old DES algorithm. I had to recompile OpenSwan with a WEAK switch (or something like that) to get that to work. In the end I got it to go past Phase 1 and yes you are right, my setting then was ike=des-md5-modp768. Since I did not get past phase 2, I got in contact with this mailing list and most of the responses were "don't use DES, but 3DES". After that am still getting nowhere and in fact don't get past Phase 1 now. I asked the system administrator to change to 3DES, which he kindly did. I doubt if he changed the group and that most likely is the cause.<BR>
<BR>
Which group should I advise him to change to? Group 2 or 5?<BR>
<BR>
Even though OpenSwan does not support DES and Group 1, if I recompile it again with the "WEAK" switch, will ike=3des-md5-modp768 work? I realize it is better to change the group, but if for some reason that can not/will not be done I need an alternative.<BR>
<BR>
Will report back if I hear something. I believe it is the ThanksGiving holiday weekend in the US, so it may take a couple of days before I get a response from the sysadmin.<BR>
<BR>
Thanks again,<BR>
Bas.<BR>
<BR>
<BR>
<BR>
</BODY>
</HTML>