Lync 2013 (and 2010 for that matter) documentation recommends using a Reverse Proxy to abstract the Lync Server Front End Web Services from the baddies on the outside world. A cursory look at a Lync Front End Server will reveal that the Lync Server installation process does indeed create two websites. But what is the difference? What might be the possible reasons for having two websites?
Here is a typical Lync EE pool server IIS manager showing the Lync Web Services.
Two websites. Because the websites are both using the same IP address, different ports are needed. If you look at the binding for each you will see the External answering on ports 8080 and 4443 while the Internal is setup on 80 and 443.
Because we are exposing our internal server we want the Reverse Proxy to stop traffic and play fetch for us. Understandable, yes? Because we have two websites that are different but on the same IP, we need different ports. Again, understandable. But if you look at the following eye-chart – you can also see that there are differences in the virtual directories. The Internal virtuals down below that are different from the external website (in addition to, and similar but named differently) simply have no business being exposed to non-internal users; I think the virtual directory names provide all the clues you need to agree with that assessment: CSCP (the control panel), OCSPowerShell, and RGSconfig (Response Group Configuration page) jump out at me.
If your Lync Web Services get their authentication scheme messed up (now how would that happen?) you can also use this handy chart to return the website and virtual directories to their initial state. How convenient is that?
So, we can see that there is a few reasons to have two websites: two websites on the same IP but using different ports, the difference between virtual directories on the internal v external websites, and the content that is not very desirable to expose to external users who just might not be your best friend.