Optimized External Access Path

Another strong benefit of using a Director is its capability to serve as a barrier between internal pools and external traffic. To understand the benefit here, it is important to know that Edge servers do not authenticate external user requests across the Internet and merely pass this traffic to a next-hop internal server to handle authentication. This means that without a Director all external traffic is being authenticated by a Front End pool, or in other words, anonymous Internet traffic is being allowed to communicate with an internal domain member server.

Instead of allowing authentication requests from an Edge server to pass directly to a Front End pool, a Director can be placed in between this communication path and used to authenticate users before external traffic ever reaches a Front End server. This doesn’t change the fact that an internal domain member is accepting unauthenticated traffic, but it does provide some protection for Front End pools because traffic will never get through the Director without being authenticated.

A Director can also help simplify the federation and remote access paths for SIP traffic within an organization. Instead of requiring firewall rules for SIP between all Front End pools, a Director pool can be specified as the outbound federation route. This means that all Front End pools send their remote traffic to the Director first, which then communicates with the Edge servers. This scenario is depicted in Figure 9.2 where the Director stays within the communication path at all times to ensure that the internal pools are protected. This topology also helps with troubleshooting efforts because the signaling path is more predictable, and reduces the number of firewall rules required.

Figure 9.2. Director placement for Edge services.