SSL Bridging

The final methodology, which is the preferred scenario, is to use SSL Bridging. In this case, the client’s SSL tunnels at the reverse proxy as in an offloading scenario, but the reverse proxy then opens a second HTTPS connection back to the internal resource. This ensures that the entire transmission is encrypted from end to end.

There is also some added flexibility in this case, in that a reverse proxy can redirect that second connection to a port other than 443 back on the internal resource without the client’s knowledge. As far as the client knows, it still has a connection on port 443 to the internal resource, even though the reverse proxy might bridge this connection to port 4443 on the internal Front End pool. Figure 31.10 shows where the reverse proxy bridges a port 443 connection from the client to port 4443 on the Front End pool, but still secures the traffic.

Image

Figure 31.10. SSL bridging.

To summarize the options, the preferred method for Lync Server is SSL Bridging to ensure an end-to-end encryption of the traffic with the most flexibility. SSL offloading is not supported, so if bridging is not an option, the reverse proxy deployment should use SSL pass-through.

Note

A common question is to ask whether a reverse proxy is actually needed, or whether an organization can simply do a port translation at the firewall to a Front End pool. Though technically possible, this scenario is entirely unsupported by Microsoft and should be avoided. Not using a reverse proxy also means that public certificates might need to be placed on the Front End Servers because they will communicate directly with Internet users.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset