Hi everyone,
We’re pleased to introduce our new guest blogger, Mark Grimes from Microsoft Consultancy Services. Mark’s been involved in some pretty complex Web Application Proxy deployments and has put together some great hints and tips we wanted to share. Over to Mark…..
Introduction
In this posting I want to share with you some of the fundamental rules that you need to follow when publishing applications in Web Application Proxy.
Perhaps a more accurate title for this might be, “paths that work and those that don't”? No matter what the title, if you learn some simple rules to follow, you will improve your paths to success when publishing applications in Web Application Proxy.
Web Application Proxy is a new role in Windows Server 2012 R2 that allows an administrator to publish access to an internal web application for external users.
If you do not follow these paths to success, then you will often be politely asked to stop what you are doing right before you think you are done with your publishing. In this blog, we’ll show you some examples of those GUI stop signs, which will be presented to you as you attempt to do something that is simply not allowed and we’ll also explain the reasons why. In some cases you may receive a warning just as soon as you enter your external and internal URLs. But sometimes you will just have to wait a few clicks before receive your surprise announcement declaring that you cannot do what you just thought you could do. And as administrators, we do not like surprises.
Knowing these rules in advance will help you plan your Web Application Proxy deployment and avoid unforeseen issues when you’re right in the middle of your deployment.
Let's summarize these "paths to success" to help you be successful in publishing applications through Web Application Proxy. Then we'll break them down one by one with examples for each.
1. External publishing through HTTPS only
2. Web Application Proxy can translate the host portion of the fqdn names but not path names
3. The absolute path must have a “/” suffix
4. Web Application Proxy supports wildcard certificates, but not wildcard host names for publishing
5. Nesting is for the birds, not Web Application Proxy
1. External publishing through HTTPS only
For publishing of web sites, port rules are simple. Externally, Web Application Proxy only currently only supports secure external publishing with HTTPS. This is to be secure by design. Web Application Proxy supports connecting to the internally published server over either HTTP or HTTPS URLs. The only thing that will stop this from happening is if you do not follow the rest of the rules after this one. Here is the example warning you will get as soon as you currently try to type HTTP for the external URL.
So you say, “Hey, what about all of those HTTP only sites we have that we need to publish?”
As you’ll no doubt have seen from Meir’s recent blog support for HTTP publishing along with a ton of other great new functionality is being added to Web Application Proxy in Windows Server vNext :-
In the interim, one example of an easy work around, which many of our customers do, is to implement something like an F5 load balancer iRule, which does a simple URL rewrite from HTTP for inbound requests to the network, to HTTPS traffic heading to Web Application Proxy.
2. Web Application Proxy can translate the host name portion of the published path but not path names
Web Application Proxy supports different internal and external FQDN’s e.g. https://www.contoso.com externally, but with an internal server name of http://secret-server.net. With an internal name like that, we surely do not want to share that name with the world. Note, in this example, the external URL is HTTPS and the internal URL is HTTP and it’s worth just noting this as although we currently only support external access over HTTPS we can bridge to HTTP internally. There is no path after the host name portion (which would have to match), so this will work and apply to all paths under the FQDN. Here is what it looks like:
Note: a warning dialog box does come up, but it is just noticing that the host names indeed are different.
After clicking Publish in the Publishing wizard, you will get a successful confirmation.
To simplify the second part of this rule with an example, which is “Web Application Proxy cannot translate path names”, we’ll keep the external and internal host portions of the names the same but only change the path names following, to make them different.
In this first example, let’s try to publish https://contoso.com/app1/ (externally) to https://contoso.com/secret-app/ (internally).
You get the same warning as above, but you can still click through this and will not be blocked until the very end once published 
To fix this, match the path following the FQDN host name portions for BOTH the external and internal names.
Following are successful examples with the same hostname and pathnames and then publishing apps with different host name portions of the fqdn, but the same path names following the hostnames.
If you have not done publishing with Web Application Proxy yet, the first scenario in the picture above is how the Web Application Proxy wizard assumes by default that you will publish the apps. This means that as soon as you type in your application’s external name, it auto-fills in the application’s internal name to be the same. This is by design and helps to fully mitigate any host translation issues.
3. The absolute path must have a “/” suffix
This one is a quick and simple rule. What this means, is to always end any application path with a trailing “/”. In the example below, https://contoso.com/app1 is attempted to be published (and not https://contoso.com/app1/). Once Publish was clicked, the interface complained once again with the dialog box below.
But here is a little twist even to this one! My customer had some paths that did not have a trailing slash. We’ll use the failed publishing attempt above as a requirement. Well no worries mate! If you publish https://contoso.com/app1/and the customer needs https://contoso.com/app1 (sans slash), this will still work as it is implicitly allowed by design.
4. Web Application Proxy supports wildcard certificates, but not wildcard host names for publishing
There will be other blog posts covering certificates, but we just want to differentiate these two “wild” examples.
As shown below, wildcard certificates such as *.contoso.com are used to quickly publish any application without having to make a new certificate for every name. This means that for any host name that start with something.contoso.com, this certificate will work for just the one level beyond the dns name of contoso.com. We’ll stop right there to save the rest of the certificate tips and tricks for another later blog post.
Next, we’ll try this using wildcard HOST names and see what happens.
The warnings in RED let us know that this is not valid to use wildcard HOST names.
This is an important requirement especially for publishing Apps for SharePoint where each application has a GUID FQDN under the app namespace e.g. contosoapps.com and is another feature that is added in the vNext release:-
To complete the set, if you are thinking about wildcards in the URL path, well this is just simply implied and allowed. So if you publish https://contoso.com/ internally and externally. Then ANY sub-path beneath that will work as well e.g.
• https://contoso.com/app1/secure/
• https://contoso.com/app2/public/
…will ALL be allowed to pass through the gateway if you published https://contoso.com/
In one customer scenario, they have many sub paths for different apps or fedlets within their Java applications. In this case things like:
• https://contoso.com/app1/ is equivalent to https://contoso.com/app1/*
• https://contoso.com/app2/secure/ is equivalent to https://contoso.com/app2/secure/*
5. Nesting is for the birds, not Web Application Proxy
This final scenario we’re going to look at is what happens when you combine overlapping or nested path publishing.
Nesting paths in Web Application Proxy is a situation where there is one path published initially, which is then later published later with the same initial fqdn followed by an overlapping path. As an example, if you tried to publish the following internal URLS:
• https://contoso.com/app1/
AND
• https://contoso.com/app1/public/
…here is the warning you will get.
Besides trying to avoid these “nestings”, how else can you avoid this? One option would be to use alternate DNS host names. If you published the following:
• https://contoso.com/app1/
AND
• http://public.contoso.com/app1/public/
..this WILL work. Why? Remember rule #2 above? Web Application Proxy can translate host portion of the path but not pathnames between the internal and externally published URLs.
We do recognise that this is a requirement for a number of scenarios and it’s something the Product Group are evaluating for vNext.
Summary
There you have it. Five rules for “paths to success” in publishing applications in Web Application Proxy. If you follow these rules, may your publishing be successful ever after! And I do hope that these rules help you to avoid the common errors as shown above. Just like anything we do, practice makes perfect, or at least makes fewer mistakes.
Till the next time – Mark @ Microsoft