@senattcs wrote:

Hello… one of my clients sends requests with following path:
GET /xxx/YYYY/SUBSCRIBER/ZZZ/query?appid=pqrst&PHONE=123456789 HTTP/1.1
and when I’m sending to backend it should go as:
GET /xxx/yyyy/subscriber/zzz/query/?appid=pqrst&PHONE=123456789 HTTP/1.1

notice- everything is converted to lower case and added “/” after query.
To achieve this: I added following in backend section:
http-request set-path %[path,lower]/

when I did that- I see that around 2 secs is sent in client request transfer, here is the log statement:

2019-03-23T18:17:49-07:00 haproxy[12250] :4226 [23/Mar/2019:18:17:47.088] http_frontend Login.QueryCustomer/s_Login.QueryCustomer 2245/0/0/391/2636 200 5190 - - ---- 8/8/1/1/0 0/0 {} “GET /xxx/yyyy/subscriber/zzz/query/?appid=pqrst&PHONE=123456789 HTTP/1.1”

Any reason why “TR” is 2245?

Posts: 1

Participants: 1

Read full topic

@crisrodrigues wrote:

Hi,

We’ve been using haproxy-1.8.18 happily since it was released.

It sits in front our app server and gets requested to route them to our backend farm depending on the desired app service.

We use:

• nbproc 5;
• 1 unix frontend attached to each process;
• communicate with a few hundred (~300) backends. We use server-templates for a few cases with DNS resolution and IP addresses (IPv4 and IPv6) for the rest.

All frontends are non-encrypted HTTP/1.1 and backends vary between TLS are HTTP.

This is the very same (boring but long) config file we’ve always used.

And this weekend a few haproxy processes started dying. “show errors” don’t show anything (and can’t be used after the process dies), so not a clue besides this dmesg messages:

[12313007.354629] haproxy[1010574]: segfault at 58 ip 000000000048de73 sp 00007ffd7e218950 error 4 in haproxy[400000+146000]
[12313007.355575] Code: 44 24 18 48 8b 00 48 85 c0 74 1f 89 4c 24 28 48 89 54 24 20 4c 89 e7 4c 89 04 24 ff d0 8b 4c 24 28 48 8b 54 24 20 4c 8b 04 24 <48> 8b 42 58 48 85 c0 0f 84 4c 08 00 00 4d 85 c0 74 0d 41 83 78 10 
[12316538.140456] haproxy[1013602]: segfault at 58 ip 000000000048de73 sp 00007ffe09fbe5e0 error 4 in haproxy[400000+146000]
[12316538.141250] Code: 44 24 18 48 8b 00 48 85 c0 74 1f 89 4c 24 28 48 89 54 24 20 4c 89 e7 4c 89 04 24 ff d0 8b 4c 24 28 48 8b 54 24 20 4c 8b 04 24 <48> 8b 42 58 48 85 c0 0f 84 4c 08 00 00 4d 85 c0 74 0d 41 83 78 10 
[12424725.217771] haproxy[1112079]: segfault at 58 ip 000000000048de73 sp 00007fff1d1e87c0 error 4 in haproxy[400000+146000]
[12424725.218582] Code: 44 24 18 48 8b 00 48 85 c0 74 1f 89 4c 24 28 48 89 54 24 20 4c 89 e7 4c 89 04 24 ff d0 8b 4c 24 28 48 8b 54 24 20 4c 8b 04 24 <48> 8b 42 58 48 85 c0 0f 84 4c 08 00 00 4d 85 c0 74 0d 41 83 78 10 
[12444059.954893] haproxy[1112083]: segfault at 58 ip 000000000048de73 sp 00007fff1d1e87c0 error 4 in haproxy[400000+146000]
[12444059.955708] Code: 44 24 18 48 8b 00 48 85 c0 74 1f 89 4c 24 28 48 89 54 24 20 4c 89 e7 4c 89 04 24 ff d0 8b 4c 24 28 48 8b 54 24 20 4c 8b 04 24 <48> 8b 42 58 48 85 c0 0f 84 4c 08 00 00 4d 85 c0 74 0d 41 83 78 10 
[12473582.800870] haproxy[1162962]: segfault at 58 ip 000000000048de73 sp 00007fff3d196f00 error 4 in haproxy[400000+146000]
[12473582.801908] Code: 44 24 18 48 8b 00 48 85 c0 74 1f 89 4c 24 28 48 89 54 24 20 4c 89 e7 4c 89 04 24 ff d0 8b 4c 24 28 48 8b 54 24 20 4c 8b 04 24 <48> 8b 42 58 48 85 c0 0f 84 4c 08 00 00 4d 85 c0 74 0d 41 83 78 10 
[12489985.349159] haproxy[1162959]: segfault at 58 ip 000000000048de73 sp 00007fff3d196f00 error 4 in haproxy[400000+146000]
[12489985.350112] Code: 44 24 18 48 8b 00 48 85 c0 74 1f 89 4c 24 28 48 89 54 24 20 4c 89 e7 4c 89 04 24 ff d0 8b 4c 24 28 48 8b 54 24 20 4c 8b 04 24 <48> 8b 42 58 48 85 c0 0f 84 4c 08 00 00 4d 85 c0 74 0d 41 83 78 10 

