Re: [*EXT*] Re option forwardfor with IPv6

[Ionel GARDAIS]

I'm currently facing a bug in gerrit 3.1.x which strip the last hextet of an 
IPv6 address.
https://bugs.chromium.org/p/gerrit/issues/detail?id=12429#c4

A patch is on its way.
Maybe it will make IPv6 logging more consistent.

Will post my finding then.

-- 
Ionel GARDAIS

- Mail original -
De: "Lukas Tribus" 
À: "Ionel GARDAIS" 
Cc: "haproxy" 
Envoyé: Mardi 3 Mars 2020 20:57:45
Objet: [*EXT*] Re option forwardfor with IPv6

Hello,

On Tue, 3 Mar 2020 at 19:06, Ionel GARDAIS
 wrote:
>
> Hi,
>
> What is the expected behavior of "option forwardfor" with an IPv6 connection ?
> Frontend listen on IPv4 and IPv6.

The expected behavior is to insert the IPv6 address into the X-F-F
header, and this is exactly what happens in my repro here.


> For IPv4 incoming connections, the server correctly displays the original IP 
> address, wether the haproxy-to-server is made with IPv4 or IPv6.
> For IPv6 incoming connections, the server displays the IP of haproxy, wether 
> the haproxy-to-server is made with IPv4 or IPv6.

Ok, but "server displays" is not equivalent with "haproxy sends in the
X-Forwarded-For header".

Does your server actually support IPv6 addresses in this header? If
yes, what do you see in your logs/on your servers, when you make a
call directly to it without haproxy in the question?

curl -H "X-Forwarded-For: 2001:0db8:85a3:::8a2e:0370:7334"
http://direct-backend-server.example.org/testurl



Lukas
--
232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON
Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301

Re: mirroragent (haproxy)

[Tuktamyshev Ainur]

Dear Christopher

