mirror of
https://github.com/strongswan/strongswan.git
synced 2025-10-04 00:00:14 -04:00
760d7c9b4f
The network namespace scenario requires a kernel patch in 4.19 and 4.20 kernels (the fix is included in 5.0 kernels).
23 lines
1.3 KiB
Plaintext
23 lines
1.3 KiB
Plaintext
This scenario demonstrates a property of <b>XFRM interfaces</b> that allows
|
|
moving them into network namespaces while retaining access to IPsec SAs and
|
|
policies in the original namespace. This enables an IKE daemon in one namespace
|
|
to provide IPsec tunnels for processes in other namespaces without having to
|
|
give them access to the keys and IKE credentials.
|
|
<p/>
|
|
The gateways use <b>route-based forwarding</b> with <b>XFRM interfaces</b>, with
|
|
firewall rules to allow traffic to pass. The IPsec traffic selector used is
|
|
0.0.0.0/0, however, specific routing is achieved with routes on the XFRM
|
|
interfaces. The IKE daemon does not install routes for CHILD_SAs with outbound
|
|
interface ID, so static routes are installed for the target subnets.
|
|
<p/>
|
|
The XFRM interface on gateway <b>moon</b> is moved into a new network namespace
|
|
from which a ping is sent to client <b>bob</b>. It is then moved back out and
|
|
<b>alice</b> sends another ping to <b>bob</b> to test if that works too.
|
|
<p/>
|
|
Gateway <b>sun</b> dynamically creates the XFRM interface via updown script
|
|
using the passed unique generated interface ID.
|
|
<p/>
|
|
Note that the dropped packet seen on the <b>XFRM interface</b> on <b>moon</b>
|
|
is an IPv6 Router Solicitation (NDP) sent from that namespace, which doesn't
|
|
match the IPsec policy.
|