I’m not sure what info I can provide since this is live traffic, but obviously I’ll try and get as much as possible. I since updated to 1.8.19 with the latest patches on top of it (as of March 23rd git tree) but can’t spot a single problem there that’s related. And segfault is…weird!

Anyway, the usual part of our config is:

global
    nbproc 5
    maxconn 900000
    ulimit-n 2701398
    user haproxy
    group haproxy
    daemon
    ssl-engine rdrand
    ssl-mode-async
    tune.ssl.default-dh-param 2048
    tune.ssl.maxrecord 1419
    unix-bind user haproxy mode 777
    hard-stop-after 1m
    tune.idletimer 1000
    tune.bufsize 131072

resolvers dnsserver
  nameserver cloudflare 1.1.1.1:53
  resolve_retries       3
  hold valid 3s
  hold timeout 1s
  hold refused 1s
  accepted_payload_size 1024

defaults
    mode    http
    retries 1
    maxconn 900000
    timeout connect 10s
    timeout server 100s
    timeout server-fin 3s
    timeout check 10s
    timeout client 100s
    timeout client-fin 3s
    timeout http-request 3s
    timeout http-keep-alive 5s
    timeout tunnel 300s
    option http-no-delay
    default-server init-addr none
    option accept-invalid-http-response
    option tcp-check

frontend front
    bind-process 1-5 

    bind /var/run/backend1.sock process 1
    bind /var/run/backend2.sock process 2
    bind /var/run/backend3.sock process 3
    bind /var/run/backend4.sock process 4
    bind /var/run/backend5.sock process 5

For backend selection, we use a few tricks:

• All servers in each backend use a tcp-check (L4) to see if the desired port is available;
• We store in HTTP headers 2 possible backends: A first (better) and a second (slower, but possible) backend name;
• We use a var (set-var with req context) to retrieve the desired backend name from a HTTP header;
• We set a ACL to check how many servers are alive in the first (better) backend, such as:

    acl avail var(req.back_first),nbsrv ge 1

• We use the backends as:

    use_backend %[var(req.back_first)] if avail
    use_backend %[var(req.back_second)]

Any info you need to help figure this out would be greatly appreciated

Posts: 1

Participants: 1

Read full topic

@olivia wrote:

I have following HAProxy configuration on 1.8.14

http-request set-var(txn.a) hdr(Origin)
acl x var(txn.a),lower,map(/etc/haproxy/test.map,'false') -m found
http-response    add-header  B  %[var(txn.a)]   if x

I expected the behavior to be that if a request’s Origin header content is present in test.map file, the response will have a new header B with that content. However I’m getting header B set with Origin’s content despite if the content is in test.map or not. What did I do wrong? Thanks for the help in advance.

