unsubscribe

[Jessie P]

unsubscribe

unsubscribe

[Zhongbao Nie]

unsubscribe



***  Please note that this message and any attachments may contain confidential 
and proprietary material and information and are intended only for the use of 
the intended recipient(s). If you are not the intended recipient, you are 
hereby notified that any review, use, disclosure, dissemination, distribution 
or copying of this message and any attachments is strictly prohibited. If you 
have received this email in error, please immediately notify the sender and 
destroy this e-mail and any attachments and all copies, whether electronic or 
printed. Please also note that any views, opinions, conclusions or commitments 
expressed in this message are those of the individual sender and do not 
necessarily reflect the views of Fortinet, Inc., its affiliates, and emails are 
not binding on Fortinet and only a writing manually signed by Fortinet's 
General Counsel can be a binding commitment of Fortinet to Fortinet's customers 
or partners. Thank you. *** 

unsubscrib

[Zhongbao Nie]

unsubscrib



***  Please note that this message and any attachments may contain confidential 
and proprietary material and information and are intended only for the use of 
the intended recipient(s). If you are not the intended recipient, you are 
hereby notified that any review, use, disclosure, dissemination, distribution 
or copying of this message and any attachments is strictly prohibited. If you 
have received this email in error, please immediately notify the sender and 
destroy this e-mail and any attachments and all copies, whether electronic or 
printed. Please also note that any views, opinions, conclusions or commitments 
expressed in this message are those of the individual sender and do not 
necessarily reflect the views of Fortinet, Inc., its affiliates, and emails are 
not binding on Fortinet and only a writing manually signed by Fortinet's 
General Counsel can be a binding commitment of Fortinet to Fortinet's customers 
or partners. Thank you. *** 

[PATCH] BUG/MEDIUM: Fix RFC5077 resumption when more than TLS_TICKETS_NO are present

[Nenad Merdanovic]

Olivier Doucet reported the issue on the ML and tested that when using
more than TLS_TICKETS_NO keys in the file, the CPU usage is much higeher
than expected.

Lukas Tribus then provided a test case which showed that resumption doesn't
work at all in that case.

This fix needs to be backported to 1.6.

Signed-off-by: Nenad Merdanovic 
---
 src/ssl_sock.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/ssl_sock.c b/src/ssl_sock.c
