Hey, On 11 Sep 2014, at 13:05, Lennart Sorensen <[email protected]> wrote
> We switched to netkey for our use some years ago when we found a > particular use case we couldn't get klips to handle (running the default > route through the ipsec tunnel). If I understand correctly, this can be done by having a 0.0.0/0 remote subnet. Do you mean something else? > Also the klips interfaces and keeping > them bound to other interfaces that could come and go (ppp interfaces > for example) was a pain to keep track of to know when ipsec had to be > restarted to keep things working. Yes, this is a rather a nasty limitation. I *think* (might be wrong) that this is more an integration problem between the startup glue scripts and pluto/klips vs a real klips problem. Ie. you could probably work around this by making your own action mechanism that add/removed the ipsec interfaces without doing a full restart. But great if netkey makes this a non problem. > The hard coded limit on the number > of interfaces that could be used to handle ipsec traffic at a time was > also an annoyance. Yeah, we crank up the limit but it is still hardcoded and not changeable at even module load time AFAIK. > klips made firewalling a bit more obvious, but once > we looked at how to do firewalling for netkey it wasn't hard and there > was no obvious benefit to using klips for us. I played with using some of the special netfilter matches for netkey, and I know it can be done… it’s just “weirder”. I believe, for instance, that under ntetkey libpcap will se both the cleartext and the cyphered packets…. > If there are any benefits > to klips I don't know what they are. Hopefully our developer friends > will fill us in on that. Yes indeed. :) -- Lawrence Manning Founder and Developer [email protected] Smoothwall Ltd Phone: +44 (0) 8701 999500 www.smoothwall.net Smoothwall Limited is registered in England, Company Number: 4298247 and whose registered address is 1 John Charles Way, Leeds, LS12 6QA United Kingdom This email and any attachments transmitted with it are confidential to the intended recipient(s) and may not be communicated to any other person or published by any means without the permission of Smoothwall Limited. Any opinions stated in this message are solely those of the author. _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
