[Swan-commit] Changes to ref refs/heads/master

[Paul Wouters]

New commits:
commit 19468ba1f71bfece1c35e79388aa7bda5aa0ecde
Author: Paul Wouters 
Date:   Mon Oct 17 20:14:47 2016 -0400

testing: fixup ikev1-impair-gx-02 now whack is properly released

___
Swan-commit mailing list
Swan-commit@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan-commit

[Swan-commit] Changes to ref refs/heads/master

[Paul Wouters]

New commits:
commit 130b744190c251ba91398ca20645c36809523fae
Author: Paul Wouters 
Date:   Mon Oct 17 16:39:58 2016 -0400

IKEv1: some IKE SA failure on the initiator would lead to hanging state

This initiator getting STF_FAIL in its state would have its event removed,
and would never do anything anymore. It would not retransmit or timeout.
Errors with STF_FATAL were not affected.

As a side-effect, the whack would also not be released and the ipsec
auto --up command would hang.

This could be seen in various test cases, including ikev1-impair-gx-02
and nss-cert-10-notyetvalid-responder as it caused the test to timeout.

___
Swan-commit mailing list
Swan-commit@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan-commit

[Swan-commit] Changes to ref refs/heads/master

[Paul Wouters]

New commits:
commit 3c51882829f8040499fd44c8ee499e09ebb9f0fb
Author: D. Hugh Redelmeier 
Date:   Mon Oct 17 14:09:03 2016 -0400

pluto: close whack socket in add_pending when duplicate pending is skipped

Signed-off-by: Paul Wouters 

___
Swan-commit mailing list
Swan-commit@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan-commit

Re: [Swan] Problem with setting up ipsec

[Paul Wouters]

On Mon, 17 Oct 2016, Maciej Piechotka wrote:


Possibly interesting data point - I was able to set up ipsec tunnel with pure 
Fedora (userspace + kernel) but not Fedora strongswan tools or Centos libreswan 
tools
on CoreOS kernel.


I don't know what "pure fedora (userspace + kernel)" means?

Perhaps you are trying to say the userlands that work on fedora/centos
do not work on coreos kernels?

Its surely possible the CoreOS kernel is missing some kind of required
feature for IPsec to work...

Paul

On Sun, Oct 16, 2016 at 8:56 PM Maciej Piechotka  wrote:
  Hi Paul,

  Sorry - I've tried it before but I forgot to reenable it after
  recreation of VM. However it doesn't help.

  Matt

  On Sun, Oct 16, 2016 at 6:47 PM, Paul Wouters  wrote:
  > On Sun, 16 Oct 2016, Maciej Piechotka wrote:
  >
  >> I have problem with setting up ipsec. I see ESP packets coming through
  >> but they are dropped during policy check (i.e. XfrmInTmplMismatch is
  >> increased) so in tcpdump only the ESP packets are shown. I could not
  >> find any information how to proceed from here.
  >>
  >> Matt
  >> PS. I disabled receiving messages from this group so please include me
  >> in To: or Cc: list.
  >
  >
  > Note that your barf's did not include log files. But regardless, it
  > shows the kernel ip xfrm state/policy showing the tunnels are up fine.
  >
  > The only thing I can see wrong is:
  >
  > Checking for IPsec support in kernel                    [OK]
  >  NETKEY: Testing XFRM related proc values
  >          ICMP default/send_redirects                    [NOT DISABLED]
  >
  >   Disable /proc/sys/net/ipv4/conf/*/send_redirects or NETKEY will act on
  > or cause sending of bogus ICMP redirects!
  >
  >          ICMP default/accept_redirects                  [NOT DISABLED]
  >
  >   Disable /proc/sys/net/ipv4/conf/*/accept_redirects or NETKEY will act
  > on or cause sending of bogus ICMP redirects!
  >
  >          XFRM larval drop                               [OK]
  > Pluto ipsec.conf syntax                                 [OK]
  > Hardware random device                                  [N/A]
  > Two or more interfaces found, checking IP forwarding    [OK]
  > Checking rp_filter                                      [ENABLED]
  >  /proc/sys/net/ipv4/conf/all/rp_filter                  [ENABLED]
  >  /proc/sys/net/ipv4/conf/default/rp_filter              [ENABLED]
  >  /proc/sys/net/ipv4/conf/eth0/rp_filter                 [ENABLED]
  >  /proc/sys/net/ipv4/conf/eth1/rp_filter                 [ENABLED]
  >  /proc/sys/net/ipv4/conf/flannel0/rp_filter             [ENABLED]
  >  /proc/sys/net/ipv4/conf/ip_vti0/rp_filter              [ENABLED]
  >
  >
  > Please completely disable redirects and rp_filter
  >
  > 
