Re: Get http connection client/server ip/port

[Peter Hudec]

just to be sure I have tried another kernel, with the same result

0 : CentOS Linux (5.1.16-1.el7.elrepo.x86_64) 7 (Core)
1 : CentOS Linux (4.4.184-1.el7.elrepo.x86_64) 7 (Core)
2 : CentOS Linux (3.10.0-957.21.3.el7.x86_64) 7 (Core)



> On 5 Jul 2019, at 23:23, Peter Hudec  wrote:
> 
> There was no IPv6..
> 
> If I change BIND from
> 
> bind :80
> bind :443 ssl crt /home/certs/haproxy/combined/
> 
> to
> 
> bind :::80 v4v6
> bind :::443 v4v6 ssl crt /home/certs/haproxy/combined/
> 
> the IPv4 and IPv6 are working as expected.
> 
> But in this setup IPv4 is wrongIPv6 is OK
> 
> bind :::80
> bind :::443 ssl crt /home/certs/haproxy/combined/
> bind :80
> bind :443 ssl crt /home/certs/haproxy/combined/
> 
> 
>   regards
>   Peter
> 
>> On 5 Jul 2019, at 23:12, Peter Hudec > > wrote:
>> 
>> it works on localhost, but not on public ip
>> 
>> curl -k -v https://2.57.64.11 
>> curl -k -v http://2.57.64.11 
>> 
>> or try IPv6 2a09:d4c0::11
>> 
>>  Peter
>> 
>>> On 5 Jul 2019, at 23:02, Peter Hudec >> > wrote:
>>> 
>>> thos config do not works.
>>> I took your working config anf add mu global sand default section
>>> 
>>> global
>>> log 127.0.0.1 local2
>>> 
>>> chroot  /var/lib/haproxy
>>> pidfile /var/run/haproxy.pid
>>> maxconn 4000
>>> userhaproxy
>>> group   haproxy
>>> daemon
>>> 
>>> # turn on stats unix socket
>>> stats socket /var/opt/rh/rh-haproxy18/lib/haproxy/stats
>>> 
>>> # set default parameters to the modern configuration
>>> # https://mozilla.github.io/server-side-tls/ssl-config-generator/ 
>>> 
>>> 
>>> ssl-default-bind-ciphers 
>>> ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
>>> ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets
>>> ssl-default-server-ciphers 
>>> ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
>>> ssl-default-server-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets
>>> tune.ssl.default-dh-param 2048
>>> ssl-server-verify none
>>> 
>>> #-
>>> # HTTP section defaults, frontends and backends
>>> #-
>>> 
>>> defaults HTTP
>>> modehttp
>>> log global
>>> option  httplog
>>> option  dontlognull
>>> option http-server-close
>>> option forwardfor   except 127.0.0.0/8
>>> 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
>>> timeout tunnel  3600s
>>> maxconn 3000
>>> default-server inter 15s rise 2 fall 2
>>> 
>>> 
>>> #-
>>> # main frontend which proxys to the backends
>>> #-
>>> listen fe_http_main
>>> bind :80
>>> bind :443 ssl crt /home/certs/haproxy/combined/
>>> mode http
>>> 
>>> tcp-request inspect-delay 5s
>>> tcp-request content accept if HTTP
>>> 
>>> timeout connect 1s
>>> timeout server  5s
>>> timeout client  5s
>>> 
>>> http-response set-header X-Server-IP %[dst]
>>> http-response set-header X-Server-Port %[dst_port]
>>> http-response set-header X-Client-IP %[src]
>>> http-response set-header X-Client-Port %[src_port]
>>> server www  127.0.0.1:8000
>>> 
>>> listen srv
>>> mode http
>>> bind 127.0.0.1:8000
>>> http-request deny deny_status 200
>>> 
>>> 
 On 5 Jul 2019, at 22:55, Peter Hudec >>> > wrote:
 
 There’s not problem with nginx/php.
 
 If I add this lines in my config
 
 http-response set-header X-Server-IP %[dst]
 http-response set-header X-Server-Port %[dst_port]
 http-response set-header X-Client-IP %[src]
 http-response set-header X-Client-Port %[src_port]
 
 see exactly the same.
 
Peter
 
> On 5 Jul 2019, at 22:53, Christopher Faulet 

Re: Get http connection client/server ip/port

[Peter Hudec]

There was no IPv6..

If I change BIND from

bind :80
bind :443 ssl crt /home/certs/haproxy/combined/

to

bind :::80 v4v6
bind :::443 v4v6 ssl crt /home/certs/haproxy/combined/

the IPv4 and IPv6 are working as expected.

But in this setup IPv4 is wrongIPv6 is OK

bind :::80
bind :::443 ssl crt /home/certs/haproxy/combined/
bind :80
bind :443 ssl crt /home/certs/haproxy/combined/


regards
Peter

