cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Weber <terbol...@gmail.com>
Subject Re: VPC Site to Site VPN CIDR RFC1918
Date Thu, 22 May 2014 22:31:42 GMT
Filed ticket https://issues.apache.org/jira/browse/CLOUDSTACK-6747 for it
:-)


-- 
Erik Weber


On Fri, May 23, 2014 at 12:24 AM, Chiradeep Vittal <
Chiradeep.Vittal@citrix.com> wrote:

> 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