]> git.ipfire.org Git - thirdparty/strongswan.git/blob - testing/tests/route-based/net2net-xfrmi-netns/description.txt
testing: Add scenarios that use XFRM interfaces
[thirdparty/strongswan.git] / testing / tests / route-based / net2net-xfrmi-netns / description.txt
1 This scenario demonstrates a property of <b>XFRM interfaces</b> that allows
2 moving them into network namespaces while retaining access to IPsec SAs and
3 policies in the original namespace. This enables an IKE daemon in one namespace
4 to provide IPsec tunnels for processes in other namespaces without having to
5 give them access to the keys and IKE credentials.
6 <p/>
7 The gateways use <b>route-based forwarding</b> with <b>XFRM interfaces</b>, with
8 firewall rules to allow traffic to pass. The IPsec traffic selector used is
9 0.0.0.0/0, however, specific routing is achieved with routes on the XFRM
10 interfaces. The IKE daemon does not install routes for CHILD_SAs with outbound
11 interface ID, so static routes are installed for the target subnets.
12 <p/>
13 The XFRM interface on gateway <b>moon</b> is moved into a new network namespace
14 from which a ping is sent to client <b>bob</b>. It is then moved back out and
15 <b>alice</b> sends another ping to <b>bob</b> to test if that works too.
16 <p/>
17 Gateway <b>sun</b> dynamically creates the XFRM interface via updown script
18 using the passed unique generated interface ID.
19 <p/>
20 Note that the dropped packet seen on the <b>XFRM interface</b> on <b>moon</b>
21 is an IPv6 Router Solicitation (NDP) sent from that namespace, which doesn't
22 match the IPsec policy.