Posts: 3

Participants: 2

Read full topic

@shlomi wrote:

Hi, Recently I installed HAProxy as a reverse proxy only.
When I use it internally inside my LAN, everything works perfect.
When I use it externally, I get 408 BADREQ.
I made 2 simple firewall rules:
Policy:
Source: Any - Destination: HAProxy_External_IP & Internal IP - Service: Any - Accept
NAT:
Destination: HAProxy_External_IP - Destination Port: Any - Destination IP: HAProxy_Internal_IP - Service port: Original

When I browse to my URL, I get this error in haproxy.log:

Mar 26 01:29:42 localhost haproxy[13266]: 212.xxxxx0:56170 [26/Mar/2019:01:28:52.760] http-in http-in/ -1/-1/-1/-1/50001 408 213 - - cR-- 0/0/0/0/0 0/0 “”
Mar 26 01:29:42 localhost haproxy[13266]: 212.xxxxx0:56170 [26/Mar/2019:01:28:52.760] http-in http-in/ -1/-1/-1/-1/50001 408 213 - - cR-- 0/0/0/0/0 0/0 “”

My HaProxy Config:

global
log 127.0.0.1:514 local0 info
log 127.0.0.1:514 local1 notice
tune.maxrewrite 16384
tune.bufsize 32768
chroot /var/lib/haproxy
stats socket /run/haproxy/admin.sock mode 660 level admin
stats timeout 30s
user haproxy
group haproxy
daemon

defaults
log global
mode http
option forwardfor
option http-server-close
option httplog

option dontlognull

    timeout connect 5000
    timeout client  50000
    timeout server  50000
    errorfile 400 /etc/haproxy/errors/400.http
    errorfile 403 /etc/haproxy/errors/403.http
    errorfile 408 /etc/haproxy/errors/408.http
    errorfile 500 /etc/haproxy/errors/500.http
    errorfile 502 /etc/haproxy/errors/502.http
    errorfile 503 /etc/haproxy/errors/503.http
    errorfile 504 /etc/haproxy/errors/504.http

frontend http-in
log 127.0.0.1:514 local0 debug
bind *:80

    # Define hosts
    acl host_1 hdr(host) -i test.prv.com
    acl host_2 hdr(host) -i test.prv.com

    ## figure out which one to use
    use_backend back1 if host_1
    use_backend back2 if host_2

backend back1
log 127.0.0.1:514 local0 debug
balance leastconn
option httpclose
option forwardfor
cookie JSESSIONID prefix
server node1 192.168.30.103:80 cookie A check

backend back2
log 127.0.0.1:514 local0 debug
server node1 google.com:80

Posts: 1

Participants: 1

Read full topic

@user5396668 wrote:

Hi,

Is it possible to make haproxy be a proxy between a client that communicates over tcp with MD5 signature option (RFC 2385) and a server without MD5 option?
(Which means that haproxy will be the endpoint of the TCP MD5 session).

Thanks!

Posts: 1

Participants: 1

Read full topic

@senattcs wrote:

How does “TR” gets calculated in case of keep-alive connection? is there anything special calculation…

Posts: 1

Participants: 1

Read full topic

@kotarusv wrote:

Hi

is it possible to disable stats logging in 1.8.19 ? We used listen directive to configure stats page

Srinivas Kotaru

Posts: 1

Participants: 1

Read full topic

@Thoufiq wrote:

We have installed HAProxy on ubuntu . Where should i run ‘Show’ commands of HAProxy? how can i get into HAProxy configuration management in ubunt?Please help…

Posts: 1

Participants: 1

Read full topic

@shamsimam wrote:

I would appreciate some help getting my HA-Proxy instance set up to accept h2 or http/1.1 traffic and perform SSL termination using the http mode. I have tried the following setup:

frontend local_fe
    mode http
    option http-use-htx
    bind *:8080 proto h2
    default_backend local_be

backend local_be
    mode http
    option http-use-htx
    server localhost localhost:9090 proto h2

