No matter you use which version of Lync Server（Skype for business) and so on.

It's very important to understand the following content


from http://www.shudnow.net/2012/04/25/lync-2010-edge-servers-and-ip-requirements-nat-vs-public-ip/

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.