Paths to Success with Web Application Proxy


 

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.

image

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 :-

http://blogs.technet.com/b/applicationproxyblog/archive/2014/10/01/introducing-the-next-version-of-web-application-proxy.aspx

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:

image

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

image

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 Sad smile

image

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.

image

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.

image

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.

image

Next, we’ll try this using wildcard HOST names and see what happens.

image

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:-

http://blogs.technet.com/b/applicationproxyblog/archive/2014/10/01/introducing-the-next-version-of-web-application-proxy.aspx

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.

image

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

Comments (11)

  1. KC_Craig says:

    Great article – Actual Use Cases!
    Using this to front end our SP2013 WWW, OWA and ADFS all over port 443. Perfect.

  2. @Some Guy and Frustrated Engineer. We do have some limitations in the current release and there’s work going on in terms of WAP vNext to fill a lot of the holes. Some of this is detailed in the following blog although there are other improvements coming
    in addition to this:-
    http://blogs.technet.com/b/applicationproxyblog/archive/2014/10/01/introducing-the-next-version-of-web-application-proxy.aspx
    If you have specific publishing areas which you are limited by in the current release please let us know the details so we can feed this back into the PG to try to cover as much as we can in the next release.

  3. John B. says:

    I enjoy the article. I must say I have found much success using "no hands proxies" as a reliable service. I recommend their service. Thanks again for your insight!

  4. Anonymous says:

    Applica

  5. Some Guy says:

    Argh, this article could be called "reasons to stick with TMG for publishing." Nice to see WAP’s shortcomings listed in a concise fashion, but it doesn’t make it any less frustrating.

  6. Frustrated Engineer says:

    I agree with ‘Some Guy’ I was hoping that WAP would be a replacement for TMG….MS has really dropped the ball on the death of TMG and a roadmap that leads to the edge of a cliff.

  7. sgayam says:

    Good one .. Thanks…

  8. Anonymous says:

    Welcome to this custom Quick Reference Guide. The purpose of this guide is to provide you with the latest

  9. Jerryy says:

    This is useful information.. Interesting post.. Thanks for sharing..

    http://evincetech.com

  10. Another Guy says:

    Thank you for the useful information.

    I have one question that from my understanding can not be fully answered from the information in this post.

    Will it be possible with WAP 2012 R2 to publish two different appliactions with distinct paths but different internal FQDNs to the same external FQDN?

    Internal URLs
    https://name.internal/appone/
    https://anothername.internal/apptwo/

    To be published external URLs:
    https://sameexternalname.com/appone/
    https://sameexternalname.com/apptwo/

    (knowing that this would create an error, when someone accesses
    https://sameexternalname.com/ without specifying /appone/ or /apptwo/ )

    Thank you in advance for any answer!

  11. Sys_Admin_EB says:

    I have a strange issue. We have our sharepoint server out on the web. We moved it from a MS TMG server to the WAP. Https:\\sharepoint.company.com. The backend rule is set to go to http:\\bufsps01.local.company.com. When we hit the site for sharepoint and it asks for login, we login and then it forward to the internal DNS entry of just bufsps01/default.aspx. and the page stalls out and says teh site cant be reached”bufsps01 server DNS address could not be found.

Skip to main content