Publicly routable IP address needed for A/V Edge server

When deploying OCS 2007 in a environment where you wish to have remote users (i.e. users outside of your network) still be able to use the services you will need to deploy an Edge Server. The Edge Server was known as the Access Proxy in LCS 2005. Much like the front end pool of OCS 2007, the Edge Server can scale to the needs of your environment and can be deployed in a consolidated mode (all roles on one server) or expanded mode (seperate servers for each role). The roles for the Edge Server are the Access Edge Server, Web Conferencing Edge Server, and A/V Edge Server. The Access Edge Server is essentially the same thing as the Access Proxy of LCS 2005 (with improvements). The Web Conferencing Edge Server allows remote and anonymous users to attend web conferences that are hosted on your OCS environment. The A/V Edge Server allows remote users to participate in audio and video communication. The external network interface for the A/V Edge Server must use a publiclly routeable IP address and cannot be NAT'ed.

This often solicits a gasp by the network security people. So, I'd like to try to explain what we are doing to make this work and why it is not as big of a security risk as some may think. First, we have to dispel of the notion that NAT equals security. It doesn't. The security risk is the application bound to the port, not knowing the IP address to the application. In other words, teaching a dog to meow doesn't make a cat feel any better. If NAT is your sole means of security from the Internet then you better start planning for IPv6 now because NAT doesn't exist in the IPv6 world. What's that you say??? How can that be??? You see, non-routeable addresses were not invented for security. They were invented to expand the number of users on the Internet without running out of addresses. Since the Internet has continued to grow beyond what non-routable IP addresses can help solve, IPv6 has been adopted. IPv6 is an exponetial leap in the number of addresses available, so we no longer need non-routable IP addresses anymore. So, NAT won't exist in IPv6 either. All addresses will be routable.

OK, so I'm not using IPv6 now and you're still making me use a public IP address on the A/V Edge Server. That is true and it is because of the technology Microsoft is using to allow A/V to traverse firewalls and the Internet. In particular we are talking about ICE (Interactive Connectivity Establishment) which is a draft standard being considered by the IETF and co-authored by Microsoft and Cisco. ICE makes use of two protocols, STUN (Simple Traversal of UPD through NATs) and TURN (Traversal Using Relay NAT).

So, if we look at the RFC for STUN (RFC 3489) we see that STUN assumes that the server exists on the public Internet. If the server is located in another private address realm, the user may or may not be able to use its discovered address to communicate with other users. There is no way to detect such a condition (RFC 3489 Section 14.3). STUN imposes some restrictions on the network topologies for porper operation. If client A obtains an address from STUN server X, and sends it to client B, B may not be able to send to A using that IP address. The STUN server must be in the network which is a common ancestor to both - in this case, the public Internet (RFC 3489 Section 14.3).

Again, this is not something that has been developed by Microsoft by itself. It was co-authored with Cisco to help overcome NAT traversal for UDP traffic. Any other application that uses STUN will have the same requirements.

Comments (12)
  1. Anonymous says:

    Generic for lexapro. Lexapro weight gain. Bipolar and lexapro. Lexapro. Side effects of drug lexapro. Lexapro side effects. Lexapro abuse.

  2. Anonymous says:

    Chad and I work together so his blog will be another great one to monitor. As we are in the same site

  3. chlacy says:


    I agree with your point about the usefulness of a firewall. Using a publicly routable IP address doesn’t mean you can’t have the machine behind a firewall. What you can’t do is NAT the interface to a non-routable IP address. The reason for this is when the server and the client are negotiating, the server will respond back with its IP address and port. So, if the server has been deployed with a 192.168.x.x IP, it will send this information to the external client who then cannot reach the server. Your firewall just needs to be set up to have the needed ports open to that IP address. I hope this makes a little more sense.

  4. chlacy says:

    STUN / TURN are assigned to the client via in-band provisioning. At one point there were some registry setting to set these servers, but I believe they have been removed.

  5. chlacy says:

    This is a common question. Security folks have been lulled into a false notion that NAT equals security and that open ports are explotation vectors. The best way I know to explain that in our case the wide range of ports provide more security is to explain that first and foremost, nothing is actively listening on these ports. This is very different than most of applications that need ports opened up on the firewall. So, right off the bat we can show that open these ports on the firewall has not reduced security at all because nothing is listening. These ports get opened only after a client connecting through the edge server requests an A/V session. OCS will then tell the client, I’m going to open up port #XXXX for you to use. Then and only then is anything listening on that one port and when the A/V session is closed, the port goes back to an inactive state.

    So, you are saying to yourself, if I can intercept this negotiation of ports between OCS and the client then I can attack the port. Sorry, that communication is encrypted. What does this mean? In order to effectively use these ports to attack a network you need to be able to break the encrypted traffic, spoof the pakcets being sent and impersonate authentication and hit the port exactly when it is open. And htis all has to take place while that A/V session is established becuase that door is going to close.

    You can see that if I only had one port open I would be much more vulnerable to attack. With just one port I have established a known vector. The biggest part of the equation has already been answered. Now I just have to wait for the right time. With such a wide range of ports to use, it is more random and harder for the bad guy to anticipate.

  6. chlacy says:


    I’m not sure where you are reading that you need a routable IP address on the private interface. If I have mislead you, then I appologize. The routable IP address must be on the public interface or external interface as the documentation reads.

  7. Gene says:

    Does anyone know how to assign the STUN / TURN servers in Office Communicator 2007 so it can communicate with others that are also behind a NAT ?

    Thank you!

  8. lars says:

    What are the recommendations when it comes to security. The server itself is not easy to lockdown if you need port 50000-59999 open. Can this be deployed on a standalone server? What would you think would be the best argument to sell the public ip to security people and costumers.

  9. Brian says:

    If the server is on a public ip and not behind a firewall then the ability to know the source IPs have been diminished.  

    NAT does not equal security, I agree but I get two things that giving the server a straight public IP does not offer.  1 – The firewall can only allow ports xx-yy to be allowed.  I would not have to worry about the OCS guy deciding to run a FTP server on that system, because that port is not being allowed out the firewall. 2 – The ability to log the source ip addresses into the firewall log is another advantage.

  10. carsten says:

    Why Do I need a public IP on the private interface?

  11. Vlad says:


    The question I have is about a routable IP address on the private interface. Are you telling it can be NATed?

    Here is quote from Microsoft Edge Server Deployment guide:


    To conform to the requirement of a publicly routable IP address of the A/V Edge Server, the external firewall of the perimeter network must not act as a NAT (Network Address Translator) for this IP address.

    Additionally, the internal firewall must not act as a NAT for the internal IP address of the A/V Edge Server. The internal IP address of the A/V Edge Server must be fully routable from the internal network to the internal IP address of the A/V Edge Server.

    Any commects?

  12. Ath-x64 says:

    My problem with this is that it leave small businesses out of the equation and requires a more expensive (and complex) hardware to work.

    lets not mention the fact that the server now sits outside any protection my firewall might offer. This is a VERY foolish move by MS.

    They have alienated many customers that might not want to pay extra for an additional IP or 3 (since each edge server type requires its own unique IP).

    There is no reason not to allow this to be NAT’d even L2TP can be NAT’d all the cever words will not remove the glaring mistake MS has made by forcing the edge server on the world. This includes the Edge server in Exchange 07.

    I am not sure where you are getting that NAT will go away with IPV6, Internal mnetworks will still need some sort of NAT to allow for multiple hosts to use the same gateway. otherwise all internal IPs would be acessible from the internet.

Comments are closed.

Skip to main content