[Swan] Opportunistic Encryption in VirtualBox

Jonathan Thompson jonathan.thompson at polarisalpha.com
Fri Dec 7 19:13:54 UTC 2018

Thanks for the quick response!

1) I am definitely aiming for the "enterprise mesh" deployment, so it sounds like symmetric auth is the right way to go.

2) I went ahead and removed the "interfaces" line to keep things clean.

3) No problem - I'm using Ansible to deploy anyway, so it's not a huge deal to specify the network interface in the "left" field in oe-certificate.conf.

I am indeed using libreswan 3.25; here's my CentOS version, in case that's relevant:



CentOS Linux release 7.6.1810 (Core)


Here are the logs after running with plutodebug=all: (ping originator): https://pastebin.com/iS6ws1VF (ping target): https://pastebin.com/U5YGJijH

Thanks again,

From: Paul Wouters <paul at nohats.ca>
Sent: Friday, December 7, 2018 7:15:35 AM
To: Jonathan Thompson
Cc: swan at lists.libreswan.org
Subject: Re: [Swan] Opportunistic Encryption in VirtualBox

On Fri, 7 Dec 2018, Jonathan Thompson wrote:

> I'm working on setting up a libreswan testbed in VirtualBox with two virtual machines utilizing opportunistic
> encryption. I'm following the guide here: https://libreswan.org/wiki/HOWTO:_Opportunistic_IPsec

> 1) Both "rightauth" and "leftauth" need to be set to "rsasig" in /etc/ipsec.d/oe-certificate.conf.

that really depends on what kind of Opportunistic you want. If this is
for the "enterprise mesh" kind of deployment, then yes it is usually
symmetric and you can use authby=rsasig without using

If you want to support anonymous connections to servers (eg
Opportunistic on public internet servers) then you use asymmetric
authentication where the client uses authnull.

> 2) In VirtualBox, I'm using an internal network to connect the two machines which isn't exposed to the host
> machine. Since the default route for VirtualBox VMs is eth0, I had to configure IPSec to run on the eth1
> interface by specifying 'interfaces="ipsec0=eth1"'.

That looks suspicious. I assume you are not using the KLIPS IPsec stack
but the buildin XFRM/NETKEY IPsec stack, and then the interfaces= line
is ignored.

> 3) Since I'm using a network interface other than the %defaultroute, it seems I had to manually set "left=<eth1
> ip>" in oe-certificate.conf. Is there a more elegant way to accomplish this? (like, a %ipsec0 magic, which I
> tried out of curiosity but didn't work. Couldn't find more documentation on that.).

Unfortunately, that is probably the only workaround for that right now.

> Once that's all done and ipsec is restarted, I ping one machine from the other, and get the following result in
> the pluto logs:

> Dec  7 00:16:04.780176: "private#"[1] ... #1: switched from
> "private#"[1] ... to "private#"

Hmm it is switching from the instance of the template back to the
template, which seems wrong. Is this an older version of libreswan?
Please use at least 3.25. (odd that is what you are using it seems)

> Dec  7 00:16:04.781855: "private#"[2] ... #1: certificate verified OK:
> CN=,*************
> Dec  7 00:16:04.782210: "private#"[2] ... #1: Authenticated using RSA
> Dec  7 00:16:04.785707: "private#"[2] ... #1: responding to AUTH message (ID 1)
> from with encrypted notification AUTHENTICATION_FAILED

It's odd it authenticated and then entered the failure path. Perhaps
rerun with plutodebug=all to see what's going on? But I suspect an
older (broken) version....

> Dec  7 00:16:04.784864: "private#"[1] ... #1: responding to INFORMATIONAL message
> (ID 0) from with encrypted notification INVALID_IKE_SPI

This just looks like one end restarted and some old messages are getting

> I'm working from the base 'centos/7' Vagrant image. I can add the Vagrantfile I'm using as well.
> Thanks in advance! I'm hoping this is something super simple. Please let me know what other information I can
> provide to help.

Please add plutodebug=all and post the log somewhere so I can have a
look at it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20181207/c7651c23/attachment.html>

More information about the Swan mailing list