Configuration`s and info about haproxy and spoa version in attachment.

>   * If possible, info about the mirror requests
Requests coming to haproxy should go to a specific IP, as well as duplicated in 
our parser located on another IP address.
On the parser’s machine, we don’t see any incoming requests from the SPOA, even 
when removing tcpdump.
The connection between the servers is stable.


-- 
Best regards.
Tuktamyshev A.N.
ph. +7-965-243-99-81


03.03.2020, 18:21, "Christopher Faulet" :
> Le 03/03/2020 à 14:39, Tuktamyshev Ainur a écrit :
>>  Dear, Collegues.
>>
>>  There was a problem when mirroring traffic through Haproxy.
>>
>>  In our spoa-mirror logs next mistakes:
>>  [ 0][ 0.000600] --- start --- 2020-03-03 15:48:30 -
>>  [ 1][ 318.942594] <1:26> (E) Failed to receive frame data: Stale file handle
>>  [ 2][ 416.600422] <2:26> (E) Failed to send frame length: Broken pipe
>>  [ 8][ 698.488390] <8:29> (E) Failed to send frame length: Broken pipe
>>  [ 5][ 698.677793] <5:26> (E) Failed to send frame length: Broken pipe
>>  [ 9][ 698.871186] <9:30> (E) Failed to send frame length: Broken pipe
>>  [ 7][ 699.071718] <7:28> (E) Failed to send frame length: Broken pipe
>>  [10][ 699.391399] <10:31> (E) Failed to send frame length: Broken pipe
>>  [ 6][ 699.585724] <6:27> (E) Failed to send frame length: Broken pipe
>>  [ 1][ 699.791090] <11:32> (E) Failed to send frame length: Broken pipe
>>
>>  Haproxy version: "HA-Proxy version 2.1.0 2019/11/25"
>>
>>  Can you help with this?
>>  If necessary, provide additional information.
>
> Hi,
>
> First of all, could you provide following info please ?
>
>   * "haproxy -vv" output
>   * haproxy configuration
>   * spoa-mirror version
>   * spoa-mirror configuration
>   * If possible, info about the mirror requests
>
> --
> Christopher Faulet<>

Re: Segfault on 2.1.3

[Vincent Bernat]

 ❦  3 mars 2020 15:34 -07, Sean Reifschneider :

> We've been running haproxy 1.8 series for quite a while.  We're currently
> in the process of updating to 2.1, and have installed from the vbernat PPA
> on Ubuntu 18.04 using the same old config file.
>
> Now we are seeing segfaults a few times a day:

You can easily collect core information if you install systemd-coredump.
Then, use "coredumpctl list" to locate the collected core, then
"coredumpctl info XXX" to get some stack traces. If you install the
-dbgsym package, you can also use "coredumpctl debug XXX" then use "bt
full" and send the output.
-- 
Don't stop with your first draft.
- The Elements of Programming Style (Kernighan & Plauger)

[PR] Add missing string length for lua sticktable lookup

[PR Bot]

Dear list!

Author: Nathan Neulinger 
Number of patches: 1

This is an automated relay of the Github pull request:
   Add missing string length for lua sticktable lookup

Patch title(s): 
   Add missing string length for lua sticktable lookup

Link:
   https://github.com/haproxy/haproxy/pull/530

Edit locally:
   wget https://github.com/haproxy/haproxy/pull/530.patch && vi 530.patch

Apply locally:
   curl https://github.com/haproxy/haproxy/pull/530.patch | git am -

Description:
   Consider moving this to smp_to_stkey - or at least adding a:
   ```if ( smp->data.u.str.data == 0 ) { static_table_key.key_len =
   strlen(smp->data.u.str.key); }```
   
   equivalent to smp_to_stkey

Instructions:
   This github pull request will be closed automatically; patch should be
   reviewed on the haproxy mailing list (haproxy@formilux.org). Everyone is
   invited to comment, even the patch's author. Please keep the author and
   list CCed in replies. Please note that in absence of any response this
   pull request will be lost.

stable-bot: Bugfixes waiting for a release 2.1 (17), 2.0 (13)

[stable-bot]

Hi,

This is a friendly bot that watches fixes pending for the next haproxy-stable 
release!  One such e-mail is sent periodically once patches are waiting in the 
last maintenance branch, and an ideal release date is computed based on the 
severity of these fixes and their merge date.  Responses to this mail must be 
sent to the mailing list.


Last release 2.1.3 was issued on 2020-02-12.  There are currently 17 patches in 
the queue cut down this way:
- 1 MAJOR, first one merged on 2020-02-21
- 4 MEDIUM, first one merged on 2020-02-21
- 12 MINOR, first one merged on 2020-02-21

Thus the computed ideal release date for 2.1.4 would be 2020-03-06, which is in 
one week or less.

Last release 2.0.13 was issued on 2020-02-13.  There are currently 13 patches 
in the queue cut down this way:
- 1 MAJOR, first one merged on 2020-02-21
- 4 MEDIUM, first one merged on 2020-02-21
- 8 MINOR, first one merged on 2020-02-21

Thus the computed ideal release date for 2.0.14 would be 2020-03-06, which is 
in one week or less.

The current list of patches in the queue is:
 - 2.0, 2.1  - MAJOR   : http-ana: Always abort the request 
when a tarpit is triggered
 - 2.0, 2.1  - MEDIUM  : muxes: Use the right argument when 
calling the destroy method.
 - 2.0, 2.1  - MEDIUM  : shctx: make sure to keep all blocks 
aligned
 - 2.0, 2.1  - MEDIUM  : ebtree: don't set attribute packed 
without unaligned access support
 - 2.0, 2.1  - MEDIUM  : ssl: fix several bad pointer aliases 
in a few sample fetch functions
 - 2.0, 2.1  - MINOR   : http: http-request replace-path 
duplicates the query string
 - 2.0, 2.1  - MINOR   : http-ana: Matching on monitor-uri 
should be case-sensitive
 - 2.0, 2.1  - MINOR   : sample: Make sure to return stable IDs 
in the unique-id fetch
 - 2.0, 2.1  - MINOR   : namespace: avoid closing fd when 
socket failed in my_socketat
 - 2.0, 2.1  - MINOR   : sample: fix the json converter's 
endian-sensitivity
 - 2.1   - MINOR   : mux-fcgi: Forbid special characters 
when matching PATH_INFO param
 - 2.1   - MINOR   : http-htx: Don't return error if 
authority is updated without changes
 - 2.0, 2.1  - MINOR   : filters: Count HTTP headers as 
filtered data but don't forward them
 - 2.1   - MINOR   : http-htx: Do case-insensive 
comparisons on Host header name
 - 2.0, 2.1  - MINOR   : dns: ignore trailing dot
 - 2.0, 2.1  - MINOR   : connection: make sure to correctly tag 
local PROXY connections
 - 2.1   - MINOR   : h2: reject again empty :path 
pseudo-headers

-- 
The haproxy stable-bot is freely provided by HAProxy Technologies to help 
improve the quality of each HAProxy release.  If you have any issue with these 
emails or if you want to suggest some improvements, please post them on the 
list so that the solutions suiting the most users can be found.

Segfault on 2.1.3

[Sean Reifschneider]

We've been running haproxy 1.8 series for quite a while.  We're currently
in the process of updating to 2.1, and have installed from the vbernat PPA
on Ubuntu 18.04 using the same old config file.

Now we are seeing segfaults a few times a day:

Mar 03 14:53:52 fw1.dev.realgo.com kernel: haproxy[8654]: segfault at 18 ip
56389a674d08 sp 7fac18dba030 error 4 in haproxy[56389a52b000+235000]
Mar 03 14:53:52 fw1.dev.realgo.com haproxy[8649]: [ALERT] 062/145352 (8649)
: Current worker #1 (8653) exited with code 139 (Segmentation fault)
Mar 03 14:53:52 fw1.dev.realgo.com haproxy[8649]: [ALERT] 062/145352 (8649)
: exit-on-failure: killing every processes with SIGTERM
Mar 03 14:53:52 fw1.dev.realgo.com haproxy[8649]: [WARNING] 062/145352
(8649) : All workers exited. Exiting... (139)
Mar 03 14:53:52 fw1.dev.realgo.com systemd[1]: haproxy.service: Main
process exited, code=exited, status=139/n/a
Mar 03 14:53:52 fw1.dev.realgo.com systemd[1]: haproxy.service: Failed with
result 'exit-code'.

Looks like it is restarting 5-10 times a day during the work week, less
during the weekend where only our monitoring system is hitting it.

I haven't tried disabling htx, which the other recent Segfault thread said
resolved it.  I'm currently trying reverting down to 2.0.13.

I'm happy to provide the config if that helps.  It's 419 lines.

Sean

[PATCH] limit cirrus-ci to stable freebsd images only

[Илья Шипицин]

Hello,

"snap" images are not usable. they break all the time.
let us switch to freebsd-12.1 (the only available stable image)

Cheers,
Ilya Shipitcin
From 19206e40c7f7d7bbef014a660fc2060f3882a9de Mon Sep 17 00:00:00 2001
From: Ilya Shipitsin 
Date: Wed, 4 Mar 2020 01:18:02 +0500
Subject: [PATCH] BUILD: cirrus-ci: get rid of unstable freebsd images

the only stable available freebsd image on cirrus is 12.1
let us drop all "snap" images, they are unusable for running tests
because of being fragile
---
 .cirrus.yml | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/.cirrus.yml b/.cirrus.yml
index 86b404782..982773467 100644
--- a/.cirrus.yml
+++ b/.cirrus.yml
@@ -1,14 +1,10 @@
 FreeBSD_task:
   freebsd_instance:
 matrix:
-  image_family: freebsd-13-0-snap
-  image_family: freebsd-12-1-snap
-  image_family: freebsd-11-3-snap
+  image_family: freebsd-12-1
   only_if: $CIRRUS_BRANCH =~ 'master|next'
-  env:
-IGNORE_OSVERSION: yes # supress package installation error on FreeBSD-13
   install_script:
-- pkg update -f && pkg upgrade -y && pkg install -y openssl git gmake lua53 socat
+- pkg update -f && pkg upgrade -y && pkg install -y openssl111 git gmake lua53 socat
   script:
 - git clone https://github.com/VTest/VTest.git ../vtest
 - make -C ../vtest
-- 
2.24.1

Re: option forwardfor with IPv6

[Lukas Tribus]

Hello,

On Tue, 3 Mar 2020 at 19:06, Ionel GARDAIS
 wrote:
>
> Hi,
>
> What is the expected behavior of "option forwardfor" with an IPv6 connection ?
> Frontend listen on IPv4 and IPv6.

The expected behavior is to insert the IPv6 address into the X-F-F
header, and this is exactly what happens in my repro here.


> For IPv4 incoming connections, the server correctly displays the original IP 
> address, wether the haproxy-to-server is made with IPv4 or IPv6.
> For IPv6 incoming connections, the server displays the IP of haproxy, wether 
> the haproxy-to-server is made with IPv4 or IPv6.

Ok, but "server displays" is not equivalent with "haproxy sends in the
X-Forwarded-For header".

Does your server actually support IPv6 addresses in this header? If
yes, what do you see in your logs/on your servers, when you make a
call directly to it without haproxy in the question?

curl -H "X-Forwarded-For: 2001:0db8:85a3:::8a2e:0370:7334"
http://direct-backend-server.example.org/testurl



Lukas

option forwardfor with IPv6

[Ionel GARDAIS]

Hi, 

What is the expected behavior of "option forwardfor" with an IPv6 connection ? 
Frontend listen on IPv4 and IPv6. 

For IPv4 incoming connections, the server correctly displays the original IP 
address, wether the haproxy-to-server is made with IPv4 or IPv6. 
For IPv6 incoming connections, the server displays the IP of haproxy, wether 
the haproxy-to-server is made with IPv4 or IPv6. 

The default section reads 
option forwardfor except 127.0.0.1/8 
and there is no override of this setting. 

Should I add a line like 
http-request set-header X-Forwarded-For %[src] 
instead of using option forwardfor ? 

Thanks, 
Ionel 

--
232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON
Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301

Re: Log IP and port from haproxy to server

[Pepe Charli]

Thanks
I was not looking at the proper documentation.

El mar., 3 mar. 2020 a las 17:33, Tim Düsterhus () escribió:
>
> Pepe,
>
> Am 03.03.20 um 17:28 schrieb Pepe Charli:
> > In "mode tcp", Is it possible to log the IP and port from haproxy to
> > server (haproxyIP and haproxPort)?
> >
> > clientIP:ClientPort- > frontendIP:frontendPort
> > haproxyIP:haproxyPort -> serverIP:serverPort
> >   %ci:%cp  %fi:%fp
> >  %??:%??  %si:%sp
> >
>
> This should be possible with %bi and %bp:
>
> >   |   | %bi  | backend_source_ip   (connecting address)  | IP  |
> >   |   | %bp  | backend_source_port (connecting address)  | numeric |
> (from http://cbonte.github.io/haproxy-dconv/2.1/configuration.html#8.2.4)
>
> Best regards
> Tim Düsterhus

Re: Log IP and port from haproxy to server

[Tim Düsterhus]

Pepe,

Am 03.03.20 um 17:28 schrieb Pepe Charli:
> In "mode tcp", Is it possible to log the IP and port from haproxy to
> server (haproxyIP and haproxPort)?
> 
> clientIP:ClientPort- > frontendIP:frontendPort
> haproxyIP:haproxyPort -> serverIP:serverPort
>   %ci:%cp  %fi:%fp
>  %??:%??  %si:%sp
> 

This should be possible with %bi and %bp:

>   |   | %bi  | backend_source_ip   (connecting address)  | IP  |
>   |   | %bp  | backend_source_port (connecting address)  | numeric |
(from http://cbonte.github.io/haproxy-dconv/2.1/configuration.html#8.2.4)

Best regards
Tim Düsterhus

Log IP and port from haproxy to server

[Pepe Charli]

In "mode tcp", Is it possible to log the IP and port from haproxy to
server (haproxyIP and haproxPort)?

clientIP:ClientPort- > frontendIP:frontendPort
haproxyIP:haproxyPort -> serverIP:serverPort
  %ci:%cp  %fi:%fp
 %??:%??  %si:%sp


Thanks,

Re: mirroragent (haproxy)

[Christopher Faulet]

Le 03/03/2020 à 14:39, Tuktamyshev Ainur a écrit :

Dear, Collegues.

There was a problem when mirroring traffic through Haproxy.

In our spoa-mirror logs next mistakes:
[ 0][0.000600] --- start --- 2020-03-03 15:48:30 -
[ 1][  318.942594]   <1:26> (E) Failed to receive frame data: Stale file handle
[ 2][  416.600422]   <2:26> (E) Failed to send frame length: Broken pipe
[ 8][  698.488390]   <8:29> (E) Failed to send frame length: Broken pipe
[ 5][  698.677793]   <5:26> (E) Failed to send frame length: Broken pipe
[ 9][  698.871186]   <9:30> (E) Failed to send frame length: Broken pipe
[ 7][  699.071718]   <7:28> (E) Failed to send frame length: Broken pipe
[10][  699.391399]   <10:31> (E) Failed to send frame length: Broken pipe
[ 6][  699.585724]   <6:27> (E) Failed to send frame length: Broken pipe
[ 1][  699.791090]   <11:32> (E) Failed to send frame length: Broken pipe

Haproxy version: "HA-Proxy version 2.1.0 2019/11/25"

Can you help with this?
If necessary, provide additional information.




Hi,

First of all, could you provide following info please ?

 * "haproxy -vv" output
 * haproxy configuration
 * spoa-mirror version
 * spoa-mirror configuration
 * If possible, info about the mirror requests


--
Christopher Faulet

[PATCH] MINOR: ssl: add "ca-no-names-file" directive

[Emmanuel Hocdet]

rebase from dev branch:(https://github.com/haproxy/haproxy/issues/404)++ManuLe 20 déc. 2019 à 17:00, Emmanuel Hocdet  a écrit :patch update,Le 19 déc. 2019 à 17:08, Emmanuel Hocdet  a écrit :With this proposition, ca-root-file should be rename to something like ca-end-file.Refer to https://github.com/haproxy/haproxy/issues/404 discussion.Le 19 déc. 2019 à 13:10, Emmanuel Hocdet  a écrit :Hi,The purpose of this patch is to fix #404 and keep compatibility with actual"ca-file » directive for bind line.

0001-MINOR-ssl-add-ca-no-names-file-directive.patch
Description: Binary data

interpreting haproxy 2.1 EOL statement

[Andrew McDermott]

Hi,

>From the following:

  $ ~/git.haproxy.org/haproxy-2.1/haproxy  -v
  HA-Proxy version 2.1.3-ce757f-13 2020/02/21 - https://haproxy.org/
  Status: stable branch - will stop receiving fixes around Q1 2021.
  Known bugs: http://www.haproxy.org/bugs/bugs-2.1.3.html

that EOL is around Q1 2021.

Broadly, when is that? Jan-March 2021?

TIA

mirroragent (haproxy)

[Tuktamyshev Ainur]

Dear, Collegues.

There was a problem when mirroring traffic through Haproxy.

In our spoa-mirror logs next mistakes: 
[ 0][0.000600] --- start --- 2020-03-03 15:48:30 -
[ 1][  318.942594]   <1:26> (E) Failed to receive frame data: Stale file handle
[ 2][  416.600422]   <2:26> (E) Failed to send frame length: Broken pipe
[ 8][  698.488390]   <8:29> (E) Failed to send frame length: Broken pipe
[ 5][  698.677793]   <5:26> (E) Failed to send frame length: Broken pipe
[ 9][  698.871186]   <9:30> (E) Failed to send frame length: Broken pipe
[ 7][  699.071718]   <7:28> (E) Failed to send frame length: Broken pipe
[10][  699.391399]   <10:31> (E) Failed to send frame length: Broken pipe
[ 6][  699.585724]   <6:27> (E) Failed to send frame length: Broken pipe
[ 1][  699.791090]   <11:32> (E) Failed to send frame length: Broken pipe

Haproxy version: "HA-Proxy version 2.1.0 2019/11/25"

Can you help with this?
If necessary, provide additional information.


-- 
Best regards.
Tuktamyshev A.N.
ph. +7-965-243-99-81

Re: Let's Encrypt ca-file for check-ssl on server line

[Aleksandar Lazic]

Hi all.

Thanks for help.

Regards
Aleks

On 02.03.20 23:25, Tim Düsterhus wrote:

Aleks,

Am 02.03.20 um 23:19 schrieb Aleksandar Lazic:

I think I found the solution.

```
curl -vO https://letsencrypt.org/certs/isrgrootx1.pem.txt
curl -vo https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem.txt
curl -vO https://letsencrypt.org/certs/letsencryptauthorityx3.pem.txt
cat letsencryptauthorityx3.pem.txt lets-encrypt-x3-cross-signed.pem.txt
isrgrootx1.pem.txt > /etc/haproxy/letsencryptauthorityx3.pem
```

Now the server line is this.

```
server static_stor storage.sbg.cloud.ovh.net:443 resolvers mydns check
check-ssl check-sni storage.sbg.cloud.ovh.net sni
str(storage.sbg.cloud.ovh.net) ca-file
/etc/haproxy/letsencryptauthorityx3.pem backup

```

No more SSL Handshake errors.



Yes. The certificate chain OVH uses is the one chaining to IdenTrust
(DST), not the one to ISRG. You can easily check this by looking up the
TLS details within your favorite web browser.

Best regards
Tim Düsterhus