> On 5 Jul 2019, at 23:12, Peter Hudec  wrote:
> 
> it works on localhost, but not on public ip
> 
> curl -k -v https://2.57.64.11 
> curl -k -v http://2.57.64.11 
> 
> or try IPv6 2a09:d4c0::11
> 
>   Peter
> 
>> On 5 Jul 2019, at 23:02, Peter Hudec > > wrote:
>> 
>> thos config do not works.
>> I took your working config anf add mu global sand default section
>> 
>> global
>> log 127.0.0.1 local2
>> 
>> chroot  /var/lib/haproxy
>> pidfile /var/run/haproxy.pid
>> maxconn 4000
>> userhaproxy
>> group   haproxy
>> daemon
>> 
>> # turn on stats unix socket
>> stats socket /var/opt/rh/rh-haproxy18/lib/haproxy/stats
>> 
>> # set default parameters to the modern configuration
>> # https://mozilla.github.io/server-side-tls/ssl-config-generator/ 
>> 
>> 
>> ssl-default-bind-ciphers 
>> ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
>> ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets
>> ssl-default-server-ciphers 
>> ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
>> ssl-default-server-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets
>> tune.ssl.default-dh-param 2048
>> ssl-server-verify none
>> 
>> #-
>> # HTTP section defaults, frontends and backends
>> #-
>> 
>> defaults HTTP
>> modehttp
>> log global
>> option  httplog
>> option  dontlognull
>> option http-server-close
>> option forwardfor   except 127.0.0.0/8
>> 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
>> timeout tunnel  3600s
>> maxconn 3000
>> default-server inter 15s rise 2 fall 2
>> 
>> 
>> #-
>> # main frontend which proxys to the backends
>> #-
>> listen fe_http_main
>> bind :80
>> bind :443 ssl crt /home/certs/haproxy/combined/
>> mode http
>> 
>> tcp-request inspect-delay 5s
>> tcp-request content accept if HTTP
>> 
>> timeout connect 1s
>> timeout server  5s
>> timeout client  5s
>> 
>> http-response set-header X-Server-IP %[dst]
>> http-response set-header X-Server-Port %[dst_port]
>> http-response set-header X-Client-IP %[src]
>> http-response set-header X-Client-Port %[src_port]
>> server www  127.0.0.1:8000
>> 
>> listen srv
>> mode http
>> bind 127.0.0.1:8000
>> http-request deny deny_status 200
>> 
>> 
>>> On 5 Jul 2019, at 22:55, Peter Hudec >> > wrote:
>>> 
>>> There’s not problem with nginx/php.
>>> 
>>> If I add this lines in my config
>>> 
>>> http-response set-header X-Server-IP %[dst]
>>> http-response set-header X-Server-Port %[dst_port]
>>> http-response set-header X-Client-IP %[src]
>>> http-response set-header X-Client-Port %[src_port]
>>> 
>>> see exactly the same.
>>> 
>>> Peter
>>> 
 On 5 Jul 2019, at 22:53, Christopher Faulet >>> > wrote:
 
 Le 05/07/2019 à 21:55, Peter Hudec a écrit :
> Hi Jarno,
> thanks for answer.
> I tried to run the haproxy in debug mode, but I do not see the request 
> headers for the upstream in the log.
> But I have found some new facts.
> Test these 2 scenarios, at this moment there is no valid certs
> http://web01.test.host.sk/test.php 
> 

Re: Get http connection client/server ip/port

[Peter Hudec]

it works on localhost, but not on public ip

curl -k -v https://2.57.64.11 
curl -k -v http://2.57.64.11

or try IPv6 2a09:d4c0::11

Peter

