This might not be related to your issue but I remember putting in a
fix for a labeled IPsec setup in last year (around 3.14?). You should
at least make sure that your build has it, it's the most recent
labeled IPsec related change.
commit 1543f3c66bce961a94d119d7b3c32ad965cf07d3
Author: Matt Rogers <mrog...@redhat.com>
Date: Wed Aug 19 15:59:12 2015 -0400
Fix labeled ipsec SECCTX parsing
diff --git a/programs/pluto/ikev1_spdb_struct.c
b/programs/pluto/ikev1_spdb_struct.c
index da8c76c..b144331 100644
--- a/programs/pluto/ikev1_spdb_struct.c
+++ b/programs/pluto/ikev1_spdb_struct.c
@@ -84,7 +84,7 @@ static bool parse_secctx_attr(pb_stream *pbs, struct
state *st)
zero(&uctx.sec_ctx_value); /* abundance of caution */
- if (in_raw(uctx.sec_ctx_value, uctx.ctx.ctx_len, pbs,
+ if (!in_raw(uctx.sec_ctx_value, uctx.ctx.ctx_len, pbs,
"Sec Ctx Textual Label"))
return FALSE;
On Fri, Feb 3, 2017 at 6:56 PM, Jeff Becker <jeffrey.c.bec...@nasa.gov> wrote:
> On 02/03/2017 09:31 AM, Paul Wouters wrote:
>>
>> On Thu, 2 Feb 2017, Jeff Becker wrote:
>>
>>> Hi. Using libreswan, I was able to set up an unlabeled ipsec tunnel
>>> between two CentOS 7.3 hosts.
>>
>>
>>> However, if I add the following to my ipsec.conf...
>>>
>>> labeled-ipsec=yes
>>>
>>> policy-label=unconfined.user:msg_filter.role:msg_filter.ext_gateway.process:s0
>>>
>>> restart ipsec on both sides, add the new tunnel and try to bring it up, I
>>> get:
>>
>>
>>> 117 "dtsd-tunnel" #2: STATE_QUICK_I1: initiate
>>> 003 "dtsd-tunnel" #2: ERROR: netlink XFRM_MSG_UPDPOLICY response for flow
>>> tun.10000@198.9.7.199 included errno 22: Invalid argument
>>> 002 "dtsd-tunnel" #2: raw_eroute() in setup_half_ipsec_sa() failed to add
>>> inbound
>>>
>>> I chose the policy-label from the example in the latest SELinux notebook
>>> (https://selinuxproject.org/page/Category:Notebook). Not sure if
>>> that's the issue, or if it's something else. Please advise. Thanks.
>>
>>
>> Our test configuration uses:
>>
>> policy_label=system_u:object_r:ipsec_spd_t:s0-s15:c0.c1023
>
>
> I got the above (actually policy-label=system_u:object_r:ipsec_spd_t:s0) to
> work by fixing an AVC denial. Now when I bring up the tunnel I see:
>
> # ipsec auto --up dtsd-tunnel
> 002 "dtsd-tunnel" #1: initiating Main Mode
> 104 "dtsd-tunnel" #1: STATE_MAIN_I1: initiate
> 003 "dtsd-tunnel" #1: received Vendor ID payload [Dead Peer Detection]
> 003 "dtsd-tunnel" #1: received Vendor ID payload [FRAGMENTATION]
> 003 "dtsd-tunnel" #1: received Vendor ID payload [RFC 3947]
> 002 "dtsd-tunnel" #1: enabling possible NAT-traversal with method RFC 3947
> (NAT-Traversal)
> 002 "dtsd-tunnel" #1: transition from state STATE_MAIN_I1 to state
> STATE_MAIN_I2
> 106 "dtsd-tunnel" #1: STATE_MAIN_I2: sent MI2, expecting MR2
> 003 "dtsd-tunnel" #1: NAT-Traversal: Result using RFC 3947 (NAT-Traversal)
> sender port 500: no NAT detected
> 002 "dtsd-tunnel" #1: transition from state STATE_MAIN_I2 to state
> STATE_MAIN_I3
> 108 "dtsd-tunnel" #1: STATE_MAIN_I3: sent MI3, expecting MR3
> 003 "dtsd-tunnel" #1: received Vendor ID payload [CAN-IKEv2]
> 002 "dtsd-tunnel" #1: Main mode peer ID is ID_IPV4_ADDR: '198.9.7.198'
> 002 "dtsd-tunnel" #1: transition from state STATE_MAIN_I3 to state
> STATE_MAIN_I4
> 004 "dtsd-tunnel" #1: STATE_MAIN_I4: ISAKMP SA established {auth=RSA_SIG
> cipher=aes_256 integ=sha group=MODP2048}
> 002 "dtsd-tunnel" #2: initiating Quick Mode
> RSASIG+ENCRYPT+TUNNEL+PFS+UP+IKEV1_ALLOW+IKEV2_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW
> {using isakmp#1 msgid:3849768f proposal=defaults
> pfsgroup=OAKLEY_GROUP_MODP2048}
> 117 "dtsd-tunnel" #2: STATE_QUICK_I1: initiate
> 002 "dtsd-tunnel" #2: transition from state STATE_QUICK_I1 to state
> STATE_QUICK_I2
> 004 "dtsd-tunnel" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel
> mode {ESP=>0xc01ab79f <0x4f6e6b26 xfrm=AES_128-HMAC_SHA1 NATOA=none
> NATD=none DPD=passive}
>
> I don't see anything above that indicates that labeled ipsec is being used,
> but maybe that's OK. Anyhow, after setting this up, I can't seem to ping the
> other side of the tunnel (I was able to ping in the case without labeled
> ipsec). Any suggestions are appreciated. Thanks.
>
> -jeff
>
>>
>> I think we also needed to put the system in MLS mode for this to properly
>> work?
>>
>> I'll ask some of the selinux people inside Red Hat if they know more.
>>
>> Paul
>
>
>
> _______________________________________________
> Swan mailing list
> Swan@lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan
_______________________________________________
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan
