On 02/07/2017 05:30 PM, Paul Wouters wrote:
On Tue, 7 Feb 2017, Jeff Becker wrote:
Could this be the problem?
#grep errno /var/log/secure
Feb 7 23:20:15 dtn1 pluto[4320]: "dtsd-tunnel" #1: ERROR: netlink
response for Del SA esp.71664063@198.9.7.198 included errno 3: No
such process
That sho
On Tue, 7 Feb 2017, Jeff Becker wrote:
It should not take a while. It is all instant. You might want to look at
the logs to see what happened? Look for "pluto" logs in /var/log/secure.
Could this be the problem?
#grep errno /var/log/secure
Feb 7 23:20:15 dtn1 pluto[4320]: "dtsd-tunnel" #1:
On 02/06/2017 06:24 PM, Paul Wouters wrote:
On Sat, 4 Feb 2017, Jeff Becker wrote:
Spoke too soon. I reverted to the unlabeled tunnel to test
something, then
restarted the labeled tunnel (successfully) . Once again I couldn't
ping,
but now tracepath didn't work either. When I run ipsec stat
On Sat, 4 Feb 2017, Jeff Becker wrote:
Spoke too soon. I reverted to the unlabeled tunnel to test something, then
restarted the labeled tunnel (successfully) . Once again I couldn't ping,
but now tracepath didn't work either. When I run ipsec status, the tail of
it shows:
000 198.9.7.199/3
On 02/04/2017 03:40 PM, Jeff Becker wrote:
On 02/04/2017 02:34 PM, Jeff Becker wrote:
On 02/03/2017 04:57 PM, Paul Wouters wrote:
My guess would be that your ping is either not covered by the
tunnel, or
you are using ICMP packets with the wrong label?
I fixed another AVC denial disallowing p
On 02/04/2017 02:34 PM, Jeff Becker wrote:
On 02/03/2017 04:57 PM, Paul Wouters wrote:
My guess would be that your ping is either not covered by the tunnel, or
you are using ICMP packets with the wrong label?
I fixed another AVC denial disallowing polmatch for scontext
unlabeled_t, and tconte
On 02/03/2017 04:57 PM, Paul Wouters wrote:
On Fri, 3 Feb 2017, Jeff Becker wrote:
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 b
On Sat, 4 Feb 2017, Jeff Becker wrote:
On 02/03/2017 04:51 PM, Matt Rogers wrote:
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
Hi Matt,
On 02/03/2017 04:51 PM, Matt Rogers wrote:
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.
I've install
On Fri, 3 Feb 2017, Jeff Becker wrote:
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:
004 "dtsd-tun
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 Roger
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
Hi. Using libreswan, I was able to set up an unlabeled ipsec tunnel
between two CentOS 7.3 hosts.
#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
13 matches
Mail list logo
