Re: question related to setting up tcp relay

[Rajiv]

Thanks Baptiste for sharing documents

Actually error says 400 and it further says that http request is being sent
https so it seems to be proxy generated error.

ssl/tsl passthrough what i am trying to achieve with following
configuration, but failing to do so

global

log 127.0.0.1 local2
chroot  /var/lib/haproxy
pidfile /var/run/haproxy.pid
maxconn 5000
userhaproxy
group   haproxy
daemon
stats socket /var/lib/haproxy/stats
ssl-server-verify none


defaults

modehttp
log global
option  httplog
option  dontlognull
option  redispatch
retries 3
timeout http-request10s
timeout queue   1m
timeout connect 10s
timeout client  1m
timeout server  1m
timeout http-keep-alive 10s
timeout check   10s
maxconn 5000
stats enable
stats uri /stats
stats realm Haproxy\ Statistics
stats auth haproxy:haproxy@197


frontend www-https

mode tcp
bind *:443 ssl crt /etc/haproxy/ssl/server.pem
acl is_pg-risk-homeurl_beg /home


backend pg-risk-home

balance roundrobin
mode tcp
server pg-risk1 itscenter.alipay.com:443 check




I know i am missing something very silly here...

Regards,
Rajiv

On Thu, Aug 11, 2016 at 3:10 PM, Baptiste  wrote:

> Hi,
>
> A few interesting pages for you:
>   http://haproxy.com/doc/hapee/1.5/traffic_management/tls.html
>   http://haproxy.com/doc/hapee/1.5/deployment_guides/tls_layouts.html
>
> Please note that 404 sounds more a server issue :)
>
> Baptiste
>
>
>
> On Thu, Aug 11, 2016 at 9:03 AM, Rajiv  wrote:
>
>> well it is my more than 4 years old bond with HAproxy which can be broken
>> by mere ssl :)
>>
>> Willy,
>> I apologize for sending little information below is the configuration in
>> question, I am not removing obvious one to make sure that  i am not doing
>> any mistake here
>>
>> ===
>>
>> *global*
>>
>>
>>
>>
>>
>>
>>
>>
>> *log 127.0.0.1 local2chroot  /var/lib/haproxypidfile
>> /var/run/haproxy.pidmaxconn 5000userhaproxygroup
>> haproxydaemonstats socket /var/lib/haproxy/stats*
>>
>>
>>
>> *defaults*
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *modehttplog globaloption
>>  httplogoption  dontlognulloption
>> http-server-closeoption forwardfor   except 127.0.0.0/8
>> option  redispatchretries
>>   3timeout http-request10stimeout queue   1mtimeout connect
>> 10stimeout client  1mtimeout server  1mtimeout
>> http-keep-alive 10stimeout check   10smaxconn
>> 5000stats enablestats uri /statsstats realm Haproxy\ Statisticsstats auth
>> haproxy:haproxy@197*
>>
>>
>>
>> *frontend www-http*
>>
>>
>>
>> *bind *:80 bind *:443 ssl crt /etc/haproxy/ssl/server.pem **reqadd
>> X-Forwarded-Proto:\ https if { ssl_fc }*
>> *default_backend test*
>>
>>
>> *backend test*
>>
>> *server test1 assets.saas..com:443 
>> check ssl verify none*
>>
>> ===
>>
>> with above configuration when my request is forwarded I get 404 from 
>> *assets.saas..com:443
>> * , where as if i curl directly i am
>> getting successfully 200
>>
>> Regards,
>> Rajiv
>>
>> On Thu, Aug 11, 2016 at 11:49 AM, Willy Tarreau  wrote:
>>
>>> Hi Rajiv,
>>>
>>> first, please don't resurrect 4-years old threads to ask a new question,
>>> that's the best way to ensure nobody will read it.
>>>
>>> On Thu, Aug 11, 2016 at 11:35:52AM +0530, Rajiv wrote:
>>> > Hi Expert,
>>> >
>>> > After a long period once again i need your help, actually i am kind of
>>> > stuck so please help
>>> > I have to forward my incoming ssl request to other host who is again
>>> on ssl
>>> >
>>> > both end points are ssl terminated are using their own certificates,
>>> so it
>>> > is possible?
>>>
>>> Well, I don't understand what difficulties you are facing as what you
>>> describe seems pretty common and you gave little information. Would you
>>> please post your current configuration here and explain what you tried
>>> to chage ? Have you looked for the word "ssl" in the documentation ?
>>>
>>> > if yes then please help me getting its configuration and i am very well
>>> > aware that same can be done in nginx
>>>
>>> If you feel more easy with configuring nginx, maybe you should switch to
>>> it. You should not be ashamed. There's no point in forcing yourself to
>>> use a product you find difficult to configure if another one serves you
>>> better. I mean both products are free!
>>>
>>> Regards,
>>> Willy
>>>
>>
>>
>

