SA / MAG 7.1R5 Lync Reverse Proxy Support

[jspanitz_]

We are trying to set up our MAG 4610's as a reverse proxy for MS Lync 2010. We've read through quite a few of the forum threads, specifically https://forums.pulsesecure.net/topic/pulse-connect-secure/109348-configuring-ssl-vpn-as-reverse-prox... and are having very strange results.

Our first question is, is the MAG officially supported by Juniper as a reverse proxy for Lync? We opened a support request and while they worked on the case they seemed to indicate that the MAGs can not reverse proxy from port 443 to port 4443 which is required by Lync. Our testing showed otherwise, but an official stance would be nice.

Second, after setting up Lync and pointing the external urls to a VIP on the MAG, we configured the MAG as such:

Signing In Policies

Virtual Host Names:

• lyncdiscover.domain.com/
• lyncwebext.domain.com/
• meet.domain.com/

All are Auth Only

All have a virtual host name that matches our external DNS entries:

• lyncdiscover.domain.com
• lyncwebext.domain.com
• meet.domain.com

All have a backend URL of https:4443

• https://lyncdiscover.domain.local:4443/*
• https://lyncwebext.domain.local:4443/*
• https://meet.domain.local:4443/*

Authorization Server is set to No Authorization

Role Option is set to a role created for Lync.

ActiveSync is NOT checked

User Roles

Lync Proxy Role:

General | Overview - Only Web is checked

• Web | Bookmarks - 3 bookmarks are mapped from Resource Profiles, one for each URL / Signing In Page
• Web | Options - Under Advanced Options | Allow browsing untrusted SSL websites is checked

Resource Profiles

3 Resource Profiles, one for each bookmark / signing in page

Resource

Type - Custom

Base URL - each set to backend URLs

• https://lyncdiscover.domain.local:4443
• https://lyncwebext.domain.local:4443
• https://meet.domain.local:4443

Autopolicies: Web Access Control - Each set to backend URLs

• https://lyncdiscover.domain.local:4443/* Allow
• https://lyncwebext.domain.local:4443/* Allow
• https://meet.domain.local:4443/* Allow

Autopolicies: Rewriting Options

• All set to - No rewriting

Roles

All mapped to Lync Proxy Role

Bookmarks

All created with URL matching backend URLs

• https://lyncdiscover.domain.local:4443
• https://lyncwebext.domain.local:4443
• https://meet.domain.local:4443

Resource Policies

3 Policies, one for each Resource Profile

Web ACL

