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

[D. Hugh Redelmeier]

New commits:
commit e987cf92205ee19ae11ebfc9d62cab8b8ce15538
Author: D. Hugh Redelmeier 
Date:   Fri Jul 20 22:41:03 2018 -0400

libipsecconf: since resolvip isn't used, get rid of it

___
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

[D. Hugh Redelmeier]

New commits:
commit f01486bbd06322d73ce782f98334d5a5c37b51a7
Author: D. Hugh Redelmeier 
Date:   Fri Jul 20 22:16:59 2018 -0400

pervasive: use PRINTF_LIKE and UNUSED instead of bulky GCC-isms

___
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

[D. Hugh Redelmeier]

New commits:
commit 12b0082e835ffee4b37ac76850f243e2068c295b
Author: D. Hugh Redelmeier 
Date:   Fri Jul 20 22:00:13 2018 -0400

libipsecconf: respect that starter_error_append takes a format

___
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

[Andrew Cagney]

New commits:
commit d0a999e96d887871563be4e03d9c9ef044a850f5
Author: Andrew Cagney 
Date:   Fri Jul 20 16:48:08 2018 -0400

building: add mk/configs.mk that builds a few random config combinations

___
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

[Andrew Cagney]

New commits:
commit 30b52bfffdbc8e3f11631c45f921ebc4c00f4787
Author: Andrew Cagney 
Date:   Fri Jul 20 16:41:03 2018 -0400

building: only set SO_PRIORITY on systems that support it

___
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

[Andrew Cagney]

New commits:
commit bc0f64cf79bfc77ffb15ed3a7fb976f64b31d8fd
Author: Andrew Cagney 
Date:   Fri Jul 20 15:49:49 2018 -0400

building: cleanup plutomain.c's #include list

___
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

[Andrew Cagney]

New commits:
commit b16c2d16c16b1ff16e003fd4384a855170f2e176
Author: Andrew Cagney 
Date:   Fri Jul 20 15:39:57 2018 -0400

building: "kernel.h" needs "connections.h" for policy_prio_t

___
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

[Andrew Cagney]

New commits:
commit 79651c29254397a3c474e88da9cc5e1fcc5f59fb
Author: Andrew Cagney 
Date:   Fri Jul 20 15:34:25 2018 -0400

building: suck all of packet.h into vendor.h so that the pb_stream typedef 
is defined

Which I think is lame.  A better solution would be to drop the
pb_stream typedef and instead use struct packet_byte_stream in the
reference parameter.

___
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

[Andrew Cagney]

New commits:
commit 553f7ee85db1716a8c15504b47e3df5975ee5d95
Author: Andrew Cagney 
Date:   Fri Jul 20 15:31:15 2018 -0400

building: directly include more of "virtual.h"'s dependencies

___
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

[Andrew Cagney]

New commits:
commit 84e89d47bfb960df5d738154359527693bacc74e
Author: Andrew Cagney 
Date:   Fri Jul 20 15:28:20 2018 -0400

Revert "kernel: sort the listed algorithms by FQN"

Oops; hiding behind another commit.  Change not yet ready for prime time.

This reverts commit 1b50f053c20b7e91fdc919c3e5c965de35adc78d.

___
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

[Andrew Cagney]

New commits:
commit e912b952e1c2f88f3d3dc4e29df745cc19a0df19
Author: Andrew Cagney 
Date:   Fri Jul 20 15:24:32 2018 -0400

building: wrap connections.h in #ifdef CONNECTIONS_H

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

Re: [Swan-dev] lost art: using TPM for entropy

[Andrew Cagney]

FYI,

The place I normally notice a lack of entropy is at the start while
the keys are being created.  So during a test run would be new issue.

Have a look in the debug.log for an unresolved test.  Since it
contains all the boot messages you might be able to spot a pattern for
what is taking so long.

Andrew


































































































