Bug 128030 - [ipsec] Enable IPSec in GENERIC kernel configuration
Summary: [ipsec] Enable IPSec in GENERIC kernel configuration
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: conf (show other bugs)
Version: CURRENT
Hardware: Any Any
: Normal Affects Many People
Assignee: George V. Neville-Neil
Keywords: feature, patch
Depends on:
Blocks: 212018
  Show dependency treegraph
Reported: 2008-10-12 12:10 UTC by Lionel Fourquaux
Modified: 2019-05-12 10:32 UTC (History)
21 users (show)

See Also:
koobs: mfc-stable11?
koobs: mfc-stable10?
koobs: mfc-stable9?


Note You need to log in before you can comment on or make changes to this bug.
Description Lionel Fourquaux 2008-10-12 12:10:00 UTC
I believe there is a clear case for enabling IPsec in the GENERIC kernel:
 * freebsd-update does not (and cannot) patch custom kernels, making it harder to maintain an IPsec-enabled FreeBSD environment;
 * AFAIK, the IPsec implementation in FreeBSD is not experimental any more;
 * AFAIK, there is no reason nowadays to try to squeeze the kernel in the smallest possible file, a few more kilobytes won't cause harm;
 * IPsec in more and more an "expected" part of a full-featured network stack (it's part of the IPv6 spec, and it's available out-of-the box in other OSes, be it OpenBSD, Linux, or even Windows).
Unless there is an overwhelming reason not to do it, having IPsec support (disabled by default, but with no need for a custom kernel build) looks like a good idea.


According to the handbook, this require adding these lines to the GENERIC conf file.

options   IPSEC        #IP security
device    crypto

Bug report kern/97057 suggests that IPSEC_FILTERGIF is also required for pf to work correctly.
How-To-Repeat: Try to enable IPsec using a GENERIC kernel.
Comment 1 Gavin Atkinson freebsd_committer freebsd_triage 2008-10-18 17:55:14 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-net

Over to maintainer(s) for consideration
Comment 2 Bjoern A. Zeeb freebsd_committer 2009-01-30 20:10:45 UTC

the problem here is that enabling IPsec adds overhead to the entire
IPv4/v6 network stack handling.

A lot of people are currently working on performnce optimizations for
all kinds of different setups. All those would be hurt if IPSEC would
be on by default and they wouldn't need it. That's all kinds of
various ISP server business for example.

If we want to enable IPSEC by default on GENERIC the criteria to fix
is "it must not measurably add up to processing times/reduce pps/.."
if the connections do not use it.


Bjoern A. Zeeb                      The greatest risk is not taking one.
Comment 3 Bjoern A. Zeeb freebsd_committer 2009-01-30 23:27:32 UTC
State Changed
From-To: open->suspended

Susepend until enough work on fixing IPsec and performance 
wise integration into the main network stack code flow 
has been/can be done. 

Comment 4 Bjoern A. Zeeb freebsd_committer 2009-01-30 23:27:32 UTC
Responsible Changed
From-To: freebsd-net->bz

I'll take it so I'll have it in mind.
Comment 5 Bjoern A. Zeeb freebsd_committer 2014-05-18 06:02:19 UTC
Responsible Changed
From-To: bz->gnn

I shall not use bugzilla (at least until we will have a CLI).
Comment 6 c_dornig 2015-03-10 17:24:38 UTC
Hi *,

I vote for an enabled IPSEC option in GENERIC too.
I would appreciate it very much to have this option.

Or is it maybe possible to have it as an loadable module ?
It would make the life easier with a freebsd ipsec client software running (like security/ike)

Comment 7 Matt Hamilton 2015-06-30 15:50:01 UTC
I too would also like it in GENERIC (or a loadable module if possible). Having to compile a custom kernel just to get IPSEC is a pain. I've just run freebsd-update on a system and now lost my IPSEC capability :( So I have to choose between either having IPSEC and having to do source upgrades all the time, or not having ISPEC and use the binary update system. 


Comment 8 sf(jungleboogie) 2015-06-30 15:55:56 UTC
I'd like to request ipsec be enabled in generic.

The depends on is the documentation:
Comment 9 Mark Felder freebsd_committer 2015-06-30 16:20:53 UTC

You'll catch more flies with IPSEC honey

I understand there are known performance effects of enabling this, so I think it should be considered a priority to minimize/correct the deficiencies.
Comment 10 George V. Neville-Neil freebsd_committer 2015-06-30 16:33:22 UTC
I am actively looking into this.  I will start a round of tests and then see what we need to do to make this work for 11.
Comment 11 Martin 2015-07-04 07:40:31 UTC

IPSEC should really be part of the GENERIC kernel.
Comment 12 commit-hook freebsd_committer 2015-07-04 17:37:47 UTC
A commit references this bug:

Author: gnn
Date: Sat Jul  4 17:37:03 UTC 2015
New revision: 285142
URL: https://svnweb.freebsd.org/changeset/base/285142

  Enable IPSEC in all GENERIC kernels.

  Universe and kernel build tests passed 4 July 2015

  PR:		128030
  Sponsored by:	Rubicon Communications (Netgate)

Comment 13 Kubilay Kocak freebsd_committer freebsd_triage 2015-07-05 00:37:40 UTC
Thank you George!

Are merges to stable/10 and stable/9 possible?

Please MFC if so. If not, please set mfc-* flag values to - with a comment so that users know why not, thank you!
Comment 14 Kubilay Kocak freebsd_committer freebsd_triage 2015-11-08 14:38:45 UTC
Pending MFC to stable/9 & stable/10
Comment 15 Kamil Choudhury 2015-11-08 14:58:41 UTC
First of all: thanks so much for doing this. 

Is there any chance we could MFC this to 9/STABLE and 10/STABLE?
Comment 16 Nick B 2015-12-19 01:41:33 UTC
Any update on the MFC to 10.x?
Comment 17 Mark Felder freebsd_committer 2015-12-31 15:34:43 UTC
(In reply to Nick B from comment #16)

I suspect we won't see it MFC to 10.x unless the performance impact is deemed acceptable. It's supposedly minor, but the further improvements to make IPSEC have a negligible penalty likely cannot be MFC'd to 10.x.

gnn should have more details as he was involved in the actual analysis of the impact.
Comment 18 Nick B 2015-12-31 19:58:58 UTC
(In reply to Mark Felder from comment #17)
Mark, appreciate your response on this.  That said, it is very impractical to have to compile a new kernel in order to have IPSEC support, a feature FreeBSD in 2015 (and now 2016) should support natively without hassle.  

Is there no way to have it enabled in kernel, but disabled by default in a sysctl OID of some kind if there is a performance hit?  That way, the user could just turn on the IPSEC network code via sysctl.  Also, what kind of hit are we talking on a modern server?
Comment 19 Ed Maste freebsd_committer 2016-01-04 03:11:14 UTC
> Is there no way to have it enabled in kernel, but disabled by default in a sysctl OID of some kind if there is a performance hit?

Yes, that is exactly the work that was done in -CURRENT to allow it to be compiled in by default,  but have a minimal effect on performance unless turned on. I'm not sure how difficult the MFC would be.
Comment 20 Darryn Nicol 2016-08-20 14:23:03 UTC
I'm not sure if this is would require a separate request but I'd like to see IPSEC_NAT_T enabled in the GENERIC kernel also. I use my laptop as a mobile IPSEC client and have to deal with connecting through natted IPs. Currently I need to run a custom kernel just to add IPSEC and IPSEC_NAT_T support and it makes keeping my system up to date somewhat cumbersome.
Comment 21 Kubilay Kocak freebsd_committer freebsd_triage 2016-08-20 14:45:05 UTC
(In reply to geezabiscuit2 from comment #20)

This issue has already been committed to head and is pending MFC (see comment 13, comment 14, comment 16)

I'd suggest create a separate issue with a similar summary (replacing IPSec with IPSEC_NAT_T of course) and add this issue's URL to the new issues "See Also:" field
Comment 22 karl 2016-08-20 15:17:44 UTC
(In reply to geezabiscuit2 from comment #20)

While we're on the topic...

options         IPSEC_FILTERTUNNEL

ought to be in GENERIC as well.... 
and, arguably

device enc

StrongSwan currently requires (even in 11.x) a custom kernel because these two entries are not in GENERIC.
Comment 23 Sydney Meyer 2016-08-20 19:37:39 UTC
Comment 24 Darryn Nicol 2016-08-20 23:02:28 UTC
I've created a new request to add IPSEC_NAT_T:

Comment 25 Bjoern A. Zeeb freebsd_committer 2016-08-21 00:17:46 UTC
(In reply to karl from comment #22)

The kernel option IPSEC_FILTERTUNNEL should be removed ... as indicated in commit .. uhm .. https://svnweb.freebsd.org/base?view=revision&revision=192648  ;  my bad;  should have done that 6 years ago ...  please use the loader tunable;  no need to compile a different kernel for this anymore.
Comment 26 Bjoern A. Zeeb freebsd_committer 2016-08-21 00:22:14 UTC
(In reply to Bjoern A. Zeeb from comment #25)

Whoops. make that a sysctl (he who can read his own commit messages ...)  so you can change it at runtime;  even better;  no need to reboot or compile a kernel ;-)
Comment 27 Andrey V. Elsukov freebsd_committer 2016-08-21 18:22:38 UTC
(In reply to karl from comment #22)
> and, arguably
> device enc
> StrongSwan currently requires (even in 11.x) a custom kernel because these
> two entries are not in GENERIC.

I made if_enc loadable in 11.0.
Comment 28 karl 2016-08-21 18:48:05 UTC
(In reply to Andrey V. Elsukov from comment #27)

Excellent... thank you; this implies that if IPSEC_NAT_T is put in GENERIC's config then a modified kernel is no longer necessary for StrongSwan (and other IPSEC users who wish to run through encrypted traffic through ipfw or similar, and most will.)
Comment 29 George V. Neville-Neil freebsd_committer 2016-12-12 12:43:55 UTC
Any additional updates related to IPSEC can be their own PRs.  The work spoken of here is now complete.
Comment 30 Kubilay Kocak freebsd_committer freebsd_triage 2019-05-12 06:54:04 UTC
Author: gallatin
Date: Thu May  9 22:38:15 2019
New Revision: 347410
URL: https://svnweb.freebsd.org/changeset/base/347410

  Remove IPSEC from GENERIC due to performance issues
  Having IPSEC compiled into the kernel imposes a non-trivial
  performance penalty on multi-threaded workloads due to IPSEC
  refcounting. In my benchmarks of multi-threaded UDP
  transmit (connected sockets), I've seen a roughly 20% performance
  penalty when the IPSEC option is included in the kernel (16.8Mpps
  vs 13.8Mpps with 32 senders on a 14 core / 28 HTT Xeon
  2697v3)). This is largely due to key_addref() incrementing and
  decrementing an atomic reference count on the default
  policy. This cause all CPUs to stall on the same cacheline, as it
  bounces between different CPUs.
  Given that relatively few users use ipsec, and that it can be
  loaded as a module, it seems reasonable to ask those users to
  load the ipsec module so as to avoid imposing this penalty on the
  GENERIC kernel. Its my hope that this will make FreeBSD look
  better in "out of the box" benchmark comparisons with other
  operating systems.
  Many thanks to ae for fixing auto-loading of ipsec.ko when
  ifconfig tries to configure ipsec, and to cy for volunteering
  to ensure the the racoon ports will load the ipsec.ko module
  Reviewed by:	cem, cy, delphij, gnn, jhb, jpaetzel
  Differential Revision:	https://reviews.freebsd.org/D20163

Comment 31 Miroslav Lachman 2019-05-12 10:32:19 UTC
Was or will be ipsec related ports maintainers notified about this change / need of kldload? E.g. security/strongswan