Testing racoon

Discussion:

Testing racoon

(too old to reply)

Chuck Zmudzinski

2018-05-31 20:30:52 UTC

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.

Thanks,

Chuck Zmudzinski

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Christos Zoulas

2018-06-01 00:47:03 UTC

Permalink

Post by Chuck Zmudzinski
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

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Chuck Zmudzinski

2018-06-13 15:23:25 UTC

Permalink

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

Post by Christos Zoulas

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Christos Zoulas

2018-06-13 16:22:19 UTC

Permalink

On Jun 13, 11:23am, ***@gmail.com (Chuck Zmudzinski) wrote:
-- Subject: Re: Testing racoon

Thanks for all the feedback and testing!

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

There might be still an issue with buffer space in current, but we explicitly
bumped the limits for syslogd and kernel sockets. I am not sure what went
on here and the ipsec related socket buffers got full.

| 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.
|

Yes, I'd like that very much too. I got it to compile as I mentioned, but
did not have time to work on it more. Perhaps we should just move it to
a github repository or something and work on it together.

christos

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Chuck Zmudzinski

2018-06-13 18:20:49 UTC

Permalink

I saw your comment, Buck Rogers, when you made the racoon2
package compile again in the 25th century!

I will have some time to debug it and try to find out why IKEv1 isn't
working in the next few weeks. It will probably take me a little
while to learn how to setup the configuration files in racoon2.

I looked at the racoon2 project page. The most recent version is
8 years old. Oh My!

Chuck

Post by Christos Zoulas
-- Subject: Re: Testing racoon
Thanks for all the feedback and testing!
| The problem was fixed by a reboot of the whole system, and then racoon
| started normally again.
There might be still an issue with buffer space in current, but we explicitly
bumped the limits for syslogd and kernel sockets. I am not sure what went
on here and the ipsec related socket buffers got full.
| 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.
|
Yes, I'd like that very much too. I got it to compile as I mentioned, but
did not have time to work on it more. Perhaps we should just move it to
a github repository or something and work on it together.
christos

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Roy Marples

2018-06-13 20:26:28 UTC

Permalink

Looking through our sources for racoon (and assuming racoon2 behaves
similar here), racoon will always set it's own view on how big the
receive buffer should be. See pfkey_set_buffer_size().

So the default socket buffer sizes are not guilty here.

I suspect the error Chuck is seeing was fixed last week by this commit:
https://mail-index.netbsd.org/source-changes/2018/06/06/msg095775.html

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Chuck Zmudzinski

2018-06-14 16:20:04 UTC

Permalink

Post by Roy Marples

Looking through our sources for racoon (and assuming racoon2 behaves
similar here), racoon will always set it's own view on how big the
receive buffer should be. See pfkey_set_buffer_size().
So the default socket buffer sizes are not guilty here.
https://mail-index.netbsd.org/source-changes/2018/06/06/msg095775.html
Roy

It could have been fixed by that - I was testing a snapshot from a
couple of days before that commit.
I am now updated to a snapshot from yesterday and will presume it is fixed.

Thanks,

Chuck

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de