cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chiradeep Vittal <Chiradeep.Vit...@citrix.com>
Subject Re: VPC Site to Site VPN CIDR RFC1918
Date Thu, 22 May 2014 22:24:52 GMT
Seems reasonable to relax this constraint.

From: Erik Weber <terbolous@gmail.com<mailto:terbolous@gmail.com>>
Reply-To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" <dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>>
Date: Thursday, May 22, 2014 at 1:40 AM
To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" <dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>>
Subject: Re: VPC Site to Site VPN CIDR RFC1918

We have no problem getting s2s to connect if the 'other end' from cs point
of view is within rfc1918.
Our problem is purely related to the limitation of only allowing rfc1918
networks on the other end.

Erik Weber


On Thu, May 22, 2014 at 10:21 AM, Daan Hoogland <daan.hoogland@gmail.com<mailto:daan.hoogland@gmail.com>>wrote:

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.neelarapu@citrix.com<mailto:sanjeev.neelarapu@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:terbolous@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.hoogland@gmail.com<mailto:daan.hoogland@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 <terbolous@gmail.com<mailto:terbolous@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.hoogland@gmail.com<mailto:daan.hoogland@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.hoogland@gmail.com<mailto:daan.hoogland@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 <terbolous@gmail.com<mailto:terbolous@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.hoogland@gmail.com<mailto:daan.hoogland@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
>> >> >>> <terbolous@gmail.com<mailto:terbolous@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



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message