RSS Subscription 168 Posts and 2,769 Comments

Lync 2010 Edge Servers and IP Requirements – NAT vs Public IP

To this date, I still see a lot of confusion as to the IP requirements of Lync 2010 Edge Servers.  I have seen the following questions:

  • Why do we require Public IP addresses on all 3 Lync Edge Roles when using Hardware Load Balancing?
  • Why does the Audio/Video Edge Role need a Public IP when behind a Hardware Load Balancer?
  • Why can we NAT when we’re doing DNS Load Balancing?
  • Why can’t we have a mix of Public IP and NAT’d IPs on the same Edge Server?

Have you been pondering the answer to any of the above four questions? If so, this blog article is for you.  Read on…

Edge IP Requirements and Assumptions

First of all, let’s list out Edge Networking requirements and assumptions according to the official Lync 2010 documentation (only listing the ones relevant to this document to preface my own points):

    • Two network interface cards (NICs) configured as follows:
      • Edge internal interface is on a different network than the Edge external interface.
      • The Edge external interface NIC has three IP addresses bound to it (that is, Access, Web Conferencing and A/V, with the Access IP address set to primary and the other two IP addresses set to secondary).
      • Only one default gateway is configured and it is assigned to the Access Edge external interface and pointed to the external firewall’s IP address.
    • The NIC for the Edge external interface and the NIC for the Edge internal interface are on two separate networks that do not have routing configured between them.
    • Windows Server 2008 strong host model is used on all Edge Servers. For details, see “The Cable Guy: Strong and Weak Host Models” at http://go.microsoft.com/fwlink/?LinkId=178004
    • There is a route from the network containing the Edge internal interface to any networks that contain Lync 2010 clients or servers running Lync Server 2010.
    • All Edge external interfaces use either NAT, with destination IP addresses changed inbound and the source IP addresses changed outbound combined with DNS load balancing. Or, they use publicly routable IP addresses combined with hardware load balancing.
      • A hybrid configuration with Access Edge service and Web Conferencing Edge service behind NAT and the A/V Edge service configured with a publicly routable IP address, is not supported in Lync Server 2010.

In Lync Server 2010, only 2 NICs are supported on the Edge Role

Some history information on Office Communications Server (OCS) 2007 R2

In Office Communications Server (OCS) 2007 and OCS 2007 R2, we generally saw two types of NIC Configurations:

Note: Keep in mind that while Private IPs are shown above, you can alternatively use Public IP Address on the NICs themselves.

Method #1

Every Role has its’ own dedicated NIC. This is recommended due to people having issues in the past with communications when roles share IP Addresses on the same NIC.

Method #2

It is also possible to use one NIC for the Audio/Video Edge Server, Web Conferencing Edge Server, as well as the Access Edge Server. Because of this, all 3 Edge Server Roles would have Private IPs meaning they can all be on the same NIC. You would then use a dedicated NIC for the Internal NIC.

Method #1 worked just fine out of the box with Windows 2003.  Windows 2008 and using Windows 2008 R2 both use the new Strong Host networking model which introduce some complications when using Method #1.  There are some security differences with the Strong Host model than what the Weak Host model used.  For example, if traffic comes in on one interface, it’s going to leave back out that same interface.  But with Windows 2003 networking, you can only have one default gateway.  So there are some tricks to do with multiple NICs such as assigning multiple Default Gateways and tweaking your Windows routes.  Jeff Schertz, Lync MVP, details this on his blog article here.  Generally, Method #1 will give you greater performance benefits but with how OCS scales and its sizing guidance, 2 NICs are fine.

Fast Forward to Lync Server 2010

See how complicated this all was in OCS 2007 R2?  Should I use 2 NICs?  Should I use 4 NICs?  If I use 4 NICs, should I create additional static routes?  Should I disable strong host model?  This complication is unnecessary.  This is why we have the following requirement listed above which I have again posted here:

    • Two network interface cards (NICs) configured as follows:
      • Edge internal interface is on a different network than the Edge external interface.
      • The Edge external interface NIC has three IP addresses bound to it (that is, Access, Web Conferencing and A/V, with the Access IP address set to primary and the other two IP addresses set to secondary).

