1

I posted this in a different forum and got nothing, so I'm a bit desperate.

Here is my scenario:

  • IIS running sites on 80 and 443 - external.foo.com and https://external.foo.com

  • On the same node, a separate web service is running an app (ASP) on port 801 - "web app3" .

I need all traffic coming to http(s)://external.foo.com/app3 to be routed to the local port 801 with SSL offloading - so the connection from the client to IIS is SSL, but IIS's connection to the local service is http over port 801.


I have ARR configured with a Proxy setup on localhost:801 which created a default rewrite rule. I have all the IIS sites and requests to external.foo.com/app3 being redirected to app3 now via HTTPS and it appears offloading is working fine using ARR default rule. The Global rule is below.

<proxy enabled="true" />
        <rewrite>
            <globalRules>
                <clear />
                <rule name="ARR_App3Proxy_loadbalance" enabled="true" patternSyntax="Wildcard" stopProcessing="true">
                    <match url="*" />
                    <action type="Rewrite" url="http://App3Proxy/{R:0}" />
                    <conditions logicalGrouping="MatchAll" trackAllCaptures="false">
                    </conditions>
                </rule>
            </globalRules>
        </rewrite>

Now I just need to target external.foo.com/app3 specifically so my other IIS sites will be excluded from this... If I leave the rule alone, it redirects every site request to app 3 over https w/ offloading just fine, but as soon as I try to set any url matching or condition, the IIS sites revert back to their default, but I cannot get app3 to load by opening http(s)://external.foo.com/app3.

I honestly think there are 2 things wrong, I am not targeting external.foo.com/app3 properly and that port 80 or 443 is also being implied for some reason when I edit the default rule. I have tried a 100 times to make this work, but I'm running out of steam.

Any advice or assistance will be greatly appreciated!

  • Http and https are always ports 80 and 443 respective because this is what the browser expects and what these protocols bind to. I do not know IIS anymore, however, with Apache we use a proxy on the server to solve these problems. I am not sure what the right answer is for you. Sorry. We will just have to wait for one of our IIS people to answer. Meanwhile, I can at least up vote hoping to gain attention. Cheers!! – closetnoc Jun 29 '18 at 23:26
  • @closetnoc If you don't supply a port, a browser will attempt to connect an http request to port 80, and an https request to port 443, but you can tell it to use a different port with the colon after the domain: http://www.example.com:8080 would happily connect to a configured web server on that port. The danger with low port numbers is port clash. – Zhaph - Ben Duguid Jul 9 '18 at 23:55
  • @Zhaph-BenDuguid Yes. I realize that. My point was a noob point in case the OP did not understand how it worked. Cheers!! – closetnoc Jul 9 '18 at 23:59
  • @closetnoc - no worries, thought you probably did know, but it was your use of "always" in the first sentence ;) – Zhaph - Ben Duguid Jul 10 '18 at 1:02
  • @Zhaph-BenDuguid I used always because that is what the browser will do with http or https. Your mention of adding a port number is valid and will tell the browser to use another port of course. Cheers mate!! – closetnoc Jul 10 '18 at 1:07
1

Change your match pattern to only match the path you're interested in:

<rule name="ARR_App3Proxy_loadbalance" enabled="true" stopProcessing="true">
  <match url="^app3(.*)$" />
  <action type="Rewrite" url="http://App3Proxy:801{R:1}" />
</rule>

Here I've changed the rule into a regex match rather than a wildcard match, and then set the match pattern to:

  • ^ start of path - in rules this is everything after the first trailing slash after the domain.
  • app3 only match if the path is app3 - should ignore other folders and paths - this should be enough
  • (.*)$ capture everything else to the end of the URL - this should include trailing slashes, query strings, etc.

Then the action is set to rewrite on the server to the correct protocol and port (http://app3proxy:801) with the capture from the rule {R:1} (because R:0 is the whole matched string (in this case app3/somepath)).

Finally this assumes that you have set up name resolution internally for app3proxy to your site - the easiest way to confirm that is request it in a browser on the server. If you don't have a local DNS server you can add the entry to you can either add an entry to the servers hosts file or just use the internal IP address (if it's the same server then http://127.0.0.1:801 should work).

Notes on steps taken locally to confirm:

  1. Installed Application Request Routing 3.0 from Web Platform Installer.
  2. Within IIS Manager, at the server level, enabled ARR with the "Enable proxy" setting - left all other options at their default, including leaving "Proxy Type | Use URL Rewrite to inspect incoming requests" unticked (although SSL Offloading is ticked) - this results in the informative note "Server routing rules have not been created".
  3. Ensure that I can resolve the sub-sites correctly on the server (including one on port 801.
  4. In the IIS website, added the Rewrite rules to the application.

Sample rules:

<rules>
  <rule name="Brickjax Reverse Proxy" stopProcessing="true">
    <match url="^brickjax(.*)$" />
    <action type="Rewrite" url="http://local.brickjax.doodle.co.uk{R:1}"  />
  </rule>
  <rule name="LapTimes Rewrite">
    <match url="^laptimes(.*)$" />
    <action type="Rewrite" url="http://local.laptimes.doodle.co.uk:801{R:1}" />
  </rule>
</rules>

Then when I request https://localhost/ I get the default IIS website, while https://localhost/brickjax takes me to the dev instance of my BrickJax site and https://localhost/laptimes takes me to the dev instance of my LapTimes application:

Secure primary with SSL offload onto the insecure local sites

Other things to check out

Are your applications doing any checking or processing of the incoming request path? If so, you'll need to ensure that you are checking for the correct URL and path - for example I tried to configure a URL rewrite rule for my main production site, which issued a 301 redirect as I'd miss-configured the domain - this response was handed back to my local IIS, which passed it on to the browser, resulting in a different result to the expected.

Again, the Failed Request Tracing is a great help here - look for both RewriteModule and ApplicationRequestRouting they should give you some ideas as to what is happening.

  • 1
    Hi Ben, thanks for your input! Unfortunately your rule is not working. I am getting " 404 - File or directory not found. The resource you are looking for might have been removed, had its name changed, or is temporarily unavailable. " Tried using the hostname, loopback IP and proxy name with no luck. Any advice? – Charlie Echo Jul 11 '18 at 21:25
  • I'd recommend installing and then enabling the Tracing IIS feature - this might give you a bit more detail to go on - can you identify where the 404 is coming from, is it your main server or the internal one? This configuration should work: blogs.msdn.microsoft.com/friis/2016/08/25/… - note that the "Reverse Proxy" rule is basically an inbound rule as above and an outbound rule that modifies links from the internal server. – Zhaph - Ben Duguid Jul 11 '18 at 21:32
  • 1
    Additional info here: Module IIS Web Core Notification MapRequestHandler Handler StaticFile Error Code 0x80070002 Requested URL external.foo.com:443/app3 Physical Path C:\inetpub\wwwroot\app3 Logon Method Anonymous Logon User Anonymous – Charlie Echo Jul 11 '18 at 21:32
  • The Main server is the internal server which is responding on port 801 - same server with a different service listening on a different port. – Charlie Echo Jul 11 '18 at 21:34
  • 1
    The path is bogus, app3 is not running in IIS, its running in a separate web service. But I don't think that is the problem because as soon as remove the "match" from the rule it redirects App3 as well as all the IIS sites to App3's page... its something to do with the matching rule and IIS 10... – Charlie Echo Jul 11 '18 at 21:43

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.