index 1017388..994cdcc 100644
--- a/src/ssl_sock.c
+++ b/src/ssl_sock.c
@@ -5406,8 +5406,8 @@ static int bind_parse_tls_ticket_keys(char **args, int 
cur_arg, struct proxy *px
fclose(f);
 
/* Use penultimate key for encryption, handle when TLS_TICKETS_NO = 1 */
-   i-=2;
-   keys_ref->tls_ticket_enc_index = i < 0 ? 0 : i;
+   i -= 2;
+   keys_ref->tls_ticket_enc_index = i < 0 ? 0 : i % TLS_TICKETS_NO;
keys_ref->unique_id = -1;
conf->keys_ref = keys_ref;
 
-- 
2.7.0

Re: Weird stick-tables / peers behaviour

[Willy Tarreau]

On Fri, Mar 25, 2016 at 01:53:50PM +0100, Willy Tarreau wrote:
> I think it's even different (but could be wrong) since Christian spoke
> about counters suddenly doubling. The issue you faced Sylvain which I
> still have no idea how to fix unfortunately is that the peers applet
> is not always woken up when a connection establishes on the other side
> and it may simply miss an event, resulting in everything remaining
> stable and appear frozen until the connection closes. Here it seems
> data are exchanged but incorrect. This one could be easier to reproduce
> however, we'll check.

OK I found it. Indeed it was easy to reproduce. The frequency counters
are sent as "now - freq.date", which is a positive age compared to the
current date. But on receipt, this age was *added* to the current date
instead of subtracted. So since the date was always in the future, they
were always expired if the activity changed side in less than the
counter's measuring period (eg: 10s).

I'm commiting this simple fix that you can apply to your tree for now.

Cheers,
Willy

diff --git a/src/peers.c b/src/peers.c
index c29ea73..9918dac 100644
--- a/src/peers.c
+++ b/src/peers.c
@@ -1153,7 +1153,7 @@ switchstate:
case 
STD_T_FRQP: {

struct freq_ctr_period data;
 
-   
data.curr_tick = tick_add(now_ms, intdecode(_cur, msg_end));
+   
data.curr_tick = tick_add(now_ms, -intdecode(_cur, msg_end));

if (!msg_cur) {

/* malformed message */

appctx->st0 = PEER_SESS_ST_ERRPROTO;

Re: TLS Tickets and CPU usage

[Willy Tarreau]

On Fri, Mar 25, 2016 at 03:43:31PM +0100, Nenad Merdanovic wrote:
> Hello Willy,
> 
> On 03/25/2016 03:29 PM, Nenad Merdanovic wrote:
> [..snip..]
> 
> Ah, just ignore this :) I've now realized what you meant.

:-)

> Sure, I'll
> rewrite the patch like that. To me it doesn't make much difference in
> readability and they do accomplish the same purpose, so we can do it as
> you prefer.

The difference for me is that in one case I have to open the C file
to check if "i" is signed or unsigned to estimate the range of the
resulting modulo while in the other case I know that it's only applied
to a positive value so it's positive by definition. In your case the
code was protected at the next line so it was OK (and confirmed by the
two testers), but once people pick a few lines there and reuse them
somewhere else it's a different story. Or if they are simply inspired
they might not get this important detail.

So it's not a matter of strict preference, just less ambiguity or
doubt when reading a patch or a small portion of code.

Also modulos are commonly used to ensure a number is between 0 and N-1
as often used in maths, but that's clearly not how computers use them,
instead they only take the reminder of the divide operation, and it's
common when reading such code to make the wrong assumption. How many of
us have seen apparently harmless but exploitable functions like this :

 char hex_digit(int v) {
 return hextab[v % 16];
 }

or even :

 char base_digit(int v, int base) {
 return base ? base36_tab[v % base] : 0;
 }

That's why I tend to be extra careful where there's a risk it could be
overlooked.

Cheers,
Willy

Re: TLS Tickets and CPU usage

[Nenad Merdanovic]

Hello Willy,

On 03/25/2016 03:29 PM, Nenad Merdanovic wrote:
[..snip..]

Ah, just ignore this :) I've now realized what you meant. Sure, I'll
rewrite the patch like that. To me it doesn't make much difference in
readability and they do accomplish the same purpose, so we can do it as
you prefer.

Regards,
Nenad

Re: TLS Tickets and CPU usage

[Nenad Merdanovic]

Hello Willy,

