Lync 2013 without Reverse Proxy

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

 

7 thoughts on “Lync 2013 without Reverse Proxy

  1. 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!

  2. 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.

Leave a Reply

Your email address will not be published. Required fields are marked *