CODEWITHSUNDEEP
dockerhttpshaproxykeepalived
Gianluca Tresoldi
Gianluca Tresoldi

Reputation: 1

HAProxy HTTPS timeout with Chrome, works after curl/wget request

I’m experiencing a strange issue with HAProxy running as a Docker container. HAProxy exposes services on a public IP, which is a floating VIP managed by Keepalived between two nodes.

The problem occurs only with HTTPS. When I try to open a page in Chrome, the connection times out, even after refreshing or the browser’s automatic retries. However, if I perform an HTTPS request using curl or wget, subsequent requests from Chrome start working temporarily before the issue reoccurs.

Inspecting the traffic with tcpdump reveals that connections appear to have incorrect TCP sequence numbers after the 3-way handshake:

client->server seq=0,len=0 [SYN]
server->client seq=0,len=0 [SYN,ACK]
client->server seq=1,ack=1,len=0 [ACK]
client->server seq=1441,ack=1,len=327 [PSH,ACK]

On the other hand, requests made with curl or wget seem to work fine:

client->server seq=0,len=0 [SYN]
server->client seq=0,len=0 [SYN,ACK]
client->server seq=1,ack=1,len=0 [ACK]
client->server seq=1,ack=1,len=388 [PSH,ACK] (TLS client Hello)

After making a request with curl, subsequent requests from Chrome start working again, which is driving me crazy. :)

Here’s my haproxy.cfg:

global
    maxconn 50000

defaults
    timeout client 30s
    timeout server 30s
    timeout connect 5s

frontend www
    bind :80
    bind :443 ssl crt-list /usr/local/etc/haproxy/crt-list.txt

    acl invalid_host hdr(host) -m found
    acl allowed_hosts hdr(host) -i creator.dev.mydomain.com www.dev.mydomain.com
    http-request deny if invalid_host !allowed_hosts

    redirect scheme https if !{ ssl_fc }
    http-response set-header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

    default_backend swarm_cluster

backend swarm_cluster
    mode http
    balance roundrobin
    cookie SERVERID insert indirect nocache
    server worker1 192.168.24.101:443 ssl verify none check send-proxy
    server worker2 192.168.24.102:443 ssl verify none check send-proxy
    server worker3 192.168.24.103:443 ssl verify none check send-proxy

Does anyone have any idea what could be causing this behavior? Thansk a lot!

I tried the following steps:

Checked backend server.

Analyzed traffic with tcpdump

Tested with different tools: Requests made with curl and wget worked fine, and interestingly, they temporarily "fixed" the issue for Chrome requests.

Upvotes: -1

Views: 11

Answers (0)

Related Questions