We can see that based on this requirements, we must now use only 2 NICs.  In the requirements listed above, you may also have seen the following:

  • All Edge external interfaces use either NAT, with destination IP addresses changed inbound and the source IP addresses changed outbound combined with DNS load balancing. Or, they use publicly routable IP addresses combined with hardware load balancing.
    • A hybrid configuration with Access Edge service and Web Conferencing Edge service behind NAT and the A/V Edge service configured with a publicly routable IP address, is not supported in Lync Server 2010.

What this means is, if we’re using a single Edge Server or DNS Load Balancing and are using NAT, the external interface must contain all Public IP Addresses.  There’s no hybrid configuration.  If we’re using a single Edge Server or DNS Load Balancing and are using Public IP Addresses, the external interface must contain all Private IP Addresses.  If we’re using a Hardware Load Balancer, documentation has always mentioned the A/V role requires a Public IP Address.  This is still true with Lync Server 2010.  But because there is no hybrid configuration (due to simplicity), that means all Lync Server 2010 Edge Roles must now use Public IP Addresses as well.

The NIC Model in Lync Server 2010 is as follows:

We can see if we’re using a single Edge Server or DNS Load Balancing, we can use either NAT or Public IPs on the External NIC.  But if we’re using Hardware Load Balancers, we must use Public IP Addresses on the external NIC.  This brings is into our next topic.

Why do we need Public IP Addresses on our Lync 2010 Edge Server’s External Interface when using Hardware Load Balancers?

There is a lot of information to digest to fully understand why we need to use a Public IP on a Lync Server 2010 Edge Server’s External Interface when using Hardware Load Balancers.  I will do my best to explain thoroughly.

Let’s start with te following blog article which provides a good summary on Public IP requirements for the external interface of the Edge Server for the Audio/Video Edge Role: http://blogs.technet.com/b/chlacy/archive/2008/03/12/a-v-edge-and-publicly-routable-ip-addresses-part-ii.aspx

It states,

The external A/V Edge requires a publicly routable IP address for several reasons.  First, the A/V Edge server implements the STUN protocol, a mechanism whereby the A/V Edge server reflects back the IP address it saw from a user’s home router.  This home router IP address is used to enable the use of efficient media paths using the ICE protocol and is also needed to ensure proper IP permissions are set on the A/V Edge server’s 50,000 port range.  If the A/V Edge external address was behind a NATed IP, the A/V edge server would return that address instead of the address of the home router, leading to less efficient (sometimes broken) media paths and permission issues on the 50,000 port range.  A second reason for publicly routable IPs is to support UDP load balancing.  For real time audio/video traffic, UDP is the preferred protocol to transfer RTP packets.  However, UDP is a stateless protocol, so some load balancers distribute UDP packets to the servers without any context for the current session.  To mitigate this, the A/V edge server returns its external IP address on the first UDP packet of a media session, and OC or the Meeting Console client sends subsequent UDP traffic directly to that IP address instead of through the load balancer.  In order for this mechanism to work, the external IP must be publicly routable.  Note that supporting a publicly routable IP address on the external edge does not preclude a company from using a firewall.  To the contrary, Microsoft recommends that all externally facing servers be protected with a firewall…provided that firewall does not NAT the IP address.

Source Network Address Translation (SNAT)

In order to fully understand the above and what it means for Audio/Video needing a Public IP (and therefore based on what was discussed above, all other Edge Role’s would also need Public IPs for the external interface), we must first understand how Load Balancers work with Source Network Address Translation (SNAT).

To put it simply, SNAT essentially changes the source address in the IP header of the packet to be the IP of the Hardware Load Balancer.  What this means, if a Hardware Load Balancer sends traffic to a server, the Source IP will be the hardware load balancer meaning the server will return the traffic to the Hardware Load Balancer and the Hardware Load Balancer will then communicate back to the client who initiated the original communication.  The server will never directly communicate back to the originating client.

Lets demonstrate this in a one armed SNAT configuration for a typical Edge Server.  My explanation of SNAT is based on Andrew Ehrensing’s Teched Video on Exchange 2010 Load Balancing which you can find here which will explain SNAT based on all private IP Addresses.  Later on, I’ll explain how this relates to Lync Server 2010 Edge Server’s Access Edge, Web Conferencing Edge, and Audio/Video Edge IPs.

As we can see in this screenshot, we have a Hardware Load Balancer with a NIC assigned as 10.10.10.5.  Because this NIC belongs to the 10.10.10.0/24 network, we can create a Virtual IP Address of 10.10.10.6 which is what clients will connect to.