On 03/25/2016 01:37 PM, Willy Tarreau wrote:
> Hi Nenad,
> 
> On Fri, Mar 25, 2016 at 11:35:01AM +0100, Nenad Merdanovic wrote:
>> diff --git a/src/ssl_sock.c b/src/ssl_sock.c
>> index 1017388..767d6e9 100644
>> --- a/src/ssl_sock.c
>> +++ b/src/ssl_sock.c
>> @@ -5406,7 +5406,7 @@ static int bind_parse_tls_ticket_keys(char **args, int 
>> cur_arg, struct proxy *px
>>  fclose(f);
>>  
>>  /* Use penultimate key for encryption, handle when TLS_TICKETS_NO = 1 */
>> -i-=2;
>> +i = (i - 2) % TLS_TICKETS_NO;
>>  keys_ref->tls_ticket_enc_index = i < 0 ? 0 : i;
> 
> I'm still seeing an issue here which is that i is an integer so
> (i - 2) % TLS_TICKETS_NO will be negative for values of i between
> 0 and 1.
> 

Right, but this is covered with:
keys_ref->tls_ticket_enc_index = i < 0 ? 0 : i;

It can only happen in one case, if TLS_TICKET_NO = 1 (build time) and
there is only one key in the file (i = 1). There are explicit checks for
other cases:
#if (defined SSL_CTRL_SET_TLSEXT_TICKET_KEY_CB && TLS_TICKETS_NO > 0)

and

if (i < TLS_TICKETS_NO) {
if (err)
memprintf(err, "'%s' : please supply at least %d
keys in the tls-tickets-file", args[cur_arg+1], TLS_TICKETS_NO);
return ERR_ALERT | ERR_FATAL;
}

The ternary operator here covers the case where the result is negative
and sets the index to 0 (which is the only key we have).

> If this is intended, then maybe it would be better do fix it this way
> instead so that there's no ambiguity regarding the validity of the
> above operation :
> 
> - keys_ref->tls_ticket_enc_index = i < 0 ? 0 : i;
> + keys_ref->tls_ticket_enc_index = i < 0 ? 0 : i % TLS_TICKETS_NO;
> 

I am afraid this would do the unwanted, because i % TLS_TICKET_NO, as
you said, can be negative, and we'd have a negative index being used as
an array index:
head =
objt_listener(conn->target)->bind_conf->keys_ref->tls_ticket_enc_index;
memcpy(key_name, keys[head].name, 16);


> What do you think ?
> 
> Thanks,
> Willy
> 

I might've missed something, but I think the fix should be as-is, but
please do not commit it yet, I need to do some more testing.

Regards,
Nenad

Re: TLS Tickets and CPU usage

[Olivier Doucet]

2016-03-25 11:35 GMT+01:00 Nenad Merdanovic :

> Hey Olivier,
>
> Can you try the attached patch? I need to run some more tests, but I
> think this should fix it.
>

A summary of all tests performed :
WITHOUT PATCH:

With 0 ticket in file : HAProxy refuse to start " '/tmp/tls_ticket_keys' :
please supply at least 3 keys in the tls-tickets-file"
With 1 ticket in file : HAProxy refuses to start (same)
With 2 tickets in file : HAProxy refuses to start (same)
With 3 tickets in file : working as expected (reuse OK)
With 4 tickets in file : working as expected (reuse OK)
With 5 tickets in file : no more session reuse

WITH PATCH
"0001-BUG-MEDIUM-Fix-RFC5077-resumption-when-more-than-TLS.patch" :
With 0 ticket in file : HAProxy refuse to start " '/tmp/tls_ticket_keys' :
please supply at least 3 keys in the tls-tickets-file"
With 1 ticket in file : HAProxy refuses to start (same)
With 2 tickets in file : HAProxy refuses to start (same)
With 3 tickets in file : working as expected (reuse OK)
With 4 tickets in file : working as expected (reuse OK)
With 5 tickets in file : working as expected (reuse OK)
With 6 tickets in file : working as expected (reuse OK)


Many thanks to you all, and to Vincent Bernat for the tool rfc5077-client

Olivier




> Regards,
> Nenad
>
> On 3/24/2016 10:05 PM, Olivier Doucet wrote:
> > Hi again,
> >
> >
> > 2016-03-24 21:15 GMT+01:00 Lukas Tribus  > >:
> >
> > Hi Nenad,
> >
> >
> > >> Well, its not supposed to look like this, there is clearly
> something
> > >> wrong. Master key fluctuates between the requests with TLS tickets
> > >> and the reuse collumn shows failure.
> > >
> > > Looks like a haproxy bug, I think I can reproduce it.
> > >
> > > Can you try with EXACTLY 3 keys in /tmp/tls_ticket_keys?
> >
> >
> > Tried and now behaviour is like expected !
> > https://gist.github.com/anonymous/779fbc4f1cf8b23e9b1f
> >
> > And, I can confirm that now, CPU is not doubled \o/
> >
> >
> >
> >
> >
> > there seems to be a bug in the handling of the tls-ticket-keys file.
> >
> > When there are 5 or more ticket keys in the file, clients using TLS
> > tickets
> > can no longer resume the TLS session (and fallback to full
> negotiation):
> >
> > https://gist.github.com/anonymous/6ec7c863f497cfd849a4
> >
> >
> > Workaround would be to remove the oldest key from the file, so
> > that the number of keys in the file remains below 5.
> >
> > That's what I did : keep last 2 keys and add a new one.
> >
> >  Olivier
>

Re: servers multiple sources

[Willy Tarreau]

On Tue, Mar 22, 2016 at 11:16:04AM +0100, Beluc wrote:
> well, it's can become a real mess with lot of server and source :)

No because you just have to assign a source range to your loopback and
use all this range for all your servers. James is right. There's no way
you'll establish more than 64k connections to a same target from a
single source. Note that a trick also consists in having multiple
addresses (or ports) on your servers so that you can establish more
connections, but it often ends up eating many more addresses than
by having the aliases on the load balancer.

Willy

Re: Haproxy and FastCGI sockets

[Willy Tarreau]

Hello Stojan,

On Thu, Mar 24, 2016 at 08:25:02PM +0100, Stojan Ran??i?? wrote:
> Hello,
> 
> we're using Haproxy  1.5.5-1 to load balance traffic between frontentds
> running Lighttpd with mod_FastCGI and backends running a custom Perl app,
> based on FastCGI. Traffic between front and backends is not http - frontends
> open a socket to the VIP, and thus communicate to the backends.
> 
> The problem occurs when we restart haproxy due to config changes, as the
> frontend doesn't know the socket has closed, and starts throwing errors.

Why do you say it doesn't know the socket has closed ? The message is
explicit, it's notified by a FIN, receives a POLLHUP event, performs a
read() returning zero and must close on its side. It's hard to be more
explicit.

> After restarting Lighty on the frontends, everything works fine again.

You probably have to check if there's something in its configuration
making use of connection pools and to bypass the sanity checks before
reusing an idle connection. Clearly there's something abnormal here,
because I cannot believe that a FastCGI frontend needs to be restarted
if one of the backend dies. Imagine if you had to restart haproxy each
time a backend server restarts!

> The question is - can Haproxy handle such restarts in a better way, or is
> this the only way?

No, just like any process being restarted or dying.

Regards,
Willy

Re: SO_REUSEPORT and process load distribution

[Willy Tarreau]

Hi Conrad,

On Thu, Mar 24, 2016 at 08:40:40AM +0100, Conrad Hoffmann wrote:
> Hello,
> 
> I know SO_REUSEPORT has been discussed here a few times and I am aware that
> haproxy uses it to make restarts less disruptive, as a new instance can
> bind() to the listen ports without the need to stop the old instance first.
> 
> But there is another aspect of SO_REUSEPORT that I have not yet seen
> discussed here (my apologies if I missed this, pointers welcome). The
> original patch for SO_REUSEPORT [1] explicitly mentions an uneven
> distribution across threads/processes for the "accept on a single
> listener socket from multiple threads" case, which the author intended to
> get rid of with SO_REUSEPORT. What I have so far never seen a detailed
> explanation of, though, is what the exact criteria are to get this to work.
> 
> We always have and still are seeing this uneven distribution in our haproxy
> processes (haproxy 1.6, linux 3.16). My assumption is that this is because
> we use haproxy in daemon mode, which (I think) basically means that when a
> reload happens, one process is started, it binds all the sockets (using
> SO_REUSEPORT, which lets it take over sockets from the previous instance),
> but then fork()s the child processes, which thus inherit the already bound
> socket(s).

There are two aspects of SO_REUSEPORT that you're mixing here in fact. The
first goal is to allow a new process to bind before the old one unbinds.
That offers seamless reload operations.

The second aspect is that SO_REUSEPORT as it was reimplemented in kernel 3.9
additionally provides incoming connection load balancing across all listening
sockets. But for this to work you need multiple sockets, so it's not one
socket forked and inherited by all the children which will get this load
balancing. You nede each one to perform an independant bind().

That's why for people who need to implement this in haproxy, we recommend to
simply declare multiple "bind" lines each with a different process mapping.
Eg:

   frontend foo
   bind :80 process 1
   bind :80 process 2
   bind :80 process 3
   bind :80 process 4

This way you really have 4 different sockets and the kernel will distribute
the load between them.

> My gut feeling - but I cannot point to any reliable reference - is that the
> even load distribution mecahnism only kicks in if all processes do the call
> to at least bind(), possibly listen() or even socket() themselves. Just
> setting SO_REUSEPORT but otherwise using the "accept on a single
> listener socket from multiple threads" might not actually reap the intended
> benefits here.

That's absolutely true.

> So my question is basically: do I understand this situation correctly? Can
> someone who is more experienced with the kernel networking code comment on
> this aspect of SO_REUSEPORT?

There's nothing to add here, I guess overall you got most of it. There are
regularly some threads on the netdev mailing list on this subject (and one at
this very moment). The load balancing aspect is moving away from SO_REUSEPORT
to BPF instead and we'll have to estimate how to use it to allow a process to
stop receiving without impacting other processes.

If you need more info, you can easily strace haproxy in multi-process mode,
you'll see how it does the socket(), bind(), listen(), fork() and of course
setsockopt(). You'll see that it starts as many sockets as needed before
forking and that only after forking it closes the ones that do not belong
to certain processes anymore.

Cheers,
Willy

Re: Exchange 2013 / NTLM Connections

[Willy Tarreau]

On Thu, Mar 24, 2016 at 01:27:59PM +0100, Baptiste wrote:
> Hi Graham,
> 
> The http-keep-alive mode is recommended, with the "option
> prefer-last-server" (which should be implicitly set by HAProxy in your
> case).
> Hopefully you're not using the http-reuse option.

FWIW, http-reuse correctly deals with 401/407, the connections are
marked private and are never shared.

Willy

Re: Weird stick-tables / peers behaviour

[Willy Tarreau]

On Fri, Mar 25, 2016 at 09:28:32AM +0100, Sylvain Faivre wrote:
> On 03/24/2016 04:07 PM, Christian Ruppert wrote:
> >Hi all,
> >
> >I've just upgraded some hosts to 1.6.4 (from 1.5) and immediately got a
> >
> [...]
> >
> >and two for doing some "curl -Lvs http://127.0.0.1:8080; by hand.
> >If you do some on the first and some on the second host you'll notice
> >different values on one side. Also the counter may e.g. double while the
> >other side has the correct/actual value. This results into several
> >thousands of requests on our prod. systems but according to the logs it
> >can't be correct.
> >Does anybody else have similar weirdness or can you guys confirm false
> >values?
> >The *_cnt values seem to be ok but the *_rate ones seem to be false in
> >some cases.
> >
> 
> Hi,
> 
> This is a know bug in the 1.6 series.
> Willy spoke about it in a few posts on this list.
> It is not fixed yet.

I think it's even different (but could be wrong) since Christian spoke
about counters suddenly doubling. The issue you faced Sylvain which I
still have no idea how to fix unfortunately is that the peers applet
is not always woken up when a connection establishes on the other side
and it may simply miss an event, resulting in everything remaining
stable and appear frozen until the connection closes. Here it seems
data are exchanged but incorrect. This one could be easier to reproduce
however, we'll check.

Best regards,
Willy

Re: Weird stick-tables / peers behaviour

[Willy Tarreau]

Hi Lukas,

On Thu, Mar 24, 2016 at 04:20:34PM +0100, Lukas Tribus wrote:
> > Hi all,
> >
> > I've just upgraded some hosts to 1.6.4 (from 1.5) and immediately got a
> > bunch of SMS because we're using stick-tables to track the connections
> > and monitor http_req_rate. The stick-tables data will be synced to the
> > other peers using the "peers" section.
> 
> Possibly related to the ML thread "src_get_gpc0 seems not to work after
> commit f71f6f6" (but I didn't look into the details).

It seems different in fact. The other one is related to the test for
smp->strm == NULL which affects only "tcp-request connection" rules.

Willy

Re: src_get_gpc0 seems not to work after commit f71f6f6

[Willy Tarreau]

Hi,

On Wed, Mar 23, 2016 at 04:40:24PM +0900, Sehoon Kim wrote:
> Hi,
> 
> As below, I use stick-table for temporary acl.
> After commit f71f6f6, src_get_gpc0 seems not to work.
> 
> So, I revert commit f71f6f6, and it works!!

(...)
> tcp-request connection accept if { src_get_gpc0(whitelist) eq 1 }

Aie, you're definitely right, I broke it with this fix :-(
So I'll have to modify it to move some of the controls elsewhere.
I was fooled by the code being located in stream.c and still being
able to be called with no valid stream :-/ It seems it will be time
to move some parts again.

I'll work on a fix, thanks for reporting this and sorry for the mess :-(

Willy

Re: TLS Tickets and CPU usage

[Willy Tarreau]

Hi Nenad,

On Fri, Mar 25, 2016 at 11:35:01AM +0100, Nenad Merdanovic wrote:
> diff --git a/src/ssl_sock.c b/src/ssl_sock.c
> index 1017388..767d6e9 100644
> --- a/src/ssl_sock.c
> +++ b/src/ssl_sock.c
> @@ -5406,7 +5406,7 @@ static int bind_parse_tls_ticket_keys(char **args, int 
> cur_arg, struct proxy *px
>   fclose(f);
>  
>   /* Use penultimate key for encryption, handle when TLS_TICKETS_NO = 1 */
> - i-=2;
> + i = (i - 2) % TLS_TICKETS_NO;
>   keys_ref->tls_ticket_enc_index = i < 0 ? 0 : i;

I'm still seeing an issue here which is that i is an integer so
(i - 2) % TLS_TICKETS_NO will be negative for values of i between
0 and 1.

If this is intended, then maybe it would be better do fix it this way
instead so that there's no ambiguity regarding the validity of the
above operation :

-   keys_ref->tls_ticket_enc_index = i < 0 ? 0 : i;
+   keys_ref->tls_ticket_enc_index = i < 0 ? 0 : i % TLS_TICKETS_NO;

What do you think ?

Thanks,
Willy

RE: TLS Tickets and CPU usage

[Lukas Tribus]

> Hey Olivier,
>
> Can you try the attached patch? I need to run some more tests, but I
> think this should fix it.

It definitely fixes the test case here.


thanks,

Lukas

  

RE: SSL Cipher stats

[Stefan Johansson]

Thanks for your suggestion, sorry for the late reply.

I gave it some thought and we decided to simply just shut SSLv3 and RC4 off 
completely right away.
We were going to use the stats to check how much traffic would be lost, but we 
managed to get browser statistics elsewhere, which pointed to less than 1% 
(Windows XP etc).

So basically there's no reason to run those any longer.

Cheers.


-Original Message-
From: Chad Lavoie [mailto:clav...@haproxy.com] 
Sent: Tuesday, March 8, 2016 9:45 PM
To: haproxy@formilux.org
Cc: Jeff Palmer ; Stefan Johansson 

Subject: Re: SSL Cipher stats

Greetings,

On 03/08/2016 11:20 AM, Jeff Palmer wrote:
> I too would be interested in this.
>
> extra points if the info could be gathered for individual backends or 
> frontends.
I didn't explicitly mention it, but my example config tracks by frontend id in 
the stick table (id was 7 in my example).  If in "tcp-request content track-sc0 
fe_id() table sslv3-count if { ssl_fc }" fe_id is changed with be_id then it 
will track based on the backend instead.

To translate the id's to names looking at the iid field of "show stat" 
(to the socket as the show table is done to get the stats) will identify the 
one in question.

Also, I neglected to mention if you have nbproc >1 it won't add up the values, 
so if its important to have all of the requests processed adding them up via a 
shell script should be able to do that.

- Chad
>
>
>
> On Tue, Mar 8, 2016 at 11:18 AM, Stefan Johansson 
>  wrote:
>> Hi,
>>
>>
>>
>> is it possible somehow to extract statistics on cipher used (total 
>> SSLv3, total RC4 etc.) without necessarily turning on connection 
>> logging and extract the data from there?
>>
>>
>>
>> Thank you.
>>
>>
>>
>> Regards,
>>
>> Stefan
>
>

Re: servers multiple sources

[Aleksandar Lazic]

Hi.

Am 25-03-2016 11:05, schrieb Beluc:

Hi,
@James Brown : sure ;)

I configure a server to use source a.b.c.d:1-6 and I got
"Connect() failed for backend abcd: no free ports."

Maybe a problem with kernel I use ...


or the range is not high enough

http://www.tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3/chap6sec70.html

what shows a

cat /proc/sys/net/ipv4/ip_local_port_range

or

sysctl -a|egrep ip_local_port_range

BR Aleks


Regards,

2016-03-22 18:45 GMT+01:00 James Brown :
Templating out (or entirely-procedurally-generating) your HAproxy 
config

file is a must once you exceed the bare minimum of complexity. :-)

