Bug 1934859 - only the first labeled ipsec tunnel is working when IKEv2 is used
Summary: only the first labeled ipsec tunnel is working when IKEv2 is used
Keywords:
Status: ASSIGNED
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: libreswan
Version: 8.4
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: 8.5
Assignee: Daiki Ueno
QA Contact: Ondrej Moriš
Khushbu Borole
URL:
Whiteboard:
Depends On: 1958968
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-03-03 21:42 UTC by Ondrej Moriš
Modified: 2021-08-17 08:05 UTC (History)
2 users (show)

Fixed In Version: libreswan-4.4-1.el8
Doc Type: Known Issue
Doc Text:
.Using multiple labeled IPsec connections with `IKEv2` do not work correctly When Libreswan uses the `IKEv2` protocol, security labels for IPsec do not work correctly for more than one connection. As a consequence, Libreswan using labeled IPsec can establish only the first connection, but cannot establish subsequent connections correctly. To use more than one connection, use the `IKEv1` protocol.
Clone Of:
: 1993103 (view as bug list)
Environment:
Last Closed:
Type: Bug
Target Upstream Version:
kborole: needinfo-


Attachments (Terms of Use)

Description Ondrej Moriš 2021-03-03 21:42:20 UTC
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.

conn test
 authby=secret
 left=<CLIENT>
 right=<SERVER> 
 ikev2=<IKE>
 policy-label=system_u:object_r:ipsec_spd_t:s0
 auto=add 

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):

libreswan-4.3-2.el8

How reproducible:

100%

Steps to Reproduce:

1. See BZ#1025061#c44 for detailed reproducer.

Actual results:

Only the first connection works as expected, subsequent connection are broken.

Expected results:

Ordering of connection should not matter, (1), (2) and (3) should work as expected regardless of their ordering.

Comment 3 Ondrej Moriš 2021-03-10 16:46:04 UTC
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.

Comment 4 Paul Wouters 2021-04-22 19:45:29 UTC
this is addressed in upstream 4.4

Comment 6 Ondrej Moriš 2021-05-10 11:06:50 UTC
Here's a proposal for Doc Text:

Cause: 

When IKEv2 protocol is used, labeled ipsec does not work correctly for more than one connection.

Consequence: 

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.

Result: 

(I am not sure what should belong to this part)


Note You need to log in before you can comment on or make changes to this bug.