Our first packet will be from the Client Computer with an IP of 10.10.10.40 to the Hardware Load Balancer’s Virtual IP Address of 10.10.10.6.

We now see SNAT at work.  When the traffic is sent to the server, we see the Source IP is defined as the Hardware Load Balancer’s Self IP.  This means that the Server will see the Source IP as 10.10.10.5 instead of 10.10.10.40 and because of that, the server will return the traffic to 10.10.10.5 instead of 10.10.10.40.

As we can see, the Server will respond to 10.10.10.5 with the requested data instead of responding to 10.10.10.40.

We finally see the VIP respond to the Client computer with the data the server had returned to the hardware load balancer.

How does SNAT relate to the Lync Server 2010 Edge?

Let’s take a look at some F5 documentation on the external interface of a Lync Server 2010 Edge Server.  You can see the F5 BIGIP LTM 10.2.2 documentation here.  As of the writing of this blog article, the document revision is 1.9.  Looking at Page 7 (may be different in a future document revision), we can see the section entitled, “Configuration table for BIG-IP objects: Edge Servers – External Interface.”  Take a look at the SNAT requirements for each Lync Server 2010 Edge Role.  You will see that SNAT is enabled for the Access Edge Role and the Web Conferencing Edge Role.  SNAT is NOT enabled for the Lync Server 2010 Audio/Video Edge Role.

What does this mean?  This means that the Audio/Video Edge Server will respond directly to the client on the Internet and will not return Audio/Video or even Desktop Sharing traffic through the Hardware Load Balancer.  In fact, if we take a look at the Planning Documentation for Lync Server 2010, we can see that ports required for Audio/Video need to be opened to and from  the Lync Server 2010 Audio/Video Edge role directly as well as to the Hardware Load Balancer Virtual IP Address (VIP) belonging to the Audio/Video role.  We can see this in the following diagram provided by Microsoft for the External Topology with Hardware Load Balancing.

Putting it all together

Now with that said.  Let’s put all this information together to really understand why we must use a Public IP address on the Edge Server’s Audio/Video IP.  Because the Lync Audio/Video Edge based on the ICE (TURN/STUN) must be able to respond directly to clients with its own Public IP Address which means it needs to respond directly to clients. If we were to use SNAT, this means the Audio/Video would respond through the Hardware Load Balancer and Audio/Video traffic would overload a Hardware Load Balancer and potentially provide a degredated experience. On top of that, if the UDP packets were to go through a hardware load balancer, you’d run into UDP issues as described such as the fact that UDP is a stateless protocol, so some load balancers distribute UDP packets to the servers without any context for the current session.  By having a Public IP on the Edge and not using SNAT on the Hardware Load Balancer for the Audio/Video IP, it allows the Hardware Load Balancer to respond to the client to respond directly to clients negating the UDP problems mentioned and allowing a better Audio/Video experience with the client being able to talk directly to the Lync Server 2010 Edge Server’s Audio/Video Public IP.

Now, I’m sure you are asking the question, well if I’m using DNS Load Balancing, why can I use a NAT’d IP for the Lync Server 2010 Edge Server?  Well, it’s pretty simple.  We have no Hardware Load Balancer in the mix.  When we configure DNS Load Balancing, it allows us to specify the Public IP of our Lync Server 2010 Edge Server’s Publicly Routable IP Address.  Because of this, the Lync Server 2010 will forcefully respond with its Public IP Address instead of the NAT’s Private IP Address.  We can’t do this with a Hardware Load Balancer because we can’t NAT the connections twice; once to a Private IP on the HLB Audio/Video VIP and another to the Private IP of the Audio/Video IP.  So we elect to have Public IP Addresses on both the VIP and the Server, the traffic is not NAT’d, and the Audio/Video Role can reply with its Public IP and then clients will then begin to send communication directly to the Lync Server 2010 Edge Server.

Share