Best of luck!

On Tue, Mar 22, 2016 at 3:16 AM, Beluc  wrote:


well, it's can become a real mess with lot of server and source :)
but sure, it works !

2016-03-21 19:21 GMT+01:00 James Brown :
> Why not just add each server multiple times with a different src
> parameter
> and a different name.
>
> Something like
>
> backend my_be
> mode tcp
> server server1_src1 10.1.0.1 source 10.0.0.1
> server server1_src2 10.1.0.1 source 10.0.0.2
> server server2_src1 10.1.0.2 source 10.0.0.1
> server server2_src2 10.1.0.2 source 10.0.0.2
>
> On Mon, Mar 21, 2016 at 8:20 AM, Beluc  wrote:
>>
>> Hi,
>>
>> We're trying to find a way to have multiple sources per server and
>> thus bypass 64k connections per server.
>>
>> We already tried with SNAT iptables :
>> iptables -t nat -A POSTROUTING -o eth2 -j SNAT --to 10.0.0.1-10.0.10
>>
>> without success because kernel is hashing real source ip and real
>> destination ip, so only one source ip nated is used (aka same as using
>> one different source per server).
>>
>> Any idea on achieving this ? maybe in lua ?
>>
>> Regards,
>>
>
>
>
> --
> James Brown
> Engineer





