HAProxy community

HAproxy and Outlook 2010 on Exchange 2016

Hello, I’m very new to haproxy, managed to get a working configuration by combining a week of Googling and surfing the web.

The one issue I have is OA - RPC over HTTPS is not working on L7 configuration.

Outlook 2010 won’t connect. The only error I get is Can’t connect to Exchange, mailbox unavailable (pardon, don’t recall the excact error) , outlook logging stops after autodiscover and nothing in the logs, seems like it won’t connect to the DAG.

haproxy version 2.0.8 on Debian Buster, Exchange 2016 (migrated from 2010), all the namespaces point to mail.domain.com, had a round robin DNS (yeah I know it’s 2019) which worked , won’t say perfectly but decently on the non caching ISPs, the caching ones…
hence haproxy…

snipped config :

ssl-default-bind-options no-sslv3
ssl-default-server-options no-sslv3
tune.ssl.default-dh-param 2048

mode http
log global
option httplog
option dontlognull
option forwardfor except
option redispatch

option contstats

retries                 3
timeout http-request    10s
timeout queue           1m
timeout connect         10s
timeout client          15m # this value should be rather high with Exchange
timeout server          15m # this value should be rather high with Exchange
timeout http-keep-alive 10s
timeout check           10s
maxconn                 100000

frontend fe_ex2016
http-response set-header X-Frame-Options SAMEORIGIN
http-response set-header X-Content-Type-Options nosniff
mode http
bind aaa:bbb:cccc:dddd::30:80 transparent
bind ssl crt /etc/ssl/certs/exchange.pem
bind aaa:bbbb:cccc:dddd::30:443 transparent ssl crt /etc/ssl/certs/exchange.pem
redirect scheme https code 301 if !{ ssl_fc } # redirect 80 -> 443 (for owa)
acl autodiscover url_beg /Autodiscover
acl autodiscover url_beg /autodiscover
acl mapi url_beg /mapi
acl rpc url_beg /rpc/rpcproxy.dll
acl owa url_beg /owa
acl owa url_beg /OWA
acl eas url_beg /Microsoft-Server-ActiveSync
acl ecp url_beg /ecp
acl ews url_beg /EWS
acl ews url_beg /ews
acl oab url_beg /OAB
use_backend be_ex2016_autodiscover if autodiscover
use_backend be_ex2016_mapi if mapi
use_backend be_ex2016_rpc if rpc
option accept-invalid-http-request
use_backend be_ex2016_owa if owa
use_backend be_ex2016_eas if eas
use_backend be_ex2016_ecp if ecp
use_backend be_ex2016_ews if ews
use_backend be_ex2016_oab if oab
default_backend be_ex2016

backend be_ex2016_rpc
mode http
balance roundrobin
option httpchk GET /rpc/healthcheck.htm
option log-health-checks
http-check expect status 200
server exch1 check ssl inter 15s verify required ca-file /etc/ssl/certs/ca-certificates.crt
server exch2 check ssl inter 15s verify required ca-file /etc/ssl/certs/ca-certificates.crt

the things I’ve tried so far:
acl rpc url_beg /rpc/ -> acl rpc url_beg /rpc/rpcproxy.dll
ssl-default-bind-ciphers added ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES
and to the fe
option accept-invalid-http-request

haven’t taken this to production, tests been made offsite with hosts file, on the FW I have opened 443 to the VIP of haproxy.

Any and all help much appreciated, maybe I’ve been just staring at this for too long and can’t see the forest for the trees…

If You can, I would suggest trying to use https://testconnectivity.microsoft.com/ – this would show at exact step where the connection fails. But since You said this setup is on a test lab, then next thing for You is to turn on debug log of haproxy and also check IIS logs on exchange CAS server it get’s routed to. Could be something as trivial as some wrong port closed or a route missing.

For starters, let me apologize for making a very poor problem description.
At the time I posted this I was very tired and frustrated. The problem explanation itself was lacking almost all of the actual data needed to resolve this.

Let’s start from the beginning.

The Exchange DAG cluster I’m connecting to is a production system.
I’m testing haproxy on it via host files , setting the clusters IPV4 and IPV6 on a host file as not to break anything in production. The cluster has mail.domain.com set for all services, both internally, which I pointed to haproxys VIP when I started testing, and externally with round robin DNS pointing to the public ip addresses of both servers.

This problem is happening only with Outlook 2010 sp2+ , the one that use MAPI not RPC over https, Outlook 2010 w sp1 would connect fine with RPC over https. Outlook 2013+ all connect fine, tried on 3 different OSes, win7,win10 and win server 2008 R2.

Upon further testing, CAS connections work, (as far as I can tell) but DAG won’t connect.
I ran into the problem when trying to connect from an offsite Windows 2008 R2 server with Outlook 2010. Tried another W2K8R2 server with Outlook 2010 from a different site. This led me to falsely believe that the problem was with RPC over https when the actual problem was MAPI connections from Outlook 2010.
Upgraded Outlook on one of the servers to 2013, and it connected right away.

At first I thought it was a cipher problem or windows trying to use tls 1.0 even if 1.2 was enabled
Then found the winhttp reg edit, even if tls 1.2 is enabled outlook 2010 might not use it by default (https://blogs.technet.microsoft.com/schrimsher/2016/07/08/enabling-tls-1-1-and-1-2-in-outlook-on-windows-7/)
Did a wireshark capture that showed Outlook was using tls 1.2, tried to connect 3 times (had 3 set as retries in haproxy.cfg) and every time the client would drop the connection. It would go application data-application data, the RST from the client.
Creating a new Outlook profile would do autodiscover fine, the give the outlook can’t connect to exchange server.
Trying to create a profile manually that uses RPC over https won’t work either, Outlook just white screens for a few minutes untill it give the same error.
This could be seen on outlook also if I opened connection status (CTRL, right click), a brief flash of connecting (to the DAG I presume) with auth part showing error, was for a half a second so coudn’t screen shot it.

If I connected directly to the servers w/o haproxy in between everything works fine.

I then installed a W7 and a W10 wks VMs to rule out W2K8R2 specific problems.
Both would connect fine untill I updated Outlooks on the VM to the one that uses MAPI. No matter what version of tls I was using.

On the logs I don’t see any reason for the RST from the client… It won’t show on haproxy logs or exchange mapi logs.