F5 and Lync

Hi,

 

We are currently working on guidance for using LTM as the Lync reverse proxy. Although that guidance is not yet complete, I've successfully used a virtual server on an external BIG-IP to forward reverse proxy traffic to an internal virtual server that has director servers for pool members. With only one LTM, you could add a self IP to the same network that your Lync servers are on, and create a new external virtual server to grab the reverse proxy traffic and forward it on, which would require changing DNS to point clients at that virtual. With one virtual server, you could do it with an iRule that catches requests for the meet/dialin URLs and forwards that traffic to the internal server pool rather than the edge. Something like this might work:

 

 

when HTTP_REQUEST {

 

if { [HTTP::host] equals"meet.mydomain.com"} {

 

pool my_lync_reverse_proxy_pool

 

}

 

}

Any ETA on when we might see something?

Still would love some help on this. Currently still struggling with using it as a reverse proxy. We have everything working with external web services and the Lync client or the web client. The last piece to the puzzle is mobility. Androids seem happy but iPhones are whining about the cert. They hit the F5 and immediately fail with cert errors. It's baffling!

Who is your cert issued by? It is possible that clientside SSL profile on the BigIP is not chained correctly - if your certificate requires an intermediate certificate to be chained, some browsers/devices will give you untrusted warning because they don't have the right CA bundle/chain installed on them. I've seen issues where Windows devices would not complain of SSL, but mobile devices such as iPads would - thus I highly recommend verifying proper CA/Chain installed on the BigIP and the clientsideSSL profile.

 

Posted By Michael Koyfman on 02/21/2012 10:39 PM

 

Who is your cert issued by? It is possible that clientside SSL profile on the BigIP is not chained correctly - if your certificate requires an intermediate certificate to be chained, some browsers/devices will give you untrusted warning because they don't have the right CA bundle/chain installed on them. I've seen issues where Windows devices would not complain of SSL, but mobile devices such as iPads would - thus I highly recommend verifying proper CA/Chain installed on the BigIP and the clientsideSSL profile.

 

 

The public cert is issued by Thawte. We've tried doing just the cert and also the entire chain. Both with the same result. I guess that is where my knowledge of certs ends...

 

 

Do you think it should be just cert or entire chain?

 

@sipple31 Did you ever get this resolved? Having the same issue.

Posted By Ed Swindelles on 03/07/2012 10:56 AM

 

@sipple31 Did you ever get this resolved? Having the same issue.

 

Actually my boss and I sat in a conference call for two hours last night with Microsoft and F5 engineers. They ran through our environment and all looked OK. Long story shortened... if you put your reverse proxy virtual server type to "Performance (layer 4)" and everything works, you are running into the same issue as us.

 

Basically it seems that SOME (notice I didn't say all) parts of Lync are unhappy with how the F5 is chaining or terminating the certs. We even tried putting a cert from our corporate CA on the outside edge of the F5, trusting it, and still wouldn't work. Definitely something F5 needs to work out.

 

 

 

 

They opened up an engineering ticket for us last night - I can let you know what happens.

 

Thanks. I actually solved this problem yesterday afternoon, with help from the experts at Microsoft "tier 3" support. The engineer had me to packet captures on our F5 units for both an iPhone and a WP7 connection. The former fails, the latter succeeds. He compared the packet captures and found that the iPhone tries to initiate a TLS v1.2 connection, and the F5 closes the connection. The WP7 initiates a TLS v1.0 connection, and communication continues. With that information, I found this F5 KB article: https://support.f5.com/kb/en-us/solutions/public/13000/000/sol13037.html?sr=19939546. This article identifies a TLS bug in specific firmware versions when using TLS v1.1 or v1.2. The solution is to upgrade to at least BIG-IP v10.2.2 HF1. I was on the release version of 10.2.2. I updated to 10.2.2 HF4, and iPhones and iPads could suddenly connect fine.

That's great info Ed. Thanks for posting the solution. TMM added support for TLS1.2 in versions 10.2.3 and 11.0 (and apparently 10.2.2 with a hotfix).

 

 

Aaron