The official way to publish Lync 2013 services involves a reverse proxy. This little guide will show you that it’s possible to do without. However, this is only appropriate for lab environments. Since Forefront TMG is no longer an option, Microsoft recommends using IIS ARR; a guide can be found here.
Having said all that, here’s a way to do this all using a firewall. My servers and firewall/network layouts are as follows:
|WAN||212.x.y.30, NAT to Lync 2013 Frontend||IP 192.168.x.57 (Internal Network)|
|WAN||212.x.y.29, NAT to Lync 2013 Edge||IP 10.10.x.58 (DMZ Network)|
|Internal||Internal clients and servers, 192.168.x.y/24||Home of “lync1”, 192.168.x.57|
|DMZ||DMZ network, 10.10.x.y/24||Home of “lync2”, 10.10.x.58|
Lync 2013 Standard Edition Frontend Server. Clients are registered on this server. IP Address 192.168.x.57
Lync 2013 Standard Edition Consolidated Edge Server. Used for Federation and Public IM Connectivity (PIC), e.g. Skype connectivity. Not an AD member server, IP addresses are 192.168.x.58 (internal network) and 10.10.x.58 (DMZ network). Default Gateway has to be 10.10.x.1, which means the network adapter with the 192.168.x.58 address has no default gateway specified. This address is only used to forward edge traffic to the Lync1 server.
There are several ports that need to be published both for external user access (to the Frontend Server) and Federation/PIC (to the Edge Server).
|Public IP||Public Port||Private IP||Private Port||Reason|
|212.x.y.30||443/TCP||192.168.x.57||4443/TCP||Lync Web Services, Dial-In, Web App, Address book|
|212.x.y.29||441-443/TCP||10.10.x.58||441-443/TCP||A/V Edge (441), Web Conferencing (442), Access Edge (443)|
|212.x.y.29||5269/TCP||10.10.x.58||5269/TCP||XMPP (eXtensible Messaging and Presence Protocol) Federation|
|212.x.y.29||3478/UDP||10.10.x.58||3478/UDP||STUN, required for PIC|
|212.x.y.29||5061/TCP||10.10.x.58||5061/TCP||SIP, for federated connectivity|
As you can see, I’m cheating a bit with the first rule. On the public interface, I’m receiving HTTPS traffic on port 443, which I redirect to port 4443 on the Lync server. This is where you would normally place a reverse proxy, which on its public interface would accept port 443 and proxy it to destination port 4443. I have taken some precautions on the firewall, so I think I’m safe enough, plus this is only a test environment, NOT a supported scenario.
My AD domain name (“domain.local) and SIP domain (“publicsip.com”) name are not the same. For that and other reasons I’m using split DNS, which means that the SIP domain name exists on both the internal and an external DNS server.
Internal DNS Server
|lync1||192.168.x.57||A Record, Frontend Server|
|lync2||192.168.x.58||A Record, Edge Server|
|lyncdiscoverinternal||lync1.domain.local||Autodiscover Record, internal Win8/Mobile clients|
|_sip._tls||lync.publicsip.com||SRV Record, target port 5061|
|_sipinternaltls._tcp||lync.publicsip.com||SRV Record, target port 5061|
|lync||192.168.x.57||A Record, Frontend Server|
|lyncdiscover||212.x.y.30||Internal Mobile Client connectivity (yes, they connect to public IP!)|
|lyncdiscoverinternal||192.168.x.57||Internal Lync Client connectivity (autodiscover)|
External DNS Server
|_sip._tls||sip.publicsip.com||SRV record, target port 443|
|_sipfederationtls._tcp||sip.publicsip.com||SRV record, target port 5061|
|sip||212.x.y.29||A Record, Edge Server|
|lyndiscover||212.x.y.30||A Record, Frontend Server|