HAProxy is not redirecting to Apache Tomcat Server on SLES

[Rahul Shivalkar]

Hello,
I am using HAProxy. I have Apache tomcat cluster, ElasticSearch cluster and
OrientDB Cluster, every node is on different machine having different IP
address. I have configured 3 HAProxies, 1 for tomcat, 1 for elastic and 1
for orientdb having same configuration(except IPs). HAProxy is working fine
for OrientDb and elastic but not for Tomcat. HAProxy for tomcat is not
redirecting to tomcat nodes giving no error on browser. Please help me.
Thanks in advance.

-- 
*Thanks & Regards,*
*Shivalkar Rahul M.*
*Jr. Software Developer,*
*ContentSphere Technologies India Pvt. Ltd.*

Re: HAProxy is not redirecting to Apache Tomcat Server on SLES

[Aleksandar Lazic]

Hi.
Am 11-08-2016 13:49, schrieb Rahul Shivalkar:


Hello,
I am using HAProxy.


Which version of HAProxy?

haproxy -vv

I have Apache tomcat cluster, ElasticSearch cluster and OrientDB 
Cluster,

every node is on different machine having different IP address.

I have configured 3 HAProxies, 1 for tomcat, 1 for elastic and 1 for
orientdb having same configuration(except IPs).


Please can you show the config.


HAProxy is working fine for OrientDb and elastic but not for Tomcat.
HAProxy for tomcat is not redirecting to tomcat nodes giving no error 
on browser.


Well some logs (haproxy, tomcat) would be helpfully ;-)
Ah and when you send the server.xml could also not be that wrong.

Yust a short shot.
Do you use the HTTP-port to talk with tomcat or the ajp port?


Please help me. Thanks in advance.


With some more information I'm sure that the community can help you ;-)

BR aleks

New mailing list archive

[Aleksandar Lazic]

Hi.

sorry to disturb you again but gmane.org  is history 
https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/ ;-(


Maybe we can try to use this one?

https://www.mail-archive.com/haproxy@formilux.org/

Best regards
Aleks

专注化学品出口国际快运

[无需提供任何资料]

我这边专注化学品3-9类危'险品'空'运无需提供；危包证；及任何资料'
电池产品及带电；池产品；等国际快.递《电池敏感货物）等类似液体 粉末 固体 颗粒 片状 等等疑难产品！
详情了解更多qq:87317.2863 Mob:0086-136.36535443详情:wechat:13636.535443 
Skype:mafus200434 

Fw: lighting fixtures required for 3 projects in mid east

[shum.vincent]

 
Besidesthecustomziedrecessedlightingfi=xturesintheUS.Wealsorequirethelightingfixturesbelow=,for3projectsintheMidEast:
 seethespecsbelow: 
Pleasenote,besidesqualityneedbegood,&=nbsp;thepricemustalsobeverycompetitive,sowecoulddirectlyfo=rwardyourquotationtocustomeranddiscuss.
 1-DecorativeChandler SuitingApartments( HallsBedRooms):Qnt.350pcs 
2-2X36WFlorescentTypesforCarParks,=IP65Qnt.500pcs 
3-2X36WFlorissantTypeforCarPa=rk,IP65alongwithEMBatteryfor3Hours  =sp; 
Qnt.150pcs 4-20W,LEDDownLight,IP44OrMo=re, RoundwhiteShape,=5000KNonDimmable
 Qnt.900pcs 
5-10W,LED,SpotLight,IP20,RoundWh=iteFinishShape3000K,NonDimmableQnt.2,250pcs 
6-MirrorLight,IP44,between60=to80cmLength:Qnt.360pcs 
7-LEDExitLight,IP54orMoreQnt.200pcs 
8-LEDEmergencyLight,RoundShade3Hou=rsNonMaintain,IP540rMoreQnt.300pcs 
9-CoridorsAutomatic MotionSensorsQnt.70pcs 
10-AluDaiCast,BluckHeadIP65,White=RoundShape,2,18WPLQnt.50pcs  
Pleasenote,whenyoumakequotations:1.thepriceshouldbeex-works,excludi=nglightsourceandballasts/drivers2.thelightsourceshouldbequotedspe=arately3.thecontrolgear(ballastsorLEDdri=vers)shouldbequotedseparately4.yourquotationsheetsmustbeinexce=lfile,shouldnotbePDForwordfiles!5.foreachitem,atyourquotation,mus=tbeindicating:
 productimagesproductsizesmaterialswattage
systemlumenou=tput@stablestatus, notinitialstatus!
colortemperatu=res6.warrantymustbe3years,sincedate=ofleavingfromyourfactoryforthefirsttime.
  
onthisSunday,whencustomercomebackto=work,wewillnegotiatewiththe,becausetheyarenotworkinginFrid=ayandSaturday!
 Lookingforwardtoyourpromptreply!  
KindRegards,VincentManagerChinaMobile=:+8613570439296  
VKSCO.,LTD&=nbsp;UNIT04,7/F,BRIGHTWAYTOWER,NO.33MONGKOKROAD,KOWLOON,HK=Email:shum.vinc...@outlook.com
 

[PATCHES] 2 new functions for standard.c

[Baptiste]

Hi the list, Willy,

Please find in attachment a couple of patches to add a couple of IP related
functions:
- ipcmp to compare 2 ipcmp, à la strcmp
- ipcpy to copy an IP address, à la strcpy

Baptiste
From 85868161bd3ee2b60a8964645dde48b891315e73 Mon Sep 17 00:00:00 2001
From: Baptiste Assmann 
Date: Sat, 23 Jan 2016 23:39:12 +0100
Subject: [PATCH 01/11] MINOR: standard.c: ipcmp() function to compare 2 IP
 addresses stored in 2 struct sockaddr_storage

new ipcmp() function to compare 2 IP addresses stored in struct
sockaddr_storage.
Returns 0 if both addresses doesn't match and 1 if they do.
---
 include/common/standard.h |  6 ++
 src/standard.c| 30 ++
 2 files changed, 36 insertions(+)

diff --git a/include/common/standard.h b/include/common/standard.h
index 5afaad2..bc1ab40 100644
--- a/include/common/standard.h
+++ b/include/common/standard.h
@@ -880,6 +880,12 @@ extern void v4tov6(struct in6_addr *sin6_addr, struct in_addr *sin_addr);
  */
 extern int v6tov4(struct in_addr *sin_addr, struct in6_addr *sin6_addr);
 
+/* compare two struct sockaddr_storage and return:
+ *  0 (true)  if the addr is the same in both
+ *  1 (false) if the addr is not the same in both
+ */
+int ipcmp(struct sockaddr_storage *ss1, struct sockaddr_storage *ss2);
+
 char *human_time(int t, short hz_div);
 
 extern const char *monthname[];
diff --git a/src/standard.c b/src/standard.c
index c2d1689..d85c720 100644
--- a/src/standard.c
+++ b/src/standard.c
@@ -2558,6 +2558,36 @@ int v6tov4(struct in_addr *sin_addr, struct in6_addr *sin6_addr)
 	return 0;
 }
 
