Lync 2010 Mobility Sign-in not working from external

Hi Jordan, are you using LTM as a reverse proxy for external Mobility connections, or ISA/TMG?

 

 

We see a lot of weird errors like this due to certificate issues. Is the external client able to resolve the certificate authority? Does the cert on the external reverse proxy contain the correct name(s)?

 

 

thanks

 

Mike

Hi Mike

 

No, we're using a Juniper MAG as the RP. The external client is able to resolve the CA, and the cert contains the correct names

 

Thanks

 

Jordan

Hi Mike

 

No, we're using a Juniper MAG as the RP. The external client is able to resolve the CA, and the cert contains the correct names

 

Thanks

 

Jordan

I don't have any experience with Juniper, but since the Mobility traffic has to pass through the RP, I wonder if whatever auth it's passing to the FE is incorrect.

 

 

The iApp has the capability to set up an LTM VIP for reverse proxy. Is it possible for you to test using that configuration, and circumvent the Juniper?

 

 

We see the same behaviour if we point internal traffic to the LTM VIP - clients are unable to sign in, and the log files show 401's from the FE severs.

If you are deploying Mobility externally at all, you are supposed to have both internal and external clients go through the external reverse proxy: http://technet.microsoft.com/en-us/library/hh690030.aspx

 

 

"Important:

 

All Mobility and LyncDiscover traffic goes through the reverse proxy, regardless of where the origination point is – internal or external. Internal traffic, in the case of a single or farm of reverse proxies, or a device that is providing the reverse proxy function a problem can arise where the internal traffic is egressing an interface and attempting to immediately ingress on the same interface. This behavior, called ‘hair pinning’, must be allowed for LyncDiscover and Mobility to function. One solution to this problem is to use a reverse proxy that is separate from the firewall (where this rule is typically enforced for security purposes). The hairpin can occur at the interface of the reverse proxy instead of being directed to the internal firewall interface, and then directed immediately back through the firewall external interface, which is typically a disallowed behavior.

 

In summary, use the DNS host or CNAME records to define the reverse proxy for the hairpin behavior – not the firewall - if at all possible."

 

 

This article is for 2013, but the same applies to Lync 2010. At any rate, which LTM VIP are you pointing the internal clients at, the 4443 VIP?

Hi Mike

 

If I point the internal clients to the 4443 VIP via the RP we're generally able to sign in - there are occasional failures with some clients citing "unable to find certificate", but subsequent attempts on the same client sign in successfully.

 

 

The client log files from those attempts that trigger the unable to find cert message do not contain any information, they're totally empty.

 

 

Hi Mike

 

If I point the internal clients to the 4443 VIP via the RP we're generally able to sign in - there are occasional failures with some clients citing "unable to find certificate", but subsequent attempts on the same client sign in successfully.

 

 

The client log files from those attempts that trigger the unable to find cert message do not contain any information, they're totally empty.

 

 

I think you're on the right track. Do you have the external lyncdiscover.yourdomain.com DNS host name added as a subject alternative name in the certs being used on both the reverse proxy and internal 4443 VIP?

Hi Mike

 

We do have the same certificate, with lyncdiscover.domain.com added as a SAN, in both the reverse proxy and the internal 4443 VIP. I've been through the process of reimporting the certificate and chain to the F5 - doing so has eliminated the occasional failures when signing in on internal wifi. the only issue we're still having is signing in from external networks (ie, 3g)