Bug 1934859

Summary:	only the first labeled ipsec tunnel is working when IKEv2 is used
Product:	Red Hat Enterprise Linux 8	Reporter:	Ondrej Moriš <omoris>
Component:	libreswan	Assignee:	Daiki Ueno <dueno>
Status:	CLOSED DUPLICATE	QA Contact:	Ondrej Moriš <omoris>
Severity:	medium	Docs Contact:	Khushbu Borole <kborole>
Priority:	medium
Version:	8.4	CC:	dueno, pvrabec, sbroz
Target Milestone:	rc	Keywords:	Triaged
Target Release:	8.5	Flags:	kborole: needinfo- pm-rhel: mirror+
Hardware:	All
OS:	Linux
Whiteboard:
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.	Story Points:	---
Clone Of:
Clones:	1993103 (view as bug list)		Environment:
Last Closed:	2021-12-07 15:45:28 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1958968
Bug Blocks:

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)