> On 5 Jul 2019, at 23:02, Peter Hudec  wrote:
> 
> thos config do not works.
> I took your working config anf add mu global sand default section
> 
> global
> log 127.0.0.1 local2
> 
> chroot  /var/lib/haproxy
> pidfile /var/run/haproxy.pid
> maxconn 4000
> userhaproxy
> group   haproxy
> daemon
> 
> # turn on stats unix socket
> stats socket /var/opt/rh/rh-haproxy18/lib/haproxy/stats
> 
> # set default parameters to the modern configuration
> # https://mozilla.github.io/server-side-tls/ssl-config-generator/ 
> 
> 
> ssl-default-bind-ciphers 
> ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
> ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets
> ssl-default-server-ciphers 
> ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
> ssl-default-server-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets
> tune.ssl.default-dh-param 2048
> ssl-server-verify none
> 
> #-
> # HTTP section defaults, frontends and backends
> #-
> 
> defaults HTTP
> modehttp
> log global
> option  httplog
> option  dontlognull
> option http-server-close
> option forwardfor   except 127.0.0.0/8
> 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
> timeout tunnel  3600s
> maxconn 3000
> default-server inter 15s rise 2 fall 2
> 
> 
> #-
> # main frontend which proxys to the backends
> #-
> listen fe_http_main
> bind :80
> bind :443 ssl crt /home/certs/haproxy/combined/
> mode http
> 
> tcp-request inspect-delay 5s
> tcp-request content accept if HTTP
> 
> timeout connect 1s
> timeout server  5s
> timeout client  5s
> 
> http-response set-header X-Server-IP %[dst]
> http-response set-header X-Server-Port %[dst_port]
> http-response set-header X-Client-IP %[src]
> http-response set-header X-Client-Port %[src_port]
> server www  127.0.0.1:8000
> 
> listen srv
> mode http
> bind 127.0.0.1:8000
> http-request deny deny_status 200
> 
> 
>> On 5 Jul 2019, at 22:55, Peter Hudec > > wrote:
>> 
>> There’s not problem with nginx/php.
>> 
>> If I add this lines in my config
>> 
>> http-response set-header X-Server-IP %[dst]
>> http-response set-header X-Server-Port %[dst_port]
>> http-response set-header X-Client-IP %[src]
>> http-response set-header X-Client-Port %[src_port]
>> 
>> see exactly the same.
>> 
>>  Peter
>> 
>>> On 5 Jul 2019, at 22:53, Christopher Faulet >> > wrote:
>>> 
>>> Le 05/07/2019 à 21:55, Peter Hudec a écrit :
 Hi Jarno,
 thanks for answer.
 I tried to run the haproxy in debug mode, but I do not see the request 
 headers for the upstream in the log.
 But I have found some new facts.
 Test these 2 scenarios, at this moment there is no valid certs
 http://web01.test.host.sk/test.php 
 https://web01.test.host.sk/test.php 
 look for the
 X_SERVER_IP
 X_SERVER_PORT
 X_CLIENT_IP
 X_CLIENT_PORT
 See the difference?
 For the HTTP, the values are correct, for HTTPS not.
 I’m running RH SCL HAPROXY. I could try to compile newer version or are 
 there any for CentOS7?
>>> 
>>> I don't know how your nginx/php is configured. But try to replace nginx by 
>>> a ncat. Something like that:
>>> 
>>>  printf "HTTP/1.1 200 ok\r\nContent-length: 0\r\n\r\n" | nc -l -p  {PORT}
>>> 
>>> You will see the request from the server point of view. If it still fails, 
>>> share the smallest HAProxy configuration to reproduce the bug.
>>> 

Re: Get http connection client/server ip/port

[Peter Hudec]

thos config do not works.
I took your working config anf add mu global sand default section

global
log 127.0.0.1 local2

chroot  /var/lib/haproxy
pidfile /var/run/haproxy.pid
maxconn 4000
userhaproxy
group   haproxy
daemon

# turn on stats unix socket
stats socket /var/opt/rh/rh-haproxy18/lib/haproxy/stats

# set default parameters to the modern configuration
# https://mozilla.github.io/server-side-tls/ssl-config-generator/

ssl-default-bind-ciphers 
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets
ssl-default-server-ciphers 
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
ssl-default-server-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets
tune.ssl.default-dh-param 2048
ssl-server-verify none

#-
# HTTP section defaults, frontends and backends
#-

defaults HTTP
modehttp
log global
option  httplog
option  dontlognull
option http-server-close
option forwardfor   except 127.0.0.0/8
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
timeout tunnel  3600s
maxconn 3000
default-server inter 15s rise 2 fall 2


#-
# main frontend which proxys to the backends
#-
listen fe_http_main
bind :80
bind :443 ssl crt /home/certs/haproxy/combined/
mode http

tcp-request inspect-delay 5s
tcp-request content accept if HTTP

timeout connect 1s
timeout server  5s
timeout client  5s

http-response set-header X-Server-IP %[dst]
http-response set-header X-Server-Port %[dst_port]
http-response set-header X-Client-IP %[src]
http-response set-header X-Client-Port %[src_port]
server www  127.0.0.1:8000

listen srv
mode http
bind 127.0.0.1:8000
http-request deny deny_status 200