--
James Brown
Engineer

Re: TLS Tickets and CPU usage

[Nenad Merdanovic]

Hey Olivier,

Can you try the attached patch? I need to run some more tests, but I
think this should fix it.

Regards,
Nenad

On 3/24/2016 10:05 PM, Olivier Doucet wrote:
> Hi again,
> 
> 
> 2016-03-24 21:15 GMT+01:00 Lukas Tribus  >:
> 
> Hi Nenad,
> 
> 
> >> Well, its not supposed to look like this, there is clearly something
> >> wrong. Master key fluctuates between the requests with TLS tickets
> >> and the reuse collumn shows failure.
> >
> > Looks like a haproxy bug, I think I can reproduce it.
> >
> > Can you try with EXACTLY 3 keys in /tmp/tls_ticket_keys?
> 
> 
> Tried and now behaviour is like expected !
> https://gist.github.com/anonymous/779fbc4f1cf8b23e9b1f
> 
> And, I can confirm that now, CPU is not doubled \o/
> 
> 
> 
>  
> 
> there seems to be a bug in the handling of the tls-ticket-keys file.
> 
> When there are 5 or more ticket keys in the file, clients using TLS
> tickets
> can no longer resume the TLS session (and fallback to full negotiation):
> 
> https://gist.github.com/anonymous/6ec7c863f497cfd849a4
> 
> 
> Workaround would be to remove the oldest key from the file, so
> that the number of keys in the file remains below 5.
> 
> That's what I did : keep last 2 keys and add a new one.
> 
>  Olivier
From 074792e61070c8fae16cd0b2fae4dfb6e6eeff7a Mon Sep 17 00:00:00 2001
From: Nenad Merdanovic 
Date: Fri, 25 Mar 2016 11:14:43 +0100
Subject: [PATCH] BUG/MEDIUM: Fix RFC5077 resumption when more than
 TLS_TICKETS_NO are present

