Looks like this bug was introduced by Pull Request #1423
https://github.com/apache/cloudstack/pull/1423
It added code to start ipsec
(cloudstack/systemvm/patches/debian/config/opt/cloud/bin/configure.py)
if vpnconfig['create']:
logging.debug("Enabling remote access vpn on "+ public_ip)
CsHelper.start_if_stopped("ipsec")
self.configure_l2tpIpsec(public_ip, self.dbag[public_ip])
The issue is that if a reboot is issued from the CloudStack UI (as opposed to
manually by logging into the vRouter), the NICS (except eth0) are not added to
the VM until the cloud service is running.
Since ipsec was started before the nics were added to the VM and before the
public IP address is added to the nic, ipsec is not listening on the public IP
address and all VPNs are broken.
This is not a problem with the Site2Site VPN section of configure.py, because
that section does not start ipsec if the public IP is not on the system yet...
That is my synopsis at least.
Thanks
Sean
-----Original Message-----
From: Sean Lair
Sent: Thursday, February 23, 2017 2:27 PM
To: dev@cloudstack.apache.org
Subject: VPN/IPSEC problem after upgrading to 4.9.2.0
We just upgraded from 4.8.1.1 to 4.9.2.0. After upgrading we rebooted the
virtual routers, and noticed that our site-to-site VPNs and remote-access VPNs
would no longer connect. After troubleshooting, we noticed that Openswan
(ipsec.d) wasn't listening on the vRouter's IPs. Here is the abbreviated
output of "ipsec auto -status" while we were having the issue:
root@r-10-VM:~# ipsec auto --status
000 using kernel interface: netkey
000 interface lo/lo 127.0.0.1
000 interface lo/lo 127.0.0.1
000 interface eth0/eth0 169.254.1.45
000 interface eth0/eth0 169.254.1.45
000 %myid = (none)
Openswan only knows about the loopback and 169.254.1.45 address.... We
rebooted the vRouter several times with the same results. However, if we
manually stopped and started ipsec, then issued a "ipsec auto -status", the
abbreviated output would be:
root@r-10-VM:~# ipsec auto --status
000 using kernel interface: netkey
000 interface lo/lo 127.0.0.1
000 interface lo/lo 127.0.0.1
000 interface eth0/eth0 169.254.1.45
000 interface eth0/eth0 169.254.1.45
000 interface eth1/eth1 192.103.11.172
000 interface eth1/eth1 192.103.11.172
000 interface eth2/eth2 192.168.1.1
000 interface eth2/eth2 192.168.1.1
000 %myid = (none)
Openswan now knows about the additional interfaces and VPNs function as
expected... It's like ipsec.d is started before all of the interfaces are
configured? Is this a known bug or I am off-base with my analysis somehow?
Thanks
Sean