However, using proto h2 still sends over the packets using https (as reported by my backend written in Jetty). Any suggestions to what I should change in my config?

Posts: 1

Participants: 1

Read full topic

@typoworx wrote:

Hello,
I’m trying to figure out how to use HA-Proxy behind Cloudflare using SRV-Record (Minecraft-Server) and HA-Proxy to forward the IP/Port given by SRV-Record hint to internal IP (VM System). This is the first time I try to figure out how SRV-Record/Resolver works.

Does a resolver make sense in HA-Proxy using “server-template” to make HA-Proxy try to resolve the IP/Port configuration in this case (mode TCP) or is this useful for HTTP(s) Balancing only?

Will the SRV record need to point to HA-Proxy IP (given by Target & Port) or to the internal IP-Adress that HA-Proxy should resolve to internally to forward it into the private VM-Network? If so, will the native A-Record point to HA-Proxy then?

Example:
_minecraft.node01.foobar.com <-- SRV Record pointing to target 172.16.2.100, port 25565
node01.foobar.com <-- HA-Proxy IP

or will I have to create a normal frontend for each VM-Node and TCP-Port the usual way to forward each port to internal VM-IP/Port and use SRV only as hint for the TCP-Port to be used by Minecraft Game-Clients?

Posts: 1

Participants: 1

Read full topic

@acruma wrote:

Error : haproxy.service: Failed with result ‘exit-code’.

My config :

Global and Defaults ( are for defect )

#Configurando frontend HTTP
frontend Accesos_HTTP
bind *:80
mode http
option httpclose
option http-server-close
option forwardfor
# Protección DDOS
stick-table type ip size 100k expire 30s store conn_rate(3s)
# Cortar la conexión si el cliente hace más de 10 peticiones
tcp-request connection reject if { src_conn_rate ge 10 }
tcp-request connection track-sc1 src
http-request set-header X-Forwarded-Port %[dst_port]
http-request add-header X-Forwarded-Proto https if { ssl_fc }
option httplog
# Reparto de tráfico estático directamente hacia los servidores web.
use_backend nodes80 { path_end .jpg .png .gif .css .js }
default_backend nodes80

#Configurando frontend HTTPS
frontend Accesos_HTTPS
bind *:443
mode tcp
default_backend nodes443

#Configurando ip de web Servidor Apache/Varnish para HTTP
backend nodes80
mode http
balance roundrobin
server web01 192.168.33.101:80 check

#Configurando ip de web Servidor Apache/Varnish para HTTPS
backend nodes443
mode tcp
balance roundrobin
stick-table type ip size 200k expire 30m
stick on src
server web01 192.168.33.101:443 check

#Acceso a la interfaz de estadisticas
listen stats :4443
mode http
stats enable
stats hide-version
stats uri /
stats refresh 5s
stats auth user:pass

Posts: 1

Participants: 1

Read full topic

@ooglykraken wrote:

I’m trying to setup mutual tls for an haproxy instance and have ssl termination but I don’t think its actually setup properly to do so.

This is my front end

   log 127.0.0.1 local0 info

   bind localhost:443 ssl crt /etc/ssl/private/server.pem ca-file /etc/ssl/private/ca.crt verify optional

   reqadd X-Forwarded-Proto:\ https

   acl PATH-tls-test path_beg /test

   use_backend SERVER-tls-test if PATH-tls-test

   default_backend no-server

Posts: 2

Participants: 2

Read full topic

@moscardo wrote:

Hi,
I am using HTTP mode (ssl traffic) with option forwardfor in the frontend and backend, but I don’t get the header in the backend servers. Is there anything I am missing?

frontend www_embl_ssl
  bind 10.11.6.41:443 ssl crt /etc/haproxy/embl.pem
  mode http
  default_backend www_embl_ssl_back
  description www.embl.de SSL version
  log global
  maxconn 8000
  monitor-uri /monitoruri
  option forwardfor
  option httplog
  option dontlognull
  timeout client 30s
  use_backend dm_ssl_back if { hdr(host) -i dm.domain.com }

backend dm_ssl_back
  mode http
  timeout connect 5s
  timeout server 31s
  option forwardfor
  server a1 10.12.33.226:443 check inter 5s fall 4 rise 3 ssl verify none

I tried also to log all headers but I was just receiving {} in the logs.

Thanks.

Posts: 1

Participants: 1

Read full topic

@rockandska wrote:

Hi,

Similar to #2134

Despite it is the same error and the same fix, i don’t use resolvers in my conf

# haproxy -v
HA-Proxy version 1.7.5-2 2017/05/17

backend bk_redis
  mode tcp
  option tcp-check
  #tcp-check connect     --> comment it solved the problem
  tcp-check send PING\r\n
  tcp-check expect string +PONG
  tcp-check send info\ replication\r\n
  tcp-check expect string role:master
  tcp-check send QUIT\r\n
  tcp-check expect string +OK
  server redis-1-debian-9 redis-1-debian-9:6379 check inter 1s
  server redis-2-debian-9 redis-2-debian-9:6379 check inter 1s
  server redis-3-debian-9 redis-3-debian-9:6379 check inter 1s

But when i read the doc, it clearly state that tcp-check connect is required

In a tcp-check ruleset a 'connect' is required, it is also mandatory to start
the ruleset with a 'connect' rule. Purpose is to ensure admin know what they
do.

• Why tcp-check connect fail ? bug ?
• Despite what the doc says, is it ok to remove tcp-check connect ? what is the implication of this choice ?
• Since we don’t have the problem with the exact same conf with v1.5.18 (centos7 ), could we remove it on this version too to have the same config on 1.5.18 and 1.7.5 ?

Regards,

Posts: 1

Participants: 1

Read full topic

@talion wrote:

Hello all,

I am stress testing my HAProxy setup and i noticed that my backend IP is exposed! When i make same test to my nginx proxy the IP addresses is not shown to my stress tool. Is it by design or its my configuration mistake ?

I am proxying my another nginx installation with HAProxy.

---

echo “GET http://Frontend IP:8088/app_api.php” | vegeta -cpus=4 attack -connections=1000000 -timeout=2m -rate=30000 -workers=50 | tee results.bin | vegeta report
^CRequests [total, rate] 14470, 3902.70
Duration [total, attack, wait] 4.036639963s, 3.707685559s, 328.954404ms
Latencies [mean, 50, 95, 99, max] 20.845444ms, 0s, 0s, 272.588244ms, 4.021258059s
Bytes In [total, mean] 15390, 1.06
Bytes Out [total, mean] 0, 0.00
Success [ratio] 0.00%
Status Codes [code:count] 0:14350 404:30 429:90
Error Set:
Get http://Frontend IP:8088/app_api.php: dial tcp: lookup p1.dtv.sx on 127.0.0.53:53: no such host
Get http://Frontend IP:8088/app_api.php: dial tcp: lookup p1.dtv.sx on 127.0.0.53:53: dial udp 127.0.0.53:53: socket: too many open files
404 Not Found
429 Too Many Requests
Get http://Frontend IP:8088/app_api.php: dial tcp 0.0.0.0:0->Backend IP:8088:8000: socket: too many open files
Get http://Frontend IP:8088/app_api.php: dial tcp 0.0.0.0:0->Backend IP:8088:8000: connect: connection refused

---

HAProxy Configuration;

global
nbproc 1
nbthread 4
cpu-map auto:1/1-4 0-3
log /dev/log local0
log /dev/log local1 notice
chroot /var/lib/haproxy
stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
stats timeout 30s
user haproxy
group haproxy
daemon
maxconn 1000000

    # Default SSL material locations
    ca-base /etc/ssl/certs
    crt-base /etc/ssl/private

    # Default ciphers to use on SSL-enabled listening sockets.
    # For more information, see ciphers(1SSL). This list is from:
    #  https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/
    # An alternative list with additional directives can be obtained from
    #  https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=haproxy
    ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS
    ssl-default-bind-options no-sslv3

defaults
log global
mode http
option httplog
option dontlognull
retries 3
#option forwardfor
option http-server-close
option redispatch
option http-buffer-request
timeout http-request 10s
timeout queue 1m
timeout connect 10s
timeout client 1m
timeout server 1m
timeout http-keep-alive 10s
timeout check 10s
errorfile 400 /etc/haproxy/errors/400.http
errorfile 403 /etc/haproxy/errors/403.http
errorfile 408 /etc/haproxy/errors/408.http
errorfile 500 /etc/haproxy/errors/500.http
errorfile 502 /etc/haproxy/errors/502.http
errorfile 503 /etc/haproxy/errors/503.http
errorfile 504 /etc/haproxy/errors/504.http
maxconn 300000

backend per_ip_rates
stick-table type ip size 1m expire 10m store http_req_rate(10s)

frontend fe1
bind :8088
mode http
http-request track-sc0 src table per_ip_rates
http-request deny deny_status 429 if { sc_http_req_rate(0) gt 100 }
reqidel ^X-Forwarded-For:.*
default_backend backend_servers

backend backend_servers
mode http
balance roundrobin
option httpchk
server domain1 backendIP check port 80

listen stats
bind :19090
stats enable
stats hide-version
stats refresh 10s
stats show-legends
stats realm HAProxy\ Statistics
stats show-node
stats auth
stats uri /

HAProxy -vv ;

HA-Proxy version 1.9.6-1ppa1~bionic 2019/03/30 - https://haproxy.org/
Build options :
TARGET = linux2628
CPU = generic
CC = gcc
CFLAGS = -O2 -g -O2 -fdebug-prefix-map=/build/haproxy-YXfmbO/haproxy-1.9.6=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv -Wno-format-truncation -Wno-unused-label -Wno-sign-compare -Wno-unused-parameter -Wno-old-style-declaration -Wno-ignored-qualifiers -Wno-clobbered -Wno-missing-field-initializers -Wno-implicit-fallthrough -Wno-stringop-overflow -Wtype-limits -Wshift-negative-value -Wshift-overflow=2 -Wduplicated-cond -Wnull-dereference
OPTIONS = USE_GETADDRINFO=1 USE_ZLIB=1 USE_REGPARM=1 USE_OPENSSL=1 USE_LUA=1 USE_SYSTEMD=1 USE_PCRE2=1 USE_PCRE2_JIT=1 USE_NS=1

Default settings :
maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Built with OpenSSL version : OpenSSL 1.1.0g 2 Nov 2017
Running on OpenSSL version : OpenSSL 1.1.0g 2 Nov 2017
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2
Built with Lua version : Lua 5.3.3
Built with network namespace support.
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT IP_FREEBIND
Built with zlib version : 1.2.11
Running on zlib version : 1.2.11
Compression algorithms supported : identity(“identity”), deflate(“deflate”), raw-deflate(“deflate”), gzip(“gzip”)
Built with PCRE2 version : 10.31 2018-02-12
PCRE2 library supports JIT : yes
Encrypted password support via crypt(3): yes
Built with multi-threading support.

Available polling systems :
epoll : pref=300, test result OK
poll : pref=200, test result OK
select : pref=150, test result OK
Total: 3 (3 usable), will use epoll.

Available multiplexer protocols :
(protocols marked as cannot be specified using ‘proto’ keyword)
h2 : mode=HTX side=FE|BE
h2 : mode=HTTP side=FE
: mode=HTX side=FE|BE
: mode=TCP|HTTP side=FE|BE

Available filters :
[SPOE] spoe
[COMP] compression
[CACHE] cache
[TRACE] trace

Thanks!

Talion

Posts: 1

Participants: 1

Read full topic

@nem wrote:

Most of the examples I’m finding are terminating an explicit SSL stream or HTTP proxies. I’m able to terminate SMTPS/IMAPS/POP3S no problem, but running into difficulty with switching backends when SSL is negotiated via STARTTLS.

First, is it even possible for haproxy to change its backend during communication if req_ssl_hello_type is present?

If so, then is this a pipe dream? Read data on *:143, connect to the normal unencrypted backend (127.0.0.1:1430), then when req_ssl_hello_type comes across the wire, redirect the stream to *:993, which is another haproxy frontend with SNI support to terminate SSL, then send that to 127.0.0.1:1430.

This old posting for Exchange 2010 hints I’m chasing something unattainable.

Posts: 1

Participants: 1

Read full topic

@pmsc1979 wrote:

Im having problems with haproxy (v1.5.18) but i believe the problem can be a configuration, i will explain my setup:

The request is made by php with curl.

CLIENT >> HA-SITE >> WEBSERVER1 >> HA-WEBSERVICE >> WEBSERVER2 [EMPTY]

The problem happens when WEBSERVER1 tries to get statitics from HA-WEBSERVICE
(returns empty).

But if i connect directly WEBSERVER1 to WEBSERVER2 the problem does not happen.

CLIENT >> HA-SITE >> WEBSERVER1 >> WEBSERVER2 [OK]

Posts: 1

Participants: 1

Read full topic

@SeanHaynes wrote:

Afternoon - I have completed a cluster build of 2 x haproxy servers sat on 2 x Ubuntu Servers using Pacemaker / Corosync / Heartbeat. The cluster sits infront of 3 x MS IIS web servers

The resources appear to be configured ok and fail over works well.

I have 2 issues, which I suspect are related. When I call up a web page served by the IIS servers on the local same subnet it will initially take anything up to 9 seconds to load. If I then close the web page and reopen the link it is considerably faster.

The second issue is that if I then try and access the web pages from another subnet, sometimes it will load - slowly, but mostly it times out.

Clearly I have missed something - so in the first instance has anyone else suffered a similar thing?

Below is the base haproxy.cfg:

System information as of Tue Apr 2 15:02:49 UTC 2019

System load: 0.79 Processes: 141
global
log /dev/log local0
log /dev/log local1 notice
chroot /var/lib/haproxy
stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
stats timeout 30s
user haproxy
group haproxy
daemon

    # Default SSL material locations
    ca-base /etc/ssl/certs
    crt-base /etc/ssl/private

    # Default ciphers to use on SSL-enabled listening sockets.
    # For more information, see ciphers(1SSL). This list is from:
    #  https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/
    # An alternative list with additional directives can be obtained from
    #  https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=haproxy

defaults
log global
mode http
option httplog
GNU nano 2.9.3 /etc/haproxy/haproxy.cfg

    option  dontlognull
    timeout connect 5000
    timeout client  50000
    timeout server  50000
    errorfile 400 /etc/haproxy/errors/400.http
    errorfile 403 /etc/haproxy/errors/403.http
    errorfile 408 /etc/haproxy/errors/408.http
    errorfile 500 /etc/haproxy/errors/500.http
    errorfile 502 /etc/haproxy/errors/502.http
    errorfile 503 /etc/haproxy/errors/503.http
    errorfile 504 /etc/haproxy/errors/504.http

listen stats
bind *:1936
mode http
log global

    maxconn 10

    clitimeout      100s
    srvtimeout      100s
    contimeout      100s
    timeout queue   100s

    stats enable
    stats hide-version
    stats refresh 30s
    stats show-node
    stats auth xxxxx
    stats uri  /haproxy?stats

frontend http_front
bind 172.21.1.119:80
mode http
default_backend http_back

backend http_back
balance roundrobin
mode http
server xxxxxxxxx 172.21.1.169:80 check
server xxxxxxxxx 172.21.1.168:80 check

A tcpdump from a host on another subnet - the requests are inbound but dont sem to be responded to:

sysadmin@haproxy1:~$ sudo tcpdump -i eth0 host 192.168.75.54
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
15:52:40.263804 IP ukbcalt45324.autologic.int.63371 > haproxy.http: Flags [S], seq 2415765373, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
15:52:40.266058 IP ukbcalt45324.autologic.int.63372 > haproxy.http: Flags [S], seq 1828596436, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
15:52:40.513741 IP ukbcalt45324.autologic.int.63373 > haproxy.http: Flags [S], seq 289814379, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
15:52:43.264073 IP ukbcalt45324.autologic.int.63371 > haproxy.http: Flags [S], seq 2415765373, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
15:52:43.266619 IP ukbcalt45324.autologic.int.63372 > haproxy.http: Flags [S], seq 1828596436, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
15:52:43.513608 IP ukbcalt45324.autologic.int.63373 > haproxy.http: Flags [S], seq 289814379, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
15:52:49.264183 IP ukbcalt45324.autologic.int.63371 > haproxy.http: Flags [S], seq 2415765373, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
15:52:49.267135 IP ukbcalt45324.autologic.int.63372 > haproxy.http: Flags [S], seq 1828596436, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
15:52:49.514263 IP ukbcalt45324.autologic.int.63373 > haproxy.http: Flags [S], seq 289814379, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
15:53:01.397340 IP ukbcalt45324.autologic.int.63384 > haproxy.http: Flags [S], seq 1529278499, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
15:53:04.396828 IP ukbcalt45324.autologic.int.63384 > haproxy.http: Flags [S], seq 1529278499, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0

Posts: 1

Participants: 1

Read full topic

@jmorfali wrote:

Hello!

At the moment I have two servers under centos 7.

• 10.10.104.200 = Loadbalencer with Haproxy
• 10.10.105.100 = web server

I want the clients to enter their ftp (ex Filezilla) 10.10.104.200 and be redirected automatically to the server 10.10.105.100. I still have not found a way that works well … Thank you very much for helping me.

Here is my current configuration of haproxy.cfg:

global
log /dev/log local0
log /dev/log local1 notice
chroot /var/lib/haproxy
stats timeout 30s
user haproxy
group haproxy
daemon

defaults
log global
mode http
option httplog
option tcplog
retries 3
maxconn 10000
option redispatch
option dontlognull
timeout connect 5000
timeout client 50000
timeout server 50000

frontend http_front
bind *:80
default_backend http_back

backend http_back
balance roundrobin
server serveurBack 10.10.105.100:80 check

listen stats
bind *:8181
stats enable
stats uri /
stats realm Haproxy\ Statistics
stats auth :

frontend ftp-pool
bind *:21 transparent
bind *:30000-35020 transparent
mode tcp
maxconn 2000
option tcplog
option tcp-check
default_backend ftp-pool-backend

backend ftp-pool-backend
balance source
hash-type consistent
server ftp01 10.10.105.100 check port 21

backend ftp-pool-backend-static
balance source
hash-type consistent

THX!
Have a good day

Posts: 1

Participants: 1

Read full topic

@hden wrote:

I’m trying to setup an internal proxy that forward HTTP requests to a HTTPS backend.
An echo server https://echo-5ooike70s.now.sh was used for development. I’ve managed to setup the configuration following previous discussion here, but the following configuration:

defaults
  retries 3
  maxconn 3000
  timeout connect 5s
  timeout server 10s
  timeout client 10s

frontend frontend_http
  bind *:8000
  mode http
  reqadd X-Forwarded-Proto:\ http
  default_backend backend_https

backend backend_https
  mode http
  server remote echo-5ooike70s.now.sh:443 check ssl verify none

Results in errors:

[WARNING] 092/134701 (46341) : Server backend_https/remote is DOWN, reason: Layer6 invalid response, info: "SSL handshake failure", check duration: 13ms. 0 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue.

[ALERT] 092/134701 (46341) : backend 'backend_https' has no server available!

HA-Proxy version 1.9.4 2019/02/06
curl -vvk results for the server are shown here https://gist.github.com/hden/7cc26dc03d755e47645fd667e48e87ca#file-curl-vvk

Any help or suggestions are appreciated. Thanks!

Posts: 1

Participants: 1

Read full topic