Olivier Doucet reported the issue on the ML and tested that when using
more than TLS_TICKETS_NO keys in the file, the CPU usage is much higeher
than expected.

Lukas Tribus then provided a test case which showed that resumption doesn't
work at all in that case.

This fix needs to be backported to 1.6.

Signed-off-by: Nenad Merdanovic 
---
 src/ssl_sock.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/ssl_sock.c b/src/ssl_sock.c
index 1017388..767d6e9 100644
--- a/src/ssl_sock.c
+++ b/src/ssl_sock.c
@@ -5406,7 +5406,7 @@ static int bind_parse_tls_ticket_keys(char **args, int 
cur_arg, struct proxy *px
fclose(f);
 
/* Use penultimate key for encryption, handle when TLS_TICKETS_NO = 1 */
-   i-=2;
+   i = (i - 2) % TLS_TICKETS_NO;
keys_ref->tls_ticket_enc_index = i < 0 ? 0 : i;
keys_ref->unique_id = -1;
conf->keys_ref = keys_ref;
-- 
2.7.0

Re: servers multiple sources

[Beluc]

Hi,
@James Brown : sure ;)

I configure a server to use source a.b.c.d:1-6 and I got
"Connect() failed for backend abcd: no free ports."

Maybe a problem with kernel I use ...