• Detailed Rules - Allow HTTPs to backend URLs
• Action - Allow
• Resources - *:*/*

DNS

External DNS is pointed to firewall which NATs to DMZ and external VIPs on MAG

• lyncdiscover.domain.com
• lyncwebext.domain.com
• meet.domain.com

Internal DNS -Split Brain

External FQDNs point to DMZ and External VIPs on MAG

• lyncdiscover.domain.com
• lyncwebext.domain.com
• meet.domain.com

Internal FQDNs point to lync server

• lyncdiscoverinternal.domain.local
• lyncwebext.domain.local
• meet.domain.local

Now the real fun part, we have exactly one mobile device that we were able to get working. We can not duplicate it on any other devices. Can anyone see a problem with our setup and why clients would not be able to connect?

Then we had a different user try to sign in on the working device and it failed. Now the working device no longer works either. Microsoft is blaming the MAGs and I'm thinking this looks more like a Lync issue. Just need to confirm our setup is supported and correct.

[jspanitz_]

Below are the logs from the MAG on a connection attempt from a mobile client:

Info	WEB20174	2012-03-02 10:37:28 - mag1-vpn-pabth - [166.147.111.131] 80eabf0()[PROXY Lync] - WebRequest completed, GET to https://lyncwebext.domain.local:4443//Autodiscover/AutodiscoverService.svc/root/user from 172.28.2.110 result=401 sent=0 received=1293 in 1 seconds
Info	WEB20169	2012-03-02 10:37:28 - mag1-vpn-pabth - [166.147.111.131] 80eabf0()[PROXY Lync] - WebRequest ok : Host: lyncwebext.domain.local, Request: /Autodiscover/AutodiscoverService.svc/root/user
Info	WEB20174	2012-03-02 10:37:27 - mag1-vpn-pabth - [166.147.111.131] 80eabf0()[PROXY Lync] - WebRequest completed, POST to https://lyncwebext.domain.local:4443//WebTicket/WebTicketService.svc/Auth from 172.28.2.110 result=200 sent=1353 received=5144 in 1 seconds
Info	WEB20169	2012-03-02 10:37:27 - mag1-vpn-pabth - [166.147.111.131] 80eabf0()[PROXY Lync] - WebRequest ok : Host: lyncwebext.domain.local, Request: /WebTicket/WebTicketService.svc/Auth
Info	WEB20174	2012-03-02 10:37:27 - mag1-vpn-pabth - [166.147.111.131] 80eabf0()[PROXY Lync] - WebRequest completed, GET to https://lyncwebext.domain.local:4443//Autodiscover/AutodiscoverService.svc/root/user from 172.28.2.110 result=401 sent=0 received=1293 in 0 seconds
Info	WEB20169	2012-03-02 10:37:27 - mag1-vpn-pabth - [166.147.111.131] 80eabf0()[PROXY Lync] - WebRequest ok : Host: lyncwebext.domain.local, Request: /Autodiscover/AutodiscoverService.svc/root/user
Info	WEB20174	2012-03-02 10:37:26 - mag1-vpn-pabth - [166.147.111.131] 80eabf0()[PROXY Lync] - WebRequest completed, POST to https://lyncwebext.domain.local:4443//WebTicket/WebTicketService.svc/Auth from 172.28.2.110 result=200 sent=1353 received=5144 in 1 seconds
Info	WEB20169	2012-03-02 10:37:26 - mag1-vpn-pabth - [166.147.111.131] 80eabf0()[PROXY Lync] - WebRequest ok : Host: lyncwebext.domain.local, Request: /WebTicket/WebTicketService.svc/Auth
Info	WEB20174	2012-03-02 10:37:25 - mag1-vpn-pabth - [166.147.111.131] 80eabf0()[PROXY Lync] - WebRequest completed, POST to https://lyncwebext.domain.local:4443//WebTicket/WebTicketService.svc/mex from 172.28.2.110 result=200 sent=348 received=18461 in 1 seconds
Info	WEB20169	2012-03-02 10:37:25 - mag1-vpn-pabth - [166.147.111.131] 80eabf0()[PROXY Lync] - WebRequest ok : Host: lyncwebext.domain.local, Request: /WebTicket/WebTicketService.svc/mex
Info	WEB20174	2012-03-02 10:37:25 - mag1-vpn-pabth - [166.147.111.131] 80eabf0()[PROXY Lync] - WebRequest completed, GET to https://lyncwebext.domain.local:4443//Autodiscover/AutodiscoverService.svc/root/user from 172.28.2.110 result=401 sent=0 received=1293 in 0 seconds
Info	WEB20169	2012-03-02 10:37:25 - mag1-vpn-pabth - [166.147.111.131] 80eabf0()[PROXY Lync] - WebRequest ok : Host: lyncwebext.domain.local, Request: /Autodiscover/AutodiscoverService.svc/root/user
Info	WEB20174	2012-03-02 10:37:24 - mag1-vpn-pabth - [166.147.111.131] 80b4938()[PROXY Lync] - WebRequest completed, GET to https://lyncdiscover.domain.local:4443//[email protected]com from 172.28.2.110 result=200 sent=0 received=437 in 0 seconds
Info	WEB20169	2012-03-02 10:37:24 - mag1-vpn-pabth - [166.147.111.131] 80b4938()[PROXY Lync] - WebRequest ok : Host: lyncdiscover.domain.local, Request: /[email protected]

[dcvers_]

We spent months trying to get Lync to work then gave up and got quotes for Microsoft TMG reverse proxy. Management saw the cost and told us to get it work via the the Juniper. We started again and it worked first time. Crazy!

I think one of the issue is I believe there are different way the backend Lync environment can be set up (never got a clear answer from the Lync experts on this). Originally we were told similar destinations to yours "meet.xxx.yyy" etc but the second time the Lync guys told us "join.xxx.yyy".

In the end our working config was very simple:

4 Auth only policies:

join.xxx.yyy to join.xxx.yyy:4443
dirpool.xxx.yyy to dirpool.xxx.yyy:4443
fepool.xxx.yyy to fepool.xxx.yyy:4443
lyncdiscover.xxx.yyy to lyncdiscover.xxx.yyy:4443

And role with associated resource policy allow the above desinations plus the backend servers actual names

One point to note is we a currently running 6.5R4.1

[jspanitz_]

Can you elaborate any more on your configuration. Are your Mags external and internal nics both behind firewalls? What about your DNS, is your internal and external namespace the same or different?

It's a shame Juniper doesn't do a better job with communicating out supported configurations for well known apps. It makes us question our move from Cisco.

[dcvers_]

We're actually still on the old SA hardware but this shouldn't make a difference.

Yes both internal and external NICS are in DMZs behind firewalls. The DNS is split in the sense that externally the DNS points to VPN boxes and internally the same names are alisas pointing to the Lync boxes. We did try with different internal names but it didn't work. The Lync team told me it is the port (4443) that Lync uses to decide if the client is internal or external.

[zanyterp_]

Using the authorization only URL for anything other than ActiveSync is not supported. With that said, some applications do work successfully. If something does not work, depending on the failure point, we will work on a case-by-case process to find a solution.

The user access log you posted showed that the failure is specifically tied to authentication; a 401 is being sent back. What do users see? Is this on a mobile device or full desktop? Does Lync require direct access from the server to the PC?

I also see you listed that you noted that you have a no rewriting policy configured; was that a typo? If you choose to not rewrite, the traffic will be redirected for direct access. If the server is internal only, this won't work; you must rewrite the traffic to send through the MAG (unless you have a rewrite policy listed above it that takes precedence).

Lync is not a supported application, meaning it is not something we have access to for testing in QA. I don't think there have been any requests to get this in any type of standard testing. If you would like to see this supported, please let your account team know. 

In the meantime, though, we can help out here or through JTAC.

[jspanitz_]

zanyterp - thanks for the info. i would suggest that the web gui and documentaiton be updated since the current set does not indicate that signing-in pages with virtual hostnames are only for ActiveSync. Actually, they seem to indicate the later:

Required: Protocol, hostname and port of the server (example: http://www.domain.com:8080). Server paths are not supported.

Either way, I hope we can get this working. Otherwise we will need to look at another reverse proxy solution.

To try and answer your questions, this is being set up for lync mobile (phones) clients. The client is making the connection and gettting the 401 from the server. Strangely, we've somehow gotten 1 and only 1 client working through a mix of internal and external testing.

The web resource profiles have Autopolicy enabled with no rewriting. By doing that it looks like a selective rewriting resource policy was created.

The automatically created selective rewriting policies defined have an action of "Don't rewrite (with Redirect)"

[zanyterp_]

---

@jspanitz wrote:

zanyterp - thanks for the info. i would suggest that the web gui and documentaiton be updated since the current set does not indicate that signing-in pages with virtual hostnames are only for ActiveSync. Actually, they seem to indicate the later:

Required: Protocol, hostname and port of the server (example: http://www.domain.com:8080). Server paths are not supported.

Either way, I hope we can get this working. Otherwise we will need to look at another reverse proxy solution.

To try and answer your questions, this is being set up for lync mobile (phones) clients. The client is making the connection and gettting the 401 from the server. Strangely, we've somehow gotten 1 and only 1 client working through a mix of internal and external testing.

The web resource profiles have Autopolicy enabled with no rewriting. By doing that it looks like a selective rewriting resource policy was created.

The automatically created selective rewriting policies defined have an action of "Don't rewrite (with Redirect)"

---

Thank you for the information on what you are doing. I agree on the documentation.

OK; that resource profile needs to be fixed (unless you want the connection to go over a VPN tunnel). The don't rewrite policy renders the authorization only URL that you have configured moot; it is sending the client to the backend server directly. The authorization only policy is based on the rewriting engine; if you don't rewrite traffic, it will not be accessible. What happens when you remove that policy?

[jspanitz_]

You want me to remove the auth only sign policy? What type of sign in policy would we use then?

[zanyterp_]

No; the auth only sign in page is fine. What you need to remove is the rule for "dont rewrite, redirect" and replace it with a "rewrite" policy so that the traffic is rewritten and sent through the IVE.