You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Sean Lair <sl...@ippathways.com> on 2017/02/23 20:26:30 UTC
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
RE: VPN/IPSEC problem after upgrading to 4.9.2.0
Posted by Sean Lair <sl...@ippathways.com>.
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