locked
Clients Reach Edge server but never connect RRS feed

  • Question

  • Hi,

    I'm new to Skype For business and we installed a front-end server and 1 edge server.

    Users can't connect fine when they're internall and connect directly to the FE server. The issue starts when users are outside the organization and need to connect over the edge server.

    On the Edge server we've 2 NICS : internal and DMZ. 
    On the DMZ interface we've the gateway configured on the internal interface no gateway is configured..

    On the Edge server we also created the necessary dns records in the local hosts file.

    When we try testing with the remote connectivity analyser we always receive the error 

    "The certificate couldn't be validated because SSL negotiating wasn't successful".. On the Edge server the certificate is a Comodo UC certificate that should be installed fine.."

    I'm breaking my head over this for more than 2 week, hope that someone can help us 

    thank you !

    The certificate couldn't be validated because SSL negotiation wasn't successful. This could have occurred as a result of a network error or because of a problem with the certificate installation.
    Elapsed Time: 78 ms.
    The certificate couldn't be validated because SSL negotiation wasn't successful. This could have occurred as a result of a network error or because of a problem with the certificate installation.
    Elapsed Time: 78 ms.
    The certificate couldn't be validated because SSL negotiation wasn't successful. This could have occurred as a result of a network error or because of a problem with the certificate installation.
    Elapsed Time: 78 ms.
    Tuesday, October 31, 2017 2:22 PM

All replies

  • It looks like the public cert you installed on the Edge server is having an issue.

    1. Run Deployment Wizard and click Step-3 to see if there is any Green-tick in certification wizard?

    2. Check the Event Viewer logs on the Edge server to draw some clues.

    3. How did you install the public cert on the Edge server.

    You may provide some screenshot here, so that I can pinpoint the root cause. 

    Tuesday, October 31, 2017 3:19 PM
  • 1. I see all green ticks

    2. In the event log nothing strange is visible.

    I guess that the problem is that we only use 1 ip address with NAT behind that, I see a lot of guides that this isn't a supported configuration and that you in that case need to deploy reverse proxy..

    I followed this guide for the FE server => http://blog.schertz.name/2015/06/sfb2015deploy1/

    and for the edge server installation => http://blog.schertz.name/2016/03/skype-for-business-2015-edge-server-deployment/

    Tuesday, October 31, 2017 3:26 PM
  • Your edge server alone won't provide you with full external access, you're correct that you need to deploy a reverse proxy solution as well - it's both these components together that provide external access to users.

    As an example; The public DNS record lyncdiscover.yourdomain.com should point to your reverse proxy for external discovery and sign-in, as you don't even have one that's a problem to start.

    It is supported to use a single IP address with NAT for your edge server. However, unless you use something like a Kemp Load Balancer that is capable or routing traffic based on header information (content switching), you will likely consume a second public IP for your reverse proxy as it will also want to use port 443 which will already be utilised by your edge server.

    Typically you'll need to utilise at least 2 public IP's at a minimum; one for edge and one for reverse proxy.

    Kind regards
    Ben


    Note: If you find a post informative, please mark it so using the arrow to the left. If it answers a question you've asked, please mark the thread as answered to aid others when they're looking for solutions to similar problems.

    Tuesday, October 31, 2017 7:12 PM
  • In this case, you may need to download and install "Lync Debugging Tool', and extract, and  copy "Snooper" to your desktop.

    And try to login using your Lync Desktop client, doesn't matter  whether it's failed or successful, it's just to generate the logs.

    Then open Snooper, click Open and browse and open Lync Desktop client log file.

    C:\Users\USER-NAME\AppData\Local\Microsoft\Office\16.0\Lync\Tracing\Lync-UccApi-0.UccApilog

    Look for failure messages, errors, warning etc. and share here. 

    Wednesday, November 1, 2017 1:17 AM
  • Hi Ben,

    Do you've a good guide that I can follow with the reverse proxy in place ? 
    Saw a few articles where we can use IIS as reverse proxy with an additional plugin, is that a good way to go ? 

    Wednesday, November 1, 2017 11:52 AM
  • Officially the only supported Microsoft reverse proxy solution is WAP (Web Application Proxy), but the previously Lync 2013 supported IIS ARR solution will work for you without an issue. WAP requires ADFS you see, and many people simply don't want to deploy an ADFS infrastructure just so they can have a WAP reverse proxy (which I get). Just know that your IIS ARR isn't 'officially' supported, but will work fine.

    If it's the free price tag that you're after, then you might also consider trying a Kemp Free LoadMaster. Again, I'm not sure whether you're playing with a lab or have minimal user count in which case this might be acceptable. But for a large high capacity user populous I'd encourage you to use a packet inspecting high capacity solution which will cost money.

    This guide is still applicable for IIS ARR; http://www.gecko-studio.co.uk/iis-arr-configuration-reverse-proxy-lync/ 

    A quick google search will reveal a lot of guides and blogs around using Kemp as a solution.

    Kind regards
    Ben


    Note: If you find a post informative, please mark it so using the arrow to the left. If it answers a question you've asked, please mark the thread as answered to aid others when they're looking for solutions to similar problems.

    Wednesday, November 1, 2017 6:29 PM
  • Hi Ben,

    Thanks for your response, really appreciate that !
    I just deployed a WAP reverse proxy this afternoon and configured a forward on this for 
    https://lyncdiscover.mydomain.com => https://s4bfrontend:4443

    This is working flawless, When I now browse to https://lyncdiscover.my-domain.com i receive the XML needed for the autodiscover.

    On public DNS i created a few DNS records as required:

    lyncdiscover.mydomain.com -> A record to the reverse proxy
    access.mydomain.com -> A record to WAN ip of S4B Edge
    _sipfederationtls._tcp -> SRV record pointing to access.mydomain.com on port 5061
    _SIP._tls -> srv record pointing to access.mydomain.com on port 443

    When I do some test in the remote connectivity tester the autodiscover test only is flawless and he find the configuration via the lyncdiscover.mydomain.com url. When I run the S4B connectivty test with the option checked to use autodiscover to detect server settings strange things are happening:

    The test is ignoring the lyncdiscover.mydomain.com dns record and he is jumping directly to the _sip._tls record wich points to access.mydomain.com which is my edge server, and ssl negotiating is failing on this..

    When I remove the _sip._tls record in public dns the remote connectivity analyser is succesfull.. Even with the _sip._tls record i can logon remotely with a S4B client , but on a mobile device it isn't working probably due to this misconfiguration..

    We need integration with our on prem s4b and Exchange Online so we need the _sip._tls SRV records for integration with Office 365...

    Any idea on what could be wrong ? 

    Wednesday, November 1, 2017 10:06 PM