[Buildroot] [PATCH 1/3] package/strongswan: enable kernel-libipsec

[Buildroot] [PATCH 1/3] package/strongswan: enable kernel-libipsec

[Wei Dai]

The kernel-libipsec plugin for libcharon provides an IPsec
backend that runs entirely in userland, using TUN devices and
strongSwan's own libipsec implementation.

Unlike the default kernel-netlink and kernel-pfkey backends,
which install SAs into the OS IPsec stack, this plugin is a
useful alternative when the kernel IPsec stack does not support
a required algorithm (e.g. AES-GCM on platforms lacking it).
It generally performs worse than the kernel stack, so it is
not recommended for high-throughput security gateways.

Enable it with --enable-kernel-libipsec. A network kernel
backend (kernel-netlink or kernel-pfroute) is still required.

Signed-off-by: Wei Dai <daiwei@sunkaisens.com>
---
 package/strongswan/strongswan.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/strongswan/strongswan.mk b/package/strongswan/strongswan.mk
index 2e20b244ad..0823732d1b 100644
--- a/package/strongswan/strongswan.mk
+++ b/package/strongswan/strongswan.mk
@@ -17,6 +17,7 @@ STRONGSWAN_CONF_OPTS += \
 	--enable-led \
 	--enable-pkcs11=yes \
 	--enable-kernel-netlink=yes \
+	--enable-kernel-libipsec=yes \
 	--enable-socket-default=yes \
 	--enable-botan=$(if $(BR2_PACKAGE_STRONGSWAN_BOTAN),yes,no) \
 	--enable-openssl=$(if $(BR2_PACKAGE_STRONGSWAN_OPENSSL),yes,no) \
-- 
2.47.3

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 2/3] package/strongswan: add eap-aka-3gpp support

[Wei Dai]

Add the eap-aka-3gpp plugin, an EAP-AKA backend implementing the
3GPP MILENAGE algorithms in software. Select the EAP-AKA plugin
it depends on.

Signed-off-by: Wei Dai <daiwei@sunkaisens.com>
---
 package/strongswan/Config.in     | 5 +++++
 package/strongswan/strongswan.mk | 1 +
 2 files changed, 6 insertions(+)

diff --git a/package/strongswan/Config.in b/package/strongswan/Config.in
index 6847ca4f62..827634c071 100644
--- a/package/strongswan/Config.in
+++ b/package/strongswan/Config.in
@@ -135,6 +135,11 @@ config BR2_PACKAGE_STRONGSWAN_EAP_AKA
 	bool "Enable EAP-AKA"
 	default y if BR2_PACKAGE_STRONGSWAN_EAP # legacy
 
+config BR2_PACKAGE_STRONGSWAN_EAP_AKA_3GPP
+	bool "Enable EAP AKA backend plugin implementing 3GPP MILENAGE algorithms"
+	default y if BR2_PACKAGE_STRONGSWAN_EAP # legacy
+	select BR2_PACKAGE_STRONGSWAN_EAP_AKA
+
 config BR2_PACKAGE_STRONGSWAN_EAP_AKA_3GPP2
 	bool "Enable EAP-AKA 3GPP2 algorithms"
 	default y if BR2_PACKAGE_STRONGSWAN_EAP # legacy
diff --git a/package/strongswan/strongswan.mk b/package/strongswan/strongswan.mk
index 0823732d1b..78c1ec535d 100644
--- a/package/strongswan/strongswan.mk
+++ b/package/strongswan/strongswan.mk
@@ -43,6 +43,7 @@ STRONGSWAN_CONF_OPTS += \
 	--enable-eap-sim=$(if $(BR2_PACKAGE_STRONGSWAN_EAP_SIM),yes,no) \
 	--enable-eap-sim-file=$(if $(BR2_PACKAGE_STRONGSWAN_EAP_SIM_FILE),yes,no) \
 	--enable-eap-aka=$(if $(BR2_PACKAGE_STRONGSWAN_EAP_AKA),yes,no) \