> On 5 Jul 2019, at 22:55, Peter Hudec  wrote:
> 
> There’s not problem with nginx/php.
> 
> If I add this lines in my config
> 
> http-response set-header X-Server-IP %[dst]
> http-response set-header X-Server-Port %[dst_port]
> http-response set-header X-Client-IP %[src]
> http-response set-header X-Client-Port %[src_port]
> 
> see exactly the same.
> 
>   Peter
> 
>> On 5 Jul 2019, at 22:53, Christopher Faulet > > wrote:
>> 
>> Le 05/07/2019 à 21:55, Peter Hudec a écrit :
>>> Hi Jarno,
>>> thanks for answer.
>>> I tried to run the haproxy in debug mode, but I do not see the request 
>>> headers for the upstream in the log.
>>> But I have found some new facts.
>>> Test these 2 scenarios, at this moment there is no valid certs
>>> http://web01.test.host.sk/test.php 
>>> https://web01.test.host.sk/test.php
>>> look for the
>>> X_SERVER_IP
>>> X_SERVER_PORT
>>> X_CLIENT_IP
>>> X_CLIENT_PORT
>>> See the difference?
>>> For the HTTP, the values are correct, for HTTPS not.
>>> I’m running RH SCL HAPROXY. I could try to compile newer version or are 
>>> there any for CentOS7?
>> 
>> I don't know how your nginx/php is configured. But try to replace nginx by a 
>> ncat. Something like that:
>> 
>>  printf "HTTP/1.1 200 ok\r\nContent-length: 0\r\n\r\n" | nc -l -p  {PORT}
>> 
>> You will see the request from the server point of view. If it still fails, 
>> share the smallest HAProxy configuration to reproduce the bug.
>> 
>> -- 
>> Christopher Faulet
> 

Re: Get http connection client/server ip/port

[Peter Hudec]

There’s not problem with nginx/php.

If I add this lines in my config

http-response set-header X-Server-IP %[dst]
http-response set-header X-Server-Port %[dst_port]
http-response set-header X-Client-IP %[src]
http-response set-header X-Client-Port %[src_port]

see exactly the same.

Peter

> On 5 Jul 2019, at 22:53, Christopher Faulet  wrote:
> 
> Le 05/07/2019 à 21:55, Peter Hudec a écrit :
>> Hi Jarno,
>> thanks for answer.
>> I tried to run the haproxy in debug mode, but I do not see the request 
>> headers for the upstream in the log.
>> But I have found some new facts.
>> Test these 2 scenarios, at this moment there is no valid certs
>> http://web01.test.host.sk/test.php
>> https://web01.test.host.sk/test.php
>> look for the
>> X_SERVER_IP
>> X_SERVER_PORT
>> X_CLIENT_IP
>> X_CLIENT_PORT
>> See the difference?
>> For the HTTP, the values are correct, for HTTPS not.
>> I’m running RH SCL HAPROXY. I could try to compile newer version or are 
>> there any for CentOS7?
> 
> I don't know how your nginx/php is configured. But try to replace nginx by a 
> ncat. Something like that:
> 
>  printf "HTTP/1.1 200 ok\r\nContent-length: 0\r\n\r\n" | nc -l -p  {PORT}
> 
> You will see the request from the server point of view. If it still fails, 
> share the smallest HAProxy configuration to reproduce the bug.
> 
> -- 
> Christopher Faulet

Re: Get http connection client/server ip/port

[Christopher Faulet]

Le 05/07/2019 à 21:55, Peter Hudec a écrit :

Hi Jarno,

thanks for answer.
I tried to run the haproxy in debug mode, but I do not see the request headers 
for the upstream in the log.


But I have found some new facts.

Test these 2 scenarios, at this moment there is no valid certs

http://web01.test.host.sk/test.php
https://web01.test.host.sk/test.php

look for the
X_SERVER_IP
X_SERVER_PORT
X_CLIENT_IP
X_CLIENT_PORT

See the difference?
For the HTTP, the values are correct, for HTTPS not.

I’m running RH SCL HAPROXY. I could try to compile newer version or are there 
any for CentOS7?




I don't know how your nginx/php is configured. But try to replace nginx by a 
ncat. Something like that:


  printf "HTTP/1.1 200 ok\r\nContent-length: 0\r\n\r\n" | nc -l -p  {PORT}

You will see the request from the server point of view. If it still fails, share 
the smallest HAProxy configuration to reproduce the bug.


--
Christopher Faulet

Re: Get http connection client/server ip/port

[Peter Hudec]

Hi,

still could be problem on my side, but I have the same result with version
1.8.20
1.9.8
2.0.1

Peter