+/* compare two struct sockaddr_storage and return:
+ *  0 (true)  if the addr is the same in both
+ *  1 (false) if the addr is not the same in both
+ *  -1 (unable) if one of the addr is not AF_INET*
+ */
+int ipcmp(struct sockaddr_storage *ss1, struct sockaddr_storage *ss2)
+{
+	if ((ss1->ss_family != AF_INET) && (ss1->ss_family != AF_INET6))
+		return -1;
+
+	if ((ss2->ss_family != AF_INET) && (ss2->ss_family != AF_INET6))
+		return -1;
+
+	if (ss1->ss_family != ss2->ss_family)
+		return 1;
+
+	switch (ss1->ss_family) {
+		case AF_INET:
+			return memcmp(&((struct sockaddr_in *)ss1)->sin_addr,
+  &((struct sockaddr_in *)ss2)->sin_addr,
+  sizeof(struct in_addr)) != 0;
+		case AF_INET6:
+			return memcmp(&((struct sockaddr_in6 *)ss1)->sin6_addr,
+  &((struct sockaddr_in6 *)ss2)->sin6_addr,
+  sizeof(struct in6_addr)) != 0;
+	}
+
+	return 1;
+}
+
 char *human_time(int t, short hz_div) {
 	static char rv[sizeof("24855d23h")+1];	// longest of "23h59m" and "59m59s"
 	char *p = rv;
-- 
1.9.1

From bcb154ac7126019f1fd9358d777f460164b0c771 Mon Sep 17 00:00:00 2001
From: Baptiste Assmann 
Date: Sun, 31 Jan 2016 00:27:17 +0100
Subject: [PATCH 02/11] MINOR: standard.c: ipcpy() function to copy an IP
 address from a struct sockaddr_storage into an other one

The function ipcpy() simply duplicates the IP address found in one
struct sockaddr_storage into an other struct sockaddr_storage.
It also update the family on the destination structure.

Memory of destination structure must be allocated and cleared by the
caller.
---
 include/common/standard.h |  6 ++
 src/standard.c| 21 +
 2 files changed, 27 insertions(+)

diff --git a/include/common/standard.h b/include/common/standard.h
index bc1ab40..d4f2448 100644
--- a/include/common/standard.h
+++ b/include/common/standard.h
@@ -886,6 +886,12 @@ extern int v6tov4(struct in_addr *sin_addr, struct in6_addr *sin6_addr);
  */
 int ipcmp(struct sockaddr_storage *ss1, struct sockaddr_storage *ss2);
 
+/* copy ip from  into 
+ * the caller must clear  before calling.
+ * Returns a pointer to the destination
+ */
+struct sockaddr_storage *ipcpy(struct sockaddr_storage *source, struct sockaddr_storage *dest);
+
 char *human_time(int t, short hz_div);
 
 extern const char *monthname[];
diff --git a/src/standard.c b/src/standard.c
index d85c720..5937b48 100644
--- a/src/standard.c
+++ b/src/standard.c
@@ -2588,6 +2588,27 @@ int ipcmp(struct sockaddr_storage *ss1, struct sockaddr_storage *ss2)
 	return 1;
 }
 
+/* copy IP address from  into 
+ * the caller must allocate and clear  before calling.
+ * Returns a pointer to the destination.
+ */
+struct sockaddr_storage *ipcpy(struct sockaddr_storage *source, struct sockaddr_storage *dest)
+{
+	dest->ss_family = source->ss_family;
+
+	/* copy new addr and apply it */
+	switch (source->ss_family) {
+		case AF_INET:
+			((struct sockaddr_in *)dest)->sin_addr.s_addr = ((struct sockaddr_in *)source)->sin_addr.s_addr;
+			break;
+		case AF_INET6:
+			memcpy(((struct sockaddr_in6 *)dest)->sin6_addr.s6_addr, ((struct sockaddr_in6 *)source)->sin6_addr.s6_addr, sizeof(struct in6_addr));
+			break;
+	}
+
+	return dest;
+}
+
 char *human_time(int t, short hz_div) {
 	static char rv[sizeof("24855d23h")+1];	// longest of "23h59m" and "59m59s"
 	char *p = rv;
-- 
1.9.1

[PATCH] MAJOR: HAProxy 1.7 obsoletes a 'service port"-less server in a listen section

[Baptiste]

Hi,

This was an undocumented feature which is inherited from very early ages of
HAProxy: in a listen section (only), if a server has no service port
configured (after its IP address) and checks are enabled on it, then
HAProxy uses the port defined by the first bind line of the same section.

We decided to obsolete this feature, cause it's useless now and because it
prevented a simple and reliable way to change the server port (patches on
their way).

It's a MAJOR change which might break some configurations.

Baptiste
From 4ac38c5f2e22ff1294efbaabe9b632474924412d Mon Sep 17 00:00:00 2001
From: Baptiste Assmann 
Date: Mon, 25 Apr 2016 13:40:51 +0200
Subject: [PATCH 03/11] MAJOR: listen section: don't use first bind port
 anymore when no server ports are provided

Up to HAProxy 1.7, HAProxy used to use the first bind port from it's
local 'listen' section when no port is configured on the server.

IE, in the configuration below, the server port would be 25:

  listen smtp
   bind :25
   server s1 1.0.0.1 check

This way of working is now obsolete and can be removed, furthermore it is not
documented!

This will make the possibility to change the server's port much easier.
---
 src/server.c | 13 -
 1 file changed, 13 deletions(-)

diff --git a/src/server.c b/src/server.c
index 39fc4db..62c08b0 100644
--- a/src/server.c
+++ b/src/server.c
@@ -1767,19 +1767,6 @@ int parse_server(const char *file, int linenum, char **args, struct proxy *curpr
 			if (!newsrv->check.port)
 newsrv->check.port = realport; /* by default */
 
-			if (!newsrv->check.port) {
-/* not yet valid, because no port was set on
- * the server either. We'll check if we have
- * a known port on the first listener.
- */
-struct listener *l;
-
-list_for_each_entry(l, >conf.listeners, by_fe) {
-	newsrv->check.port = get_host_port(>addr);
-	if (newsrv->check.port)
-		break;
-}
-			}
 			/*
 			 * We need at least a service port, a check port or the first tcp-check rule must
 			 * be a 'connect' one when checking an IPv4/IPv6 server.
-- 
1.9.1

Re: [PATCH] [RFC]/MINOR: connection: Add server name to proxy protocol v2 header.

[Amos Jeffries]

On 11/08/2016 10:05 p.m., Erik Seres wrote:
> Hi Amos,
> 
> Thanks for the answers. After a bit of a delay, I’m getting back to 
> implementing this. However, I still have a couple of questions in line 
> below...
> 
> Thanks,
> Erik
> 
> 
>> On 2016 Jun 1, at 08:44, Amos Jeffries wrote:
>>
>> On 30/05/2016 11:03 p.m., Erik Seres wrote:
>>> Hi Willy and Amos,
>>>
>>> I think I am confused by what information is expected to go into the
>>> PP2_TYPE_AUTHORITY field and how it would be a suitable substitute 
>>> for what SNI represents.
>>
>> PP2 is generic and needs to relay multiple protocols.
>>
>> Authority is a frequently used and generic thing holding a host:port or
>> IP:port value representing the server for the protocol being relayed.
>>
>> SNI breakes the normal pattern used by other protocols and restricts its
>> value to only being an FQDN. No port or raw-IP representation of the
>> server permitted.
>>
>>
>> The mapping is generic and works for any wrapper protocol TLS is
>> transmitted over:
>>
>> When generating the authority from an SNI;
>> * copy the SNI value into authority as-is, and
>> * append the server port being contacted.
> 
> How to decide when to use the SNI value vs. something else to populate 
> PP2_TYPE_AUTHORITY? For example, in case it is HTTP over TLS with both the 
> “Host:” HTTP header and the TLS SNI field provided, which would take 
> precedence over the other and make it into the PP2_TYPE_AUTHORITY field? What 
> to do in conflicting cases as you mentioned earlier?
> 

There is supposed to only be one authority with the same value in all
places. So there should be no confusion over which of the same-valued
fields to use. HTTP does possibly have port number and IP address which
SNI can't store, so that is maybe better to use when you are sure they
are the same otherwise.

As to what to do when they are conflicting. That is tricky. Problems
like CVE-2009-0801 which hit Squid some years back can happen if you use
the wrong one.

In Squid to solve that CVE we find it safer to drop all the uncertain
authority name(s) and use only the IP address from the TCP level
underneath - that can't be faked. So, IMHO it would make sense to do the
same thing and not send PP2_TYPE_AUTHORITY at all if you are not certain
its value is correct. It is optional after all.

Amos

Re: Problem with redirecting www. to non-www domains back to HAProxy based on host header

[Igor Cicimov]

On Fri, Aug 12, 2016 at 9:02 AM, Maurice van Ree 
wrote:

> Hi,
>
> We ran into some trouble where users would explicitly enter www in front
> of a subdomain, having them thinking they're unable to connect. So we came
> up with a solution of registering those dns names as well, e.g.
> app.mydomain.com as well as www.app.mydomain.com and handle things from
> there. Because we use HAProxy behind an Amazon elastic load balancer which
> takes care of some things for us, the idea was to forward incoming requests
> for both dns entries to HAProxy, filter out the www. requests and do a
> permanent redirect to the non www. entry. This way they should arrive at
> the Amazon load balancer just like they never entered the www. and traffic
> should be handled as such.
>
> I tried both using the prefix and location options for the redirect, but
> keep running into the problem that the host header seems to remain
> unchanged. This is causing my acl condition to remain true at all times,
> which in turn causes a redirect loop.
>

Why don't you change the Host header too then?


> These are both acls which I came up with, where $frontend is typically
> something like myapp.mydomain.com:
>
> http-request redirect code 301 prefix {{$frontend}} if { hdr(host) -i
> www.{{$frontend}} }
> http-request redirect code 307 location {{$frontend}}%[capture.req.uri]
> if { hdr(host) -i www.{{$frontend}} }
>
> Both lead to a never ending concatenation of the $frontend variable being
> added after the original host it seems:
>
> www.myapp.mydomain.com/uri/myapp.mydomain.com/uri/..index.html
>
> I think this is caused by the host header remaining the same (I checked
> this using a Chrome plugin).
> However, when I specifically enter a protocol in front of the redirect
> location like this for example, it works fine:
>
> http-request redirect code 301 prefix http://{{$frontend}} if { hdr(host)
> -i www.{{$frontend}} }
>
> Since we have a mix of configurations where both secure and non-secure
> traffic is possible, I don't really want to complicate things further and
> go down that route.
>
> Two concrete questions:
>
> 1. Do you have any idea why this happens, and doesn't happen when
> specifying a protocol?
> 2. Is there any solution to this? As far as I know, rewriting the host
> header in a redirect isn't something that is supported by HAProxy (and not
> really that nice..) right?
>
>
> Best Regards,
>
> Maurice van Ree
>



-- 
Igor Cicimov | DevOps


p. +61 (0) 433 078 728
e. ig...@encompasscorporation.com 
w*.* www.encompasscorporation.com
a. Level 4, 65 York Street, Sydney 2000

Problem with redirecting www. to non-www domains back to HAProxy based on host header

[Maurice van Ree]

Hi,

We ran into some trouble where users would explicitly enter www in front of
a subdomain, having them thinking they're unable to connect. So we came up
with a solution of registering those dns names as well, e.g.
app.mydomain.com as well as www.app.mydomain.com and handle things from
there. Because we use HAProxy behind an Amazon elastic load balancer which
takes care of some things for us, the idea was to forward incoming requests
for both dns entries to HAProxy, filter out the www. requests and do a
permanent redirect to the non www. entry. This way they should arrive at
the Amazon load balancer just like they never entered the www. and traffic
should be handled as such.

I tried both using the prefix and location options for the redirect, but
keep running into the problem that the host header seems to remain
unchanged. This is causing my acl condition to remain true at all times,
which in turn causes a redirect loop.
These are both acls which I came up with, where $frontend is typically
something like myapp.mydomain.com:

http-request redirect code 301 prefix {{$frontend}} if { hdr(host) -i
www.{{$frontend}} }
http-request redirect code 307 location {{$frontend}}%[capture.req.uri] if
{ hdr(host) -i www.{{$frontend}} }

Both lead to a never ending concatenation of the $frontend variable being
added after the original host it seems:

www.myapp.mydomain.com/uri/myapp.mydomain.com/uri/..index.html

I think this is caused by the host header remaining the same (I checked
this using a Chrome plugin).
However, when I specifically enter a protocol in front of the redirect
location like this for example, it works fine:

http-request redirect code 301 prefix http://{{$frontend}} if { hdr(host)
-i www.{{$frontend}} }

Since we have a mix of configurations where both secure and non-secure
traffic is possible, I don't really want to complicate things further and
go down that route.

Two concrete questions:

1. Do you have any idea why this happens, and doesn't happen when
specifying a protocol?
2. Is there any solution to this? As far as I know, rewriting the host
header in a redirect isn't something that is supported by HAProxy (and not
really that nice..) right?


Best Regards,

Maurice van Ree

Re: question related to setting up tcp relay

[Rajiv]

Hi Expert,

After a long period once again i need your help, actually i am kind of
stuck so please help
I have to forward my incoming ssl request to other host who is again on ssl

both end points are ssl terminated are using their own certificates, so it
is possible?

if yes then please help me getting its configuration and i am very well
aware that same can be done in nginx

PS: I am using 1.5.X version of HAproxy.

Regards,
Rajiv

On Sun, Jan 29, 2012 at 7:07 PM, Willy Tarreau  wrote:

> On Wed, Jan 25, 2012 at 10:07:28AM +0100, Baptiste wrote:
> > Hi,
> >
> > Using HAProxy, your flow will look like below:
> >
> > client sends a event to Haproxy
> > haproxy recieves event, it selects the server from pool
> > haproxy will submit the event
> > haproxy will get response from server
> > haproxy will send response back to client
> > haproxy will wait for another event from same client
> >   [ repeat the sequence as many time as needed ]
> >   { if a timeout client or server occurs, HAProxy closes both
> connections }
> > client closes the connection to haproxy
> > haproxy closes connection to server
> > server acknoledge connection close to haproxy
> > haproxy acknoledge connection close to client
> >
> > In TCP mode, haproxy never closes a connection unless a timeout occurs.
>
> ... or any side closes, of course :-)
>
> To be more precise, there is no notion of request or response in TCP
> without knowing the upper protocol. What Rajiv described here is exactly
> how HTTP works because HTTP is composed of messages with boundaries that
> haproxy knows how to detect. But "TCP" is a stream, there is no boundary,
> so no end of response, etc...
>
> However if your protocol is simple enough, it might make sense to try to
> implement it, maybe even merging it into haproxy if other people are
> using it.
>
> Regards,
> Willy
>
>

Auto Response: Re: question related to setting up tcp relay

[Suresh Visvanathan]

hi, 
I am OOO (aug 5 to aug 10), back in office Aug 11. 

For anything urgent, pls reach out to Ian (ivh@)  thanks  -suresh

Re: question related to setting up tcp relay

[Rajiv]

well it is my more than 4 years old bond with HAproxy which can be broken
by mere ssl :)

Willy,
I apologize for sending little information below is the configuration in
question, I am not removing obvious one to make sure that  i am not doing
any mistake here

===

*global*








*log 127.0.0.1 local2chroot  /var/lib/haproxypidfile
/var/run/haproxy.pidmaxconn 5000userhaproxygroup
haproxydaemonstats socket /var/lib/haproxy/stats*



*defaults*




















*modehttplog globaloption
   httplogoption  dontlognulloption
http-server-closeoption forwardfor   except 127.0.0.0/8
option  redispatchretries
  3timeout http-request10stimeout queue   1mtimeout connect
10stimeout client  1mtimeout server  1mtimeout
http-keep-alive 10stimeout check   10smaxconn
5000stats enablestats uri /statsstats realm Haproxy\ Statisticsstats auth
haproxy:haproxy@197*



*frontend www-http*



*bind *:80 bind *:443 ssl crt /etc/haproxy/ssl/server.pem **reqadd
X-Forwarded-Proto:\ https if { ssl_fc }*
*default_backend test*


*backend test*

*server test1 assets.saas..com:443 
check ssl verify none*

===

with above configuration when my request is forwarded I get 404 from
*assets.saas..com:443
* , where as if i curl directly i am
getting successfully 200

Regards,
Rajiv

On Thu, Aug 11, 2016 at 11:49 AM, Willy Tarreau  wrote:

> Hi Rajiv,
>
> first, please don't resurrect 4-years old threads to ask a new question,
> that's the best way to ensure nobody will read it.
>
> On Thu, Aug 11, 2016 at 11:35:52AM +0530, Rajiv wrote:
> > Hi Expert,
> >
> > After a long period once again i need your help, actually i am kind of
> > stuck so please help
> > I have to forward my incoming ssl request to other host who is again on
> ssl
> >
> > both end points are ssl terminated are using their own certificates, so
> it
> > is possible?
>
> Well, I don't understand what difficulties you are facing as what you
> describe seems pretty common and you gave little information. Would you
> please post your current configuration here and explain what you tried
> to chage ? Have you looked for the word "ssl" in the documentation ?
>
> > if yes then please help me getting its configuration and i am very well
> > aware that same can be done in nginx
>
> If you feel more easy with configuring nginx, maybe you should switch to
> it. You should not be ashamed. There's no point in forcing yourself to
> use a product you find difficult to configure if another one serves you
> better. I mean both products are free!
>
> Regards,
> Willy
>

haproxy terminate with ssl backend

[daniel sanders]

Hi all I need to know if i can terminate SSL on a fronded with SNI and then 
create a new ssl session to the backend

similar to how proxy forwarding works

client ||  HA || backend

i want different certificates at each point,  and the user just gets x-forward 
with the header.


I think most of the haproxy terminology calls this ssl termination, but all the 
examples i found are for http backends not https

Re: haproxy terminate with ssl backend

[Lukas Tribus]

Hi Daniel,


Am 11.08.2016 um 09:07 schrieb daniel sanders:

Hi all I need to know if i can terminate SSL on a fronded with SNI and then 
create a new ssl session to the backend


Yes, it is possible. All you need is to specify the ssl keyword on the 
server configuration in the backend section.




Regards,

Lukas

Re: question related to setting up tcp relay

[Willy Tarreau]

Hi Rajiv,

first, please don't resurrect 4-years old threads to ask a new question,
that's the best way to ensure nobody will read it.

On Thu, Aug 11, 2016 at 11:35:52AM +0530, Rajiv wrote:
> Hi Expert,
> 
> After a long period once again i need your help, actually i am kind of
> stuck so please help
> I have to forward my incoming ssl request to other host who is again on ssl
> 
> both end points are ssl terminated are using their own certificates, so it
> is possible?

Well, I don't understand what difficulties you are facing as what you
describe seems pretty common and you gave little information. Would you
please post your current configuration here and explain what you tried
to chage ? Have you looked for the word "ssl" in the documentation ?

> if yes then please help me getting its configuration and i am very well
> aware that same can be done in nginx

If you feel more easy with configuring nginx, maybe you should switch to
it. You should not be ashamed. There's no point in forcing yourself to
use a product you find difficult to configure if another one serves you
better. I mean both products are free!

Regards,
Willy

how to register

[Reggie Magalso]

Re: question related to setting up tcp relay

[Baptiste]

Hi,

A few interesting pages for you:
  http://haproxy.com/doc/hapee/1.5/traffic_management/tls.html
  http://haproxy.com/doc/hapee/1.5/deployment_guides/tls_layouts.html

Please note that 404 sounds more a server issue :)

Baptiste



On Thu, Aug 11, 2016 at 9:03 AM, Rajiv  wrote:

> well it is my more than 4 years old bond with HAproxy which can be broken
> by mere ssl :)
>
> Willy,
> I apologize for sending little information below is the configuration in
> question, I am not removing obvious one to make sure that  i am not doing
> any mistake here
>
> ===
>
> *global*
>
>
>
>
>
>
>
>
> *log 127.0.0.1 local2chroot  /var/lib/haproxypidfile
> /var/run/haproxy.pidmaxconn 5000userhaproxygroup
> haproxydaemonstats socket /var/lib/haproxy/stats*
>
>
>
> *defaults*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *modehttplog globaloption
>  httplogoption  dontlognulloption
> http-server-closeoption forwardfor   except 127.0.0.0/8
> option  redispatchretries
>   3timeout http-request10stimeout queue   1mtimeout connect
> 10stimeout client  1mtimeout server  1mtimeout
> http-keep-alive 10stimeout check   10smaxconn
> 5000stats enablestats uri /statsstats realm Haproxy\ Statisticsstats auth
> haproxy:haproxy@197*
>
>
>
> *frontend www-http*
>
>
>
> *bind *:80 bind *:443 ssl crt /etc/haproxy/ssl/server.pem **reqadd
> X-Forwarded-Proto:\ https if { ssl_fc }*
> *default_backend test*
>
>
> *backend test*
>
> *server test1 assets.saas..com:443 
> check ssl verify none*
>
> ===
>
> with above configuration when my request is forwarded I get 404 from 
> *assets.saas..com:443
> * , where as if i curl directly i am
> getting successfully 200
>
> Regards,
> Rajiv
>
> On Thu, Aug 11, 2016 at 11:49 AM, Willy Tarreau  wrote:
>
>> Hi Rajiv,
>>
>> first, please don't resurrect 4-years old threads to ask a new question,
>> that's the best way to ensure nobody will read it.
>>
>> On Thu, Aug 11, 2016 at 11:35:52AM +0530, Rajiv wrote:
>> > Hi Expert,
>> >
>> > After a long period once again i need your help, actually i am kind of
>> > stuck so please help
>> > I have to forward my incoming ssl request to other host who is again on
>> ssl
>> >
>> > both end points are ssl terminated are using their own certificates, so
>> it
>> > is possible?
>>
>> Well, I don't understand what difficulties you are facing as what you
>> describe seems pretty common and you gave little information. Would you
>> please post your current configuration here and explain what you tried
>> to chage ? Have you looked for the word "ssl" in the documentation ?
>>
>> > if yes then please help me getting its configuration and i am very well
>> > aware that same can be done in nginx
>>
>> If you feel more easy with configuring nginx, maybe you should switch to
>> it. You should not be ashamed. There's no point in forcing yourself to
>> use a product you find difficult to configure if another one serves you
>> better. I mean both products are free!
>>
>> Regards,
>> Willy
>>
>
>

Re: [PATCH] [RFC]/MINOR: connection: Add server name to proxy protocol v2 header.

[Erik Seres]

Hi Amos,

Thanks for the answers. After a bit of a delay, I’m getting back to 
implementing this. However, I still have a couple of questions in line below...

Thanks,
Erik


> On 2016 Jun 1, at 08:44, Amos Jeffries  wrote:
> 
> On 30/05/2016 11:03 p.m., Erik Seres wrote:
>> Hi Willy and Amos,
>> 
>> I think I am confused by what information is expected to go into the
>> PP2_TYPE_AUTHORITY field and how it would be a suitable substitute 
>> for what SNI represents.
> 
> PP2 is generic and needs to relay multiple protocols.
> 
> Authority is a frequently used and generic thing holding a host:port or
> IP:port value representing the server for the protocol being relayed.
> 
> SNI breakes the normal pattern used by other protocols and restricts its
> value to only being an FQDN. No port or raw-IP representation of the
> server permitted.
> 
> 
> The mapping is generic and works for any wrapper protocol TLS is
> transmitted over:
> 
> When generating the authority from an SNI;
> * copy the SNI value into authority as-is, and
> * append the server port being contacted.

How to decide when to use the SNI value vs. something else to populate 
PP2_TYPE_AUTHORITY? For example, in case it is HTTP over TLS with both the 
“Host:” HTTP header and the TLS SNI field provided, which would take precedence 
over the other and make it into the PP2_TYPE_AUTHORITY field? What to do in 
conflicting cases as you mentioned earlier?

> When generating an SNI from an authority:
> * drop the port, and
> * if the remainder is a raw-IP, there is no SNI
> * else, the remainder is the SNI value.
> 
> 
>> 
>> Where would that information (server name?) come from outside the
>> TLS handshake?
> 
> From the authority field of whatever transfer protocol the TLS is being
> wrapped by / relayed over.
> 
> PP2 in this case. But it could also be HTTP (CONNECT message) or SMTP
> (Start-TLS).

What I meant was where to get the information to put _into_ PP2?

>> 
>> And why is HTTP CONNECT mentioned at all in this discussion?
> 
> Two reasons:
> 
> 1) Because HAProxy and Squid which implement relay and gateway for PP2
> protocol are HTTP proxies.
> 
> 2) Because there is a pile of trouble and security issues that exist as
> a direct result of the HTTP authority being represented mutiple times in
> different ways in a single CONNECT message.
> 
>  It is a good example of why we should not have several
> not-quite-identical representations in a PP2 message (PP2_TYPE_AUTHORITY
> and PP2_TYPE_SSL_SNI).
> 
> 
>> 
>> Again, excuse my ignorance but I just can’t seem to put two and two together.
>> 
> 
> Amos
>