Mailing-List: contact issues-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Date: Sat, 2 Dec 2017 13:49:00 +0000 (UTC)
From: "ASF GitHub Bot (JIRA)" <jira@apache.org>
To: cloudstack-issues@incubator.apache.org
Message-ID: <JIRA.13088872.1500579904000.371527.1512222540078@Atlassian.JIRA>
In-Reply-To: <JIRA.13088872.1500579904000@Atlassian.JIRA>
References: <JIRA.13088872.1500579904000@Atlassian.JIRA> <JIRA.13088872.1500579904136@jira-lw-us.apache.org>
Subject: [jira] [Commented] (CLOUDSTACK-10010) Some S2S VPN configurations
 fail to establish a connection
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Sat, 02 Dec 2017 13:49:09 -0000


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

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

rhtyd commented on a change in pull request #2190: CLOUDSTACK-10010: Fixed the negotiation of S2S VPN connections
URL: https://github.com/apache/cloudstack/pull/2190#discussion_r154496797
 
 
 ##########
 File path: systemvm/patches/debian/config/opt/cloud/bin/configure.py
 ##########
 @@ -582,10 +582,21 @@ def configure_ipsec(self, obj):
             logging.info("Configured vpn %s %s", leftpeer, rightpeer)
             CsHelper.execute("ipsec rereadsecrets")
 
-        # This will load the new config and start the connection when needed since auto=start in the config
+        # This will load the new config
         CsHelper.execute("ipsec reload")
         os.chmod(vpnsecretsfile, 0400)
 
+        # Check that the ipsec config is ready
+        for i in range(2):
+            result = CsHelper.execute('ipsec status vpn-%s | grep "%s"' % (rightpeer, peerlist.split(",", 1)[0]))
+            if len(result) > 0:
+                break
+            time.sleep(1)
+
+        # With 'auto=route', connections are established with an attempt to communicate over the S2S VPN
+        # Attempt to ping the other side to initialize the connection of the S2S VPN configuration
+        CsHelper.execute("timeout 0.5 ping -c 1 %s" % (peerlist.split("/", 1)[0]))
 
 Review comment:
   Here the timeout maybe too small and the ping `IP` may be something like 10.0.0.0 (for a peer cidr of 10.0.0.0/16) instead of say 10.1.1.1. It's better to ping right peer instead.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


> Some S2S VPN configurations fail to establish a connection
> ----------------------------------------------------------
>
>                 Key: CLOUDSTACK-10010
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10010
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Virtual Router
>    Affects Versions: 4.10.0.0
>            Reporter: Will Stevens
>
> I am not sure if a regression was introduced with this PR #2062, but we have found issues with this configuration now that we have it in production.
> The core of this change is to change the S2S VPN config from {{auto=start}} to {{auto=route}}. Read more about this setting here: https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection
> We found there to be issues when using {{auto=start}} for both sides of the connection as there was problem negotiating the connection. Instead the {{auto=route}} config will only establish a connection once there is an attempt to send traffic over the connection. In order to attempt to open the connection as soon as the VPN connection is configured, a ping to the other side of the connection has been added to establish the connection.


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)