On Fri, 20 Jul 2018 at 11:36, D. Hugh Redelmeier  wrote:
>
> I used to use an old machine for testing.  After a long hiatus, I'm
> trying again, with a fresh install of everything
>
> The processor is an Intel i5-2400 "Sandy Bridge".  This processor does not
> have the RDRAND feature.  You can test your own processor:
> grep rdrand /proc/cpuinfo
>
> To get more entropy without RDRAND, I used to use the TPM feature of
> the computer.  I wrote it up here:
> 
>
> This does not work on Fedora 28.  The most obvious thing is that there
> no longer is a tpm-rng module in the kernel:
> Jul 19 22:39:14 localhost.localdomain systemd-modules-load[490]: Failed to 
> find module 'tpm-rng'
>
> Consequently rngd fails.
> Jul 19 22:39:15 localhost.localdomain rngd[686]: Failed to init entropy 
> source 1: TPM RNG Device
> Jul 19 22:39:15 localhost.localdomain rngd[686]: Failed to init entropy 
> source 2: Intel RDRAND Instruction RNG
> Jul 19 22:39:15 localhost.localdomain rngd[686]: Enabling JITTER rng support
>
> I think that JITTER is a new user-space entropy gleaner.  I imagine
> that TPM RNG would still be beneficial.
>
> Does anyone know what the new way of using the TPM RNG?  Is there any
> documentation of this?  random(4) and random(7) don't help.
>
> This is intriguing but not actually helpful:
> 
> It suggests that the tpm driver does have a function "tpm_add_hwrng"
> but doesn't say how it might get invoked.
>
> Somewhere in here might be something useful:
> [build@redbird libreswan]$ find /sys -name 'tpm*'
> /sys/kernel/security/tpm0
> find: ‘/sys/kernel/debug’: Permission denied
> /sys/class/tpmrm
> /sys/class/tpm
> /sys/class/tpm/tpm0
> /sys/devices/pnp0/00:04/tpm
> /sys/devices/pnp0/00:04/tpm/tpm0
> find: ‘/sys/fs/pstore’: Permission denied
> find: ‘/sys/fs/bpf’: Permission denied
> /sys/bus/platform/drivers/tpm_tis
> /sys/bus/pnp/drivers/tpm_tis
> /sys/bus/acpi/drivers/tpm_crb
> /sys/module/tpm_tis
> /sys/module/tpm_crb
> /sys/module/tpm_tis_core
> /sys/module/tpm
>
> Reading this code, I would have expected a tpm-rngd-%d
> 
>
> 
>
> It is possible that the TPM is being used automatically.  But I have
> suspiciously many tests coming out "unresolved".  And the whole test
> run seems to be taking a long time.  For example, right now 399 of 746
> tests have been run and 231 are unresolved.
>
> My other test machine (with RDRAND hardware) gets more unresolved
> results than Andrew expects.  Sometimes 20 at the end of a whole run.
> I thought that the problem might be that it uses a hard disk.  So I
> put an SSD in the Sandy Bridge machine but unresolved gets a lot
> worse.
>
> 
>
> I have not set
> /etc/modules-load.d/virtio.conf
> as specified by
> 
> 
> There's too little explanation for me to trust it.
>
> Perhaps that is my problem.___
> Swan-dev mailing list
> Swan-dev@lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan-dev
___
Swan-dev mailing list
Swan-dev@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan-dev

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

[Paul Wouters]

New commits:
commit 810cef8b6d5959b03f8de7ca2221c7dbca184ced
Author: Paul Wouters 
Date:   Fri Jul 20 14:33:11 2018 -0400

testing: fixup output to match we no longer have "import:" output

___
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 feb534b669266442b136babce9ae316176b169d3
Author: Paul Wouters 
Date:   Fri Jul 20 14:23:54 2018 -0400

pluto: Remove st_import and pcim_* importance enum and values

While it was set and passed around everywhere, there was no more
code point left where it was used to make any kind of decision.

___
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

[Andrew Cagney]

New commits:
commit 48efefa36c6bcc82f337bed6981ee05e1a33b255
Author: Andrew Cagney 
Date:   Fri Jul 20 14:20:44 2018 -0400

building: sprinkle #ifdef USE_AES and/or USE_CAMELLIA

commit 1b50f053c20b7e91fdc919c3e5c965de35adc78d
Author: Andrew Cagney 
Date:   Fri Jul 20 13:48:53 2018 -0400

