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 >
