locked
client connectivity with Skype for Business servers via F5 Loadbalancer RRS feed

  • Question

  • Hi,

    We have a deployment scenario that is proving to be problematic. In our environment, we don't have Split-brain DNS, so our connectivity DNS records point to skype FE pool IP, which is hosted on the external side of the F5 loadbalnacer. Same goes for Edge Pool. Every client, inside or outside the organizations sees the same DNS records (effectively making all our authenticated clients internal, form Skype point of view, correct?).

    We are happy with this configuration, but here is the problem. When client attempts to connect, it will reach the FE pool through the loadbalancer, and:

    - If the loadbalancer routs the connection to the correct FE server (user's primary server), all is good and fine. Communication continues back and forth through the loadbalancer.

    - however, if the loadbalancer routs the connection to the incorrect FE server (no user's primary FE server), then the client will get a redirect instruction ( SIP/2.0 301 redirect to home server) to go directly to the FQDN on the primary FE server - which resolves on the DNS (remember, DNS resolves to everyone, everywhere). Client will then attempt to connect to the FE server directly, bypassing the loadbalancer, and failing, because the FE server is not opened to communicate to the entire world (Ideally we don't want anything besides the loadbalancer and other servers to talk to FE servers).

    My understanding it that this is a normal behavior for Skype client connectivity. Some here at work, however, are suggesting this is not adequate, and that means that Microsoft is essentially not supporting the F5 HW loadbalancer.

    Is there a way around this problem - not having to open the server ports to the entire world? Ideally the F5 loadbalancer would have to detect the redirect request and find the FQDN of the home server then redirect the connection there, on behalf of the client. I'm not even sure can F5 read this information form the stream, and/or redirect the connection this way.

    We considered:

    - Manually configuring internal clients via GPO to connect to front end pool, and having everyone else connect to edge by changing DNS records to edge. (this will still require exposing FE server ports directly, but only to the inside of the organization, not the entire world.)

    - Just have everyone (internal/external) to connect to Edge, by changing all relevant DNS records to edge pool. Everyone. Is this even supported scenario and what will break? Telephony?

    Any other suggestions, or are we missing something? Can we disable redirect to home server behavior in Skype?

    Any help or pointers would help. This project is now stalled because of this unexpected behavior.

    Thanks

    ST

     

    Friday, August 12, 2016 7:20 PM

Answers

  • Ok... I've been there.  But let me clarify first.  When you say you don't have split-brain, do you mean you use a single DNS for internal and external clients?  Or you do have seperate internal DNS servers, but your sipdomain doesn't have an internal zone?

    If it's the second scenario, you're fine, just use pinpoint DNS records so you don't have to recreate the entire zone.

    If it's the first, where there is no internal or external DNS, just DNS then:

    Ideally, you can send everyone through the edge, it will work with telephony, but emergency services and LIS will break.  If that's not a concern, that's supported and will work.  It will also solve your problems.

    The other thing I've done, is scope the A records to respond differently to different IPs.  Internal IPs get a different result for sip for example.  Lyncdiscoverinternal doesn't resolve unless you're coming from an internal IP.

    If you can, I would avoid using the load balancer with the exception of the web URLs in favor of DNS load balancing and let clients on the Internal network connect directly to the FEs on appropriate ports.


    Please remember, if you see a post that helped you please click "Vote" on the left side of the response, and if it answered your question please click "Mark As Answer". SWC Unified Communications This forum post is based upon my personal experience and does not necessarily reflect the opinion or view of Microsoft, SWC, their employees, or other MVPs.

    • Marked as answer by Sinish Friday, August 12, 2016 10:48 PM
    Friday, August 12, 2016 7:33 PM
  • Sinish,

    Skype for business was made to work in the core network, with exchange etc. Although every corporation is different. F5 does have documentation on how to setup for HLB.

    https://www.f5.com/pdf/deployment-guides/f5-lync-dg.pdf

    I would suggest using DNS load balancing for 5061 SIP traffic between Lync clients and servers.

    If you are interested in hardening your environment I have seen these setups.

    1. Have the front end pool in a seperate VLAN and open ports as you see fit.

    2. Setup a "pseudo pool" in the DMZ to take anonymous web requests and route them to the real front end pool. It will act as a director and take web requests.

     

    • Marked as answer by Sinish Friday, August 12, 2016 10:48 PM
    Friday, August 12, 2016 10:18 PM

All replies

  • Ok... I've been there.  But let me clarify first.  When you say you don't have split-brain, do you mean you use a single DNS for internal and external clients?  Or you do have seperate internal DNS servers, but your sipdomain doesn't have an internal zone?

    If it's the second scenario, you're fine, just use pinpoint DNS records so you don't have to recreate the entire zone.

    If it's the first, where there is no internal or external DNS, just DNS then:

    Ideally, you can send everyone through the edge, it will work with telephony, but emergency services and LIS will break.  If that's not a concern, that's supported and will work.  It will also solve your problems.

    The other thing I've done, is scope the A records to respond differently to different IPs.  Internal IPs get a different result for sip for example.  Lyncdiscoverinternal doesn't resolve unless you're coming from an internal IP.

    If you can, I would avoid using the load balancer with the exception of the web URLs in favor of DNS load balancing and let clients on the Internal network connect directly to the FEs on appropriate ports.


    Please remember, if you see a post that helped you please click "Vote" on the left side of the response, and if it answered your question please click "Mark As Answer". SWC Unified Communications This forum post is based upon my personal experience and does not necessarily reflect the opinion or view of Microsoft, SWC, their employees, or other MVPs.

    • Marked as answer by Sinish Friday, August 12, 2016 10:48 PM
    Friday, August 12, 2016 7:33 PM
  • Sinish,

    Skype for business was made to work in the core network, with exchange etc. Although every corporation is different. F5 does have documentation on how to setup for HLB.

    https://www.f5.com/pdf/deployment-guides/f5-lync-dg.pdf

    I would suggest using DNS load balancing for 5061 SIP traffic between Lync clients and servers.

    If you are interested in hardening your environment I have seen these setups.

    1. Have the front end pool in a seperate VLAN and open ports as you see fit.

    2. Setup a "pseudo pool" in the DMZ to take anonymous web requests and route them to the real front end pool. It will act as a director and take web requests.

     

    • Marked as answer by Sinish Friday, August 12, 2016 10:48 PM
    Friday, August 12, 2016 10:18 PM
  • Thank you guys for your great reponses.

    Anthony, yes, we only have one DNS. Thanks for elaborating both scenarios since you were not sure.  I've just never seen scenario in which everyone comes through Edge (everyone "External") so wasn't sure what will break.

    Don, we've followed the F5 document as you suggested. It all works fine, but our management cringes at the thought of opening ports directly to the server even from internal clients, and especially to the world. Your setup 2. - a pseudo pool - isn't this what Edge servers are serve as?

    We considered using directors to circumvent this problem, but it sounds, form MS documentation, that Director will just send requests to the "home" pool (we only have one pool), and after that it sounds that "SIP/2.0 301 redirect to home server" could still occur once you connect to the non-primary FE server. So sounds like Directors won't buy us anything.

    Thanks again guys. This is great feedback!! 

    Friday, August 12, 2016 10:48 PM