locked
Lync 2013 - Externally Unable to connect RRS feed

  • Question

  • Hi All,

    Hopefully you can help, none of my users are able to connect to lync from an external source, internally everything is great, when I originally started looking at the problem there were certificate errors if I went to https://sip.domain name

    This has been resolved by me binding a certificate to both internal and external https pages in IIS as well as setting the certificate in lync deployment wizard to the same certificate.

    When I try to connect to my client externally I am told that there was an issue with the certificate.

    What I am getting from the lync connectivity analyser is this:

    X-Ms-diagnostics: 28032;source="Internal server hostname";reason="The web ticket is invalid.";faultcode="wsse:InvalidSecurityToken"
      X-MS-WebTicketURL: https://Internal server hostname/WebTicket/WebTicketService.svc
      X-MS-WebTicketSupported: cwt,saml
      X-MS-Server-Fqdn: Internal server hostname
      X-Content-Type-Options: nosniff
      Cache-Control: no-cache
      Date: Thu, 28 Jul 2016 08:48:54 GMT
      Server: Microsoft-IIS/7.5
      X-Powered-By: ASP.NET
      Content-Length: 1293
      Content-Type: text/html

    As you can see for some unknown reason the analyser is going to my internal hostname of the server rather than sip.domain.com.au as an example

    Any thoughts?

    THank You

    Thursday, July 28, 2016 8:51 AM

Answers

  • Hi

    You have confirmed by suspicions in that your deployment is attempting to use direct nat to the front end server. 

    You will need to deploy a dedicated server preferrably in a DMZ that acts as a reverse proxy. Any transparent reverse proxy will work, but recommend you look at Windows Application Proxy, IIS ARR, or Kemp Load balancers will do RP functionality.

    To help you understand the topologies have a look here: https://technet.microsoft.com/en-us/library/gg398095.aspx

    I would recommend that you set your external web services FQDN to something like sws.domain.com or webext.domain.com rather than sip.domain.com. The reasons for this is that sip.domain.com is a reserved FQDN that clients use as a fallback in case discovery and SRV connections fail. This FQDN should always point to your accessedge service on your Edge server, and not be used for the web traffic.

    So what you should end up with is something like this in the public world

    lyncdiscover.domain.com  -> 443 -> Reverse Proxy IP -> 4443 -> Lync Front End

    meet.domain.com  -> 443 -> Reverse Proxy IP -> 4443 -> Lync Front End

    dialin.domain.com  -> 443 -> Reverse Proxy IP -> 4443 -> Lync Front End

    sws.domain.com  -> 443 -> Reverse Proxy IP -> 4443 -> Lync Front End

    sip.domain.com -> 443 -> Lync Access Edge IP

    webconf.domain.com -> Lync Edge Web Conf IP

    av.domain.com -> Lync Edge AV IP

    Nothing should directly NAT to your Front End servers, you NAT the ports to the reverse proxy and Edge servers respectively.

    In terms of certificate, you only need the public names in the External Cert assigned to Reverse Proxy and Edge server as SANs. If you want to use one SAN Cert for Edge and RP, then make sure the Subject Name is the access edge FQDN and all others are SANs

    hope this helps

    thanks


    Note: Please remember to `Mark as Answered` a post that answers your question and/or `Vote as Helpful` posts that have helped you. This will help others find answers to similar problems. For more Skype for Business help visit: http://www.skype4b.uk Please note that answers are based on my experience and opinion only and do not necessarily represent the views of my employer.

    Thursday, July 28, 2016 12:41 PM
  • along with create a Service record and lyncdiscover if you are trying auomatic signin method from external

    A lyncdiscover.domain.com Lync Reverse Proxy IP
    SRV _sip._tls.domain.com sip.domain.com
    SRV _sipfederationtls._tcp.domain.com sip.domain.com

    - on Edge server, make sure you  have deployed a ceritificate which has privatekey enabled.

    -  when you right click on the certificate from the certificatestore - it should be enabled for all purposes.

    - make sure you opened required ports inside out and outside to inside.

    - I would suggest to verify the topology and check what ports you have defined on edge POOL. the same ports you should opened from external to internal ( bydefault,  Federation 5061 and SIP Accessedge 443 )

    Telnet the ports and make sure those are opened.

    - if you have any routing issues between FE and Edge, make sure you have added static routes on edge to route SIP traffic appropriately.

    - on Edge, Localhost file add records for FE pool - which should resolve any DNS resolution issues.

    following article is my all time favorite to refer hope this helps to you as well.

    Port summary - Single consolidated edge with private IP addresses using NAT in Lync Server 2013 
    https://technet.microsoft.com/en-us/library/gg425891(v=ocs.15).aspx

    let us know the status.


    Regards, Rajukb | MCSE (Communication ), MCSA (o365) ,Certified "Lync server 2013 depth support engineer"| This posting is providedwith no warranties and confers no rights. If my reply answers your question please mark as answer/helpful if its helpful.

    Friday, July 29, 2016 2:58 AM

