LYNC - Use F5 LTM as reverse proxy?

Hi Chris, this guide includes the steps you need to follow to use BIG-IP as a reverse proxy for Lync. It's for version 11 but the manual steps should be the same:

 

 

http://www.f5.com/pdf/deployment-guides/microsoft-lync-iapp-dg.pdf

 

 

You will need to create a clientssl profile that uses the cert you created for Lync Web Services.

 

thanks

 

Mike

The guide asks for an internal and external IP for the reverse proxy. Can I just create an external virtual server and forward the ports to the individual FE servers in the pool?

 

I have it set up this way now and am getting a cert error from the testocsconnectivity website. Doesn't seem like a useful error though

 

 

"Additional Details

 

If you are using a Reverse Proxy to get to the Access Edge Server, this could possibly be an issue with Reverse Proxy configuration.: Exception Details: Message: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. Type: System.IO.IOException Stack Trace: at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size) at System.Net.FixedSizeReader.ReadPacket(Byte[] buffer, Int32 offset, Int32 count) at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult) at System.Net.Security.SslStream.AuthenticateAsClient(String targetHost) at TestOCSConnectivity.Tests.SSLCertificateTest.PerformTestReally() Exception Details: Message: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. Type: System.IO.IOException Stack Trace: at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size) at System.Net.FixedSizeReader.ReadPacket(Byte[] buffer, Int32 offset, Int32 count) at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult) at System.Net.Security.SslStream.AuthenticateAsClient(String targetHost) at TestOCSConnectivity.Tests.SSLCertificateTest.PerformTestReally() "

You'd never go through the reverse proxy VIP on LTM to get to the Edge server, so I'm not sure why you're seeing that message.

 

 

Forwarding RP traffic from the external LTM to the FE servers will probably work, as long as you're OK with punching holes in the firewall for those ports.

no longer getting this error, but my meeting and dialin urls still don't work. When i go to my meet URL externally it redirects to the https url and then i get "the webpage cannot be displayed".

 

I have a VS created for both port 80 and 443, these have default pools defined that goto the IPs of the FE servers on port 8080 and 4443. I also have irules set up on each VS to send the urls to the same pools defined as the default.

 

 

What else could I be missing? Is this something I can/should open a support case for?

 

I assume you are using the same cert and key on the external 443 VIP that you have configured in Lync for your web services, the Lync servers can connect to the Certification Authority and validate the cert, and that this external VIP is using a serverssl profile as well.

 

 

Have you tried running the Lync logging tool on the FE servers? This is usually pretty helpful, and would tell you right off the bat if the connection is even making it to the FE.

 

 

I recommend opening a support case. This will help track issues with the solution and allow us to have a look at your config.

Chris,

 

 

I'm getting the same error on the TestConnectivity website. Would you mind letting me know what you did to solve this problem? My meet/dialin URLs are not working either.. I can see the BIG-IP proxying traffic to my FE's on TCP/4443, so I'm enabling logging on the FE boxes now to see if I can find out what is breaking.

 

 

On the external 443 proxy VIP, I am using my SAN cert which contains SAN's for all of my webservice URL's. However, my FE boxes have an internal cert that has a CN of the FE pool name. Is this correct?

 

 

 

Thanks,

 

 

Josh

So the terminology here is confusing so I'm kind of lost. You show a firewall in front of your edge servers, do you have publically routable IP's on your Edge servers and VIP on the untrusted zone?

 

 

Depending on your firewall you could do a packet capture on it and decrpyt with the SSL in Wireshark to see what's really going on.

 

 

 

Bob James

2 Revesrse Proxies?

 

 

Why does th iApp create two reverse proxies in the configuration one external and one internal? I understand the need for different certs but can't it just be two armed rather that two reverse proxies?

 

 

A little confused with with

 

 

Thanks,

 

 

Bob James

Robert,

 

 

The guide creates two reverse proxys (internal/external) because it assumes that you are using two separate pairs of LTM's for the deployment; one for internal and one for external. The DP does not make this very clear. If you are running everything on one LTM pair, the easiest thing to do is eliminate one of the reverse proxies and just use one.

 

 

In the end, you should have one "external" reverse proxy VIP listening on TCP/443 (and TCP/80 if you need HTTP). This VIP's pool members should be your FE servers listening on TCP/4443. The clientssl profile on this VIP should be a SAN that contains the reverse proxy name, and the serverssl profile should not have any key or certificate assigned to it (although the VIP should have a serverssl profile assigned to it). This VIP should also have the iRule that is described in the DP.

 

 

Thanks,

 

 

Josh