tech-net archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Strongswan on NetBSD and pfkey extensions
Greg Troxel <gdt%lexort.com@localhost> writes:
> Valtteri Vuorikoski <vuori%notcom.org@localhost> writes:
>
>> I have been testing the Strongswan IKE daemon on NetBSD 9.0, and the
>> good news is that it compiles and works (with a few caveats) with a
>> couple of #ifdefs to the pfkey module.
>
> That's good to hear. Asssuming that belongs in pkgsrc, it would be great
> to get that (and patches) into wip.
Yeah, I was thinking about that earlier. The problem is that Strongswan
is currently a packaging nightmare. It has two configuration frontends
and you need to select one at startup: the legacy ipsec.conf one (that
no one should use but probably a lot of people want to use) or the new
swanctl one (which is a lot saner but probably few people know how to
use it). Furthermore, using the swanctl frontend pretty much requires a
service supervisor such as systemd or daemontools.
I'll try to gather strength to deal with that mess after dealing with
the functional issues. Shipping the ipsec.conf frontend may be the path
of least resistance. Current Linuxen seem to usually split Strongswan
into multiple packages to deal with the choice.
>> Caveats:
>> * Only IPv6 transport mode with IKEv2 tested so far. I might give v4/v6 tunnel
>> modes a spin later on.
>> * IPv6 source address selection incorrectly uses link-local address
>> as source unless source is manually set in config, but I think this is broken
>> on all pfroute platforms: proper address selection code only exists
>> in the netlink module.
>
> Anything you can fix upstream is even better.
I'm planning to put together a simple patch for the pfroute source
address issue and open a ticket upstream since it has been annoying me
on Darwin too for a while.
If I manage to get that working, I'll try to push the pfkey ifdefs
upstream too. It's entirely possible that those will have to stay around
as pkgsrc patches though, since upstream may not want to take
responsibility for NetBSD-specific bits without a definite maintainer
commitment.
-vuori
Home |
Main Index |
Thread Index |
Old Index