Certificates are very important. Correct public certificates must be implemented on the Edge and the Reverse Proxy. The Edge Server additionally requires an internal certificate. This ensures the correct proxying, or better said the application firewall functionality. The Reverse Proxy also needs a public certificate and must be able to recognize the internal web services-assigned certificates. The correct infrastructure is needed to ensure the HTTPS and TLS traffic will work.

The minimal deployment consists of a single Lync Edge Server and a Reverse Proxy Solution as illustrated above.

Based on the DNS entries, the clients are enabled by accessing the associated component – the Edge or Reverse Proxy. The Reverse Proxy listens on TCP port 443 and simply redirects the traffic to the internal IIS server on TCP port 4443, while it inspects the HTTPS stream, repacks and re-encrypts the traffic with the certificate assigned to the external web service web site.

The Lync Edge server acts slightly differently. It still needs a valid public certificate so that the incoming, as well as the outgoing stream, can be decrypted. Clients or other Edge Servers need a certificate validation check before accepting TLS traffic encryption. The paragraphs below discuss how Lync handles this traffic.

For example, say that Lync has an incoming SIP request. The external client will contact the Access Edge, which then terminates the SIP connection on its external Access component. Next, the request is processed and the intent is validated. Assuming that it is a user authentication, the Edge server then initiates an outgoing session on its internal Access component, contacting the next hop which was defined in the Lync topology. If anything within this traffic does not match the Lync-specific traffic, for example if there are malformed packages, the Edge Server does not process the request. The Edge Server is a fixed component in this communication path. With the VIA parameter, internal and external (NAT) IP addresses can be seen.

Refer to the example below:

The example above shows the path from client 172.28.91.102 until 10.11.10.84, which is the NATed Access IP of an Edge Server, including the external IP (which is blanked out in the screenshot above). 10.10.10.128 is the internal Front End server. The NOTIFY commands were received by the local client (172.28.91.102). The second Edge Server that is involved is 172.19.45.67, without a public IP address. This is because the log was collected on a Lync client in the internal LAN connecting the internal Edge Access interface and does not need to know any public associated IP addresses.

Two Edge Servers are involved. A SIP Proxy should look like another hop in the communication path. The Lync topology on both environments provides the Edge server with the necessary information relating to where the incoming SIP traffic should be routed first.

As the topology information is only replicated one way, and the Edge Server should be based on Microsoft best practice (meaning DNS should also only be configured on the external NIC and internally, the HOSTS file should be used) this scenario is considered as safe. Even if the Edge Server is compromised – no internal network information can be acquired.