kernel: sort the listed algorithms by FQN

Which means that the order does not depend on the back-end
specifiic SADB id.

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

Re: [Swan-dev] skipping init_pfkey()

[Andrew Cagney]

On Thu, 19 Jul 2018 at 09:38, Paul Wouters  wrote:
>
>
> Note that calling the kernel functions for registration might do
> something inside the kernel. Since we are modprobing most things
> now, we are likely not using it now. But soon when there is an
> XFRM version to replace the PF_KEY function in the kernel, that
> function will actually initialise (and/or load kernel module)
> when initialising. So we might have to re-instate something
> again soon.

Yea. NETLINK_XFRM fixing this would be nice.  The hooks are all still there.

I suspect this all works because 'ipsec start' forces all the required
kernel modules to be loaded before starting pluto (true?).  Even with
this change applied west.console.verbose.txt contains logs from what
look like kernel modules being loaded:

# ipsec start
[   63.953008] sha512_ssse3: Neither AVX nor SSSE3 is available/usable.
[   63.959133] sha256_ssse3: Neither AVX nor SSSE3 is available/usable.
[   63.981318] AVX instructions are not detected.

and this is well before the point where pluto probes the kernel for
supported algorithms (that happens during the connection).

Andrew


> Paul
>
> -- Forwarded message --
> Date: Thu, 19 Jul 2018 08:30:49
> From: Andrew Cagney 
> To: swan-com...@lists.libreswan.org
> Subject: [Swan-commit] Changes to ref refs/heads/master
>
> New commits:
> commit b248daa3564a55c216632d928d9028f56e478158
> Author: Andrew Cagney 
> Date:   Wed Jul 18 22:44:28 2018 -0400
>
>  xfrm: don't call init_pfkey() during initialization
>
>  No need since algorithms are all hardwired.
>
>  Leave the comment: PF_KEY API in Linux with netkey is a joke that
>  should be abandoned ...
>
> ___
> Swan-commit mailing list
> swan-com...@lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan-commit
> ___
> Swan-dev mailing list
> Swan-dev@lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan-dev
___
Swan-dev mailing list
Swan-dev@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan-dev

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

[Andrew Cagney]

New commits:
commit 489c579e4811212f73a9678cf442b9d61c41c92f
Author: Andrew Cagney 
Date:   Fri Jul 20 12:04:02 2018 -0400

building: delete dead code in mk/tests.sh

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

[Swan-dev] Cleaning up #includes in .c files

[Andrew Cagney]

As Antony's notice. I've been aggressively pruning the #includes for
various C files. Think of this as paying back the technical debt we've
accumulated over the years:

- when the file was created, instead of starting the #include list
from scratch, some existing list of #includes was cut/pasted
- for others, when the file was written, linux headers were pretty
messed up but that has long since been fixed

The problem is that I really can't cover all possible configurations.
However, what I'll do is add a few more to my list of test builds.
If anyone knows of a linting tool for helping here, let me know.

Andrew

-- Forwarded message -
From: Antony Antony 
Date: Fri, 20 Jul 2018 at 05:53
Subject: [Swan-commit] Changes to ref refs/heads/master
To: 


New commits:
commit 9e52c55ebb9199577fd75df5fe9fa973038869a4
Author: Antony Antony 
Date:   Fri Jul 20 11:51:12 2018 +0200

addcon: include netdb.h

92ceb628b was a bit aggressive.
addcon fails to compile with USE_DNSSEC=false

