Tests transport mode and UDP encapsulation with random source ports.
Interestingly, the responder always uses the same SA to respond (maybe
due to the cache on the policy).
As we set the remote port to 0, we'd get a mapping change message with
every packet. Setting the threshold avoids all kernel messages after the
first, which we suppress explicitly as well.
This might make debugging easier and also ensures that a possible
fallback SA without CPU ID is established first when reestablishing
an IKE_SA. Because even if such an SA is established first initially,
that might change later depending on when per-CPU SAs are rekeyed.
Not sure if this combination does make sense as the plugin itself would
be a major bottleneck.
Similar to the connmark plugin, PREROUTING rules list SPIs or UDP ports,
which would be necessary for all SAs while the OUTPUT rules would only be
required once.
The combination probably doesn't make much sense.
The OUTPUT rules would definitely only be required once, while the INPUT
and PREROUTING rules list individual SPIs and/or UDP ports, which would
be necessary for all SAs.
By the way, the rules in PREROUTING might actually not be necessary
anymore if the set_mark_in option was used for such SAs.
This uses the sequence number from acquires when installing the SA. This
allows handling narrowing properly by changing the reqid and still
removing the temporary state in the kernel. It also changes that
traffic selectors are reused during rekeying/recreation/reauthentication,
so narrowed selectors won't return to the wider configured TS because
there won't be any TS from triggering packets to narrow again.
Besides the previous key exchange method, this will allow us to also
reuse the previous traffic selectors. Some data is still passed in
separate methods as some are set even when there is no previous SA and
others are not set in all cases.
The interface for queue_child() now optionally takes the previous
Child SA to handle both recreations and initiations from scratch.
This fixes cases where `start_action = trap|start` is used and an acquire
is triggered while the SA is initiated (granted if narrowing is expected,
that's not a recommended configuration as the responder can only use
the first config when there is no packet TS). The resulting second
create-child task will potentially get dropped by the duplicate check,
so the temporary state won't get removed and traffic is blocked until
that expires, neither can acquires get triggered for traffic that doesn't
match the initial SA's policies.
This was the case before bce0c5fd74a0 ("child-create: Update CHILD_SA IP
addresses before installation") and allows listeners to consider the
traffic selectors of the SA that's about to get installed.
