I changed the rewriting policies to "Rewrite content (auto-detect content type)" but the results are the same.
ok; i wasnt sure if that would fix it, but now you are in a spot where it could work...but sounds like it is not. if you trace on ther internal port, do you see the traffic successfully going through?
Once I get the client on Lync by connecting it internally first, we can successfully use lync externally through the MAG. It's just the initial connection that keeps failing through the MAG.
Just the initial setup (which is trying to authenticate) is what fails. Once that's done, I can turn off wifi and power cycle the phone and and launch the app and it works just fine.
All the communication is client side. Nothing is initiated from the server..
That is what I was afraid of (though I am glad to hear once it is authenticated it works). If you take a TCP dump on the IVE port you are connecting to, do you see anything coming from your client IP on a non-443 port; at the same time, do you see anything odd coming from the Lync server at the same time as you are trying to register?
I was alerted by the collegue on this discussion.
Could you take a ssldump at MAG for the failed and working scenario, so that I can take a look to see what's the problem.
I just sent support a request to reopen case 2012-0229-0798. I also attached the log files request to the email to support, so hopefully they make it into the case. I will also PM you with the logs if you want. Let me know.
We were never able to get mobility to work through the Juniper SSL using a standard configuration in Lync. We're running the same MAG release you're running. The problem we had is that we could not get the proxy request to access the External Website in lync on port 4443 (We're using a director which complicates things further). Without this working, external meetings, external conferencing, external whiteboarding, and mobilty will not work because the remote clients are always pushed to the external proxies which would not work). When we changed the proxy on the mag to hit the backend host on port 443, it passed through without issue. I did not want external requests hitting that site because I assumed the external site is configured differently in IIS security wise.
However, I have used a work around that has allowed me to get this all to work, including mobility. Users can access all portions of Lync internally and externally. In order to do so, you have to modify the external website settings in IIS to listen on a different Internal IP address than the Internal Website. By default, both IIS sites listen to any unassigned address, they're distinguished by ports. What we did is bind another IP address to the server and change the external to the second IP and had it listen on 443 and 80. We had to do this on the director and Lync FE. We then used host entries on the MAG to proxy to those IP's rather than the DNS entries to make sure the MAG would send to the external website. I did verify this using IIS logs. Requests are going through.
Unfortunately, there is nothing in the Lync Topology builder that allows you to specify a different IP address for external services. However, I think those settings are only pushed down to IIS on the initial configuration. I can report that everything is working normally. If you need or want anymore details, you can reply to this thread or email me at email@example.com. I'm logged into this board via the MAG admins account.