Return-Path: X-Original-To: apmail-cloudstack-dev-archive@www.apache.org Delivered-To: apmail-cloudstack-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D49FB11CCF for ; Thu, 22 May 2014 22:25:26 +0000 (UTC) Received: (qmail 49519 invoked by uid 500); 22 May 2014 22:25:26 -0000 Delivered-To: apmail-cloudstack-dev-archive@cloudstack.apache.org Received: (qmail 49471 invoked by uid 500); 22 May 2014 22:25:26 -0000 Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cloudstack.apache.org Delivered-To: mailing list dev@cloudstack.apache.org Received: (qmail 49463 invoked by uid 99); 22 May 2014 22:25:26 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 22 May 2014 22:25:26 +0000 X-ASF-Spam-Status: No, hits=-2.8 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of Chiradeep.Vittal@citrix.com designates 66.165.176.89 as permitted sender) Received: from [66.165.176.89] (HELO SMTP.CITRIX.COM) (66.165.176.89) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 22 May 2014 22:25:21 +0000 X-IronPort-AV: E=Sophos;i="4.98,890,1392163200"; d="scan'208,217";a="134772864" Received: from sjcpex01cl01.citrite.net ([10.216.14.143]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA; 22 May 2014 22:24:54 +0000 Received: from SJCPEX01CL02.citrite.net ([169.254.2.128]) by SJCPEX01CL01.citrite.net ([10.216.14.143]) with mapi id 14.03.0181.006; Thu, 22 May 2014 15:24:53 -0700 From: Chiradeep Vittal To: "dev@cloudstack.apache.org" Subject: Re: VPC Site to Site VPN CIDR RFC1918 Thread-Topic: VPC Site to Site VPN CIDR RFC1918 Thread-Index: AQHPdN1/lch8/0yrS0y7KI/nG9T8SptLZouAgAAHFQCAAClMAIAAAKiAgAASc4CAAGX0gIAACm6AgABXWwCAAEdkgIAABUyAgABxGAA= Date: Thu, 22 May 2014 22:24:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.252.121.29] Content-Type: multipart/alternative; boundary="_000_CFA3C70B44EF0chiradeepvittalcitrixcom_" MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org --_000_CFA3C70B44EF0chiradeepvittalcitrixcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Seems reasonable to relax this constraint. From: Erik Weber > Reply-To: "dev@cloudstack.apache.org" > Date: Thursday, May 22, 2014 at 1:40 AM To: "dev@cloudstack.apache.org" > Subject: Re: VPC Site to Site VPN CIDR RFC1918 We have no problem getting s2s to connect if the 'other end' from cs point of view is within rfc1918. Our problem is purely related to the limitation of only allowing rfc1918 networks on the other end. Erik Weber On Thu, May 22, 2014 at 10:21 AM, Daan Hoogland >wrote: I ran a test with a colleague this week connecting two cs vpcs. this works. On Thu, May 22, 2014 at 6:05 AM, Sanjeev Neelarapu > wrote: > In site-to-site vpn both sides need not to be under cloudstack control. Only one site can be under cs control. > > -----Original Message----- > From: Erik Weber [mailto:terbolous@gmail.com] > Sent: Thursday, May 22, 2014 4:23 AM > To: dev > Subject: Re: VPC Site to Site VPN CIDR RFC1918 > > The documentation says something else, excerpt: > " The difference from Remote VPN is that Site-to-site VPNs connects entire networks to each other, for example, connecting a branch office network to a company headquarters network. In a site-to-site VPN, hosts do not have VPN client software; they send and receive normal TCP/IP traffic through a VPN gateway.". > > Assuming that both sides is under cloudstack control is just odd and makes no sense. > > I'll file a ticket whenever I find the time, but still appreciate input :-) > > Erik Weber > 22. mai 2014 00:16 skrev "Daan Hoogland" > f=F8lgende: > >> I guess you shouldn't use the site to site vpn but just a vpn. I am >> not sure how to configure that but you should just create an active >> (client side) vpn to the external network. I see no reason why it >> should't work. the site to site assumes you have both sides in >> cloudstack and thus with rfc1918 networks. >> >> On Wed, May 21, 2014 at 6:10 PM, Erik Weber > wrote: >> > Site to site vpn. >> > >> > I'm not in control of the 50.0.1 network, but the client is. >> > >> > Basically the use case is that they want to secure the traffic to >> > their cloud vms, and are fortunate enough to not have to use rfc1918 >> > on their network. >> > >> > I guess we could work around it by terminating the vpn on our >> > equipment >> and >> > access it as a private gateway instead, but I'd prefer to use the >> > technology that we so braverly tell our clients about. >> > >> > Erik >> > 21. mai 2014 17:05 skrev "Daan Hoogland" > >> f=F8lgende: >> > >> >> Are you creating a site to site vpn or connecting to an external >> network? >> >> >> >> On Wed, May 21, 2014 at 5:02 PM, Daan Hoogland >> >> >> > >> >> wrote: >> >> > Erik, If it doesn't work it is probably been blocked on purpose >> >> > but I don't see why it is. I don't know your use case either and >> >> > it seems an unlikely one. But if the 50.0.1 net is out of your >> >> > control you maybe should be able to configure this. So I would >> >> > say it is a bug/lack of feature. I'll look into the code for the place the error is generated. >> >> > >> >> > in short: file a ticket >> >> > >> >> > On Wed, May 21, 2014 at 2:34 PM, Erik Weber > >> wrote: >> >> >> I understand that, but what my client wants is to connect public >> >> >> ips instead of rfc1918 on one of the sides. >> >> >> >> >> >> e.g. one network has 10.0.1.0/24 and ip 1.2.3.4 the other has >> >> >> 50.0.1.0/24 and ip 50.0.0.1 >> >> >> >> >> >> but cloudstack currently does not let you do that, because it >> >> >> expects >> >> cidrs >> >> >> to be rfc1918. see log excerpt: >> >> >> >> >> >> 2014-05-21 12:30:42,326 WARN [c.c.u.n.NetUtils] >> >> >> (API-Job-Executor-7:job-3072 ctx-bf3922b1) cidr 50.0.1.0/24 is >> >> >> not >> RFC >> >> 1918 >> >> >> compliant >> >> >> 2014-05-21 12:30:42,335 ERROR [c.c.a.ApiAsyncJobDispatcher] >> >> >> (API-Job-Executor-7:job-3072) Unexpected exception while >> >> >> executing >> >> >> >> org.apache.cloudstack.api.command.user.vpn.CreateVpnCustomerGatewayCmd >> >> >> com.cloud.exception.InvalidParameterValueException: The customer >> gateway >> >> >> guest cidr list 50.0.1.0/24 is invalid guest cidr! >> >> >> at >> >> >> >> >> >> com.cloud.network.vpn.Site2SiteVpnManagerImpl.createCustomerGateway(Si >> te2SiteVpnManagerImpl.java:176) >> >> >> >> >> >> I'm wondering if this is a bug/lacking feature, or intended. >> >> >> As I initially said I'm not a network guy, so there might be >> perfectly >> >> good >> >> >> reasons this shouldn't be allowed. >> >> >> >> >> >> But if it's a bug/lacking feature it would be great to know so >> >> >> that I >> >> could >> >> >> file a ticket for it. >> >> >> >> >> >> -- >> >> >> Erik Weber >> >> >> >> >> >> >> >> >> On Wed, May 21, 2014 at 2:09 PM, Daan Hoogland < >> daan.hoogland@gmail.com >> >> >wrote: >> >> >> >> >> >>> Erik, >> >> >>> >> >> >>> The vpn let's you connect to all the computers in the network >> >> >>> on the other site on their private adresses. This means that >> >> >>> you can give >> the >> >> >>> cidr of the remote network in the definition on vpn connection. >> >> >>> >> >> >>> one network has 10.0.1.0/24 and ip 1.2.3.4 the other has >> >> >>> 10.0.2.0/24 and ip 4.3.2.1 >> >> >>> >> >> >>> on the first you define endpoint/gateway 4.3.2.1 with cidr >> 10.0.1.0/24 >> >> >>> and you make it passive >> >> >>> on the second you define the adresses of the first and stat is >> without >> >> >>> the passive function >> >> >>> now you can ping a machine with address 10.0.1.123 from a >> >> >>> machine >> with >> >> >>> ip 10.0.2.246 >> >> >>> >> >> >>> Of course you can do this to an external network as well, which >> makes >> >> >>> far more sense. >> >> >>> >> >> >>> On Wed, May 21, 2014 at 12:14 PM, Erik Weber >> >> >>> > >> >> wrote: >> >> >>> > >> >> >>> >> >> >> http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.2.0/html/I >> nstallation_Guide/vpn.html#site-to-site-vpnstates >> >> >>> : >> >> >>> > >> >> >>> > >> >> >>> > - *CIDR list*: The guest CIDR list of the remote subnets. >> Enter a >> >> CIDR >> >> >>> > or a comma-separated list of CIDRs. Ensure that a guest >> >> >>> > CIDR >> list >> >> is >> >> >>> not >> >> >>> > overlapped with the VPC=92s CIDR, or another guest CIDR. The >> >> >>> > CIDR >> >> must >> >> >>> be >> >> >>> > RFC1918-compliant. >> >> >>> > >> >> >>> > >> >> >>> > I'm not a network guy, so excuse the question if it's >> >> >>> > obvious, but >> >> if a >> >> >>> > customer only has public ip's on their end, why is rfc1918 >> required? >> >> >>> > >> >> >>> > >> >> >>> > -- >> >> >>> > Erik Weber >> >> >>> >> >> >>> >> >> >>> >> >> >>> -- >> >> >>> Daan >> >> >>> >> >> > >> >> > >> >> > >> >> > -- >> >> > Daan >> >> >> >> >> >> >> >> -- >> >> Daan >> >> >> >> >> >> -- >> Daan >> -- Daan --_000_CFA3C70B44EF0chiradeepvittalcitrixcom_--