I think that nails the problem. So if its not just me then the question is if this is intended behavior or if its a bug. If its intended then I don't think its entirely clear from the documentation that 'mode tcp' only works under certain circumstances. If we confirm that its a bug then I'd be willing to see if I can track it down and fix it.
On Tue, Jun 16, 2015 at 4:39 PM, PiBa-NL <piba.nl....@gmail.com> wrote: > Which does not prevent the backend from using mode http as the defaults > section sets. > > CJ Ess schreef op 16-6-2015 om 22:36: > > "mode tcp" is already present in mainfrontend definition below the bind > statement > > > On Mon, Jun 15, 2015 at 3:05 PM, PiBa-NL <piba.nl....@gmail.com> wrote: > >> CJ Ess schreef op 15-6-2015 om 20:52: >> >> This one has me stumped - I'm trying to proxy SMTP connections however >> I'm getting an HTTP response when I try to connect to port 25 (even though >> I've done mode tcp). >> >> This is the smallest subset that reproduced the problem - I can make >> this work by doing "mode tcp" in the default section and then doing "mode >> http" in all of the http frontends (not shown). But doing 'mode http' as >> default and then 'mode tcp' in the smtp frontend definition seems to not >> work and I'm not certain why. >> >> global >> daemon >> maxconn 10240 >> log 127.0.0.1 local0 >> log 127.0.0.1 local1 notice >> stats socket /var/run/haproxy.sock user root group root mode 600 level >> admin >> stats timeout 2m >> >> defaults >> log global >> mode http >> timeout client 30s >> timeout server 30s >> timeout connect 4s >> option socket-stats >> >> frontend mainfrontend >> bind *:25 >> mode tcp >> maxconn 10240 >> option smtpchk EHLO example.com >> default_backend mxpool >> >> backend mxpool >> >> add: >> mode tcp >> >> balance roundrobin >> server mailparser-xxx 172.0.0.51:25 check port 25 weight 20 maxconn >> 10240 >> server mailparser-yyy 172.0.0.67:25 check port 25 weight 20 maxconn >> 10240 >> >> >> > >