+	--enable-eap-aka-3gpp=$(if $(BR2_PACKAGE_STRONGSWAN_EAP_AKA_3GPP),yes,no) \
 	--enable-eap-aka-3gpp2=$(if $(BR2_PACKAGE_STRONGSWAN_EAP_AKA_3GPP2),yes,no) \
 	--enable-eap-simaka-sql=$(if $(BR2_PACKAGE_STRONGSWAN_EAP_SIMAKA_SQL),yes,no) \
 	--enable-eap-simaka-pseudonym=$(if $(BR2_PACKAGE_STRONGSWAN_EAP_SIMAKA_PSEUDONYM),yes,no) \
-- 
2.47.3

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 3/3] package/strongswan: add systemd support

[Wei Dai]

When systemd is enabled, configure strongswan with --enable-systemd
and add the systemd dependency. This builds the charon-systemd IKE
daemon, which is designed for native systemd integration (using the
systemd libraries) and is managed by systemd through a service file,
with configuration handled by the swanctl backend.

Pass --disable-systemd when systemd is not selected to keep the
build deterministic.

Signed-off-by: Wei Dai <daiwei@sunkaisens.com>
---
 package/strongswan/strongswan.mk | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/package/strongswan/strongswan.mk b/package/strongswan/strongswan.mk
index 78c1ec535d..ab4300cf14 100644
--- a/package/strongswan/strongswan.mk
+++ b/package/strongswan/strongswan.mk
@@ -71,6 +71,13 @@ endif
 # setup piddir if BR2_PACKAGE_STRONGSWAN_PIDDIR is not empty
 STRONGSWAN_CONF_OPTS += $(if $(call qstrip,$(BR2_PACKAGE_STRONGSWAN_PIDDIR)),--with-piddir=$(BR2_PACKAGE_STRONGSWAN_PIDDIR))
 
+ifeq ($(BR2_PACKAGE_SYSTEMD),y)
+STRONGSWAN_DEPENDENCIES += systemd
+STRONGSWAN_CONF_OPTS += --enable-systemd
+else
+STRONGSWAN_CONF_OPTS += --disable-systemd
+endif
+
 ifeq ($(BR2_PACKAGE_STRONGSWAN_NONROOT),y)
 STRONGSWAN_CONF_OPTS += \
 	--with-user=charon \
-- 
2.47.3

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 2/3] package/strongswan: add eap-aka-3gpp support

[Thomas Petazzoni via buildroot]

HJello,

On Sun, Sep 20, 2026 at 03:40:55PM +0800, Wei Dai wrote:
> Add the eap-aka-3gpp plugin, an EAP-AKA backend implementing the
> 3GPP MILENAGE algorithms in software. Select the EAP-AKA plugin
> it depends on.
> 
> Signed-off-by: Wei Dai <daiwei@sunkaisens.com>
> ---
>  package/strongswan/Config.in     | 5 +++++
>  package/strongswan/strongswan.mk | 1 +
>  2 files changed, 6 insertions(+)
> 
> diff --git a/package/strongswan/Config.in b/package/strongswan/Config.in
> index 6847ca4f62..827634c071 100644
> --- a/package/strongswan/Config.in
> +++ b/package/strongswan/Config.in
> @@ -135,6 +135,11 @@ config BR2_PACKAGE_STRONGSWAN_EAP_AKA
>  	bool "Enable EAP-AKA"
>  	default y if BR2_PACKAGE_STRONGSWAN_EAP # legacy
>  
> +config BR2_PACKAGE_STRONGSWAN_EAP_AKA_3GPP
> +	bool "Enable EAP AKA backend plugin implementing 3GPP MILENAGE algorithms"
> +	default y if BR2_PACKAGE_STRONGSWAN_EAP # legacy

Since BR2_PACKAGE_STRONGSWAN_EAP_AKA_3GPP is new, there's no point is
bothering with legacy handling, so I've dropped this line, and applied
your patch. Thanks!

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 3/3] package/strongswan: add systemd support

[Thomas Petazzoni via buildroot]

On Sun, Sep 20, 2026 at 03:40:56PM +0800, Wei Dai wrote:
> When systemd is enabled, configure strongswan with --enable-systemd
> and add the systemd dependency. This builds the charon-systemd IKE
> daemon, which is designed for native systemd integration (using the
> systemd libraries) and is managed by systemd through a service file,
> with configuration handled by the swanctl backend.
> 
> Pass --disable-systemd when systemd is not selected to keep the
> build deterministic.
> 
> Signed-off-by: Wei Dai <daiwei@sunkaisens.com>