> On 5 Jul 2019, at 21:55, Peter Hudec  wrote:
> 
> Hi Jarno,
> 
> thanks for answer.
> I tried to run the haproxy in debug mode, but I do not see the request 
> headers for the upstream in the log.
> 
> But I have found some new facts.
> 
> Test these 2 scenarios, at this moment there is no valid certs
> 
> http://web01.test.host.sk/test.php 
> https://web01.test.host.sk/test.php 
> 
> look for the
> X_SERVER_IP
> X_SERVER_PORT
> X_CLIENT_IP
> X_CLIENT_PORT
> 
> See the difference?
> For the HTTP, the values are correct, for HTTPS not.
> 
> I’m running RH SCL HAPROXY. I could try to compile newer version or are there 
> any for CentOS7?
> 
>   regards
>   Peter
> 
> 
> 
> 
>> On 4 Jul 2019, at 18:42, Jarno Huuskonen > > wrote:
>> 
>> Hi,
>> 
>> On Thu, Jul 04, Peter Hudec wrote:
>>> I have maybe found some bug in haproxy, submitted as 
>>> https://github.com/haproxy/haproxy/issues/154 
>>> .
>> 
>> 1.8.4 is fairly old, can you reproduce on more recent 1.8.x or latest 2.0.x ?
>> 
>>> The variables dst, dst_port are identical with the src, src_port.
>>> 
>>> Is there any other way how to get these /in this case dst/ values ??
>>> 
>>> What do I need is ..
>>> 
>>>http-request set-header X-Server-IP %[dst]
>>>http-request set-header X-Server-Port %[dst_port]
>>>http-request set-header X-Client-IP %[src]
>>>http-request set-header X-Client-Port %[src_port]
>>> 
>>> result is ;(
>>> 
>>>  'HTTP_X_CLIENT_PORT' => '22696',
>>>  'HTTP_X_CLIENT_IP' => '217.73.20.190',
>>>  'HTTP_X_SERVER_PORT' => '22696',
>>>  'HTTP_X_SERVER_IP' => '217.73.20.190’,
>> 
>> With this simple test config dst, dst_port etc. seem to work for me, does
>> this config work for you ?
>> 
>> global
>>  stats socket /tmp/stats level admin
>> 
>> defaults
>>  mode http
>>  log global
>>  option httplog
>> 
>> frontend test
>>  bind :8080
>> 
>>  default_backend test_be
>> 
>> backend test_be
>>http-request set-header X-Server-IP %[dst]
>>http-request set-header X-Server-Port %[dst_port]
>>http-request set-header X-Client-IP %[src]
>>http-request set-header X-Client-Port %[src_port]
>> 
>>  server srv1 127.0.0.1:9000 id 1
>> 
>> listen yeah
>>  bind ipv4@127.0.0.1 :9000
>>  http-request deny deny_status 200
>> 
>> run with for example haproxy -d -f tmp.conf and
>> curl http://127.0.0.1:8080  and you should see the 
>> headers from haproxy debug
>> output.
>> 
>> -Jarno
>> 
>> -- 
>> Jarno Huuskonen
> 

Re: Get http connection client/server ip/port

[Peter Hudec]

Hi Jarno,

thanks for answer.
I tried to run the haproxy in debug mode, but I do not see the request headers 
for the upstream in the log.

But I have found some new facts.

Test these 2 scenarios, at this moment there is no valid certs

http://web01.test.host.sk/test.php 
https://web01.test.host.sk/test.php

look for the
X_SERVER_IP
X_SERVER_PORT
X_CLIENT_IP
X_CLIENT_PORT

See the difference?
For the HTTP, the values are correct, for HTTPS not.

I’m running RH SCL HAPROXY. I could try to compile newer version or are there 
any for CentOS7?

regards
Peter




> On 4 Jul 2019, at 18:42, Jarno Huuskonen  wrote:
> 
> Hi,
> 
> On Thu, Jul 04, Peter Hudec wrote:
>> I have maybe found some bug in haproxy, submitted as 
>> https://github.com/haproxy/haproxy/issues/154 
>> .
> 
> 1.8.4 is fairly old, can you reproduce on more recent 1.8.x or latest 2.0.x ?
> 
>> The variables dst, dst_port are identical with the src, src_port.
>> 
>> Is there any other way how to get these /in this case dst/ values ??
>> 
>> What do I need is ..
>> 
>>http-request set-header X-Server-IP %[dst]
>>http-request set-header X-Server-Port %[dst_port]
>>http-request set-header X-Client-IP %[src]
>>http-request set-header X-Client-Port %[src_port]
>> 
>> result is ;(
>> 
>>  'HTTP_X_CLIENT_PORT' => '22696',
>>  'HTTP_X_CLIENT_IP' => '217.73.20.190',
>>  'HTTP_X_SERVER_PORT' => '22696',
>>  'HTTP_X_SERVER_IP' => '217.73.20.190’,
> 
> With this simple test config dst, dst_port etc. seem to work for me, does
> this config work for you ?
> 
> global
>   stats socket /tmp/stats level admin
> 
> defaults
>   mode http
>   log global
>   option httplog
> 
> frontend test
>   bind :8080
> 
>   default_backend test_be
> 
> backend test_be
>http-request set-header X-Server-IP %[dst]
>http-request set-header X-Server-Port %[dst_port]
>http-request set-header X-Client-IP %[src]
>http-request set-header X-Client-Port %[src_port]
> 
>   server srv1 127.0.0.1:9000 id 1
> 
> listen yeah
>   bind ipv4@127.0.0.1 :9000
>   http-request deny deny_status 200
> 
> run with for example haproxy -d -f tmp.conf and
> curl http://127.0.0.1:8080  and you should see the 
> headers from haproxy debug
> output.
> 
> -Jarno
> 
> -- 
> Jarno Huuskonen

receive side scaling, need help with approach to port ranges

[Richard Russo]

Hi,

I've been experimenting with Recieve Side Scaling (RSS) for a tcp proxy 
application. The basic idea with RSS is by configuring the NICs, kernel, and 
application to use the same CPU for a given socket, cross CPU locking and 
communication is eliminated or at least significantly reduced. On my system, 
configuring RSS allowed me to handle about three times as many sessions before 
reaching CPU saturation, with the remaining bottleneck seeming to be kernel 
processing around socket creation and closing which requires cross cpu 
coordination. 

Aligning the incoming sockets is very simple, setting a socket option 
(IP_RSS_LISTEN_BUCKET) on the listen socket restricts the accepted socket to 
that bucket, and that's straight forward to add to the tcp listener code, and 
configuration.

Aligning outgoing sockets is trickier -- there's no kernel help with a socket 
option or otherwise, an application has to run the hash (toeplitz) on the 
4-tuple of {local ip, local port, remote ip, remote port } and only use an 
outgoing port if the hash matches.  I've had trouble finding a good approach to 
handle this.

The simplest thing would be to run the hash when a port is assigned by 
port_range and return the port if it hashes to the wrong bucket; but if you've 
already used all the acceptable ports for that port range, you spend a lot of 
time hashing the ports that are still in the range, without making any progress.

If you have a port range per rss bucket, you could hash on port assignment, and 
not return the ports in case they hash to a wrong bucket; but in the case that 
the remote ip changes because you've configured it to use DNS or if you change 
the IP via "set server addr", the previously computed hashes are no longer 
valid -- you would really want to try all the ports again.

What I ended up with was a lock on port ranges (instead of atomics as used in 
07425de71777b688e77a9c70a7088c13e66e41e9 BUG/MEDIUM: port_range: Make the ring 
buffer lock-free), adding a revision counter to the port range, and resetting 
the port range whenever the server IP changed. To avoid running the hash during 
steady state, and because checking all the ports when the range needs to be 
filled, I also made port range filing incremental. 

This approach works, but it feels complicated, and it made my config much more 
verbose --- I had to duplicate my frontend sections, one for each RSS bucket, 
which sends to corresponding duplicated backends for each bucket; the backends 
had additional configuration to indicate the RSS bucket (and the number of 
buckets). Incidentally, because each RSS bucket has a distinct set of ports, 
and because my use case doesn't use any features which benefit from 
coordination within HAProxy (such as stick tables etc), this makes it possible 
to run in process mode rather than threaded mode without running into a lot of 
port already in use warnings/errors that would happen otherwise when sharing a 
port range.

If it's helpful for the discussion, I can share my patches as-is, but if there 
are better ideas on how to structure this, I'd rather try to get the changes 
done in a nice way before sharing.

Thanks!

-- 
  Richard Russo
  to...@enslaves.us

Re: [RFC PATCH] BUG/MINOR: ssl: revert empty handshake detection in OpenSSL <= 1.0.2

[Emmanuel Hocdet]

> Le 4 juil. 2019 à 18:55, Илья Шипицин  a écrit :
> 
> can you provide some comment around code ?
> 
> I think almost nobody can read such code
> 
> чт, 4 июл. 2019 г. в 21:17, Emmanuel Hocdet  >:
> Hi,
> 
> This thread reminds me that with BoringSSL empty (and abort) handshake is not 
> set.
> After tests BoringSSL seems to have simpler case.
> I sent a patch to fix that.
> 
> For OpenSSL <= 1.0.2, revert is the thing to do.
> For LibreSSL, include it with BoringSSL case could be ok (with my patch).
> With time (no HB and better error report in libSSL), it seems code could 
> simply look like:
>   if (!errno)
>   conn->err_code = CO_ER_SSL_EMPTY;
>   else
>   conn->err_code = CO_ER_SSL_ABORT;
> 

Only CO_ER_SSL_EMPTY and CO_ER_SSL_ABORT  can be set for conn->err_code
(it’s the case for BoringSSL)


> ++
> Manu
> 
>> Le 4 juil. 2019 à 12:14, Lukas Tribus mailto:lu...@ltri.eu>> 
>> a écrit :
>> 
>> Hello Ilya,
>> 
>> 
>> On Mon, 1 Jul 2019 at 23:08, Илья Шипицин > > wrote:
>>> 
>>> 
>>> 
>>> вт, 2 июл. 2019 г. в 01:34, Willy Tarreau >> >:
 
 On Mon, Jul 01, 2019 at 10:32:29PM +0200, Lukas Tribus wrote:
> Commit 54832b97 ("BUILD: enable several LibreSSL hacks, including")
> changed empty handshake detection in OpenSSL <= 1.0.2 and LibreSSL,
> from accessing packet_length directly (not available in LibreSSL) to
> calling SSL_state() instead.
 (...)
 
 Thanks a lot Lukas. Just out of curiosity, do you have any idea of a
 concrete user-visible issue this bug can cause ? It would help bisecting
 issues later. I don't know in what case an empty handshake may happen.
>>> 
>>> 
>>> nmap scan ?
>> 
>> Ilya, just to avoid misunderstandings, I would like to have your
>> feedback on this patch so we can decide whether to commit it or work
>> on counter-proposals.
>> 
>> 
>> Thanks,
>> Lukas
> 

Re: [PATCH] DOC: contrib: spoa_server Add some hints for building, spoa_server

[Christopher Faulet]

Le 03/07/2019 à 10:24, Aleksandar Lazic a écrit :

Hi.

I have added some hints into the spoa_server.
Thanks Thierry for the nice server ;-)



Thanks, merged now.

--
Christopher Faulet

Re: Help with 1.8.1/4 and spoa_server/spoa_example

[Christopher Faulet]

Le 03/07/2019 à 16:16, Aleksandar Lazic a écrit :

I know this is a old haproxy version but I have not the option to update as it's
part of a vendor product.

I need to bring the `[haproxy-2.0.git]/ contrib/spoa_server/` up and runnig or
`[haproxy-1.8.git]/contrib/spoa_example/` from 1.8.4 to be able to run a python
script.

Any help is welcome and I can offer some money for the help. It's urgent so I
will need the help asap.

You can contact me also off the list.



Hi Aleks,

The spoa_example cannot run python script. But I take a look to the spoa_server 
and it seems to usable with HAProxy 1.8 with a small patch. You must downgrade 
the SPOE version and change the encoding of the frame's flags. The example 
configuration must also be adapted because there is no debug converter in 
HAProxy 1.8.


But, as you said, HAProxy 1.8.4 is old, and many fixes was pushed on the SPOE 
since then. So you would experience some bugs. Be careful.


And I noticed a bug with the spoe_server, It seems to accept and process only 
one connection per worker because of a while loop to read frames. I'm cc'ing 
Thierry.


I attached a quick-and-dirty patch to downgrade SPOP version of the spoa_server 
to 1.0.



--
Christopher Faulet
>From 955c47ce6e8bf8a1ed644ffd353b52b54516c2fa Mon Sep 17 00:00:00 2001
From: Christopher Faulet 
Date: Fri, 5 Jul 2019 16:25:34 +0200
Subject: [PATCH] WIP: spoa_server: Downgrade SPOP version to 1.0

---
 contrib/spoa_server/spoa.c | 6 +++---
 contrib/spoa_server/spoa.h | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/contrib/spoa_server/spoa.c b/contrib/spoa_server/spoa.c
index f36c3db90..933eb79c8 100644
--- a/contrib/spoa_server/spoa.c
+++ b/contrib/spoa_server/spoa.c
@@ -687,7 +687,7 @@ static void prepare_agentack(struct worker *w)
 	w->ack[w->ack_len++] = SPOE_FRM_T_AGENT_ACK;
 
 	/* Set flags */
-	flags |= htonl(SPOE_FRM_FL_FIN);
+	flags |= SPOE_FRM_FL_FIN;
 	memcpy(w->ack + w->ack_len, , 4);
 	w->ack_len += 4;
 
@@ -949,7 +949,7 @@ prepare_agenthello(struct worker *w)
 	w->buf[idx++] = SPOE_FRM_T_AGENT_HELLO;
 
 	/* Set flags */
-	flags |= htonl(SPOE_FRM_FL_FIN);
+	flags |= SPOE_FRM_FL_FIN;
 	memcpy(w->buf+idx, , 4);
 	idx += 4;
 
@@ -994,7 +994,7 @@ prepare_agentdicon(struct worker *w)
 	w->buf[idx++] = SPOE_FRM_T_AGENT_DISCON;
 
 	/* Set flags */
-	flags |= htonl(SPOE_FRM_FL_FIN);
+	flags |= SPOE_FRM_FL_FIN;
 	memcpy(w->buf+idx, , 4);
 	idx += 4;
 
diff --git a/contrib/spoa_server/spoa.h b/contrib/spoa_server/spoa.h
index 8f912e435..0166c48c4 100644
--- a/contrib/spoa_server/spoa.h
+++ b/contrib/spoa_server/spoa.h
@@ -18,7 +18,7 @@
 #include 
 
 #define MAX_FRAME_SIZE16384
-#define SPOP_VERSION  "2.0"
+#define SPOP_VERSION  "1.0"
 #define SPOA_CAPABILITIES ""
 
 /* Flags set on the SPOE frame */
-- 
2.20.1

Re: Debugging protobuf and HTX

[Christopher Faulet]

Le 03/07/2019 à 13:28, GARDAIS Ionel a écrit :

Hi list,

We ran into an issue with haproxy 2.0.1 in front of SonarQube.
With HTX enabled, despite no errors being displayed either in haproxy nor 
SonarQube, some but not all analysis failed.


 From SonarQube, debug shows protobuf requests 
(/sonarqube/api/rules/list.protobuf) failing and fallbacking to default, or 
complete failure if no default available.


When switching back to 'no option http-use-htx', protobuf requests' answers did 
not had the same size and no more issues with SonarQube.


How could I specifically debug protobuf handling with HTX enabled ?



Hi,

I don't know if it is related. But if your tool uses WebSockets, take a look to 
the issue #131 on Github:


  https://github.com/haproxy/haproxy/issues/131

Otherwise, I'll need more information (configuration, info about SonarQube, 
network captures...).


