[
https://issues.apache.org/jira/browse/CLOUDSTACK-9801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15881642#comment-15881642
]
ASF GitHub Bot commented on CLOUDSTACK-9801:
--------------------------------------------
GitHub user Slair1 opened a pull request:
https://github.com/apache/cloudstack/pull/1966
CLOUDSTACK-9801: IPSec VPN does not work after vRouter reboot or recreate
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")
```
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/Slair1/cloudstack
CLOUDSTACK-9801--IPSec-VPN-does-not-work-after-vRouter-reboot-or-recreate
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cloudstack/pull/1966.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1966
----
----
> 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)
