0

I am unable to get HAProxy to balance SMTPS

This is my configuration:

frontend SMTPS_465
    bind 10.1.1.232:465 name smtpssl ssl crt /home/exchange.pem
    mode tcp
    option tcplog
    default_backend SMTPS_465
frontend SMTPS_587
    bind 10.1.1.232:587 name smtpssl ssl crt /home/exchange.pem
    mode tcp
    option tcplog
    default_backend SMTPS_587
backend SMTPS_465
    mode tcp
    server Exc1 fqdn1:465 check port 465 fall 3 rise 2 on-marked-down shutdown-sessions
    server Exc2 fqdn2:465 check port 465 fall 3 rise 2 on-marked-down shutdown-sessions
backend SMTPS_587
    mode tcp
    server Exc1 fqdn1:587 check port 587 fall 3 rise 2 on-marked-down shutdown-sessions
    server Exc2 fqdn2:587 check port 587 fall 3 rise 2 on-marked-down shutdown-sessions

Telneting to haproxy 465 or 587 results in different output than telneting to fqdn1 or fqdn2 ports 465 or 587

The certificate file is the same one used by exchange, and balancing owa/ecp works fine, using that certificate, so I believe I can rule out the certificate problem.

How can I see where are 465 and 587 forwarded to?

I have confirmed that both ports 465 and 587 are not used by any other service on haproxy (by stopping haproxy and checking if ports are locally open)

  • Does your Exchange server respond to implicit TLS on port 587? I would remove the `ssl crt` part from that listener. In my config I also added the following lines to the definition of my submission port: `option tcp-check`, and `tcp-check expect string 220` to check that the mail server actually responds as opposed to simply not dropping connections to the port in question. I have not load balanced the SMTPS port in my environment (I expect explicit TLS only), so I have no concrete tips there. – Mikael H Feb 08 '19 at 09:52
  • Interesting. Removing ssl crt part resulted in correct behaviour – Tomislav Plečko Feb 08 '19 at 10:26
  • 1
    It's irritating that exchange uses self signed certificate on 587 and 465. It prevents me from entering the fqdn that is exposed to the internet. That's what I was trying to do with the ssl crt option, but than, connections weren't forwarded correctly. So this is still a bit of a problem – Tomislav Plečko Feb 08 '19 at 11:01

1 Answers1

0

Removing ssl crt helped, as Mikael suggested. Certificate problem was resolved by removing exchange authentication and setting the fqdn to the correct value, on both servers receive connector, thus forcing exchange servers to present the correct certificate.