You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Erik Weber <te...@gmail.com> on 2014/05/21 12:14:06 UTC
VPC Site to Site VPN CIDR RFC1918
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
Re: VPC Site to Site VPN CIDR RFC1918
Posted by Erik Weber <te...@gmail.com>.
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 <te...@gmail.com>>
> Reply-To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <
> dev@cloudstack.apache.org<ma...@cloudstack.apache.org>>
> Date: Thursday, May 22, 2014 at 1:40 AM
> To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <
> dev@cloudstack.apache.org<ma...@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
> <ma...@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
> <sa...@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
> <ma...@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
> <ma...@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
> <ma...@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
> >> >> <da...@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
> <ma...@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<ma...@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
> >> >> >>> <te...@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
>
>
>
Re: VPC Site to Site VPN CIDR RFC1918
Posted by Chiradeep Vittal <Ch...@citrix.com>.
Seems reasonable to relax this constraint.
From: Erik Weber <te...@gmail.com>>
Reply-To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <de...@cloudstack.apache.org>>
Date: Thursday, May 22, 2014 at 1:40 AM
To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <de...@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 <da...@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
<sa...@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" <da...@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 <te...@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" <da...@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
>> >> <da...@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 <te...@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<ma...@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
>> >> >>> <te...@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
Re: VPC Site to Site VPN CIDR RFC1918
Posted by Erik Weber <te...@gmail.com>.
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 <da...@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
> <sa...@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" <da...@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 <te...@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" <da...@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
> >> >
> >> >> 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 <te...@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
> >> >> >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
> >> >> >>> <te...@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
>
Re: VPC Site to Site VPN CIDR RFC1918
Posted by Daan Hoogland <da...@gmail.com>.
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
<sa...@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" <da...@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 <te...@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" <da...@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
>> >
>> >> 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 <te...@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
>> >> >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
>> >> >>> <te...@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
RE: VPC Site to Site VPN CIDR RFC1918
Posted by Sanjeev Neelarapu <sa...@citrix.com>.
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" <da...@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 <te...@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" <da...@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
> >
> >> 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 <te...@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
> >> >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
> >> >>> <te...@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
>
Re: VPC Site to Site VPN CIDR RFC1918
Posted by Erik Weber <te...@gmail.com>.
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" <da...@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 <te...@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" <da...@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
> >
> >> 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 <te...@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.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 <te...@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
>
Re: VPC Site to Site VPN CIDR RFC1918
Posted by Daan Hoogland <da...@gmail.com>.
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 <te...@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" <da...@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 <da...@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 <te...@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.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 <te...@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
Re: VPC Site to Site VPN CIDR RFC1918
Posted by Erik Weber <te...@gmail.com>.
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" <da...@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 <da...@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 <te...@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.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 <te...@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
>
Re: VPC Site to Site VPN CIDR RFC1918
Posted by Daan Hoogland <da...@gmail.com>.
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 <da...@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 <te...@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 <da...@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 <te...@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
Re: VPC Site to Site VPN CIDR RFC1918
Posted by Daan Hoogland <da...@gmail.com>.
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 <te...@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 <da...@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 <te...@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
Re: VPC Site to Site VPN CIDR RFC1918
Posted by Erik Weber <te...@gmail.com>.
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 <da...@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 <te...@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
>
Re: VPC Site to Site VPN CIDR RFC1918
Posted by Daan Hoogland <da...@gmail.com>.
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 <te...@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
Re: VPC Site to Site VPN CIDR RFC1918
Posted by Erik Weber <te...@gmail.com>.
Great to hear. We're not seeing that as we're only trying to add one cidr
range, but all fixes are appreciated :-)
Hope someone might come up with some more info about the limitation as time
passes.
Regards,
Erik Weber
On Wed, May 21, 2014 at 12:32 PM, Alex Hitchins <al...@alexhitchins.com>wrote:
> Erik,
>
> I can't answer your question however though as you raise it I'd let you
> know; I'm working on an issue with the comma separated list. Currently it
> is failing as it's incorrectly validating the string.
>
> https://issues.apache.org/jira/browse/CLOUDSTACK-6667
>
>
> Alex Hitchins | 07788 423 969 | 01892 523 587
>
> -----Original Message-----
> From: Erik Weber [mailto:terbolous@gmail.com]
> Sent: 21 May 2014 11:14
> To: dev
> Subject: VPC Site to Site VPN CIDR RFC1918
>
>
> 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
>
>
RE: VPC Site to Site VPN CIDR RFC1918
Posted by Alex Hitchins <al...@alexhitchins.com>.
Erik,
I can't answer your question however though as you raise it I'd let you know; I'm working on an issue with the comma separated list. Currently it is failing as it's incorrectly validating the string.
https://issues.apache.org/jira/browse/CLOUDSTACK-6667
Alex Hitchins | 07788 423 969 | 01892 523 587
-----Original Message-----
From: Erik Weber [mailto:terbolous@gmail.com]
Sent: 21 May 2014 11:14
To: dev
Subject: VPC Site to Site VPN CIDR RFC1918
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