Applied to master, thanks!

Best regards,

Thomas Petazzoni
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/3] package/strongswan: enable kernel-libipsec

[Thomas Petazzoni via buildroot]

Hello,

On Sun, Sep 20, 2026 at 03:40:54PM +0800, Wei Dai wrote:
> The kernel-libipsec plugin for libcharon provides an IPsec
> backend that runs entirely in userland, using TUN devices and
> strongSwan's own libipsec implementation.
> 
> Unlike the default kernel-netlink and kernel-pfkey backends,
> which install SAs into the OS IPsec stack, this plugin is a
> useful alternative when the kernel IPsec stack does not support
> a required algorithm (e.g. AES-GCM on platforms lacking it).
> It generally performs worse than the kernel stack, so it is
> not recommended for high-throughput security gateways.
> 
> Enable it with --enable-kernel-libipsec. A network kernel
> backend (kernel-netlink or kernel-pfroute) is still required.
> 
> Signed-off-by: Wei Dai <daiwei@sunkaisens.com>

Thanks for your patch. I'm curious to understand why you enable this
new feature unconditionally, while in PATCH 2/3 you propose to enable
another feature by way of an option. Note that I'm not very familiar
with Strongswan/IPsec, so maybe the answer is obvious, but your commit
message doesn't really clarify why we would want this enabled
unconditionally, even though it was not enabled since
package/strongswan was added in Buildroot.

It might also be relevant to comment about the additional footprint
added by this option enable unconditionally.

Thanks for your feedback!

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/3] package/strongswan: enable kernel-libipsec

[Thomas Petazzoni via buildroot]

Hello Wei,

Gentle ping on the question below regarding your patch. Thanks for
your feedback!

Thomas

On Sun, Sep 20, 2026 at 02:26:33PM +0200, Thomas Petazzoni via buildroot wrote:
> Hello,
> 
> On Sun, Sep 20, 2026 at 03:40:54PM +0800, Wei Dai wrote:
> > The kernel-libipsec plugin for libcharon provides an IPsec
> > backend that runs entirely in userland, using TUN devices and
> > strongSwan's own libipsec implementation.
> > 
> > Unlike the default kernel-netlink and kernel-pfkey backends,
> > which install SAs into the OS IPsec stack, this plugin is a
> > useful alternative when the kernel IPsec stack does not support
> > a required algorithm (e.g. AES-GCM on platforms lacking it).
> > It generally performs worse than the kernel stack, so it is
> > not recommended for high-throughput security gateways.
> > 
> > Enable it with --enable-kernel-libipsec. A network kernel
> > backend (kernel-netlink or kernel-pfroute) is still required.
> > 
> > Signed-off-by: Wei Dai <daiwei@sunkaisens.com>
> 
> Thanks for your patch. I'm curious to understand why you enable this
> new feature unconditionally, while in PATCH 2/3 you propose to enable
> another feature by way of an option. Note that I'm not very familiar
> with Strongswan/IPsec, so maybe the answer is obvious, but your commit
> message doesn't really clarify why we would want this enabled
> unconditionally, even though it was not enabled since
> package/strongswan was added in Buildroot.
> 
> It might also be relevant to comment about the additional footprint
> added by this option enable unconditionally.
> 
> Thanks for your feedback!
> 
> Thomas
> -- 
> Thomas Petazzoni, co-owner and CEO, Bootlin
> Embedded Linux and Kernel engineering and training
> https://bootlin.com
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot

-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] 回复： [PATCH 1/3] package/strongswan: enable kernel-libipsec

[戴维]

