Re: racoon2 IKEv1 is working!

[Chuck Zmudzinski <frchuckz%gmail.com@localhost>]

On 06/19/2018 11:06 PM, Christos Zoulas wrote:
> In article <e237c437-5fac-30f9-c036-5923bc71bfbb%gmail.com@localhost>,
> Chuck Zmudzinski  <frchuckz%gmail.com@localhost> wrote:
> > -=-=-=-=-=-
> >
> > I have been experimenting with racoon2 since I learned of the new
> > patches to make it compile successfully on current.
> >
> > It is possible to make an IKEv1 L2TP/IPSec connection through a NAT
> > device from a Windows 10 client to a NetBSD current VPN server starting
> > with the recent patches by Christos to the current branch of
> > pkgsrc/security/racoon2 package and adding one more small patch (apply
> > after extracting and applying existing patches for the package but
> > before building and installing):
> >
> > --- pskgen/pskgen.in.orig    2005-09-16 06:52:20.000000000 +0000
> > +++ pskgen/pskgen.in
> > @@ -59,8 +59,8 @@ EOD
> > Â Â Â Â  exit 0;
> > Â }
> >
> > -require 'getopts.pl';
> > -do Getopts('rs:o:di:he:d');
> > +require Getopt::Std;
> > +Getopt::Std::getopts('rs:o:di:he:d');
> > Â $output = '-';
> > Â $output = $opt_o if ($opt_o);
> I will apply it.
>
> > Racoon2 is still rudimentary, but it is now functional (see attached log
> > snippets showing a successful connection below). Next is to try and get
> > it working as a server for IKEv2 connections. This would be a BSD
> > licensed solution for IKEv2 that racoon does not have.
> We should make a list of the stuff that is missing.
I plan on creating a TODO file for the racoon2 package today
> > It is not necessary to include the little patch shown in Christos' June
> > 13 message to iked/isakmp.c:751 to get it functional. But to fully
> > install the package and to be able to generate a pre-shared key file
> > that is compatible with racoon2, it was necessary to update the pskgen
> > perl script to a supported version of perl5's getopts function, as shown
> > in the aforementioned patch.
> I will apply that.
>
> > It was also necessary to tweak the configuration files quite a lot, and
> > I plan on patching the sample configuration files so they are closer to
> > what actually works in today's world and making them available in the
> > near future.
> Yes, I found that too; I had too comment out:
> 	kmp_sa_lifetime_time 600 sec;
>
> We should update the default config files to sane defaults, and also
> make the configuration mismatches print better diagnostics in debug mode.
> I have patches for that.
Better diagnostics would be helpful. I bumped the value of 
kmp_sa_lifetime_time up to 28800 sec (8 hours) in the default.conf file 
which is the default setting Windows 10 uses and that worked with 
Windows 10.
> > Some of the gotchas that need to be solved to get an IKEv1 connection
> > working using racoon2:
> >
> > 1) If you are using a pre-shared key for the phase 1 authentication, you
> > need to generate it with the pskgen perl script that is installed with
> > the package and usable after applying the aforementioned patch. Without
> > doing this and trying to create the psk file with an editor such as vi,
> > there will be a newline character appended that invalidates the key. You
> > can use pskgen to strip away the newline character so the key will
> > exactly match the peer's key.
> I think I am going to make the parser eat the newline; this is stupid.
Yes.
> > 2) The sample configurations don't have anything close enough to what
> > will work for a transport mode IKEv1 connection to a modern client, even
> > if NAT traversal is not needed. The proposals of the samples and default
> > configuration do not result in successful matches with the proposals of
> > a default Windows 10 client, so those proposals need to be tweaked in
> > the configuration files to more closely match what modern clients will
> > accept.
> Right.
>
> > 3) For NAT traversal in transport mode, which is the mode the built-in
> > Windows and IOS L2TP/IPsec clients use, in addition to turning on port
> > 4500 in racoon2.conf, as mentioned in the racoon2.conf sample
> > configuration file, it is necessary to add selectors for the NAT
> > original addresses to the configuration.
> Ok, we should add this to the exampless
I will do some testing today to see exactly what is needed here and will 
share patches that work in my environment.
> > 4) I have not yet tested multiple connections or roaming connections
> >from any IP address, but according to the documentation it should be 
> > able to be configured for the "road warrior" scenario. Also, I noticed
> > the hook scripts were not working as expected and when disconnecting
> > only the outgoing phase 2 security association was deleted and I had to
> > delete the incoming phase 2 security association manually using the
> > setkey tool. I was able to use the ph1-up script to start the L2TP
> > service, but I had to start it from the ph1-up script instead of from a
> > script in the ph1-up.d directory. I also had to manually stop the L2TP
> > service after disconnecting.
> >
> > It looks like Christos' recent patches successfully interface with the
> > new openssl 1.1 API on NetBSD current which appear to be incompatible
> > with openssl 1.0.x on NetBSD 7, so this package will not work on NetBSD
> > 7. It looks like NetBSD 8 does not have the new API yet so for now I
> > think this only works on NetBSD current.
> So this is tricky, and too late in the game to do something this
> intrusive.  It is simpler to pull up the compat changes from head:
> In current the openssl.old headers support the new API so we just
> need to pull them up to -8 and test them...
>
> > Are there plans to upgrade NetBSD 8 to the new openssl? If not, it might
> > be possible to get racoon2 working on NetBSD 7/8 by reversing some of
> > the recent patches that were added to support the new openssl on NetBSD
> > current.
> That would be difficult right now. It is better to pull up the modified
> all openssl headers that support both 1.1 and 1.0. I've submitted the changes
> to the openssl folks so hopefully the next 1.0 release will be forward
> compatible.
>
> Thanks for working on this. I think it would be good to either import this
> in base eventually, but for now perhaps putting on github will help to
> have many people work on it to improve it?
If you want I can open a free github account (I don't have one and maybe
this is a good time for me to open one so we can share our work there).
What is the best way? Make a git repo out of the pkgsrc/security/racoon2
directory without the work directory, or with the work directory, or just
the work directory without the pkgsrc/security/racoon2 directory?

Chuck
> christos