Description of problem:
Version 4.3 of libreswan comes with labeled ipsec updates. IKEv1 labeled ipsec was updated and labeled ipsec support for IKEv2 was introduced (BZ#1025061).
We found out that labeled ipsec works differently when IKEv1 and IKEv2 is used. No issues were found for IKEv1 but when IKEv2 is used then only the first tunnel is created correctly. Subsequent tunnels using different labels are not working as expected.
This was described in BZ#1025061#c44 and can summarized as follows:
Ipsec and selinux is configured in way that packets with ping_t and netutils_t labels should match policy-label for the following connection.
In other words,
1. "runcon -t ping_t ping <SERVER>" running on client should work and traffic should be encrypted.
2. "echo 'hello' | runcon -t netutils_t nc -w 60 <SERVER> 4300" running on client should work and traffic should be encrypted.
3. ping or ncat without correct label runs with unconfined_t label and hence should not work.
When IKEv1 is used (ikev2=no) everything works as expected. But when IKEv2 is used (ikev2=insist) then ordering of communication matters - ie. when (1) is first, it works but (2) does not and vice versa. When (3) is first then neither (1) nor (2) works.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. See BZ#1025061#c44 for detailed reproducer.
Only the first connection works as expected, subsequent connection are broken.
Ordering of connection should not matter, (1), (2) and (3) should work as expected regardless of their ordering.
Setting "Known Issues" Doc Type since we would like to have this issue documented as Known Issue of RHEL-8.4.0 minor release update.
this is addressed in upstream 4.4
Here's a proposal for Doc Text:
When IKEv2 protocol is used, labeled ipsec does not work correctly for more than one connection.
If libreswan is configured to use more than one connection using labeled ipsec, only the first connection initiated uses it correctly, subsequent connection cannot be established correctly.
Workaround (if any):
The only workaround is to IKEv1 instead of IKEv2 - labeled ipsec works correctly when IKEv1 is used.
(I am not sure what should belong to this part)