Nginx as reverse proxy for Exchange 2010 OWA + Lync Web App Integration

The main advantage in using ISA Server as a reverse proxy is for security, but of course it makes a lot more sense if you have more than a single application to publish; if you only need to make your Exchange CAS server(s) available from the outside, maybe buying, implementing and managing ISA is a bit overkill.

Using ISA, instead of plainly forwarding TCP port 443, offers the following advantages:

• Pre-authentication. Users can be authenticated by ISA Server itself, and then the request will be forwarded to the actual published server only if this authentication succeds; this blocks unauthenticated users from even trying to tamper with your web application, saving you f.e. from possible bugs in the application logon.
• HTTP filtering. Standard HTTPS connections flow through a network firewall without being analyzed at all, because traffic is of course encrypted; with ISA, HTTPS connections are made from the client to the ISA proxy and then re-opened by ISA to the web server, allowing ISA to inspect and sanitize the actual HTTP traffic; this disallows "strange" requests to your published applications, saving you from a whole lot of application bugs (buffer overflows, etc.).
• URL Filtering. If you open TCP port 80 and/or 443 to an internal web server, a client can ask the web server for anything it wants (domain, site, path, file, etc.); ISA Server can be configured to only accept certain URLs, so if you have a web server hosting multiple sites, or some internal-only web site, or some private storage area, etc., you can be sure only requests like "https://webmail.mydomain.com/owa" can reach it.
• HTTPS Redirection. Ok, this is not a major issue, but, speaking of URLs, how many users forget to put that "s" after "HTTP"? You can automatically redirect HTTP traffic to HTTPS with ISA.
• Load balancing. If you have more than one web server for the same application, ISA Server can load balance them as a single published web site, without need for hardware or software network load balancers; this load balancing also happens at the HTTP level instead of the TCP one, so it can better manage client sessions.
• All other ISA Server features. Of course. But don't overlook them. You can configure your web publishing rules to only allow certain users, only at certain times, only from certain IP ranges, etc.; you also can publish many internal web servers on a single external IP address, etc.; there are lots of things you can do with ISA once you implement it, other than publishing an Exchange CAS server.

Any redirect to localhost doesn't make sense from a remote system (e.g. client's Web browser). So the rewrite flags permanent (301) or redirect (302) are not usable in your case.

Please try following setup using a transparent rewrite rule:

location  /foo {
  rewrite /foo/(.*) /$1  break;
  proxy_pass         http://localhost:3200;
  proxy_redirect     off;
  proxy_set_header   Host $host;
}

Use curl -i to test your rewrites. A very subtle change to the rule can cause nginx to perform a redirect.