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