cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Lair <sl...@ippathways.com>
Subject VPN/IPSEC problem after upgrading to 4.9.2.0
Date Thu, 23 Feb 2017 20:26:30 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message