cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Lair <sl...@ippathways.com>
Subject RE: VPN/IPSEC problem after upgrading to 4.9.2.0
Date Thu, 23 Feb 2017 22:58:32 GMT
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

Mime
View raw message