Baracuda proxy with NTLM authentication across Riverbed Traffic Manager not working

[ace_1]

Hi Experts,

We have a new implementation setup where we have setup Barracuda Web proxy with NTLM authentication across STM with GSLB.

The setup is as follows:

1. We have configured two Barracuda Web Proxy devices in a Pool and is linked to the Virtual IP on Riverbed load balancer.

2. End users are pointed towards Virtual IP on Riverbed that balances the load to the 2 Barracuda devices in the Pool.

3. For User authentication For Web proxy NTLM authentication is being used.

4. Everything is working fine for all websites except for News sites. For example if the end user tries to access facebook.com, all the applied policies on the Web proxy works perfectly fine; however when the end user tries to access cnn.com or any other news site, he is prompted for NTLM authentication again and again irrespective of the correct username and password. 

5. A Rough Network Topology is as follows:

Web Proxy1(WP1)--------

                                   |------Riverbed Load Balancer(LB)--------End User

Web Proxy2(WP2)--------

Troubleshooting done:

6. For zeroing the problem we tried to bypass the load balancer by directing the traffic to Web proxy instead of Virtual IP on load balancer and everything worked perfectly fine. All sites be it facebook.com or cnn.com were working as per the configured policy on the Web Proxy.

7. Round Robin Algorithm is currently applied ; however we also tried to disable one of the web proxy in the pool, with the exact same result.

Any input on the above would highly appreciated.

Thanks,

Naveen

[markbod]

Hi Naveen,

I think we'll need to look at a connection trace and/or tcpdump of the problem to figure out exactly what is going on here. That's almost certainly information you wouldn't want on a public forum like this one, so you might want to open a support ticket.

NTLM authenticates the TCP connection between the client and the server. So SteelApp maintains a persistent connection whenever it detects NTLM is in use. If the persistent connection is dropped, then it can lead to the user being prompted to re-enter their password.

Checking edition.cnn.com I see that the front page pulls in resources from over 20 different hosts. I don't know, but I wonder if SteelApp links the Host with the NTLM session in some way? I presume that you have the protocol set to HTTP on SteelApp currently? Does the problem go away if you change it to "Generic Client First"?

Cheers,

Mark

[ace_1]

Hi Mark,

Thanks for the quick look and the analysis on the issue.

Support ticket is already in process; however issue seems quite strange as i have seen NTLM with other proxy and Load balancers working perfectly fine.

Issue is just with News and few business sites, So if we try to segregate the issue on the basis of type of traffic. I agree that the only diff would be that the news sites pulls data from multiple hosts. we tried to play with the persistent connection settings as well; however no luck.

Wonder why the connection would drop, One more strange thing i wanted to highlight was that the prompt was coming again and again irrespective of entering correct username and password.

Yes Protocol is set to http currently. I have no idea on "Generic client first" can you explain why and when it is used.

Cheers,

Naveen

[markbod · Accepted solution]

Hi Naveen,

NTLM usually works just fine on SteelApp too. So this is unusual.

I recommended trying with Generic Client First, because SteelApp will then default to doing connection load balancing and will not attempt to inspect the protocol. You will lose the ability to do Content Caching, Compression, and other HTTP optimizations, but I guess they're functions which are being carried out by the proxy servers anyway.

The "generic" protocols in SteelApp are usually for Load Balancing protocols which aren't well known or don't have any out-of-the-box optimizations in SteelApp. But they can be used in place of the more intelligent options where necessary. A Generic Client First protocol is one in which the client sends data on the connection first, HTTP fits into that category. We also have Generic Server First for when the servers sends data first, eg SMTP, and Generic Streaming for protocols where client and server can talk at any time.

Cheers,

Mark

[ace_1]

Hi Mark,

You scored a slam dunk !!!!

BINGO... Generic Client First resolved the issue.

Thanks for the details on Generic client first.

Any link or document for a complete descriptive packet flow for riverbed proxy ?