[
https://issues.apache.org/jira/browse/CLOUDSTACK-9801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15881766#comment-15881766
]
ASF GitHub Bot commented on CLOUDSTACK-9801:
--------------------------------------------
Github user swill commented on the issue:
https://github.com/apache/cloudstack/pull/1966
I can't see what branch this is opened against on my phone. What version of
ACS is this opened against and which version do you have a problem in. The
reason I ask is because #1741 was added in master to upgrade from openswan to
strongswan. . Thx...
> 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.3.15#6346)