[-- Attachment #1.1: Type: text/plain, Size: 3460 bytes --]

Sorry for the late reply over the holiday. After checking the official docs, I believe Patch 1 should be reverted and kept out of master for now. StrongSwan explicitly notes:
libipsec is not intended for scenarios with high amounts of traffic or high burst traffic. It is not optimized for performance and buffers each packet in memory. 
In combination with insufficient processor power this will lead to a out of memory condition and a crash of charon or the whole device. 
SA and policy lookups are also not particularly optimized. 
I primarily use this plugin to prevent installing SAs into the kernel IPsec stack. In standard XFRM, 
sensitive state materials like K and XRES stored in the kernel SPD/SAD can be read in real time (e.g., via ip xfrm),
 introducing major security risks for traffic decryption. Still, given official warnings about OOM risks and poor performance, 
we should wait for this feature to stabilize before adding it to master.
------------------------------------------------------------------
发件人：Thomas Petazzoni <thomas.petazzoni@bootlin.com>
发送时间：2026年9月29日(周二) 15:21
收件人："戴维"<daiwei@sunkaisens.com>; buildroot<buildroot@buildroot.org>; "Jérôme Pouiller"<jezz@sysmic.org>
主　题：Re: [Buildroot] [PATCH 1/3] package/strongswan: enable kernel-libipsec
Hello Wei,
Gentle ping on the question below regarding your patch. Thanks for
your feedback!
Thomas
On Sun, Sep 20, 2026 at 02:26:33PM +0200, Thomas Petazzoni via buildroot wrote:
> Hello,
> 
> On Sun, Sep 20, 2026 at 03:40:54PM +0800, Wei Dai wrote:
> > The kernel-libipsec plugin for libcharon provides an IPsec
> > backend that runs entirely in userland, using TUN devices and
> > strongSwan's own libipsec implementation.
> > 
> > Unlike the default kernel-netlink and kernel-pfkey backends,
> > which install SAs into the OS IPsec stack, this plugin is a
> > useful alternative when the kernel IPsec stack does not support
> > a required algorithm (e.g. AES-GCM on platforms lacking it).
> > It generally performs worse than the kernel stack, so it is
> > not recommended for high-throughput security gateways.
> > 
> > Enable it with --enable-kernel-libipsec. A network kernel
> > backend (kernel-netlink or kernel-pfroute) is still required.
> > 
> > Signed-off-by: Wei Dai <daiwei@sunkaisens.com>
> 
> Thanks for your patch. I'm curious to understand why you enable this
> new feature unconditionally, while in PATCH 2/3 you propose to enable
> another feature by way of an option. Note that I'm not very familiar
> with Strongswan/IPsec, so maybe the answer is obvious, but your commit
> message doesn't really clarify why we would want this enabled
> unconditionally, even though it was not enabled since
> package/strongswan was added in Buildroot.
> 
> It might also be relevant to comment about the additional footprint
> added by this option enable unconditionally.
> 
> Thanks for your feedback!
> 
> Thomas
> -- 
> Thomas Petazzoni, co-owner and CEO, Bootlin
> Embedded Linux and Kernel engineering and training
> https://bootlin.com <https://bootlin.com >
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot <https://lists.buildroot.org/mailman/listinfo/buildroot >
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com <https://bootlin.com >

[-- Attachment #1.2: Type: text/html, Size: 16457 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] 回复： [PATCH 1/3] package/strongswan: enable kernel-libipsec

[Thomas Petazzoni via buildroot]

Hello!

On Tue, Sep 29, 2026 at 05:01:29PM +0800, 戴维 wrote:
> Sorry for the late reply over the holiday. After checking the official docs, I
> believe Patch 1 should be reverted and kept out of master for now. StrongSwan
> explicitly notes:
> 
> libipsec is not intended for scenarios with high amounts of traffic or high
> burst traffic. It is not optimized for performance and buffers each packet in
> memory. 
> In combination with insufficient processor power this will lead to a out of
> memory condition and a crash of charon or the whole device. 
> SA and policy lookups are also not particularly optimized.  
> 
> I primarily use this plugin to prevent installing SAs into the kernel IPsec
> stack. In standard XFRM, 
> sensitive state materials like K and XRES stored in the kernel SPD/SAD can be
> read in real time (e.g., via ip xfrm),
> introducing major security risks for traffic decryption. Still, given official
> warnings about OOM risks and poor performance, 
> we should wait for this feature to stabilize before adding it to master.

Thanks for the feedback. Based on this feedback, I've marked the patch
as Rejected in our patch tracking system.

Thanks a lot!

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot