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(Site2SiteVpnManagerImpl.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/Installation_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 >
