Re: Testing racoon

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

Update on testing racoon on current.

With the recent patches to racoon in current, as far as I can tell racoon is
behaving well. My testing is the configuration of a server for 
L2TP/IPsec VPN
clients such as the built-in Windows, ios, and android clients with one 
or more
NAT devices between the server and the client.

In this configuration, I can test how current kernel and current racoon work
together in the case of NAT traversal in transport mode. I don't see any
significant differences between the behavior of my slightly modified NetBSD
7.1_STABLE system (I plan to update to 7.2 soon) and NetBSD current, except
for the following snippets from the system log file:

I am seeing the No buffer space available message for recvfrom from syslogd:

Jun  7 18:37:44 ave racoon: INFO: respond new phase 2 negotiation: 
192.168.137.5[4500]<=>192.168.1.80[4500]
Jun  7 18:37:44 ave syslogd[147]: recvfrom() unix `/var/run/log': No 
buffer space available

I don't think this is related to to the new racoon patches. It has been
reported and discussed in the current-users mailing list since it has been
appearing in current systems a few moths ago.

The only different behavior is this, which occurred after restarting racoon
too many times (I restarted racoon many times to test different racoon
configurations):

Jun  7 19:06:40 ave racoon: INFO: racoon process 23165 shutdown
Jun  7 19:06:40 ave racoon: INFO: @(#)ipsec-tools cvs 
(http://ipsec-tools.sourceforge.net)
Jun  7 19:06:40 ave racoon: INFO: @(#)This product linked OpenSSL 
1.1.0h  27 Mar 2018 (http://www.openssl.org/)
Jun  7 19:06:40 ave racoon: INFO: Reading configuration from 
"/etc/racoon/racoon.conf"
Jun  7 19:06:40 ave /netbsd: [ 22648.3891806] key_sendup0: couldn't send 
PF_KEY message to the socket
Jun  7 19:06:40 ave racoon: WARNING: failed to register ESP (No buffer 
space available)
Jun  7 19:06:40 ave racoon: WARNING: failed to register IPCOMP (No 
buffer space available)
Jun  7 19:06:40 ave racoon: ERROR: Must get supported algorithms list 
first.
Jun  7 19:06:40 ave racoon: ERROR: /etc/racoon/racoon.conf:107: "," 
algorithm AES not supported by the kernel (missing module?)
Jun  7 19:06:40 ave racoon: ERROR: fatal parse failure (1 errors)
Jun  7 19:06:40 ave /netbsd: [ 22648.3891806] key_sendup0: couldn't send 
PF_KEY message to the socket
Jun  7 19:08:12 ave racoon: INFO: @(#)ipsec-tools cvs 
(http://ipsec-tools.sourceforge.net)
Jun  7 19:08:12 ave racoon: INFO: @(#)This product linked OpenSSL 
1.1.0h  27 Mar 2018 (http://www.openssl.org/)
Jun  7 19:08:12 ave racoon: INFO: Reading configuration from 
"/etc/racoon/racoon.conf"
Jun  7 19:08:12 ave /netbsd: [ 22739.9291809] key_sendup0: couldn't send 
PF_KEY message to the socket
Jun  7 19:08:12 ave racoon: WARNING: failed to register AH (No buffer 
space available)
Jun  7 19:08:12 ave racoon: WARNING: failed to register ESP (No buffer 
space available)
Jun  7 19:08:12 ave racoon: WARNING: failed to register IPCOMP (No 
buffer space available)
Jun  7 19:08:12 ave racoon: ERROR: failed to regist any protocol.
Jun  7 19:09:03 ave syslogd[147]: Exiting on signal 15
Jun  7 19:09:03 ave syslogd[147]: last message repeated 2 times
Jun  7 15:10:06 ave syslogd[147]: restart
Jun  7 15:10:06 ave /netbsd: [   1.0000000] Copyright (c) 1996, 1997, 
1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,

The problem was fixed by a reboot of the whole system, and then racoon
started normally again.

I think it would be great to get racoon2 working with IKEv2, so that we 
could
use NetBSD as a server for built in Windows, ios, and android IKEv2 VPN
clients. From what I have read so far from Windows support pages and some
sample configurations of Strongswan IKEv2 VPN servers, it appears those
clients still use L2TP tunnels, but I think also it is IPsec tunnel 
mode, not
transport mode as in the case of L2TP/IPsec clients that use IKEv1. 
According to
RFC 3948, fixing NAT-T in IPsec tunnel mode does not require the 
checksum fix
but instead requires careful verification of the IP addresses of the 
tunnelled
traffic.

I plan on experimenting with the pkgsrc racoon2 with NetBSD current. We
might need to verify the kernel can implement RFC 3948 for tunnel mode.
I think it is working now for transport mode, but not yet optimal because of
the way we are fixing the tcp/udp checksums.

Chuck


On 05/31/2018 08:47 PM, Christos Zoulas wrote:
> In article <852df1f1-109d-2e06-2966-c855a822c543%gmail.com@localhost>,
> Chuck Zmudzinski  <frchuckz%gmail.com@localhost> wrote:
> > I see some new recent commits for racoon in source-changes. Now that I
> > have a functioning environment on the current kernel, I plan on creating
> > a testing environment for a full current system so I can test the
> > current racoon. I will let you know if there are any problems.
> I've also started working on racoon2 and made the pkgsrc code compile again.
> I've only been testing ikev1 so far but it does not yet work. Perhaps we
> should make a git repository and whip it to shape...
>
> christos