Mailing-List: contact users-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cloudstack.apache.org
Date: Mon, 6 Nov 2017 12:10:38 +0000 (GMT)
From: Nux! <nux@li.nux.ro>
To: users <users@cloudstack.apache.org>
Cc: dev <dev@cloudstack.apache.org>
Message-ID: <270992313.1239.1509970237965.JavaMail.zimbra@li.nux.ro>
In-Reply-To: <CAMvtBPMCKB1KJeYw4a-tY_XHNYj+SR08v_1SEz5VsYQpzhyyuQ@mail.gmail.com>
References: <1750999994.6369.1509476065042.JavaMail.zimbra@li.nux.ro> <CAMvtBPMCKB1KJeYw4a-tY_XHNYj+SR08v_1SEz5VsYQpzhyyuQ@mail.gmail.com>
Subject: Re: HTTPS LB and x-forwarded-for
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Thread-Topic: HTTPS LB and x-forwarded-for
Thread-Index: iMQHEtIF9ruD297yOq1zXcV6c5p/yA==
archived-at: Mon, 06 Nov 2017 12:10:54 -0000

Thanks Andrija,

LB outside of the VR sounds like a good idea. An appliance based on, say cl=
oud-init + ansible and so on could do the trick; alas it'd need to be outsi=
de ACS.
I guess as users we could maybe come up with a spec for an improvement, at =
least we'd have something the devs could look at whenever it is possible.

Regards,
Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

----- Original Message -----
> From: "Andrija Panic" <andrija.panic@gmail.com>
> To: "dev" <dev@cloudstack.apache.org>
> Cc: "users" <users@cloudstack.apache.org>
> Sent: Thursday, 2 November, 2017 23:21:37
> Subject: Re: HTTPS LB and x-forwarded-for

> We used to make some special stuff for one of the clients, where all LB
> configuration work is done from outside of the ACS, i.e. python script to
> feed/configure VR - install latest haproxy 1.5.x for transparent proxy,
> since client insisted on SSL termination done on backend web SSL servers.=
...
> Not good idea, that is all I can say (custom configuration thing) - but t=
he
> LB setup is actually good - transparent mode haproxy, works on TCP level,
> so you can see "real client IP" on the backend servers (which must use VR
> as the default gtw, as per default, so the whole setup works properly).
>=20
> I'm still looking forward to see some special support of LB inside VR via
> ACS - proper LB setup inside VR via GUI/API -  i.e. to enable LB
> provisioning SCRIPT (bash, or whatever),  where all needed
> install+configure can be done from client side  - otherwise covering all
> user cases, with proper HTTP checks and similar....is impossible to do
> IMHO.
>=20
> Some other clients, actually have internal FW appliance (i.e. multihomed
> VM, acting as gtw for all VMs in all networks), and haproxy instaled on
> this device (with NAT configured from VR to this internal FW/VM, so remot=
e
> IP can be seen properly) - this setup is fully under customer control, an=
d
> can provide any kind of special haproxy config...
>=20
>=20
>=20
>=20
>=20
>=20
> On 31 October 2017 at 19:54, Nux! <nux@li.nux.ro> wrote:
>=20
>> Hello,
>>
>> Of the people running an LB (VR) with https backends, how do you deal wi=
th
>> the lack of x-forwarded-for since for port 443 there's just simple TCP
>> balancing?
>>
>> Has anyone thought of terminating SSL in the VR instead? Ideas?
>>
>> Cheers
>>
>> --
>> Sent from the Delta quadrant using Borg technology!
>>
>> Nux!
>> www.nux.ro
>>
>=20
>=20
>=20
> --
>=20
> Andrija Pani=C4=87