Cannot get reverse proxy for Lync 2013 to work.

Hi, can you give us some more information about what's not working?

Is the reverse proxy virtual server listening on the external VLAN(s)? When you try to connect to your meeting and dialin URLs, do you see connections in the VS and pool member statistics, or no connections to either the VS or pool members?

Which of the 3 scenarios did you select for the reverse proxy iApp deployment?

thanks

Thanks for your fast reply.

When testing dialin, meet, or lyncweb, there is no connection externally to anything.

I chose "Forward Reverse Proxy Traffic to Lync Servers" and "Pool Members Have a Route to Clients Through the Big IP System"

If your reverse proxy virtual server isn't receiving any connections, then you most likely have a layer 2 or 3 problem. Can you ping the VS by IP address externally?

Yes I can ping the URLs and public IPs externally.

So you have DNS pointing to the VS address and you can ping it by name, yet when you try to access those URLs from the browser, the VS stats aren't showing any connections?

Correct

Can you telnet on port 443 using the Lync FQDNs? I'm not sure why you aren't seeing any connections, but we need to get at least that far before we can continue troubleshooting. If you want to open a case with F5 support, they will have you upload your configuration to iHealth. If you post the case number here, I can track it as well.

Yes I can telnet on port 443 to the URLs.

I opened a case with F5 but they said they can't help me, that this would be a design question and I would need professional services. Rather disappointed in this experience.

Case is 1-1239585158

We get this when testing from Microsoft's tool,

Testing HTTP authentication methods for URL https://lyncdiscover.domain.org/Autodiscover/AutodiscoverService.svc/root/user. HTTP authentication test failed.

Additional Details

Exception details: Message: The underlying connection was closed: An unexpected error occurred on a receive.

In my experience, 90% of the time, this is a certificate issue (especially for OSX). The Lync client runs two authentication methods, one for the SIP registration, and a second for the Lync web services. This web service path uses an HTTPS-based auth via web ticketing services. Try navigating to the following via browser:

https://"lyncwebservice".domain.com/CertProv/CertProvisioningservice.svc

You should be prompted for user credentials. Enter your regular domain auth (whatever the client is using). You'll get a return via svcutil.exe with Front End Pool data and other neat stuff.

If that works, you know the web service URL is working. You should also be able to put https://meet.domain.com/CertProv/CertProvisioningservice.svc and get the same result. In my case, I just used CNAME's to redirect autodiscover and other webservices to the lyncsvc.domain.com external name published in Topology.

If you cannot get to that name, either the certificate does not have all of the names required for the web ticket service to create a token, OR the certificate cannot be properly validated. All of these things will break HTTP auth. The testconnectivity tool should allow you to expand the results and give you some more detail.