cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLOUDSTACK-9801) IPSec VPN does not work after vRouter reboot or recreate
Date Fri, 04 Aug 2017 18:47:00 GMT

    [ https://issues.apache.org/jira/browse/CLOUDSTACK-9801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16114805#comment-16114805
] 

ASF subversion and git services commented on CLOUDSTACK-9801:
-------------------------------------------------------------

Commit a5778139c2205971a0210f30ce537217ef0a2473 in cloudstack's branch refs/heads/4.10 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)

Mime
View raw message