[Swan] Opportunistic Encryption in VirtualBox

Fri Dec 7 23:13:57 UTC 2018

I was able to get this to work! Just wanted to follow up with the solution:

I had to eliminate the "leftid=%fromcert", and replace it with "leftrsasigkey=%cert", and things are working now!

Here's the full configuration:

oe-certificate.conf

------

conn private
        # IPsec mandatory
        authby=rsasig
        rightrsasigkey=%cert
        right=%opportunisticgroup
        rightca=%same
        leftrsasigkey=%cert
        left=<machine ip, if ipsec is running on an interface other than the default>
        leftcert=yourhostname
        narrowing=yes
        type=tunnel
        ikev2=insist
        auto=ondemand
        # tune remaining options to taste - fail fast to prevent packet loss to the app
        negotiationshunt=hold
        failureshunt=drop
        # 0 means infinite tries
        keyingtries=0
        retransmit-timeout=3s

------

________________________________
From: Jonathan Thompson
Sent: Friday, December 7, 2018 12:13:54 PM
To: Paul Wouters
Cc: swan at lists.libreswan.org
Subject: Re: [Swan] Opportunistic Encryption in VirtualBox

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:

/etc/centos-release:

------

CentOS Linux release 7.6.1810 (Core)

------

Here are the logs after running with plutodebug=all:

192.168.50.3 (ping originator): https://pastebin.com/iS6ws1VF

192.168.50.2 (ping target): https://pastebin.com/U5YGJijH

Thanks again,

-Jonathan
________________________________
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
leftauth/rightauth.

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#192.168.50.0/24"[1] ...192.168.50.3 #1: switched from
> "private#192.168.50.0/24"[1] ...192.168.50.3 to "private#192.168.50.0/24"

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#192.168.50.0/24"[2] ...192.168.50.3===? #1: certificate verified OK:
> CN=192.168.50.3,*************
> Dec  7 00:16:04.782210: "private#192.168.50.0/24"[2] ...192.168.50.3===? #1: Authenticated using RSA
> Dec  7 00:16:04.785707: "private#192.168.50.0/24"[2] ...192.168.50.3===? #1: responding to AUTH message (ID 1)
> from 192.168.50.3:500 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#192.168.50.0/24"[1] ...192.168.50.2 #1: responding to INFORMATIONAL message
> (ID 0) from 192.168.50.2:500 with encrypted notification INVALID_IKE_SPI

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

> 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.

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