How to rewirte both URI and Host
Hi Willy, If I want to rewrite both Host and URI in request, and they are also in the match conditions, can HAProxy implement this requirement? The ACLs are as below: acl match_host_uri hdr_reg(Host) www.example.com ack match_host_uri /example.html But the reqrep should be used twice to rewrite both Host and URI reqrep expresion for rewritting host if match_host_uri reqrep expresion for rewritting URI if match_host_uri Since Host has been rewritten in firest reqrep directive, as I know, the second reqrep will not be executed as the match will fail. -- Best Regards, Godbach
Re: How to rewirte both URI and Host
Hi Godbach, On Tue, May 13, 2014 at 03:01:58PM +0800, Godbach wrote: Hi Willy, If I want to rewrite both Host and URI in request, and they are also in the match conditions, can HAProxy implement this requirement? The ACLs are as below: acl match_host_uri hdr_reg(Host) www.example.com ack match_host_uri /example.html But the reqrep should be used twice to rewrite both Host and URI reqrep expresion for rewritting host if match_host_uri reqrep expresion for rewritting URI if match_host_uri Since Host has been rewritten in firest reqrep directive, as I know, the second reqrep will not be executed as the match will fail. Indeed. The trick consists in capturing it using capture request header then apply your rule based on capture.req.hdr(), since this one will not change during the request. Regards, Willy
Re: How to rewirte both URI and Host
On 2014/5/13 15:05, Willy Tarreau wrote: Hi Godbach, On Tue, May 13, 2014 at 03:01:58PM +0800, Godbach wrote: Hi Willy, If I want to rewrite both Host and URI in request, and they are also in the match conditions, can HAProxy implement this requirement? The ACLs are as below: acl match_host_uri hdr_reg(Host) www.example.com ack match_host_uri /example.html But the reqrep should be used twice to rewrite both Host and URI reqrep expresion for rewritting host if match_host_uri reqrep expresion for rewritting URI if match_host_uri Since Host has been rewritten in firest reqrep directive, as I know, the second reqrep will not be executed as the match will fail. Indeed. The trick consists in capturing it using capture request header then apply your rule based on capture.req.hdr(), since this one will not change during the request. Regards, Willy Hi Willy, Thank you. Yes, there are some more caputre and fetch configurations about request and response introduced in recent releases. I can capture any header I and URI I need, then do the match base on the capture content. The requirement can be fulfilled with these new features. Great job. -- Best Regards, Godbach
Re: How to rewirte both URI and Host
On 2014/5/13 16:05, Godbach wrote: On 2014/5/13 15:05, Willy Tarreau wrote: Hi Godbach, On Tue, May 13, 2014 at 03:01:58PM +0800, Godbach wrote: Hi Willy, If I want to rewrite both Host and URI in request, and they are also in the match conditions, can HAProxy implement this requirement? The ACLs are as below: acl match_host_uri hdr_reg(Host) www.example.com ack match_host_uri /example.html But the reqrep should be used twice to rewrite both Host and URI reqrep expresion for rewritting host if match_host_uri reqrep expresion for rewritting URI if match_host_uri Since Host has been rewritten in firest reqrep directive, as I know, the second reqrep will not be executed as the match will fail. Indeed. The trick consists in capturing it using capture request header then apply your rule based on capture.req.hdr(), since this one will not change during the request. Regards, Willy Hi Willy, Thank you. Yes, there are some more caputre and fetch configurations about request and response introduced in recent releases. I can capture any header I and URI I need, then do the match base on the capture content. The requirement can be fulfilled with these new features. Great juser-defined chainob. Hi Willy, There is still an issue that the ACL will be evaluated maore than one times. Is it possbile or reasonable to rewrite more than one time with only evaluating ACL once? The similar cenario like iptables to do all matches once and do more actions in user-defined chain: iptables -N NEW_CHAIN iptables -A INPUT -p tcp -s x.x.x.x -j NEW_CHAIN iptalbes -A NEW_CHAIN -j LOG iptalbes -A NEW_CHAIN -j ACCPET or we will need two rules both with need to do match as below: iptables -A INPUT -p tcp -s x.x.x.x -j LOG iptables -A INPUT -p tcp -s x.x.x.x -j ACCEPT -- Best Regards, Godbach
Encore quelques jours, Catmandoo, Rohner, Midland
GOURDE SIGG CHAUSSETTES ROHNER TEXTLE CYCLE HIGH TECH FITNESS OUTDOOR INSCRIPTION Les Frais de port sont offert* jusqu'au Dimanche 18 Mai ! *offre non valable sur les ventes privées Vêtements de golf CATMANDOO (Fournisseur officiel des équipes Finlandaises de golf et des J.O.) Jusqu'à -60% Jusqu'au Lundi 12 Mai Caméra Full HD Talkie Walki MIDLAND -30 % Jusqu'au mercredi 14 Mai Chaussettes de sport ROHNER Compression Golf à -50% Jusqu'au Mercredi 14 Mai Le plus léger des parapluies BLUNT (1100mm de diamètre pour 450g) est à -30% Jusqu'au Dimanche 11 Mai Vélo GOCYCLE à assistance électrique avec béquille centrale Les frais de ports sont offerts sans échéance pour les vélos GOCYCLE Toutes les semaines : NOUVEAUTÉS Suivez nous sur FacebookSuivez nos Newsletter Veuillez me retirer de votre liste de diffusion.
Socket Read Errors and Timeouts on FreeBSD
Hey, after all the patches regarding the SSL crashes we started pushing more traffic to haproxy but it did not last very long. With and without kqueue enabled we're seeing lots of socket errors. The backends became unavailable / unreachable as a consequence. L4 health checks failed, traffic and CPU Load dropped - so we had to abort the test. We've tried on different machines, with different backends, with different haproxy versions (1.4.18, 1.4.25. 1.5.25) and the behavior was always the same on FreeBSD. We looked at netstat and various other system statistics but the all seemed alright. Then we switched to synthetic loadtests and we observed the behavior even quicker. When pointing the loadtesttool directly to our backend, everything was fine. Testing on a linux machine was also fine. Do you have any idea what that could be related to or do you have suggestions for debugging this? Since it does not coredump it will be a bit harder I guess. Kind regards, John-Paul Bader -- John-Paul Bader | Software Development www.wooga.com wooga GmbH | Saarbruecker Str. 38 | D-10405 Berlin Sitz der Gesellschaft: Berlin; HRB 117846 B Registergericht Berlin-Charlottenburg Geschaeftsfuehrung: Jens Begemann, Philipp Moeser
can not set mss on FreeBSD 10
Hi,Lists, I found haproxy 1.4.25 can not set mss on FreeBSD 10-stable as below: # /usr/local/sbin/haproxy -f /opt/etc/haproxy.conf [WARNING] 132/170407 (71806) : Starting frontend http-in: cannot set MSS # haproxy -vv HA-Proxy version 1.4.25 2014/03/27 Copyright 2000-2014 Willy Tarreau w...@1wt.eu Build options : TARGET = freebsd CPU = generic CC = gcc47 CFLAGS = -g -Wall -O2 -pipe -msse3 -I/usr/local/include -L/usr/local/lib -fno-strict-aliasing -DFREEBSD_PORTS OPTIONS = USE_TPROXY=1 USE_PCRE=1 Default settings : maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200 Encrypted password support via crypt(3): yes Available polling systems : kqueue : pref=300, test result OK poll : pref=200, test result OK select : pref=150, test result OK Total: 3 (3 usable), will use kqueue. Regards Simon
Coredump when parsing previously working config
Hey, a config that worked fine on 1.5-dev24 now coredumps with dev25 from 2014-05-11 Config: http://smyck.org/haproxy/haproxy_coredump_cfg.txt CoreDump http://smyck.org/haproxy/config_coredump.txt Kind regards, John -- John-Paul Bader | Software Development www.wooga.com wooga GmbH | Saarbruecker Str. 38 | D-10405 Berlin Sitz der Gesellschaft: Berlin; HRB 117846 B Registergericht Berlin-Charlottenburg Geschaeftsfuehrung: Jens Begemann, Philipp Moeser
让客户主动回复询盘给你
双喜外贸客户开发软件可以帮您： 1，代替手工，提高效果（把业务员解放出来用在跟进优质客户和询盘） 2，化被动为主动，抢先同行（避开展会，B2B僧多粥少的信息不对称） 3，淘汰三流客人，和优质客人打交道（避开价格战，做有利润的订单） 4，快速成交一批订单（网足够大，总有属于您的那些订单） 5，让全球潜在买家都记住您（对全球目标客人周期主动建立联络，精准推广效 果） 6，让业务团队更稳定（业务员主动创造机会，每天有事做） 7，客户资料，往来邮件，轻松管理（客户资料集中，往来邮件自动形成联系记 录，有效辅导业务团队） 8，轻松启动外贸业务（最容易找到工作入口，NO展会，NO平台，NO手工搜索客 户） 软件演示咨询QQ：25382_09225 添加联系请删除下划线 回复请回复QQ邮箱 双喜让您知道怎么样高效找优质客户 我已邀请您填写表单 未命名的表单。 要填写此表单，请访问： https://docs.google.com/forms/d/1Toxh2WMXJWzOEqMKggrwhsNBuN12Fr4wm6O6eAF4z9I/viewform?c=0w=1usp=mail_form_link
Re: Socket Read Errors and Timeouts on FreeBSD
Hey, we have already tried and disabled all custom sysctls - the behavior was not getting any better unfortunately :/ The whole process locks up, the stats web page does not load anymore and like described, we get lots of log entries that no backends are available anymore. I could try to create a ktrace for a synthetic test run like this as it happens rather quickly after starting the test. Kind regards, John Willy Tarreau wrote: Hi John-Paul, On Tue, May 13, 2014 at 10:56:15AM +0200, John-Paul Bader wrote: Hey, after all the patches regarding the SSL crashes we started pushing more traffic to haproxy but it did not last very long. With and without kqueue enabled we're seeing lots of socket errors. The backends became unavailable / unreachable as a consequence. L4 health checks failed, traffic and CPU Load dropped - so we had to abort the test. We've tried on different machines, with different backends, with different haproxy versions (1.4.18, 1.4.25. 1.5.25) and the behavior was always the same on FreeBSD. We looked at netstat and various other system statistics but the all seemed alright. Then we switched to synthetic loadtests and we observed the behavior even quicker. When pointing the loadtesttool directly to our backend, everything was fine. Testing on a linux machine was also fine. Do you have any idea what that could be related to or do you have suggestions for debugging this? Since it does not coredump it will be a bit harder I guess. Could you please try without your sysctls ? It's very possible that too short timeouts TCP will prevent your system from re-establishing outgoing connections from a recently closed source port that was marked free while it was not for the server. Best regards, Willy -- John-Paul Bader | Software Development www.wooga.com wooga GmbH | Saarbruecker Str. 38 | D-10405 Berlin Sitz der Gesellschaft: Berlin; HRB 117846 B Registergericht Berlin-Charlottenburg Geschaeftsfuehrung: Jens Begemann, Philipp Moeser
Explain tune.maxrewrite
Hi We use haproxy at various layers in our setup. We have been seeing 504 errors in our logs and discovered that it was haproxy that sent it. On further investigation we found that on some packets we go over 8k and it is during this time that we get the 504. On further reading the haproxy docs, we made one change: tune.maxrewrite 1024 Now we dont see any of the 504 errors anymore and everything is working perfectly. After reading the docs, we decided not to implement the #tune.bufsize32768 setting as that could have more serious implications than just changing the tune.maxrewrite setting. Q1. This is really just a further explanation as to why changing tune.maxrewrite now enabled packet sizes larger than 8k? Q2. What do we change in future if we find the same issue but the packet sizes are now greater than 16k? Q3. The 8k mentioned above, is that a default setting for the header size? If not, what does the 8k refer to? Surely the packets should be reconstructed at each end and then passed on. I have posted the haproxy config we use below. global log 127.0.0.1 local0 log 127.0.0.1 local1 debug chroot /var/lib/haproxy pidfile /var/run/haproxy.pid maxconn 4096 uid 99 gid 99 daemon stats socket /var/lib/haproxy/stats #tune.bufsize32768 tune.maxrewrite 1024 defaults modehttp retries 3 option redispatch maxconn 3000 contimeout 5000 clitimeout 5 srvtimeout 5 log global option httplog option dontlognull cookie HTTP insert nocache balance roundrobin option httpclose option forwardfor option contstats stats enable option http-server-close option abortonclose option dontlog-normal timeout http-request10s timeout queue 1m timeout connect 10s timeout client 1m timeout server 1m timeout http-keep-alive 10s timeout check 10s frontend dc1ntgxlv01.domain.com_frontend bind10.11.115.116:443 ssl crt /etc/haproxy/wildcard.domain.com.pem ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS modehttp option httpclose option forwardfor reqadd X-Forwarded-Proto:\ https default_backend dc1ntgxlv01.domain.com_backend backend dc1ntgxlv01.domain.com_backend modehttp balance roundrobin cookie SERVERID insert indirect nocache httponly secure server dc1ntgaix01 dc1ntgaix01.domain.com:443 check cookie dc1ntgaix01 ssl crt /etc/haproxy/wildcard.domain.com.pem server dc1ntgaix02 dc1ntgaix02.domain.com:443 check cookie dc1ntgaix02 ssl crt /etc/haproxy/wildcard.domain.com.pem frontend dc1ntixlv01.domain.com_frontend bind10.11.115.118:443 ssl crt /etc/haproxy/wildcard.domain1.com.pem ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS modehttp option httpclose option forwardfor reqadd X-Forwarded-Proto:\ https default_backend dc1ntixlv01.domain.com_backend backend dc1ntixlv01.domain.com_backend modehttp balance roundrobin cookie SERVERID insert indirect nocache httponly secure server dc1ntiaix01 dc1ntiaix01.domain.com:443 check cookie dc1ntiaix01 ssl crt /etc/haproxy/wildcard.domain1.com.pem server dc1ntiaix02 dc1ntiaix02.domain.com:443 check cookie dc1ntiaix02 ssl crt /etc/haproxy/wildcard.domain1.com.pem frontend dc1ntgblv01.domain.com_frontend bind10.11.115.119:443 ssl crt /etc/haproxy/wildcard.domain.com.pem ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS modehttp option httpclose option forwardfor reqadd X-Forwarded-Proto:\ https default_backend dc1ntgblv01.domain.com_backend backend dc1ntgblv01.domain.com_backend modehttp balance roundrobin cookie SERVERID insert indirect nocache httponly secure server dc1ntgabs01 dc1ntgabs01.domain.com:443 check cookie dc1ntgabs01 ssl crt /etc/haproxy/wildcard.domain.com.pem server dc1ntgabs02 dc1ntgabs02.domain.com:443 check cookie dc1ntgabs02 ssl crt /etc/haproxy/wildcard.domain.com.pem frontend dc1ntgrlv01.domain.com_frontend bind10.11.115.122:443 ssl crt /etc/haproxy/wildcard.domain.com.pem
Re: Socket Read Errors and Timeouts on FreeBSD
On Tue, May 13, 2014 at 03:03:39PM +0200, John-Paul Bader wrote: Hey, we have already tried and disabled all custom sysctls - the behavior was not getting any better unfortunately :/ The whole process locks up, the stats web page does not load anymore and like described, we get lots of log entries that no backends are available anymore. I could try to create a ktrace for a synthetic test run like this as it happens rather quickly after starting the test. That could help. The only possible reason that comes to my mind for now would be that for any reason, SO_LINGER would be ignored on fbsd when haproxy actively closes a connection to a server, preventing the port from being reusable for the time needed to get rid of the resulting TIME_WAIT socket. That would be a big problem which could affect other proxies like squid for example, so I would find it strange. Do you see any TIME_WAIT sockets on the maching running haproxy, towards the servers ? Oh and BTW, are you running with PF ? I have some old memories of PF abusively randomizing sequence numbers and preventing new connections from being initiated using a same source port from the came client. It was so odd that I had to disable it on my home reverse-proxy running OpenBSD! That is easy to test, simply run pfctl -d to disable it and test again. Regards, Willy
Re: Socket Read Errors and Timeouts on FreeBSD
Ah damn it! :) Yes - pf was accidentally re-enabled after a reboot. Thank you … will continue doing load tests now. Kind regards, John Willy Tarreau wrote: On Tue, May 13, 2014 at 03:03:39PM +0200, John-Paul Bader wrote: Hey, we have already tried and disabled all custom sysctls - the behavior was not getting any better unfortunately :/ The whole process locks up, the stats web page does not load anymore and like described, we get lots of log entries that no backends are available anymore. I could try to create a ktrace for a synthetic test run like this as it happens rather quickly after starting the test. That could help. The only possible reason that comes to my mind for now would be that for any reason, SO_LINGER would be ignored on fbsd when haproxy actively closes a connection to a server, preventing the port from being reusable for the time needed to get rid of the resulting TIME_WAIT socket. That would be a big problem which could affect other proxies like squid for example, so I would find it strange. Do you see any TIME_WAIT sockets on the maching running haproxy, towards the servers ? Oh and BTW, are you running with PF ? I have some old memories of PF abusively randomizing sequence numbers and preventing new connections from being initiated using a same source port from the came client. It was so odd that I had to disable it on my home reverse-proxy running OpenBSD! That is easy to test, simply run pfctl -d to disable it and test again. Regards, Willy -- John-Paul Bader | Software Development www.wooga.com wooga GmbH | Saarbruecker Str. 38 | D-10405 Berlin Sitz der Gesellschaft: Berlin; HRB 117846 B Registergericht Berlin-Charlottenburg Geschaeftsfuehrung: Jens Begemann, Philipp Moeser
Radios online españolas
Buenos días, Aquí tenemos los primeros hilos musicales por 24€/año. Tenga una prueba de nuestro servicio en hilos.puntoa.es ¿Prefiere un dispositivo que reciba los hilos musicales en lugar del ordenador? ¿Necesita unos altavoces? ¿No tiene internet en su negocio? Tenemos una solución para hacer que nuestros hilos musicales sea la banda sonora de su día a día. En Punto A trabajamos muy duro para ofrecerle cada día la mejor música al precio más bajo y de la forma más cómoda posible. Por ello, le ofrecemos que nos escuche durante una semana para que combruebe que un bajo precio no es sinónimo de un mal servicio. Muchas gracias de antemano. Un saludo... ¡Y punto! Música... ¡Y punto! www.puntoa.es i...@puntoa.es (+34) 693 101 640 Calzada Lateral del norte, 22 35014 Las Palmas de Gran Canaria Spain Antes de imprimir este mensaje, asegúrese de que es realmente necesario. PROTEJA EL MEDIO AMBIENTE * Si no quiere recibir más email por nuestra parte pulse aquí
Re: Socket Read Errors and Timeouts on FreeBSD
Hi,Willy, Oh and BTW, are you running with PF ? I have some old memories of PF abusively randomizing sequence numbers and preventing new connections from being initiated using a same source port from the came client. It was so odd that I had to disable it on my home reverse-proxy running OpenBSD! That is easy to test, simply run pfctl -d to disable it and test again. I have the similar trouble as John. But I used ipfw instead of pf, as of haproxy can not bind mss size on FreeBSD, maybe use pf's scrub rule is a good idea. BTW, pf has a state named sloopy, it does not check sequence numbers. Regards Simon
Re: Socket Read Errors and Timeouts on FreeBSD
Hi Simon, On Tue, May 13, 2014 at 10:59:40PM +0800, k simon wrote: Hi,Willy, Oh and BTW, are you running with PF ? I have some old memories of PF abusively randomizing sequence numbers and preventing new connections from being initiated using a same source port from the came client. It was so odd that I had to disable it on my home reverse-proxy running OpenBSD! That is easy to test, simply run pfctl -d to disable it and test again. I have the similar trouble as John. But I used ipfw instead of pf, as of haproxy can not bind mss size on FreeBSD, maybe use pf's scrub rule is a good idea. BTW, pf has a state named sloopy, it does not check sequence numbers. It's not a matter of being sloppy or not, but of being excessive in that it does not even accept valid packets generated by its own TCP stack! I think that some important transitions are still missing from its state machine. I remember having reported that issue for the first time almost 10 years ago, when comparing Netfilter in 2.4.0-pre-something with PF on OpenBSD 3. I don't know what else to say unfortunately, if people believe that a firewall should block valid packets just in case, at least there's no place for such firewalls on my nor my customers' servers! Cheers, Willy
RE: can not set mss on FreeBSD 10
Hi Simon, Hi,Lists, I found haproxy 1.4.25 can not set mss on FreeBSD 10-stable as below: # /usr/local/sbin/haproxy -f /opt/etc/haproxy.conf [WARNING] 132/170407 (71806) : Starting frontend http-in: cannot set MSS The set MSS code is straightforward, its your OS' TCP stack that doesn't let you do this. Did this work in older release of HAproxy? I don't think so. Check this out, it seems FreeBSD doesn't support settings MSS on listening sockets: http://www.freebsd.org/cgi/query-pr.cgi?pr=144000 Regards, Lukas
unique-id-header with capture request header
We have more than 1 proxy tier. The edge proxy generates a unique ID and the other tiers (and apps in between) log the value and pass it around as a per-request id. Middle tier haproxy instances capture and log the unique id using capture request header which works fine; however, for the edge proxy this doesn't work since the ID doesn't seem to be available as a request header yet and a custom log-format must be used instead. This means that the logs generated by edge and non-edge proxies have a different format and be parsed specially. Also, a custom log-format must be maintained just for this purpose. What's the best way to capture the unique-id generated in a proxy or from a request and log it in a consistent way? -Bryan
Re: unique-id-header with capture request header
*From: *Bryan Talbot bryan.tal...@playnext.com
*Sent: * 2014-05-13 11:52:32 E
*To: *HAProxy haproxy@formilux.org
*Subject: *unique-id-header with capture request header
We have more than 1 proxy tier. The edge proxy generates a unique ID
and the other tiers (and apps in between) log the value and pass it
around as a per-request id.
Middle tier haproxy instances capture and log the unique id using
capture request header which works fine; however, for the edge proxy
this doesn't work since the ID doesn't seem to be available as a
request header yet and a custom log-format must be used instead.
This means that the logs generated by edge and non-edge proxies have a
different format and be parsed specially. Also, a custom log-format
must be maintained just for this purpose.
What's the best way to capture the unique-id generated in a proxy or
from a request and log it in a consistent way?
-Bryan
We do this exact same thing. Unique ID generated on the outside, and
passed around on the inside.
However we use a custom log format on both the internal and external
haproxy so that the format is exactly the same.
External:
unique-id-format %{+X}o%pid-%rt
capture request header X-Request-Id len 12
log-format %ci:%cp\ %ft\ %b/%s\ %Tq/%Tw/%Tc/%Tr/%Tt\
%ac/%fc/%bc/%sc/%rc\ %sq/%bq\ %U/%B\ %ST\ %tsc\
%ID,%[capture.req.hdr(0)]\ +\ %r
Internal:
capture request header X-Request-Id len 12
log-format %ci:%cp\ %ft\ %b/%s\ %Tq/%Tw/%Tc/%Tr/%Tt\
%ac/%fc/%bc/%sc/%rc\ %sq/%bq\ %U/%B\ %ST\ %tsc\ %[capture.req.hdr(0)]\ +\ %r
We capture on external as well as occasionally an internal service will
re-route back through the external, and so it gets a new ID, and we can
correlate the two. But the fields are space delimited, so that even
showing 2 IDs, it's still a single field separated by comma (assuming
some client doesn't pass an invalid value in. but that's also why this
is at the end of the log line)
The other advantage of doing it that the default http log format is
missing %U, which we find useful to have.
-Patrick
Re: can not set mss on FreeBSD 10
Thank you, Lukas. Maybe I can workaround it on the front router. Regards Simon 于 14-5-13 23:29, Lukas Tribus 写道: Hi Simon, Hi,Lists, I found haproxy 1.4.25 can not set mss on FreeBSD 10-stable as below: # /usr/local/sbin/haproxy -f /opt/etc/haproxy.conf [WARNING] 132/170407 (71806) : Starting frontend http-in: cannot set MSS The set MSS code is straightforward, its your OS' TCP stack that doesn't let you do this. Did this work in older release of HAproxy? I don't think so. Check this out, it seems FreeBSD doesn't support settings MSS on listening sockets: http://www.freebsd.org/cgi/query-pr.cgi?pr=144000 Regards, Lukas