/home/build/libreswan/lib/libswan/addr_lookup.c:58:8: error:
implicit declaration of function 'getnameinfo'
[-Werror=implicit-function-declaration]
getnameinfo(sa,
^
/home/build/libreswan/lib/libswan/addr_lookup.c:58:8: error:
nested extern declaration of 'getnameinfo' [-Werror=nested-externs]

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

[Swan-dev] lost art: using TPM for entropy

[D. Hugh Redelmeier]

I used to use an old machine for testing.  After a long hiatus, I'm 
trying again, with a fresh install of everything

The processor is an Intel i5-2400 "Sandy Bridge".  This processor does not 
have the RDRAND feature.  You can test your own processor:
grep rdrand /proc/cpuinfo

To get more entropy without RDRAND, I used to use the TPM feature of
the computer.  I wrote it up here:


This does not work on Fedora 28.  The most obvious thing is that there
no longer is a tpm-rng module in the kernel:
Jul 19 22:39:14 localhost.localdomain systemd-modules-load[490]: Failed to find 
module 'tpm-rng'

Consequently rngd fails.
Jul 19 22:39:15 localhost.localdomain rngd[686]: Failed to init entropy source 
1: TPM RNG Device
Jul 19 22:39:15 localhost.localdomain rngd[686]: Failed to init entropy source 
2: Intel RDRAND Instruction RNG
Jul 19 22:39:15 localhost.localdomain rngd[686]: Enabling JITTER rng support

I think that JITTER is a new user-space entropy gleaner.  I imagine
that TPM RNG would still be beneficial.

Does anyone know what the new way of using the TPM RNG?  Is there any
documentation of this?  random(4) and random(7) don't help.

This is intriguing but not actually helpful:

It suggests that the tpm driver does have a function "tpm_add_hwrng"
but doesn't say how it might get invoked.

Somewhere in here might be something useful:
[build@redbird libreswan]$ find /sys -name 'tpm*'
/sys/kernel/security/tpm0
find: ‘/sys/kernel/debug’: Permission denied
/sys/class/tpmrm
/sys/class/tpm
/sys/class/tpm/tpm0
/sys/devices/pnp0/00:04/tpm
/sys/devices/pnp0/00:04/tpm/tpm0
find: ‘/sys/fs/pstore’: Permission denied
find: ‘/sys/fs/bpf’: Permission denied
/sys/bus/platform/drivers/tpm_tis
/sys/bus/pnp/drivers/tpm_tis
/sys/bus/acpi/drivers/tpm_crb
/sys/module/tpm_tis
/sys/module/tpm_crb
/sys/module/tpm_tis_core
/sys/module/tpm

Reading this code, I would have expected a tpm-rngd-%d




It is possible that the TPM is being used automatically.  But I have
suspiciously many tests coming out "unresolved".  And the whole test
run seems to be taking a long time.  For example, right now 399 of 746
tests have been run and 231 are unresolved.

My other test machine (with RDRAND hardware) gets more unresolved
results than Andrew expects.  Sometimes 20 at the end of a whole run.
I thought that the problem might be that it uses a hard disk.  So I
put an SSD in the Sandy Bridge machine but unresolved gets a lot
worse.



I have not set
/etc/modules-load.d/virtio.conf
as specified by


There's too little explanation for me to trust it.

Perhaps that is my problem.___
Swan-dev mailing list
Swan-dev@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan-dev

Re: [Swan-dev] qemu-img: Could not open '/home/build/pool/swanfedora22base.qcow2

[Andrew Cagney]

On Fri, 20 Jul 2018 at 10:30, D. Hugh Redelmeier  wrote:
>
> | From: Andrew Cagney 
> |
> | I'm guessing the most recent fedora?
>
> Yeah, fresh F28 install and up to date.
>
> Machine is old: i5-2400.  Which is causing entropy problems, but that's
> another story.
>
> Spoiler:
>
> The problem was that I somehow skipped adding the test user to the qemu group:
> 
> I've slightly improved the makefile's reaction to this problem. There
> is still room for improvement.

I think it is the best fix available.  Thanks.

> Surprising fact: so far this is the only place where the lack of
> group membership snagged me.
>
> | On Fri, 20 Jul 2018 at 00:12, D. Hugh Redelmeier  wrote:
> | >
> | > I'm setting up a new test system.
> | >
> | > make kvm-install failed with this message:
> | >
> | >
> | > qemu-img convert \
> | > -p -O qcow2 \
> | > /home/build/pool/swanfedora22base.qcow2 \
> | > /home/build/pool/a.clone.qcow2.tmp
> | > qemu-img: Could not open '/home/build/pool/swanfedora22base.qcow2': Could 
> not open '/home/build/pool/swanfedora22base.qcow2': Permission denied
> | >
> | > observations:
> | > -rw-r-. 1 root  qemu  8591507456 Jul 19 23:22 swanfedora22base.qcow2
> | >
> | > -rwxr-xr-x. 1 root root 1773200 Jul  3 13:42 /usr/bin/qemu-img
> | >
> | > This would work if qemu-img were setgid qemu.
> | > The makefile seems to expect that to be the case.
> |
> | Why?  No.  Only running a VM needs SUDO (and that annoys me).
>
> One doesn't need set GID qemu if one is already in the group. :-)

Interesting.

Perhaps someone knows of a how-to explaining the 'correct' way to set
up what we do such that SUDO isn't needed.  My last round of research
didn't inspire confidence:

# The alternative is qemu:///session and it doesn't require root.
# However, it has never been used, and the python tools all assume
# qemu://system. Finally, it comes with a warning: QEMU usermode
# session is not the virt-manager default.  It is likely that any
# pre-existing QEMU/KVM guests will not be available.  Networking
# options are very limited.
KVM_CONNECTION ?= qemu:///system
VIRSH = sudo virsh --connect $(KVM_CONNECTION)

> | > On the other hand, my old test system has the same file ownerships and
> | > permissions.
> |
> | I'd suspect something around the images creation - virt-install or
> | your own umask?
>
> At my build account's shell prompt, umask is 0002.  On both the old and
> new system.  I have not changed the Fedora default.
>
> | What's the ownership on the old system?
>
> -rw-r-. 1 root qemu 8591507456 Sep 17  2017 swanfedorabase.qcow2
>
> In other words, the same.
>
> But this old system has incrementally migrated from old Fedora and old
> Libreswan.  I guess that the datestamp on the file gives hints of this.
> |
> | > Doing this
> | > sudo chmod a+r ../pool/swanfedora22base.qcow2
> | > make kvm-install
> | > gets past this point.
>
> Even though this chmod isn't recommended, it seems to solve the
> problem.  Is this better than adding the user to the qemu group?
>
> Looking back on the transcript, this is how swanfedora22base.qcow2 got
> created:
>
>
> : XXX: Passing --security type=static,model=dac,label='1001:107',relabel=yes 
> to virt-install causes it to panic
> sudo virt-install --connect qemu:///system \
> --name=swanfedora22base \
> --os-variant fedora22 \
> --vcpus=1 \
> --memory 1024 \
> --nographics \
> --disk 
> size=8,cache=writeback,path=/home/build/pool/swanfedora22base.qcow2 \
> --network=network:swandefault,model=virtio \
> --rng type=random,device=/dev/random \
> --location=/home/build/pool/Fedora-Server-DVD-x86_64-22.iso \
> --initrd-inject=testing/libvirt/fedora22.ks \
> --extra-args="swanname=swanfedora22base ks=file:/fedora22.ks 
> console=tty0 console=ttyS0,115200 net.ifnames=0 biosdevname=0" \
> --noreboot
>
> So that explains why it is owned by root.
>
> Later the failure shows up.  Here it is with a bit more context.
>
> test -r /home/build/pool/swanfedora22base.qcow2 || sudo chgrp 107 
> /home/build/pool/swanfedora22base.qcow2
> test -r /home/build/pool/swanfedora22base.qcow2 || sudo chmod g+r  
> /home/build/pool/swanfedora22base.qcow2
> : create a full copy
> rm -f /home/build/pool/a.clone.qcow2
> qemu-img convert \
> -p -O qcow2 \
> /home/build/pool/swanfedora22base.qcow2 \
> /home/build/pool/a.clone.qcow2.tmp
> (0.00/100%)^Mqemu-img: Could not open 
> '/home/build/pool/swanfedora22base.qcow2': Could not open 
> '/home/build/pool/swanfedora22base.qcow2': Permission denied
> ___
> Swan-dev mailing list
> Swan-dev@lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan-dev
___
Swan-dev mailing list
Swan-dev@lists.libreswan.org

Re: [Swan] one way ping

[John Crisp]

On 20/07/18 15:08, Paul Wouters wrote:
> Not too much to add but in the past I know that dummy interfaces could eat 
> packets.
>

As a further follow up two things seemed to affect it.

One was the use of a 'dummy0' address. As the machine was on a VM I gave
it a 'Private' adaptor, which it then detected and added with a virt_io
device.

However, that still didn't seem to work. So I looked at the networking.

I had decided to use DHCP to configure the external device.

This gave the following

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref    Use
Iface
169.254.169.254 222.250.226.1   255.255.255.255 UGH   0  0    0 eth0
10.0.0.0    222.250.226.1   255.255.255.0   UG    0  0    0 eth0
192.168.81.0    *   255.255.255.0   U 0  0    0 eth1
192.168.10.0    222.250.226.1   255.255.255.0   UG    0  0    0 eth0
222.250.226.0   *   255.255.254.0   U 0  0    0 eth0
default 222.250.226.1   0.0.0.0 UG    0  0    0 eth0


inet addr:222.250.227.83  Bcast:222.250.227.255  Mask:255.255.254.0

(real IP obfuscated slightly)


I have a feeling the 'Destination' may have caused the issue, though I
am not 100% on this.

I changed the IP to static and now have this, and it works


Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref    Use
Iface
222.250.226.1   *   255.255.255.255 UH    0  0    0 eth0
10.0.0.0    222.250.226.1   255.255.255.0   UG    0  0    0 eth0
192.168.81.0    *   255.255.255.0   U 0  0    0 eth1
192.168.10.0    222.250.226.1   255.255.255.0   UG    0  0    0 eth0
222.250.226.0   *   255.255.254.0   U 0  0    0 eth0
default 222.250.226.1   0.0.0.0 UG    0  0    0 eth0


So a combination of driver/port and IP addressing seem to be at the
heart of it.

I am wondering if there is a setting in ipsec that may have got round
this (the addresing, not the dummy0 issue)?

nexthop perhaps?


signature.asc
Description: OpenPGP digital signature
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan

Re: [Swan] one way ping

[Paul Wouters]

Not too much to add but in the past I know that dummy interfaces could eat 
packets.

Paul

Sent from my phone

> On Jul 20, 2018, at 07:17, John Crisp  wrote:
> 
>> On 20/07/18 11:36, John Crisp wrote:
>> 
>> I have reason to suspect that this may be the cause of my problems.
>> 
> 
> Hmmm - maybe not, because logically it is working because once I ping
> from Libre -> Endian I can then ping from Endian -> Libre indicating
> that the underlying networking is functioning.
> 
> Thank god it is Friday.
> 
> ___
> 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

Re: [Swan] one way ping

[John Crisp]

On 20/07/18 11:36, John Crisp wrote:
> 
> I have reason to suspect that this may be the cause of my problems.
> 

Hmmm - maybe not, because logically it is working because once I ping
from Libre -> Endian I can then ping from Endian -> Libre indicating
that the underlying networking is functioning.

Thank god it is Friday.



signature.asc
Description: OpenPGP digital signature
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan

Re: [Swan] vti - route script fails with wrong address

[Heiko Helmle]

Hello list,

i ugpraded the libreswan packages to 3.25 from the Libreswan repositories, as 
there seemed to be a revamped _updown.netkey script in the package...

but it still fails with a wrong route target while trying to route it.

Is this supposed to fail? Is the routing command really supposed to use 
PLUTO_NEXTHOP in a vti configuration?  Because only the real interface sees 
PLUTO_NEXTHOP - the vti device uses PLUTO_PEER as PtP-Remote-IP.
If the script used PLUTO_PEER instead, it might work?

Still confused...

Best Regards
Heiko



Von: Swan  Im Auftrag von Heiko Helmle
Gesendet: Freitag, 6. Juli 2018 14:22
An: swan@lists.libreswan.org
Betreff: [Swan] vti - route script fails with wrong address

Hello Libreswan-Users,

i'm having trouble trying out vti-based tunnels.

I'm using libreswan-3.23-5.el7_5.x86_64 - (from the CentOS repos).

Connection is roughly this:
Left = %defaultroute
Leftsourcip, leftsubnet and rightsubnet are defined
Vti-interface and mark are defined.

Ipsec auto -add works, but
Ipsec auto -route fails:

route-client output: /usr/libexec/ipsec/_updown.netkey: doroute "ip route 
replace (rightsubnet) via (defaultroute) dev (vti-interface)  src 
(leftsourceip)" failed (RTNETLINK answers: Network is unreachable)

The script is trying to use the (real) interface's default route as a routing 
target on the vti device - and fails.

Could anyone point me where I'd have to look closer? Or is vti only supposed to 
work with left/rightsubnet set to 0.0.0.0?

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

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

[Antony Antony]

New commits:
commit 9e52c55ebb9199577fd75df5fe9fa973038869a4
Author: Antony Antony 
Date:   Fri Jul 20 11:51:12 2018 +0200

addcon: include netdb.h

92ceb628b was a bit aggressive.
addcon fails to compile with USE_DNSSEC=false

/home/build/libreswan/lib/libswan/addr_lookup.c:58:8: error: implicit 
declaration of function 'getnameinfo' [-Werror=implicit-function-declaration]
getnameinfo(sa,
^
/home/build/libreswan/lib/libswan/addr_lookup.c:58:8: error: nested extern 
declaration of 'getnameinfo' [-Werror=nested-externs]

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

Re: [Swan] one way ping

[John Crisp]

On 20/07/18 09:51, Roberto Suárez Soto wrote:
> El 20/07/18 a las 01:43, John Crisp escribió:
>> However, once up I can only ping from the Libre end -> Endian.
>>
>> Once a ping has been sent, magically I can ping from the Endian back to
>> Libre
>
> I've seen this happen when the firewall at one end ("Libre", in this
> case) doesn't allow incoming IPSec connections, or maybe just ESP
> traffic (or, if encapsulated, 4500/udp). It doesn't work when initiating
> the connection (i.e., ping) from the other side, but when you do it from
> the Libre side, the replies get into the "related" state and are
> allowed. If this is the case, you may see the dropped packets in Libre's
> logs.
>
> My 2¢, anyway.
>
Thanks !

I was checking in the cold hard light of day after a decent nights sleep
and noticed there is one significant difference I had missed.

The working versions are Proxmox VMs with virtual ethernet adaptors
using a virtio_net driver on both the 'real' outside interface and the
'dummy' internal one. That puts the machine in server-gateway mode so
the firewalling works etc etc

But the two non working machines have a ethernet dummy adaptor set up on
the 'internal' interface and that has no driver.

I have reason to suspect that this may be the cause of my problems.

I'll post back once I test a bit more

B. Rgds
John



signature.asc
Description: OpenPGP digital signature
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan

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

[Antony Antony]

New commits:
commit 8d82c84b4bd81636eb791c4bc5ee111da57ecd9f
Author: Antony Antony 
Date:   Fri Jul 20 11:30:44 2018 +0200

addcon: include lswlog.h

92ceb628b was a bit aggressive.
addcon fails to compile with USE_SECCOMP=false

/home/build/libreswan/programs/addconn/addconn.c:538:20: error: 
'RC_UNKNOWN_NAME' undeclared (first use in this function); did you mean 
'AI_CANONNAME'?
 exit_status += RC_UNKNOWN_NAME; /* cause non-zero exit code */

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

Re: [Swan] one way ping

[Roberto Suárez Soto]

El 20/07/18 a las 01:43, John Crisp escribió:
> However, once up I can only ping from the Libre end -> Endian.
>
> Once a ping has been sent, magically I can ping from the Endian back to
> Libre

    I've seen this happen when the firewall at one end ("Libre", in this
case) doesn't allow incoming IPSec connections, or maybe just ESP
traffic (or, if encapsulated, 4500/udp). It doesn't work when initiating
the connection (i.e., ping) from the other side, but when you do it from
the Libre side, the replies get into the "related" state and are
allowed. If this is the case, you may see the dropped packets in Libre's
logs.

    My 2¢, anyway.

    Greetings,

-- 
Roberto Suárez Soto
Allenta Consulting  (+34 881 922 600)
ISO 9001, ISO 14001, ISO 27001, EMAS 
Privacidad / Privacy 
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan