cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLOUDSTACK-5501) Unable to create more than one vpnConnection per vpn customer gateway
Date Mon, 08 Dec 2014 18:40:12 GMT

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

ASF GitHub Bot commented on CLOUDSTACK-5501:
--------------------------------------------

GitHub user remibergsma opened a pull request:

    https://github.com/apache/cloudstack/pull/54

    make the VPN feature work more reliable and secure

    At Schuberg Philis we wanted to use the VPN feature, but found it hard to make it work
in a reliable way. When we dove into it, we found some bugs and problems that we solved along
the way. Since this change, the VPN connections are created and destroyed as expected. Also,
we tightened the iptable rules to make it more secure.
    
    The patched ipsectunnel.sh script works fine in our tests on 4.4, 4.5 and 4.6. Possibly
also on 4.3.x when the fix for CLOUDSTACK-5501 is merged.
    
    Also, after rebooting a VPC the VPN connection reconnected as one would expect.
    
    We tested this change by using the shell script below (based on CloudMonkey). The script
will create a VPN connection between each VPN customer gateway it finds, like in a mesh network.

    
    Regards,
    Remi Bergsma / Funs Kessen
    
    #!/bin/bash
    vpncustgws=`cloudmonkey list vpncustomergateways | grep ^id | awk ' { print $3 }'`
    vpngws=`cloudmonkey list vpngateways | grep ^id | awk ' { print $3 }'`
    for vpngw in $vpngws
    do
       pubip=`cloudmonkey list vpngateways id=$vpngw | grep ^publicip | awk '{print $3}'`
       echo "dealing with $vpngw, $pubip"
       for vpncustgw in $vpncustgws
       do 
           custgw=`cloudmonkey list vpncustomergateways id=$vpncustgw | grep ^gateway | awk
'{print $3}'`
           if [ $custgw == $pubip ]
           then
               echo "$pubip is me, $vpncustgw, $custgw, $vpngw!"
           else
               echo "creating vpn: $custgw, $pubip"
               echo "cloudmonkey create vpnconnection s2scustomergatewayid=$vpncustgw s2svpngatewayid=$vpngw"
           fi
       done
    done

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/remibergsma/cloudstack master

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/cloudstack/pull/54.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 #54
    
----
commit 8b412ce194eaf195dc77531379687de43e14a088
Author: Remi Bergsma <rbergsma@schubergphilis.com>
Date:   2014-12-08T17:53:18Z

    remove biglock usage from ipsectunnel.sh
    
    Biglock breaks creating VPN's when other scripts run at the
    same time that also use the same biglock. These other scripts
    do nothing that could harm our deployment and even multiple
    vpn's can safely be created simultaniously.

commit 8b2563a216b012ab1905e65f446c8b6b1435b983
Author: Remi Bergsma <rbergsma@schubergphilis.com>
Date:   2014-12-08T17:54:27Z

    renamed $leftgw to $leftnexthop to make clear what it does

commit b95addd3efb45f61b129584ade49bad7bbaa16f8
Author: Remi Bergsma <rbergsma@schubergphilis.com>
Date:   2014-12-08T17:55:35Z

    starting the tunnel will make it keep trying until it connects
    
    Changed 'auto=add' to 'auto=start' to make sure the tunnel starts.
    When both sides are there they will connect. This resolves the
    issue that there is only a small time frame in which the VPN
    would connect.

commit f8d718e3e31ad517969663d24647fcbd9b50cc3d
Author: Remi Bergsma <rbergsma@schubergphilis.com>
Date:   2014-12-08T17:59:16Z

    add a flag -c whether or not to check the VPN on create
    
    Changed default to no, as the other side may not be up yet.
    If this check fails, the VPN enters Error state and will not
    work. It's safe to just let it connect on its own so it will
    connect when it can.

commit 7f33f7c3969d3b217ad6977f01bb487ebeee665d
Author: Remi Bergsma <rbergsma@schubergphilis.com>
Date:   2014-12-08T18:00:59Z

    prevent CloudStack from removing the VPN connection
    
    If connecting the VPN takes some time, for example because
    the other end is not (yet) up, CloudStack will delete
    the VPN because the ipsectunnel.sh does not return in time.
    The VPN connection then enters the Error state.
    
    This change makes sure ipsectunnel.sh returns in time,
    and lets ipsec connect in the background. If it all fails,
    the connection enters Disconnected.

commit ef3b4bb4e3342f166489034fa7149540d2ef1383
Author: Remi Bergsma <rbergsma@schubergphilis.com>
Date:   2014-12-08T18:06:55Z

    made iptables for the VPN connection more secure
    
    Added destination and source definition. Flag -S can be used
    to ignore this. It's the new default as it is more secure
    and does not impact the way things work (backwords compatible).

----


> Unable to create more than one vpnConnection per vpn customer gateway
> ---------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-5501
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5501
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Management Server
>    Affects Versions: 4.3.0
>            Reporter: Alena Prokharchyk
>            Assignee: Sheng Yang
>            Priority: Critical
>             Fix For: 4.4.0
>
>
> There is currently a limitation in the CS code when you can't create more than one vpn
connection per customer gateway. There are no technical reasons for this kind of limitation,
so we should remove it as the customers might want to use his customer gateway cross zones
if he owns VPCs in diff zones.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message