Edge Server Internal NAT Deployment


  • I am deploying Lync 2013 for the first time and while examining the documentation found, what I believe to be, a strange requirement. It says that the edge server needs to have at least two IPs, one external and one internal. The external can be NATed to a public IP, but the internal must remain the native IP end-to-end. This seems odd as the scenario for the edge server is in the DMZ and servers in the DMZ, by design, reside in an island.

    As an example, here is my setup. I have a proxy firewall for the DMZ. The flow of traffic works like this:

    External Traffic

    Edge Server ( --> Proxy Firewall (NAT: --> Firewall (NAT: --> Internet

    Internal Traffic

    Edge Server ( --> Proxy Firewall (NAT: --> Intranet

    So, in my scenario 1 IP is configured on the server and traffic is routed and NATed based on the destination. It sounds like this configuration will not work with Lync for two reasons: The internal and external IPs need to be on separate subnets, and the internal IP cannot be NATed. I am seriously hoping that I am mistaken and just missing something, because if I give direct access to the 192.168.5.x network from my internal network, I have just broken my DMZ and defeated the entire purpose of it.

    Can anyone help me out on this because it is going to make it impossible to use Lync and I just have a hard time believing enterprise software wouldn't support an enterprise network configuration. If I have an externally accessible server, it needs to live in the DMZ, period. It cannot live in the internal network and it cannot straddle the DMZ and internal networks. Thanks for any and all help!

    Tuesday, November 26, 2013 12:59 AM

All replies

  • You'll need an External DMZ and an Internal DMZ then.

    External Traffic (External DMZ)

    Edge Server ( --> Proxy Firewall (NAT: --> Firewall (NAT: --> Internet

    Internal Traffic (Internal DMZ)

    Edge Server ( --> Firewall --> Intranet

    Firewall rules:

    Internal Interface of the Edge server must be routable and not NAT.

    Tuesday, November 26, 2013 2:20 AM
  • So this answers my question, I suppose. Lync does not support the DMZ. What is described here is straddling the DMZ and internal network, which breaks security rules. If the DMZ is directly accessible by the internal network it is not a DMZ, but just another VLAN. So I need to create a security exception for Lync to function properly.

    Unless there is a better way? I'm not ready to mark this as an answer because I'm hoping for a solution that fits a secure network model.

    To be clear, I know that some will argue that what is proposed is still secure, but a DMZ by definition is a wholly separate network from the internal and external networks. What is proposed is not that and does not meet compliance standards for my company (and I would be shocked if this is how major corporations, including Microsoft, are deploying edge servers).

    Tuesday, November 26, 2013 2:47 AM
  • The DMZ is not accessible directly by the internal network.

    You need to create persistent static routes on the Lync edge internal interface to all internal networks where clients.

    Lisa Zheng
    TechNet Community Support

    Wednesday, November 27, 2013 12:15 PM
  • Agree with Michael and Lisa. Internal interface should be routable. Very limited firewall ports (5061) to be open from internal DMZ interface to the Front end server / director servers and a wider range of ports from the internal clients to the internal DMZ interface to be open for outbound traffic.

    To minimise the security concerns - no DNS or gateway to be specified on the internal NIC config. but to create persistent static routes to the internal client vlan's.

    If you see a post that helped you please click "Vote as Helpful" and if it answered your question, please click "Mark as Answered.

    Murali Krishnan | My blog: UnifiedMe | Twitter: @mkris9

    Wednesday, November 27, 2013 12:28 PM
  • It does not look like Lync supports my network topology and I cannot stress enough how bizarre that is. The responses to my original question have been the same: I must have a server that straddles the external and internal networks through my DMZ, which is not only a bad security practice but also more prone to network issues.

    As I said before, a DMZ is a wholly separate network that is not directly accessible from external and internal networks. It is directly accessible when there is no NAT in place, regardless of firewall rules. Lync supports NAT for the external interface but not for the internal, which means I must expose my separate DMZ IP space to my internal network, making it directly accessible.

    Since I find this so hard to believe, I'm going to try it anyway. I plan to build a small pilot deployment consisting of an Edge, Front End, Back End, and Mediation server. I will attempt to get the Edge server to work through NAT in a consistent and predictable manner and if I succeed, I'll document the process. If I fail, then Lync is off the table.

    I appreciate the responses, thank you. If anyone has any additional insight or suggestions, I welcome them. Has no one ever come across this problem before? Is my company unique in how we manage the DMZ network, because that just seems absurd.

    Wednesday, November 27, 2013 3:36 PM

    explains why NAT is not recommended.

    I have worked on deployments similar to yours and have had 'some' success with NAT. The reason why I say 'some' success is because the AV failure rate was about 12% which was higher than the accepted 1.5% for the organisation. You are more than welcome to try it and it might work - but there is always the difference between "what does work" and "What is officially supported" .

    Let us know how it goes.

    If you see a post that helped you please click "Vote as Helpful" and if it answered your question, please click "Mark as Answered.

    Murali Krishnan | My blog: UnifiedMe | Twitter: @mkris9

    Wednesday, November 27, 2013 3:51 PM