--
Christopher Faulet

Re: question about spoe doc

[Christopher Faulet]

Le 03/07/2019 à 11:03, Aleksandar Lazic a écrit :

Hi.

in the spoe doc in section **2.5. Example** are the following lines.

```
  620 spoe-message get-ip-reputation
  621 args ip=src
  622 event on-client-session if ! { src -f /etc/haproxy/whitelist.lst }
```

As far as I understood the doc in line `496 args [name=] ...` right
could be the check also against `ip` not only `src`?

git links:

http://git.haproxy.org/?p=haproxy-1.8.git;a=blob;f=doc/SPOE.txt;h=9602df95dacc3aa5f6fa9154c0cf3f2a3f4ed092;hb=HEAD

http://git.haproxy.org/?p=haproxy.git;a=blob;f=doc/SPOE.txt;h=19f00ad98d51f155494b47e680f14d6973dd91bb;hb=HEAD



Sorry, I don't understand the question. "src" is a sample fetch. "ip" is just a 
label. It may be use by the agent to match arguments. It could be a way to pass 
arguments in any order and rely on their names instead of their positions.


Hope it helps :)

--
Christopher Faulet

Re: issue with small object caching

[Christopher Faulet]

Le 04/07/2019 à 16:54, Senthil Naidu a écrit :

