Cannot get reverse proxy for Lync 2013 to work.

I can Browse the below links both from internal and external and it prompts for credential https://lyncweb.domain.org/CertProv/CertProvisioningservice.svc https://lyncpool.domain.org/CertProv/CertProvisioningservice.svc

but the problem is when i try to sign in using mobile device it prompts with error message "We can not sign you in. check your account and try later"

Any help is appriciated

That's good to know.

The next step would be to run tcpdump/ssldump on the LTM to identify what's happening when client traffic hits it: https://support.f5.com/kb/en-us/solutions/public/10000/200/sol10209.html

It will be easier to read if you use tcpdump's filtering to narrow down your capture to just the client traffic vlan and client/VS IP addresses. You should be able to view the dump files in Wireshark as well.

Tried it, don't see any new entries as we try to connect.

In your config, lyncweb.domain.org isn't in the secure_reverse_proxy iRule that forwards traffic to the RP server pool. Requests for that FQDN will be dropped since there is no default pool for that VS.

Can you navigate to:

https://lyncweb.domain.org/CertProv/CertProvisioningservice.svc https://lyncpool.domain.org/CertProv/CertProvisioningservice.svc

Both should prompt for credentials. If this fails, and you're not using the BigIP as an outbound gateway for the web servers, make sure SNAT is enabled and using available IPs. The connection closed is not something that should be happening unless the BigIP cannot hit the web server properly.

Technically the reverse proxy is just a SNAT port forward and can even be run as a fast L4 with no proxy functionality. Also, remember to make sure the internal node for the reverse proxy is set to port 4443 and not 443. This is how Lync knows the difference between external and internal connections.

Else, you may need to wireshark on the web server and BigIP to see where the connection is actually going.

Internal is "lyncpool.domain.org" (no override). External is "lyncweb.domain.org".

All SAN certs we are using are from Digicert.

Remote Certificate Subject: CN=lyncweb.domain.org, Issuer: CN=DigiCert SHA2 Secure Server CA, O=DigiCert Inc, C=US. Elapsed Time: 259 ms. Validating the certificate name. The certificate name was validated successfully.

Additional Details

Host name lyncdiscover.domain.org was found in the Certificate Subject Alternative Name entry. Elapsed Time: 1 ms. Testing the certificate date to confirm the certificate is valid. Date validation passed. The certificate hasn't expired.

Additional Details

The certificate is valid. NotBefore = 3/9/2015 12:00:00 AM, NotAfter = 3/16/2016 12:00:00 PM Elapsed Time: 0 ms. 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. Type: System.Net.WebException Stack trace: at System.Net.HttpWebRequest.GetResponse() at Microsoft.Exchange.Tools.ExRca.Extensions.RcaHttpRequest.GetResponse() 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._SslStream.StartFrameHeader(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.Security._SslStream.StartReading(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.Security._SslStream.ProcessRead(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.TlsStream.Read(Byte[] buffer, Int32 offset, Int32 size) at System.Net.PooledStream.Read(Byte[] buffer, Int32 offset, Int32 size) at System.Net.Connection.SyncRead(HttpWebRequest request, Boolean userRetrievedStream, Boolean probeRead) Exception details: Message: An existing connection was forcibly closed by the remote host Type: System.Net.Sockets.SocketException Stack trace: at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags) at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size) Elapsed Time: 509 ms.

Remember topology will have two URL's one internal and one for external. By default, the internal URL is the FQDN of the internal Lync pool (but you're allowed to override). Are you using a single namespace for external and internal functionality or separate names? Something like:

Internal: lyncpool.domain.internal External: lyncpool.domain.com

Lync will put all of these names into a cert request by default but validate that any cert answering for external and internal have all of the names a client is attempting.

And are you using externally signed certs for the external names?

Ok the external web service URL is not working internally (lyncweb.domain.org). Other simple URLs are working internally.

Externally nothing works.

Web server name points to our reverse proxy in DNS.

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.

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.