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

Reply via email to