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 <pe...@home.hudecof.net> wrote: > > it works on localhost, but not on public ip > > curl -k -v https://2.57.64.11 <https://2.57.64.11/> > curl -k -v http://2.57.64.11 <http://2.57.64.11/> > > or try IPv6 2a09:d4c0::11 > > Peter > >> On 5 Jul 2019, at 23:02, Peter Hudec <pe...@home.hudecof.net >> <mailto:pe...@home.hudecof.net>> 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 >> user haproxy >> 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/ >> <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 >> mode http >> log global >> option httplog >> option dontlognull >> option http-server-close >> option forwardfor except 127.0.0.0/8 >> option redispatch >> retries 3 >> timeout http-request 10s >> 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 <pe...@home.hudecof.net >>> <mailto:pe...@home.hudecof.net>> 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 <cfau...@haproxy.com >>>> <mailto:cfau...@haproxy.com>> 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 <http://web01.test.host.sk/test.php> >>>>> https://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 >>> >> >