[
https://issues.apache.org/jira/browse/CLOUDSTACK-9801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16118243#comment-16118243
]
ASF subversion and git services commented on CLOUDSTACK-9801:
-------------------------------------------------------------
Commit a5778139c2205971a0210f30ce537217ef0a2473 in cloudstack's branch
refs/heads/debian9-systemvmtemplate from [~slair1]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=a577813 ]
CLOUDSTACK-9801: IPSec VPN does not work after vRouter reboot or recreate
(#1966)
This makes sure IP address is active.
After a vRouter is recreated (e.g. reboot via CloudStack UI) and Remote Access
VPN enabled, VPN won't work anymore. 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)
After this commit, the following occurs and VPNs work:
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 xxx.xxx.xxx.172
000 interface eth1/eth1 xxx.xxx.xxx.172
000 interface eth2/eth2 192.168.1.1
000 interface eth2/eth2 192.168.1.1
000 %myid = (none)
eth1 interface IP is masked, but now ipsec sees all the interfaces and VPN
works.
Looks like this bug was introduced by Pull Request #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")
> IPSec VPN does not work after vRouter reboot or recreate
> --------------------------------------------------------
>
> Key: CLOUDSTACK-9801
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9801
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
> Affects Versions: 4.9.0, 4.9.2.0, 4.9.0.1
> Environment: Tested in XenServer as hypervisor. With RemoteAccess
> VPN enabled. Both Remote Access VPN and Site to Site VPN functionality won't
> work.
> Reporter: Sean Lair
> Priority: Critical
> Labels: ipsec, virtual-router, vpc, vpn
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> After a vRouter is recreated (which happens when a reboot via CloudStack UI
> for example) and Remote Access VPN enabled, VPN won't work anymore. 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)
> Notice that only eth0 is shown, not the public interface eth1. Because of
> that ipsec is broken.
> 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 xxx.xxx.xxx.172
> 000 interface eth1/eth1 xxx.xxx.xxx.172
> 000 interface eth2/eth2 192.168.1.1
> 000 interface eth2/eth2 192.168.1.1
> 000 %myid = (none)
> eth1 interface IP is masked, but now ipsec sees all the interfaces and VPN
> works.
> 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...
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