All replies

  • Hi

    When deploying an edge server, it is important that you follow the documented steps as diverting from that model causes issues. 

    The edge server is like a proxy server, it has an outside leg, publicly facing and internal leg, privately facing. As Lync depends of quite a high level of security it relies heavily on certificates and proper certificate chains.

    To this end on the external interface of your edge server you should have a public SSL certificate bound to the external interface. This certificate should contain all your subject alternative names for your edge services e.g. access.domain.com and webconf.domain.com. You do not need one for av.domain.com. If you need XMPP federation then you will need an additional SAN entry for domain.com. 

    On the internal interface you need an internal certificate from your internal CA. The subject alternative name on this certificate should be your Edge pool FQDN only. 

    You should not bind the certificates using IIS on the Edge server

    In your example here the client is attempting to connect to the Lync web services. This should be done through a reverse proxy, and not directly NAT'ed through to the front end, which I suspect is what is happening here. 

    The reason for this is that the external web site on the FE listens on ports 8080 and 4443, while the internal listens on 80 and 443. As the requests are hitting the internal website externally you are getting certificate errors and seeing internal names. The reason it is not working is because external connections rely on a different authentication method in web services than internal, so the token will never be issued.

    I would recommend that you deploy a reverse proxy, assign a public certificate to the external interface with SANs lyncdiscover.domain.com, meet.domain.com, dialin.domain.com and lyncweb-ext.domain.com (or whatever your FQDNs / Simple URLs are) make it listen on 443 and then reverse proxy the traffic to the front end server on port 4443.

    Once authentication and discovery has completed if you are using a desktop client then SIP traffic will go via the edge server e.g. sip.domain.com if you have set that as your access edge FQDN, while mobile clients SIP will always signal through the external web services via the reverse proxy, but media will go via the av interface of your edge.

    thanks


    Note: Please remember to `Mark as Answered` a post that answers your question and/or `Vote as Helpful` posts that have helped you. This will help others find answers to similar problems. For more Skype for Business help visit: http://www.skype4b.uk Please note that answers are based on my experience and opinion only and do not necessarily represent the views of my employer.

    • Proposed as answer by Liinus Friday, July 29, 2016 9:31 AM
    Thursday, July 28, 2016 9:30 AM
  • Hey Mark

    Thank you so much for your reply there is a lot of detail there.

    I can see that on the IIS front end server, there is two websites one for external and one for internal, the internal 443 page has a cert bound that was given by the CA

    The 4443 page on the external was given an external global certificate.

    Are there other Subject Alternative names that need to be on the certificate other than:

    DNS Name=sip.domain

    DNS Name=www.sip.domain

    DNS Name=dialin.domain

    DNS Name=lyncdiscover.domain

    DNS Name=meet.domain

    DNS Name=localserver.domain

     

    In the topology builder I have set the FQDN for the external site to sip.domain

    So with regards to the reverse proxy, sorry for sounding dumb here but how do I go about doing that?

    As for the NAT'ing currently I am unsure how this has been set up but should a user hit the router on 443 and then that be Nat'ed to 4443 or should it just be set 443? and then the reverse proxy takes care of that?

    You'll have to forgive, this was set up by predecessor who left it in a broken state.

    Thank You

    Thursday, July 28, 2016 11:31 AM
  • Hi

    You have confirmed by suspicions in that your deployment is attempting to use direct nat to the front end server. 

    You will need to deploy a dedicated server preferrably in a DMZ that acts as a reverse proxy. Any transparent reverse proxy will work, but recommend you look at Windows Application Proxy, IIS ARR, or Kemp Load balancers will do RP functionality.

    To help you understand the topologies have a look here: https://technet.microsoft.com/en-us/library/gg398095.aspx

    I would recommend that you set your external web services FQDN to something like sws.domain.com or webext.domain.com rather than sip.domain.com. The reasons for this is that sip.domain.com is a reserved FQDN that clients use as a fallback in case discovery and SRV connections fail. This FQDN should always point to your accessedge service on your Edge server, and not be used for the web traffic.

    So what you should end up with is something like this in the public world

    lyncdiscover.domain.com  -> 443 -> Reverse Proxy IP -> 4443 -> Lync Front End

    meet.domain.com  -> 443 -> Reverse Proxy IP -> 4443 -> Lync Front End

    dialin.domain.com  -> 443 -> Reverse Proxy IP -> 4443 -> Lync Front End

    sws.domain.com  -> 443 -> Reverse Proxy IP -> 4443 -> Lync Front End

    sip.domain.com -> 443 -> Lync Access Edge IP

    webconf.domain.com -> Lync Edge Web Conf IP

    av.domain.com -> Lync Edge AV IP

    Nothing should directly NAT to your Front End servers, you NAT the ports to the reverse proxy and Edge servers respectively.

    In terms of certificate, you only need the public names in the External Cert assigned to Reverse Proxy and Edge server as SANs. If you want to use one SAN Cert for Edge and RP, then make sure the Subject Name is the access edge FQDN and all others are SANs

    hope this helps

    thanks


    Note: Please remember to `Mark as Answered` a post that answers your question and/or `Vote as Helpful` posts that have helped you. This will help others find answers to similar problems. For more Skype for Business help visit: http://www.skype4b.uk Please note that answers are based on my experience and opinion only and do not necessarily represent the views of my employer.

    Thursday, July 28, 2016 12:41 PM
  • along with create a Service record and lyncdiscover if you are trying auomatic signin method from external

    A lyncdiscover.domain.com Lync Reverse Proxy IP
    SRV _sip._tls.domain.com sip.domain.com
    SRV _sipfederationtls._tcp.domain.com sip.domain.com

    - on Edge server, make sure you  have deployed a ceritificate which has privatekey enabled.

    -  when you right click on the certificate from the certificatestore - it should be enabled for all purposes.

    - make sure you opened required ports inside out and outside to inside.

    - I would suggest to verify the topology and check what ports you have defined on edge POOL. the same ports you should opened from external to internal ( bydefault,  Federation 5061 and SIP Accessedge 443 )

    Telnet the ports and make sure those are opened.

    - if you have any routing issues between FE and Edge, make sure you have added static routes on edge to route SIP traffic appropriately.

    - on Edge, Localhost file add records for FE pool - which should resolve any DNS resolution issues.

    following article is my all time favorite to refer hope this helps to you as well.

    Port summary - Single consolidated edge with private IP addresses using NAT in Lync Server 2013 
    https://technet.microsoft.com/en-us/library/gg425891(v=ocs.15).aspx

    let us know the status.


    Regards, Rajukb | MCSE (Communication ), MCSA (o365) ,Certified "Lync server 2013 depth support engineer"| This posting is providedwith no warranties and confers no rights. If my reply answers your question please mark as answer/helpful if its helpful.

    Friday, July 29, 2016 2:58 AM