https://libreswan.org/wiki/FAQ#Why_is_it_recommended_to_disable_rp_filter_in_.2Fproc.2Fsys.2Fnet_.3F
  >
  > 
https://libreswan.org/wiki/FAQ#Why_is_it_recommended_to_disable_send_redirects_in_.2Fproc.2Fsys.2Fnet_.3F
  >
  > Paul




___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan

Re: [Swan] Problem with setting up ipsec

[Maciej Piechotka]

Possibly interesting data point - I was able to set up ipsec tunnel with
pure Fedora (userspace + kernel) but not Fedora strongswan tools or Centos
libreswan tools on CoreOS kernel.

On Sun, Oct 16, 2016 at 8:56 PM Maciej Piechotka 
wrote:

> Hi Paul,
>
> Sorry - I've tried it before but I forgot to reenable it after
> recreation of VM. However it doesn't help.
>
> Matt
>
> On Sun, Oct 16, 2016 at 6:47 PM, Paul Wouters  wrote:
> > On Sun, 16 Oct 2016, Maciej Piechotka wrote:
> >
> >> I have problem with setting up ipsec. I see ESP packets coming through
> >> but they are dropped during policy check (i.e. XfrmInTmplMismatch is
> >> increased) so in tcpdump only the ESP packets are shown. I could not
> >> find any information how to proceed from here.
> >>
> >> Matt
> >> PS. I disabled receiving messages from this group so please include me
> >> in To: or Cc: list.
> >
> >
> > Note that your barf's did not include log files. But regardless, it
> > shows the kernel ip xfrm state/policy showing the tunnels are up fine.
> >
> > The only thing I can see wrong is:
> >
> > Checking for IPsec support in kernel[OK]
> >  NETKEY: Testing XFRM related proc values
> >  ICMP default/send_redirects[NOT DISABLED]
> >
> >   Disable /proc/sys/net/ipv4/conf/*/send_redirects or NETKEY will act on
> > or cause sending of bogus ICMP redirects!
> >
> >  ICMP default/accept_redirects  [NOT DISABLED]
> >
> >   Disable /proc/sys/net/ipv4/conf/*/accept_redirects or NETKEY will act
> > on or cause sending of bogus ICMP redirects!
> >
> >  XFRM larval drop   [OK]
> > Pluto ipsec.conf syntax [OK]
> > Hardware random device  [N/A]
> > Two or more interfaces found, checking IP forwarding[OK]
> > Checking rp_filter  [ENABLED]
> >  /proc/sys/net/ipv4/conf/all/rp_filter  [ENABLED]
> >  /proc/sys/net/ipv4/conf/default/rp_filter  [ENABLED]
> >  /proc/sys/net/ipv4/conf/eth0/rp_filter [ENABLED]
> >  /proc/sys/net/ipv4/conf/eth1/rp_filter [ENABLED]
> >  /proc/sys/net/ipv4/conf/flannel0/rp_filter [ENABLED]
> >  /proc/sys/net/ipv4/conf/ip_vti0/rp_filter  [ENABLED]
> >
> >
> > Please completely disable redirects and rp_filter
> >
> >
> https://libreswan.org/wiki/FAQ#Why_is_it_recommended_to_disable_rp_filter_in_.2Fproc.2Fsys.2Fnet_.3F
> >
> >
> https://libreswan.org/wiki/FAQ#Why_is_it_recommended_to_disable_send_redirects_in_.2Fproc.2Fsys.2Fnet_.3F
> >
> > Paul
>
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan