On 5/7/2022 9:11 AM, Shawn Heisey wrote:
A couple of days ago I noticed that quictls had made a 3.0.3 version
available. I upgraded and then tried to rebuild haproxy (master
branch). The compile failed. Don't they know they shouldn't change
API in a point release? (It's not even a good
A couple of days ago I noticed that quictls had made a 3.0.3 version
available. I upgraded and then tried to rebuild haproxy (master
branch). The compile failed. Don't they know they shouldn't change API
in a point release? (It's not even a good idea in a minor release
unless there is
On 4/29/22 11:16, Henning Svane wrote:
I have tried to build a PEM Certificate, but with no luck.
What should it include and in which order?
I use certs issued by LetsEncrypt.
My certificate file that I use for haproxy and most other software doing
TLS has four PEM-encoded items in it:
On 4/29/22 12:42, Branitsky, Norman wrote:
If you include the following in your HAProxy configuration global
section you don't need to include DH Params in the certificate:
tune.ssl.default-dh-param 2048
It takes several minutes to generate params, so I doubt that with that
option that
On 4/25/22 10:55, Shawn Heisey wrote:
I was testing with the master branch from
https://github.com/haproxy/haproxy.git. Just pulled down the latest
changes, built it, and installed it. Now I am sometimes seeing
different behavior on the large POST. It will load a page quickly
sometimes
On 5/4/22 05:30, Tom Browder wrote:
From what I've seen of HAProxy's configuration, it seems it may be
able to be used as an easy-to-configure firewall immediately
downstream from my ISP's router and inside a small Debian computer
feeding another router.
Does that sound feasible? Or is there
On 5/8/2022 3:16 AM, Willy Tarreau wrote:
There's no good solution to this, except by forcing the exact address
yourself. The BSD socket API doesn't permit to send UDP packets from a
specific source, so the commonly used approach for clients is to bind
while sending the first packet, but that
Here is the full haproxy -vv:
HAProxy version 2.7-dev4-16972e-5 2022/08/22 - https://haproxy.org/
Status: development branch - not safe for use in production.
Known bugs: https://github.com/haproxy/haproxy/issues?q=is:issue+is:open
Running on: Linux 5.15.0-1017-aws #21~20.04.1-Ubuntu SMP Fri Aug
I am running haproxy in a couple of places. It is listening on multiple
seemingly random high UDP ports.
The one running "2.6.2-ce3023-30 2022/08/03" has the following ports.
This server is in AWS. The first three lines are expected:
elyograg@bilbo:/var/log$ sudo lsof -Pn -i | grep
On 1/7/23 10:04, Willy Tarreau wrote:
However there's a solution nowadays, you can use "http-after-response"
instead of "http-response". It will apply *after* the response, and will
happily overwrite stats, redirects and even error pages. I'd say that
it's the recommended way to place alt-svc
On 1/7/23 09:59, Willy Tarreau wrote:
No, you just have one entry per "bind" line. If it's only a matter of
listening on multiple host:port and you want them merged, you could
probably put all the addresses on the same line separated by commas
and see if it's better:
bind
On 1/7/23 10:35, Shawn Heisey wrote:
I made that change, and it's still not including the alt-svc header on
the stats page.
Once again bitten by my pacemaker config! Turns out that it had
switched the VIP to the other server, which still had the old config. I
think one of my haproxy
On 1/7/23 09:41, Shawn Heisey wrote:
That's really cool. But I have an oddity I'd like to share and see if
it needs some work.
Semi-related but separate: I have this line in that frontend:
stats uri /redacted
Which works well ... but it never switches to http/3. The alt-svc
header
On 1/7/23 07:46, Willy Tarreau wrote:
Indeed, you need "option socket-stats" in the frontend that has such
listeners, so that the stats are collected per-listening socket (this
is not the case by default).
That's really cool. But I have an oddity I'd like to share and see if
it needs some
On 12/14/22 07:15, Willy Tarreau wrote:
Should I switch to quictls 1.1.1 instead?
Possibly, yes. It's more efficient in every way from what we can see.
For users who build themselves (and with QUIC right now you don't have
a better choice), it should not change anything and will keep
On 12/14/22 06:07, Willy Tarreau wrote:
> By the way, are you running with OpenSSL
> 3.0 ? That one is absolutely terrible and makes extreme abuse of
> mutexes and locks, to the point that certain workloads were divided
> by 2-digit numbers between 1.1.1 and 3.0. It took me one day to
> figure
On 12/15/22 21:49, Willy Tarreau wrote:
There's currently a great momentum around WolfSSL that was already
adopted by Apache, Curl, and Ngtcp2 (which is the QUIC stack that
powers most HTTP/3-compatible agents). Its support on haproxy is
making fast progress thanks to the efforts on the two
On 12/16/22 00:01, Willy Tarreau wrote:
- if you want to use QUIC, use quictls-1.1.1. Once you have to build
something yourself, you definitely don't want to waste your time on
the performance-crippled 3.0, and 1.1.1 will change less often than
3.0 so that also means less
On 12/16/22 00:26, Willy Tarreau wrote:
> Both work for me using firefox (green flash after reload).
It wasn't working when I tested it. I rebooted for a kernel upgrade and
it still wasn't working.
And then a while later I was poking around in my zabbix UI and saw the
green lightning bolt.
On 12/15/22 09:47, Shawn Heisey wrote:
The version of curl with http3 support is not available in any of the
distro repos for my Ubuntu machines, so I found a docker image with it.
That works in cases where a browser won't switch, but that's because it
never tries TCP, it goes straight to UDP
On 12/15/22 02:19, Willy Tarreau wrote:
I guess you'll get them only while the previous version remains maintained
(i.e. use a package from the previous LTS distro). But regardless you'll
also need to use executables linked with that version and that's where it
can become a pain.
When I
On 12/16/22 01:59, Shawn Heisey wrote:
On 12/16/22 00:26, Willy Tarreau wrote:
> Both work for me using firefox (green flash after reload).
It wasn't working when I tested it. I rebooted for a kernel upgrade and
it still wasn't working.
And then a while later I was poking around in
On 12/15/22 00:58, Amaury Denoyelle wrote:
I seem to be able to reach your website with H3 currently. Did you
revert to an older version ? Regarding this commit, it rejects requests
with invalid headers (with uppercase or non-HTTP tokens in the field
name). Have you tried with several browsers
On 12/14/22 12:06, Shawn Heisey wrote:
I built a gitlab CI config to test out changes to my build/install
scripts. I'm having some trouble with that where haproxy is not working
right, I'll start a new thread.
Turned out that most of those problems were due to docker-related
issues
On 12/14/22 19:33, Shawn Heisey wrote:
With quictls 3.0.7 it was working. I will try rebuilding and see
whether it still does. There was probably an update to haproxy as well
as changing quictls -- my build script pulls the latest from the 2.7 git
repo.
Rebuilding with quictls 3.0.7 didn't
On 12/14/22 07:15, Willy Tarreau wrote:
Should I switch to quictls 1.1.1 instead?
Possibly, yes
I did this, and now browsers do not switch to http3. A direct request
that forces http3 works, but browsers are not switching to it based on
the alt-svc header. Tried both firefox and chrome
On 12/14/22 21:23, Илья Шипицин wrote:
Can you try to bisect?
I had made some incorrect assumptions about what's needed to use bisect.
With a little bit of research I figured it out and it was a LOT easier
than I had imagined.
I suspect that it won't help, browsers tend to remember things
Since the release of 2.7.0, I changed the repository I build to 2.7
instead of master. I was noticing that some of the links in the table
at the top of haproxy.org are http instead of https.
All the links under Branch plus the git, web, and bugs links under Links
are http.
Those webservers
On 1/29/2023 10:43 PM, Jeremy Hansen wrote:
Figured out my issue. I was doing something really stupid. Make sure
if you’re using conf.d/, you name your file .cfg instead of .conf.
I don't think haproxy does a conf.d setup out of the box. You (or your
OS) would have to set that up. Or were
On 1/30/2023 12:08 AM, Jeremy Hansen wrote:
It’s working as of now but are you saying the connection from HAProxy to
the real server won’t be encrypted? I assumed at this point it’s all
passthrough. The browser isn’t complaining at the moment.
Redirecting this back to the mailing list.
On 1/7/23 09:59, Willy Tarreau wrote:
Also if you want you can show the IP:ports by adding "stats show-legends"
in your stats section. However, be aware that it will also show server IP
addresses, configured stickiness cookies etc. Thus only do this if access
to your stats page is restricted to
On 12/14/22 07:15, Willy Tarreau wrote:
On Wed, Dec 14, 2022 at 07:01:59AM -0700, Shawn Heisey wrote:
On 12/14/22 06:07, Willy Tarreau wrote:
By the way, are you running with OpenSSL
3.0 ? That one is absolutely terrible and makes extreme abuse of
mutexes and locks, to the point that certain
I have haproxy installed, doing http/3. The http/3 is working for
almost everything. I build it from the main branch and update it fairly
often.
One of the websites I have behind it is my gitlab server. That is
always http/2, it never switches to http/3.
Does anyone know why that
On 4/27/23 20:59, Tristan wrote:
Hmm. The web server is on the local gigabit LAN with the client.
Would that give TCP a significant enough boost that it could beat UDP?
Hard to say; in our case it seemed more random than actually driven by
anything remotely close to clear. I'm merely
I did figure out that ufw was not allowing udp/443. So it turns out
that wasn't working for any website on that install.
I have another install in AWS that IS working, and it turns out that
when I was seeing the green lightning bolt in firefox, it was one of
those websites, not the ones in
On 4/27/23 20:59, Tristan wrote:
Then yep, you're in the same boat as we were. It switched for no reason
one day. Even trying HTTPS/SVCB DNS records did nothing for us until it
"magically" decided to use H3.
Today it is using h3. I didn't change anything, other than installing
updates on my
On 7/8/23 21:33, Shawn Heisey wrote:
Here's the very weird part. It seems that haproxy is sending the OCSP
request to localhost, not the http://r3.o.lencr.org URL that it SHOULD
be sending it to. Right before the above log entry is this one:
Jul 8 21:15:38 - haproxy[4075] 127.0.0.1:57696
On 7/8/23 21:33, Shawn Heisey wrote:
Here's the very weird part. It seems that haproxy is sending the OCSP
request to localhost, not the http://r3.o.lencr.org URL that it SHOULD
be sending it to. Right before the above log entry is this one:
Jul 8 21:15:38 - haproxy[4075] 127.0.0.1:57696
On 7/12/23 04:13, Remi Tricot-Le Breton wrote:
On 11/07/2023 22:22, Shawn Heisey wrote:
On 7/11/23 01:30, Remi Tricot-Le Breton wrote:
That directive didn't work in "global" but it was accepted when I
moved it to "defaults". But it didn't change the behavior. IPv6 is
On 7/13/23 17:56, Shawn Heisey wrote:
I do still use this script on one of my servers where I can't get
haproxy's built-in ocsp updating to work right. It is haproxy 2.8.1.
A few minutes ago, I fixed the problem on that server with haproxy's
built-in OCSP updater, so the script is officially
On 7/13/23 09:01, Sander Klein wrote:
I tried upgrading from 2.6.14 to 2.8.1, but after the upgrade I couldn't
connect to any of the sites behind it.
While looking at the error it seems like OCSP is not working anymore.
Right now I have a setup in which I provision the certificates with the
On 7/13/23 15:00, Cyril Bonté wrote:
Hi Shawn,
Le 13/07/2023 à 18:48, Shawn Heisey a écrit :
Looks like on my last edit I deleted it and didn't add it to
defaults, so I was wrong in what I said. It throws a different error
when added to defaults:
Because it should be in the global section
I have a strange problem with OCSP updating. On one server everything
works. That server is in my basement, running Ubuntu 22.04.
Another system, Ubuntu 20.04 in AWS using exactly the same certificates
and exactly the same crt-list file is failing to do an OCSP update.
Jul 8 21:15:38 -
On 7/11/23 01:30, Remi Tricot-Le Breton wrote:
The OCSP update mechanism uses the internal http_client which then uses
the resolvers. The only time when I had some strange resolver-related
issues is when the name resolution returned IPv6 addresses which were
not properly managed on my machine.
On 7/5/23 15:27, Pavlos Parissis wrote:
There is a list of pre-defined ACLs, see
http://docs.haproxy.org/2.8/configuration.html#7.4, and in that list
you have HTTP_1.0 acl to match traffic for that version of HTTP protocol.
So, you can add below snippet to block traffic for HTTP 1.0 version
I have a backend in haproxy for my Solr server. Solr lives unencrypted
on port 8983, haproxy provides TLS for it, on a name like
`solr.example.com`.
Everything works fully as expected with HTTP 1.1, 2, or 3.
If I send a request with curl using any HTTP version to
https://solr.example.com/,
On 5/25/23 09:08, Willy Tarreau wrote:
The problem definitely is concurrency, so 1000 curl will show nothing
and will not even match production traffic. You'll need to use a load
generator that allows you to tweak the TLS resume support, like we do
with h1load's argument "--tls-reuse". Also I
On 5/29/23 20:38, Willy Tarreau wrote:
Have you verified that the CPU is saturated ?
The CPU on the machine running the test settles at about 1800 percent
for my test program. 12 real cores, hyperthreaded.
The CPU on the frontend haproxy process is barely breathing hard. Never
saw it get
On 5/29/23 19:52, Shawn Heisey wrote:
Interesting idea.
So sorry. I was writing up the new reply, and my fingers got confused
for a moment, accidentally did Ctrl-Enter which tells Thunderbird to
send the message. Will send a new complete reply.
On 5/29/23 01:43, Aleksandar Lazic wrote:
HAProxies FE => HAProxies BE => Destination Servers
Where the Destination Servers are also HAProxies which just returns a
static content or any high performance low latency HTTPS Server.
With such a Setup can you test also the Client mode of the
On 5/29/23 01:43, Aleksandar Lazic wrote:
HAProxies FE => HAProxies BE => Destination Servers
Where the Destination Servers are also HAProxies which just returns a
static content or any high performance low latency HTTPS Server.
With such a Setup can you test also the Client mode of the
On 5/31/23 23:25, Matthias Fechner wrote:
I just saw in the release notes for 2.8 that an automatic OCSP renewal
is now included and I would like to get rid of my manual scripts that
are currently injecting the OCSP information.
I checked a little bit the documentation here:
On 6/1/23 16:19, Shawn Heisey wrote:
I asked ChatGPT for help, and with that info, I was able to work out
what to do.
-
elyograg@smeagol:/etc/haproxy$ cat crt-list.txt
/etc/ssl/certs/local/REDACTED1.combined.pem [ocsp-update on]
/etc/ssl/certs/local/REDACTED2.combined.pem [ocsp-update
On 6/1/23 15:42, Willy Tarreau wrote:
So this means that the doc is still not clear enough and we need to
improve this. And indeed, I'm myself confused because William told me
a few days ago that "ocsp-update" was for crt-list lines only and it's
found in the "bind line options" section. And of
On 3/11/23 22:52, Willy Tarreau wrote:
According to the OpenSSL devs, 3.1 should be "4 times better than 3.0",
so it could still remain 5-40 times worse than 1.1.1. I intend to run
some tests soon on it on a large machine, but preparing tests takes a
lot of time and my progress got delayed by
On 6/5/23 01:41, Artur wrote:
What is suggested/recommended way to get QUIC / HTTP/3 working in
haproxy on Debian ?
I have been debating for a while whether or not to get the work I have
done on build scripts out into the world. Just mirrored the repo from
my gitlab server to github, so
On 5/19/23 14:21, Zakharychev, Bob wrote:
ssl-default-bind-options no-tls-tickets ssl-min-ver TLSv1.2
I'd suggest you try with ssl-default-bind-options as in my config, and maybe
ssl-default-bind-ciphers as well as these are for TLS
I have been unknowingly hampered in my tests by the fact
On 5/27/23 14:56, Shawn Heisey wrote:
Yup. It was using keepalive. I turned keepalive off and repeated the
tests.
I did the tests again with 200 threads. The system running the tests
has 12 hyperthreaded cores, so this definitely pushes its capabilities.
The system running haproxy has 24
On 5/27/23 02:59, Willy Tarreau wrote:
The little difference makes me think you've sent your requests over
a keep-alive connection, which is fine, but which doesn't stress the
TLS stack anymore.
Yup. It was using keepalive. I turned keepalive off and repeated the
tests.
I'm still not
On 5/27/23 18:03, Shawn Heisey wrote:
On 5/27/23 14:56, Shawn Heisey wrote:
Yup. It was using keepalive. I turned keepalive off and repeated the
tests.
I did the tests again with 200 threads. The system running the tests
has 12 hyperthreaded cores, so this definitely pushes its
On 6/2/23 14:42, Lukas Tribus wrote:
I suggest we make it configurable on the bind line like other ssl
options, so it will work for the common use cases that don't involve
crt-lists, like a simple crt statement pointing to a certificate or a
directory.
It could also be a global option *as
On 6/3/23 15:28, Shawn Heisey wrote:
So maybe a completely separate global option makes sense. The crt-list
requirement is not really a burden for me, but for someone who uses a
LOT of certificates that change frequently, it probably would become a
burden.
Unless it is possible to have
On 6/3/23 15:37, Shawn Heisey wrote:
On 6/3/23 15:28, Shawn Heisey wrote:
So maybe a completely separate global option makes sense. The
crt-list requirement is not really a burden for me, but for someone
who uses a LOT of certificates that change frequently, it probably
would become a burden
On 6/28/23 08:17, Nick Ramirez wrote:
The HAProxy source code indicates that there is a directive named
'tune.quic.backend.max-idle-timeout': haproxy/src/cfgparse-quic.c at
f473eb72066e02d44837fd77110b6ca5bdea97e2 · haproxy/haproxy (github.com)
I have a config that I have had in place for a while now. It did TLS
1.2 and 1.3, and got an A+ rating at SSL Labs.
Today I was running the SSL test again and it only got an A rating
instead of A+. Looking deeper at the results, I saw that it was no
longer doing TLS 1.2 ... only TLS 1.3.
On 12/10/2023 15:07, Tristan wrote:
Cool topic! A few things struck me (of various levels of pertinence, and
sorry in advance for the digressions):
http-request del-header [Ff]orwarded.+ -m reg
http-request del-header [Xx]-[Ff]orwarded.+ -m reg
I wonder about the regex use here to
On 12/8/23 14:35, Ionel GARDAIS wrote:
Thanks Tristan.
So typically I’d say to add to every single http frontend:
> http-request set-header X-Forwarded-For %[src]
http-request set-header X-Forwarded-Host %[hdr(Host)]
http-request set-header X-Forwarded-Proto %[ssl_fc,iif(https,http)]
On 11/18/2023 08:07, Christoph Kukulies wrote:
For haproxy I don't have a log-format string.
defaults
log global
mode http
option httplog
option dontlognull
timeout connect 5000
timeout client 5
timeout server 5
On 11/11/2023 02:26, Christoph Kukulies wrote:
The file is definitely there and the command works an a different file,
when I apply it to the previously used certificate fullchain.pem.
The file which is not working, has the following structure:
-BEGIN EC PRIVATE KEY-
I think you have
On 11/12/2023 02:37, Christoph Kukulies wrote:
what the inadvertently publicly dislosing my private key is concerned:
I obfuscated the excerpts of my .pem file by putting XX into the
string. Destroying part of it would suffice, I think.
Up to you. I wouldn't trust it personally.
What
On 11/13/23 02:09, William Lallemand wrote:
"show ssl cert" shows the certificate in the haproxy memory, and not on
the filesystem. Start by doing "show ssl cert" without any argument to
see the list of certificates whcih were loaded by haproxy.
That makes complete sense now! I saw an error
On 4/26/24 10:51, Aurelien DARRAGON wrote:
This is expected because forwarded cannot be used on frontend unlike
forwardfor:
That's interesting, because I already had `option forwardfor except
127.0.0.1` in the frontend which works perfectly. Should that be in the
backend too?
I was
I was just reading about the new "option forwarded" capability in 2.9,
so I added it to my config and now I get warnings when checking the config.
[WARNING] (253408) : config : parsing [/etc/haproxy/haproxy.cfg:45] :
'option forwarded' ignored because frontend 'web80' has no backend
On 5/6/24 06:02, Björn Jacke wrote:
frontend ft_443
bind :::443 ssl crt /ssl/combined.pem
bind quic6@:443 ssl crt /ssl/combined.pem alpn h3
option tcp-smart-accept
http-after-response add-header alt-svc 'h3=":443"; ma=600; persistent=1'
frontend ft_quic_test
mode tcp
On 4/3/24 06:02, Froehlich, Dominik wrote:
I fear that strict-sni won’t get us far. The issue is that the SNI is
just fine (it is in the crt-list), however we also need to check if the
host-header is part of the crt-list. E.g.
William's answer should work.
The strict-sni setting makes sure
201 - 275 of 275 matches
Mail list logo