# NTLM Proxy via HA Proxy

**URL:** <https://discourse.haproxy.org/t/ntlm-proxy-via-ha-proxy/2403>\
**Category:** Help!\
**Created:** [April 23, 2018, 2:27pm UTC](https://discourse.haproxy.org/t/ntlm-proxy-via-ha-proxy/2403 "2018-04-23T14:27:39Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![warnox](https://avatars.discourse-cdn.com/v4/letter/w/7bcc69/32.png) [@warnox](https://discourse.haproxy.org/u/warnox)\
**Post date:** [April 23, 2018, 2:27pm UTC](https://discourse.haproxy.org/t/ntlm-proxy-via-ha-proxy/2403/1 "2018-04-23T14:27:39Z")

</div>

Hi,

I’m testing using proxy servers behind HA Proxy load balancers. The proxy servers on the back end are Symantec’s CSPs (basically Squid running on Windows). Before you ask, no, running Squid on Linux is not supported by Symantec and it does not pass the username through to the cloud service.

With NTLM authentication, most applications work properly. There are a few apps, such as Evernote and Cortana which seem to prompt for credentials endlessly. When going direct to the proxy servers, bypassing the LB, these prompts do not come up.

I’ve set keep alives and persistence in the HA Proxy config but not sure if i’m missing something else. Config below.

> frontend CSP\_LB  
> mode tcp  
> bind \*:3128  
> option http-keep-alive  
> default\_backend CSP\_LB\_Back
> 
> backend CSP\_LB\_Back  
> balance source  
> hash-type consistent  
> option http-keep-alive  
> server srv1 srv1:3128 check maxconn 3000  
> server srv2 srv2:3128 check maxconn 3000

Thanks for any help.

---

<div class="post-metadata">

**Author:** ![lukastribus](https://avatars.discourse-cdn.com/v4/letter/l/7ea924/32.png) [@lukastribus](https://discourse.haproxy.org/u/lukastribus)\
**Post date:** [April 23, 2018, 3:09pm UTC](https://discourse.haproxy.org/t/ntlm-proxy-via-ha-proxy/2403/2 "2018-04-23T15:09:41Z")

</div>

Theoretically haproxy should detect this and handle it appropriately.

Which release are you running exactly?

Try adding [option prefer-last-server](http://cbonte.github.io/haproxy-dconv/1.8/configuration.html#4.2-option%20prefer-last-server) and if that doesn’t help, you can try [option http-tunnel](http://cbonte.github.io/haproxy-dconv/1.8/configuration.html#option%20http-tunnel) instead of http-keep-alive - but do make sure to understand its limitations and disadvantages.

---

<div class="post-metadata">

**Author:** ![warnox](https://avatars.discourse-cdn.com/v4/letter/w/7bcc69/32.png) [@warnox](https://discourse.haproxy.org/u/warnox)\
**Post date:** [April 23, 2018, 3:52pm UTC](https://discourse.haproxy.org/t/ntlm-proxy-via-ha-proxy/2403/3 "2018-04-23T15:52:04Z")

</div>

Thanks for your prompt response. HA Proxy version, 1.8.4-1deb90d 2018/02/08.

Isn’t ‘option prefer-last-server’ unnecessary if persistence is enabled with ‘hash-type consistent’?

---

<div class="post-metadata">

**Author:** ![lukastribus](https://avatars.discourse-cdn.com/v4/letter/l/7ea924/32.png) [@lukastribus](https://discourse.haproxy.org/u/lukastribus)\
**Post date:** [April 24, 2018, 7:15am UTC](https://discourse.haproxy.org/t/ntlm-proxy-via-ha-proxy/2403/4 "2018-04-24T07:15:55Z")

</div>

Theoretically yes. But because I don’t know what is causing the issue, I am proposing a few things to track down the root cause.

If you are on 1.8, you should definitely upgrade to latest 1.8.8. 1.8.4 contains quite a number of bugs, I would not recommend using it in production.

You may also give latest 1.7.10 a try, just to confirm whether your applications is broken.

If this turns out to be a bug in haproxy, we will have to know when it was introduced, and confirming whether 1.7.10 is affected or not will help.

---

<div class="post-metadata">

**Author:** ![warnox](https://avatars.discourse-cdn.com/v4/letter/w/7bcc69/32.png) [@warnox](https://discourse.haproxy.org/u/warnox)\
**Post date:** [April 24, 2018, 9:56am UTC](https://discourse.haproxy.org/t/ntlm-proxy-via-ha-proxy/2403/5 "2018-04-24T09:56:31Z")

</div>

Ok, makes sense. Updates below.

1. Updated to 1.8.8: same result
2. Tested tunnel-mode: worse result, more prompts
3. Persistence: Just realised this doesn’t matter as the second server is commented out in the backend config

To downgrade from 1.8 to 1.7, do I follow the same steps as for upgrading?

---

<div class="post-metadata">

**Author:** ![lukastribus](https://avatars.discourse-cdn.com/v4/letter/l/7ea924/32.png) [@lukastribus](https://discourse.haproxy.org/u/lukastribus)\
**Post date:** [April 24, 2018, 11:39am UTC](https://discourse.haproxy.org/t/ntlm-proxy-via-ha-proxy/2403/6 "2018-04-24T11:39:57Z")

</div>

The fact that tunnel-mode makes things worse is troubling …

Not sure what upgrade procedure you used. It depends on OS and process handler. If this is systemd, make sure you update the systemd unit file when switching between 1.7 and 1.8 and consider that 1.7 uses an additional executable (haproxy-systemd-wrapper) while 1.8 does not.

---

<div class="post-metadata">

**Author:** ![warnox](https://avatars.discourse-cdn.com/v4/letter/w/7bcc69/32.png) [@warnox](https://discourse.haproxy.org/u/warnox)\
**Post date:** [May 3, 2018, 9:03am UTC](https://discourse.haproxy.org/t/ntlm-proxy-via-ha-proxy/2403/7 "2018-05-03T09:03:49Z")

</div>

I’m testing the tunnel mode again and will let you know how that goes.

In terms http-keep-alive and tunnel-mode options, do these apply even in TCP mode?

---

<div class="post-metadata">

**Author:** ![lukastribus](https://avatars.discourse-cdn.com/v4/letter/l/7ea924/32.png) [@lukastribus](https://discourse.haproxy.org/u/lukastribus)\
**Post date:** [May 3, 2018, 9:08am UTC](https://discourse.haproxy.org/t/ntlm-proxy-via-ha-proxy/2403/8 "2018-05-03T09:08:28Z")

</div>

No, all those options are for HTTP mode. I overlooked that you are already in TCP mode. When you are in TCP mode and still have troubles with NTLM, then the problem is not haproxy, there is simply no way for haproxy to intervene.

---

<div class="post-metadata">

**Author:** ![warnox](https://avatars.discourse-cdn.com/v4/letter/w/7bcc69/32.png) [@warnox](https://discourse.haproxy.org/u/warnox)\
**Post date:** [May 3, 2018, 1:17pm UTC](https://discourse.haproxy.org/t/ntlm-proxy-via-ha-proxy/2403/9 "2018-05-03T13:17:13Z")

</div>

Alright, that’s fine.

Maybe it’s worth testing it in HTTP mode instead.

---

<div class="post-metadata">

**Author:** ![warnox](https://avatars.discourse-cdn.com/v4/letter/w/7bcc69/32.png) [@warnox](https://discourse.haproxy.org/u/warnox)\
**Post date:** [May 9, 2018, 11:40am UTC](https://discourse.haproxy.org/t/ntlm-proxy-via-ha-proxy/2403/10 "2018-05-09T11:40:58Z")

</div>

It seems changing the mode from TCP to HTTP, fixed the issue with application login prompts. I’m not quite sure why though.