Regards,

2016-03-22 18:45 GMT+01:00 James Brown :
> Templating out (or entirely-procedurally-generating) your HAproxy config
> file is a must once you exceed the bare minimum of complexity. :-)
>
> Best of luck!
>
> On Tue, Mar 22, 2016 at 3:16 AM, Beluc  wrote:
>>
>> well, it's can become a real mess with lot of server and source :)
>> but sure, it works !
>>
>> 2016-03-21 19:21 GMT+01:00 James Brown :
>> > Why not just add each server multiple times with a different src
>> > parameter
>> > and a different name.
>> >
>> > Something like
>> >
>> > backend my_be
>> > mode tcp
>> > server server1_src1 10.1.0.1 source 10.0.0.1
>> > server server1_src2 10.1.0.1 source 10.0.0.2
>> > server server2_src1 10.1.0.2 source 10.0.0.1
>> > server server2_src2 10.1.0.2 source 10.0.0.2
>> >
>> > On Mon, Mar 21, 2016 at 8:20 AM, Beluc  wrote:
>> >>
>> >> Hi,
>> >>
>> >> We're trying to find a way to have multiple sources per server and
>> >> thus bypass 64k connections per server.
>> >>
>> >> We already tried with SNAT iptables :
>> >> iptables -t nat -A POSTROUTING -o eth2 -j SNAT --to 10.0.0.1-10.0.10
>> >>
>> >> without success because kernel is hashing real source ip and real
>> >> destination ip, so only one source ip nated is used (aka same as using
>> >> one different source per server).
>> >>
>> >> Any idea on achieving this ? maybe in lua ?
>> >>
>> >> Regards,
>> >>
>> >
>> >
>> >
>> > --
>> > James Brown
>> > Engineer
>
>
>
>
> --
> James Brown
> Engineer

