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 <[email protected]> Sent: Friday, December 7, 2018 7:15:35 AM To: Jonathan Thompson Cc: [email protected] 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
_______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
