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 <[email protected]> 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 <[email protected]
>> <mailto:[email protected]>> 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 <[email protected]
>>> <mailto:[email protected]>> 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 <[email protected]
>>>> <mailto:[email protected]>> 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
>>>
>>
>