22 Responses to “Lync 2010 Edge Servers and IP Requirements – NAT vs Public IP”

  1. on 08 Jun 2012 at 7:46 amMike

    Excellent info, thank you!!

  2. on 13 Jun 2012 at 12:13 amNoman

    Hello

    i have one standard edition server and now i am deploying edge server (single-edge).

    as i dont have any DMZ right now, am i able to deploy edge with single PUBLIC IP on edternal edge or i must use NAT ?

    nomansaeed@gmail.com

  3. on 14 Jun 2012 at 7:20 pmElan Shudnow

    Well you don't have to absolutely have a DMZ. Edge just needs to have 2 NICs with each segment being on a different subnet. Basically, follow the NIC guidelines above and follow the entire design guidance provided on Technet.

  4. on 13 Jun 2012 at 3:00 pmclbirch

    On the second diagram, labeled "The NIC Model in Lync Server 2010 is as follows:" is it a mistake that the IPs for Access and WebConf are labeled "Private"? They are given the same range as the AV Public IP and you actually say they all have to be public.

    Just getting clarification…thanks!

    casey

  5. on 14 Jun 2012 at 7:18 pmElan Shudnow

    Oops, thanks for catching that. I'll get it updated sometime in the next few days.

  6. on 18 Jun 2012 at 2:00 pmRichard

    Very professional explanation! If you understand HW loadbalancing theory + add the NAT into the picture = you are at expert level, way above the average IT admins.

  7. on 19 Jun 2012 at 7:02 amEric

    I agree with Richard, very professional !

    A similar post explaining access from a corporate environment to Lync Online would be tremendously helpfull.
    There seem to be a ton of questions with little to no answers when you try to "translate" the Lync 2010 info to Lync Online.

    For example…
    – What can or can't I use the corporate BlueCoat SG proxy for ?
    – Can I open the firewall only for the Lync UDP ports and use the Bluecoat as forward proxy for all TCP traffic (including Lync)?
    – Or can all traffic be routed via the proxy and UDP be blocked at the internet perimeter ? Or will that result in reduced functionality (like no more A/V, but still functioning chat) ?

  8. on 18 Aug 2012 at 10:05 pmLipozene

    Outstanding blog post, I have marked your site so ideally I’ll see much more on this subject in the foreseeable future.

  9. on 21 Jun 2012 at 5:27 amJai

    Great explanation

  10. on 16 Jul 2012 at 2:00 pmAdrian

    This is a very professional explanation! Thank you! Iflexion

  11. on 08 Aug 2012 at 9:30 amMyrcin

    Hi Elan, many thanks for this great article. There is an option to use a single IP address for all Lync Edge services (Access, WebConf and A/V). Of course I would have to use different ports for each service. Is it possbile to use the same option when using HLB? All vendors say that for Edge pool of two Lync Edge servers 9 Public routable IPs are required. I wonder if 3 IPs would be enough if we use “Use a single FQDN & IP Address” option?

  12. on 08 Aug 2012 at 2:10 pmElan Shudnow

    Asked this same quesiton to Microsoft when Lync first came out. They said the single IP model can work for both DNS Load Balancing and HLB. The problem you will encounter, is everything documented out there including HLB documentation is all based off of the 3 IP model. So it's probably more of a headache than it's worth by trying to save 2 IPs.

  13. on 15 Oct 2012 at 11:15 amRaul

    Hello Elan, thank you very much for this great article!
    I have a single OCS 2007 Edge Server. I have never configured the A/V for external users due to the requirement of IP Public on the network interfaces of the Edge Server.
    Now I'm planning to migrate to Lync 2010. I will maintain a single Edge Server. I want to enable A/V for external users without setting Public IP to the edge server network interfaces. Is it possible? By your explanation, I have understood that now (with Lync 2010) it is possible, but I would prefer your confirmation.
    I also have the doubt about if I can have a single public IP address on the firewall with three different ports and NAT the traffic to three different NICs on the Edge Server.
    Thank you very much!

  14. on 15 Oct 2012 at 6:12 pmElan Shudnow

    Raul, yes you can NAT with a single Lync 2010 Edge Server. In Lync 2010, you also have the option to use 3 IPs as was the case with OCS 2007 and a single IP for all 3 roles. The recommended method in Lync 2010 is to use 3 external facing IPs and NAT all 3. This is the Microsoft recommended method and is the documented method in regards to how to open firewall ports, etc…

  15. on 16 Dec 2012 at 4:18 amBest cloud hosting

    Awesome piece of the writing shared about Lync 2010 edge servers and IP requirements – NAT vs Public IP which is so effective allocation. I just wanted to comment your blog and say that I really enjoyed reading your blog post here. It was very informative. Keep it up and I’ll be back to read more soon. Thanks :)

  16. on 21 Dec 2012 at 9:37 amDan Sheehan

    This is definitely a lot clearer than most of the write-ups we have seen, and we are hoping you can answer something we seem to be missing.

    Part #1

    We are a little confused when it comes to using a hardware load balancer with our 2 Edge servers, in our case the HLB is an F5 LTM HA pair, and are hoping you can help us sort it out because neither F5 or Microsoft is able to explain it definitively enough for us.

    We see our 2 options as follows:
    #1 – Use the DMZ default gateway of .1 as the default gateway on our Edge servers, and SNAT all traffic coming through the HLB pair to our Edge servers (including AV) so the traffic is returned to the client through the VIP that it is expecting a response from.
    #2 – Use the F5 LTM floating DMZ IP as the default gateway on our Edge servers, and SNAT only Web and Conf traffic (not AV), so all traffic to the client goes back through the HLB.

  17. on 21 Dec 2012 at 9:38 amDan Sheehan

    Part #2
    We have tried #2 and sort of have it working, but this flies in the face of your statement "This means that the Audio/Video Edge Server will respond directly to the client on the Internet and will not return Audio/Video or even Desktop Sharing traffic through the Hardware Load Balancer." Also if using the F5 LTM floating DMZ IP s the Edge Server default gateway is what F5 intended, we aren't sure why they say to SNAT any traffic to the Edge server because all traffic will be routed back out throught the HLB anyway.

    When we tried #1 in the past, we are pretty sure we ran into issues where the AV traffic wasn't working to any clients. We were thinking we needed to SNAT the initial AV connection to the Edge server, so that the return packet to the client would have the source IP of the F5 VIP the client was expect a response from, but we were hoping the information inside the response packet would point the client to the directlty to the Edge Server AV public IP. I.E. Initially go through the HLB for AV communications as a hand off to the Edge server for direct communication to the client.

  18. on 21 Dec 2012 at 9:38 amDan Sheehan

    Part #3

    We are further confused by this statement and were hoping you clarify it:
    "By having a Public IP on the Edge and not using SNAT on the Hardware Load Balancer for the Audio/Video IP, it allows the Hardware Load Balancer to respond to the client to respond directly to clients negating the UDP problems mentioned and allowing a better Audio/Video experience with the client being able to talk directly to the Lync Server 2010 Edge Server’s Audio/Video Public IP."
    Specifically the statement "it allows the Hardware Load Balancer to respond to the client to respond directly to clients". I.E. There seems to be 1 too many "to responds" in there and we aren't following what you are meaning.

  19. on 21 Dec 2012 at 9:39 amDan Sheehan

    Part #4 – sorry for breaking it up like this, your website made me do that. :-)

    To summarize our confusion, in a HLB configuration, what should the Edge servers use as their default gateway (the F5 LTM floating VIP or the DMZ Default Gateway), and should any of the AV traffic (including maybe just the initial connection) be SNATed.
    If the answer is to use .1 as the Edge server default gateway but to to not SNAT the AV traffic at all, how will clients react to initially sending AV packets into the F5 LTM VIP for AV, and a response comes from a completely different IP in the same subnet (I.E. The Edge server).

    Thanks Elan!!!

  20. on 11 Jan 2013 at 8:42 pmMichael

    Does this also apply to Lync 2013?

  21. on 06 Feb 2014 at 8:11 pmchris

    I would also like to confirm if all of this still applies to Lync 2013? Thank you.

  22. on 12 Feb 2014 at 5:14 amIan Arakel

    Hi Team,

    We have an issue in our setup.

    We are from the firewall admin team and in close sync with the Exchange team to fix the issue.

    Below is a summary of the issue:

    1.
    We are trying to initiate desktop sharing from Public internet to a user within our corporate setup.

    2.
    The observation is that the desktop sharing fails with an error "Sharing failed due to network issues, please try later".
    The communication right now is between the external server (IP: A.B.C.D,Private IP:192.168.4.x) to the Lync server in the DMZ range (Public IP: E.F.G.H,Private IP 172.31.32.X)

    3.
    The firewall logs suggest that the return traffic from the edge server 172.31.32.x was hitting the private IP 192.168.4.x of the external server which should not be the case since the communication should happen with its public IP(A.B.C.D).
    Please note 192.168.x.x is our internal zone subnet of our corporate setup.

    We referred the below link: http://social.technet.microsoft.com/Forums/lync/e

    It states the dependency of the same on STUN/TURN process.

    Could someone please help us out here????

Trackback this post | Feed on Comments to this post

Leave a Reply