Hi,

I there any fix that can be applied for small object caching to work with 
Firefox and chrome too, With Internet Explorer I am able to hit the cache 
properly.

As mentioned in my earlier  , I can see that firefox is sending  header 
Cache-Control: no-cache and  Pragma: no-cache , While IE is not sending this 
headers



Hi,

So you must find a way to enable the cache on Firefox and Chrome. I don't know 
how to to so, but you may take a look to the developer tools of each browser. 
May be the cache is explicitly disabled.


On HAProxy side, you can remove the header "Cache-Control" before using the 
cache. But, IMHO, it is a really bad idea. If the client set this header, it is 
on purpose (or it should be).


--
Christopher Faulet

Re: Get http connection client/server ip/port

[Christopher Faulet]

Le 04/07/2019 à 15:16, Peter Hudec a écrit :

Hi,

I have maybe found some bug in haproxy, submitted as 
https://github.com/haproxy/haproxy/issues/154.

The variables dst, dst_port are identical with the src, src_port.

Is there any other way how to get these /in this case dst/ values ??

What do I need is ..

 http-request set-header X-Server-IP %[dst]
 http-request set-header X-Server-Port %[dst_port]
 http-request set-header X-Client-IP %[src]
 http-request set-header X-Client-Port %[src_port]

result is ;(

   'HTTP_X_CLIENT_PORT' => '22696',
   'HTTP_X_CLIENT_IP' => '217.73.20.190',
   'HTTP_X_SERVER_PORT' => '22696',
   'HTTP_X_SERVER_IP' => '217.73.20.190’,



Hi,

For the record, I closed the issue on Github. I guess it is a problem with the 
server. I've made some tests, and the HTTP request's headers are set to the 
right values.


Regards,
--
Christopher Faulet

[PATCH] DOC: Fix typo in intro.txt

[Alain Belkadi]

Hello,

You will find as attachement my first ultra-small contribution to the 
documentation, a fix for a typo.


Regards,

--
[Alain Belkadi / LinuxBeach]From ba4a3f9674d31622a002a12a97b7ae6fdeb080b7 Mon Sep 17 00:00:00 2001
From: Alain Belkadi 
Date: Fri, 5 Jul 2019 10:12:40 +0200
Subject: [PATCH] DOC: Fix typo in intro.txt

---
 doc/intro.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/intro.txt b/doc/intro.txt
index 0ee9fa2d..4eaf18ef 100644
--- a/doc/intro.txt
+++ b/doc/intro.txt
@@ -1071,7 +1071,7 @@ components.
 
 HAProxy provides very detailed logs, with millisecond accuracy and the exact
 connection accept time that can be searched in firewalls logs (e.g. for NAT
-correlation). By default, TCP and HTTP logs are quite detailed an contain
+correlation). By default, TCP and HTTP logs are quite detailed and contain
 everything needed for troubleshooting, such as source IP address and port,
 frontend, backend, server, timers (request receipt duration, queue duration,
 connection setup time, response headers time, data transfer time), global
-- 
2.11.0