Re: Weird stick-tables / peers behaviour

[Sylvain Faivre]

On 03/24/2016 04:07 PM, Christian Ruppert wrote:

Hi all,

I've just upgraded some hosts to 1.6.4 (from 1.5) and immediately got a


[...]


and two for doing some "curl -Lvs http://127.0.0.1:8080; by hand.
If you do some on the first and some on the second host you'll notice
different values on one side. Also the counter may e.g. double while the
other side has the correct/actual value. This results into several
thousands of requests on our prod. systems but according to the logs it
can't be correct.
Does anybody else have similar weirdness or can you guys confirm false
values?
The *_cnt values seem to be ok but the *_rate ones seem to be false in
some cases.



Hi,

This is a know bug in the 1.6 series.
Willy spoke about it in a few posts on this list.
It is not fixed yet.

Regards.
Sylvain

Re: using use_backend rules with map files

[Thierry FOURNIER]

Hi,

When use_backend is choosed, the evaluation of other use_backend
conditions stops. Your configuration just miss a test like this:

   acl test_path path,map_beg(/etc/haproxy/path2backends.map) -m bool true

   use_backend bk_%[path,map_beg(/etc/haproxy/path2backends.map)] if test_path
   use_backend 
bk_%[req.hdr(host),lower,map(/etc/haproxy/host2backends.map,stats)]

Thierry

On Wed, 16 Mar 2016 23:32:34 +0100
Michael Rennecke  wrote:

> Hello,
> 
> is it possible use use_backend rules with map files multiple times in
> one frontend? My small example don't work. HAProxy returns 503, if no
> match in the first map file. it would be great, if HAProxy can continue
> the processing of the request.
> 
> Regards,
> Michael
> 
> global
> log /dev/loglocal0
> log /dev/loglocal1 notice
> 
> 
> defaults
> mode http
> timeout connect 5s
> timeout client 15s
> timeout server 15s
> 
> 
> frontend http-in
> bind :8080
> 
> use_backend bk_%[path,map_beg(/etc/haproxy/path2backends.map)]
> use_backend
> bk_%[req.hdr(host),lower,map(/etc/haproxy/host2backends.map,stats)]
> 
> 
> backend bk_stats
> stats enable
> stats show-legends
> stats realm Haproxy\ Statistics
> stats uri /
> stats refresh 30s
> 
> 
> backend bk_host1
> server a1 127.0.0.1:9001
> 
> 
> backend bk_host2
> server a2 127.0.0.1:9002
> 
> 
> backend bk_path1
> server a3 127.0.0.1:9003
> 
> 
> backend bk_path2
> server a4 127.0.0.1:9004
> 


--