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 <sanjeev.neelar...@citrix.com> 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:terbol...@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" <daan.hoogl...@gmail.com> følgende: > >> 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 <terbol...@gmail.com> 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" <daan.hoogl...@gmail.com> >> følgende: >> > >> >> 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 >> >> <daan.hoogl...@gmail.com >> > >> >> 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 <terbol...@gmail.com> >> 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.hoogl...@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 >> >> >>> <terbol...@gmail.com> >> >> 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’s 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
