On Wed, Nov 18, 2015 at 3:45 AM, Piotr Kubaj <[email protected]> wrote:
> Hi,
>
> I've got a home server with 1 public IP, on which I host a couple of my
> websites. Each of them is in a separate jail. Haproxy listens on the
> outgoing IP and directs the traffic to the appropriate jail. Each of my
> websites works fast. However, if uploading files in Owncloud goes VERY
> slow and in the end I get a Bad Gateway error if the file is larger than
> ~100KB. Smaller files go through, but slowly. If I make the Owncloud
> jail listen on the external IP and connect directly to it, there's no
> problem, so it must be something about Haproxy configuration.
>
Hard to guess what the issue is but haproxy logging would probably help.
However, the logging configuration is a bit of a mess as it's configured to
be "all on" and "all off" at the same time. There are also other
configuration oddities.
>
> My operating system is FreeBSD 10.2-RELEASE-p7/amd64. Each jail is at
> the same version. Haproxy is at 1.6.2 version. I'm not sure if that
> matters, but I use Lighttpd 1.4.37 as a WWW server.
>
> Below is my haproxy.conf:
> global
> ssl-default-bind-options no-sslv3 no-tls-tickets force-tlsv12
> ssl-default-bind-ciphers AES256+EECDH:AES256+EDH
> tune.ssl.default-dh-param 4096
>
4096 bit DH params will be pretty slow to handshake. Maybe that's okay in
your circumstance though since you seem to be using this for a personal use
and not expecting a high connection rate. You also have a 8 kbit RSA self
signed certificate and using 256 bit ciphers which increase TLS overhead.
> log /var/run/log local0 notice
>
Is that where the logging socket is on FreeBSD now? I haven't used FreeBSD
in quite a while.
> maxconn 4096
> user daemon
> group daemon
> daemon
>
> defaults
> mode http
> option httplog
> option dontlognull
> option forwardfor
> option http-server-close
> option httpclose
> option tcplog
> option dontlog-normal
>
You have both tcp logging and http logging enabled at the same time. In
addition, you also have all logging disabled with "dontlognull" and
"dontlog-normal". If all your proxies are HTTP like you've shown, just
enable httplog and remove the tcplog option. When troubleshooting, enable
logging at least normal connections.
You also do not want to use both httpclose and http-server-close since they
conflict. Remove option httpclose.
Timeouts are also missing and you should be getting warnings about that too.
[WARNING] 321/103152 (87887) : config : missing timeouts for proxy
'https-in'.
| While not properly invalid, you will certainly encounter various
problems
| with such a configuration. To fix this, please ensure that all
following
| timeouts are set to a non-zero value: 'client', 'connect', 'server'.
>
>
> frontend http-in
> bind 192.168.11.3:80
> reqadd X-Forwarded-Proto:\ http
> redirect scheme https code 301 if !{ ssl_fc }
>
Why bother to add a request header which will never be used?
>
> frontend https-in
> option httplog
> option forwardfor
> option http-server-close
> option httpclose
>
Don't need to repeat all of the above since it should be set in defaults
above (if set properly).
With no "log global" you won't get any logs anyway and are probably seeing
a warning when haproxy checks the config or starts.
[WARNING] 321/103109 (87884) : config : log format ignored for proxy
'https-in' since it has no log address.
> rspadd Public-Key-Pins:\
> pin-sha256="1Pw5h93NOsPw6j/vaTYl5VvW9cmtuZXtNP3cVz10hKo=";\
> max-age=15768000;\ includeSubDomains
>
AFAIK, HPKP is only somewhat supported by only the most recent browser
releases. I believe that it's also ignored by them for certificates which
are self-signed or signed by a CA that is not in the browsers
system-defined CA set. Probably doesn't cause your issue but who knows --
it is still experimental.
The "http-response set-header" supported in haproxy 1.5 and later is more
powerful and easier to read than the old reqadd and rspadd features.
> bind 192.168.11.3:443 ssl crt /usr/local/etc/haproxy.pem ciphers
> AES256+EECDH:AES256+EDH force-tlsv12 no-sslv3
>
Don't need to repeat these options that are already set globally.
>
> backend 10amd64
> server node1 192.168.11.3:81 cookie A check
>
>
Setting sticky cookies and not using them is probably harmless but what's
the point?
-Bryan
