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:
Firewall
| Interface | IP, Network | Comments |
| 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 |
Server Lync1
Lync 2013 Standard Edition Frontend Server. Clients are registered on this server. IP Address 192.168.x.57
Server Lync2
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.
Firewall rules
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.
DNS records
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
Zone domain.local
| Record | IP/Alias/SRV | Reason |
| 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 |
Zone publicsip.com
| Record | IP/Alias/SRV | Reason |
| _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
Zone publicsip.com
| Record | IP/Alias/SRV | Reason |
| _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 |
It looks like you’re Natting a public IP to the Lync front end-server. This method introduces unnecessary risk, even with deep packet inspection.
If you’re going to skip the DMZ for the reverse-proxy, why bother with an access-edge server? Natting a public IP to the Lync front end-server introduces unnecessary risk, even with deep packet inspection.
I also suggest you create a separate subnet for the perimeter interfaces:
WAN:212.x.y.29
Access Edge NIC1: 10.10.x.58 (DMZ)
Access Edge NIC2: 172.16.1.1/30 (Perimeter)
Front-End NIC2: 172.16.1.2/30 (Perimeter)
Front-End NIC1: 192.168.x.57 (Inside)
On the Access Edge server:
1. Change host file to match internal Lync DNS references.
2. Add persistent static routes on Access Edge server to forward Lync and OWA IPs.
3. Do the same thing for the reverse-proxy server.
Cheers!
Thanks for your input, I’ll give it a shot (once I got time 🙂 )
Just wondering how u installed SSL certificates in this type of configuration particularly public purchases SSL certificates
Created the CSRs from the console, copy/pasted them in the registrar’s web form and that was that. Or am I missing your point?
Sorry wasn’t exactly clear, u have three sections to assign a certificate in Lync 2013, Internal, External and Server Default
I know this setup in Lync 2010 without a reverse proxy you assigned a public cert to the external site only
Is this the same what you did in your setup for Lync 2013?
Pretty much, yes. Other than the few things I did on my firewall to avoid having a reverse proxy, the Lync setup is absolutely standard. Meaning I created the config, published it, started the setup on the servers and went through the normal certificate request/download/install procedure.
The complete list of reverse proxies tested with Microsoft is listed here: (click on Reverse Proxy)
http://technet.microsoft.com/en-us/lync/gg131938.aspx
F5 Networks has also been added to the list