Home > Forefront TMG 2010, Unified Access Gateway > HTTP to HTTPS Redirection Options in Forefront TMG and UAG

HTTP to HTTPS Redirection Options in Forefront TMG and UAG

January 6, 2011

When publishing SSL-protected web sites such as Microsoft Outlook Web App with Forefront Threat Management Gateway (TMG) 2010 or Unified Access Gateway (UAG) 2010, it is often desirable to allow clients to enter the URL of the site without specifying the HTTPS protocol explicitly. For example, when publishing Outlook Web App (OWA) 2010 where the full URL is https://mail.celestix.net/owa/, for convenience an administrator might want to redirect non-secure requests for http://mail.celestix.net/owa/ to use the secure HTTPS protocol automatically. This can be done in a number of ways, depending on which Forefront solution is used for publishing.

Forefront TMG

With TMG, HTTPS redirection can be enabled by opening the properties of the web listener used in the publishing rule and selecting Enable HTTPS connections on port: and Redirect authenticated traffic from HTTP to HTTPS.

Now when users request the non-secure http://mail.celestix.net/owa/ they will automatically be redirected to the secure https://mail.celestix.net/owa/.

Even more convenient is to redirect requests for the base URL http://mail.celestix.net/ to the correct path https://mail.celestix.net/owa/. The easiest way to accomplish this is to create a new publishing rule that denies requests to http://mail.celestix.net/ and redirects them to https://mail.celestix.net/owa/. To enable this functionality, use the Web Site Publishing Wizard to create a publishing rule that denies access to http://mail.celesitx.net/ and redirects those requests to https://mail.celestix.net/owa/.

Be sure to place this rule before the publishing rule allowing access to the SSL-protected web site.

Now when users request the non-secure http://mail.celestix.net/ they will automatically be redirected to the secure https://mail.celestix.net/owa/.

Forefront UAG

Configuring Forefront UAG to redirect HTTP to HTTPS is even simpler. After you’ve created a trunk and published OWA, right-click HTTP Connections in the UAG management console navigation tree, select New Trunk, and then select the HTTP to HTTPS redirection option.

  1. Rick
    January 24, 2011 at 8:29 am

    Why even allow port 80 to your TMG/UAG box? Seems risky. Wouldn’t it be better to have a firewall in front of TMG/UAG that only allows port 443 (and whatever other ports you need) and block port 80? We do the redirection on our website that is being hosted elsewhere then it sends it to our corporate network via https only.

  2. January 24, 2011 at 5:07 pm

    That depends on your security policy and your appetite for risk. For many, allowing inbound port 80 is acceptable, and this article discusses ways in which to improve usability by redirecting those requests to port 443 (HTTPS). I do like your method of using an externally hosted web site to do the redirection though!

  3. Chris
    April 23, 2011 at 1:01 am

    It does not seem like a true redirect? the new rule provides the default TMG forms based login page while the actual OWA rule would show the Exchange forms based page. Sure you could change the redirect rule to show the Exchange login page but its not the same really.

  4. April 24, 2011 at 4:33 pm

    Not sure what you are talking about, Chris. The redirect is a function of a ‘deny’ rule in TMG. The client never gets an FBA page from the deny rule in question, just an HTTP 302 response (object moved).

  5. May 12, 2011 at 5:31 am

    Thank you! this the easiest way to redirect a link to an other…
    I spent two days trying things… very helpfull thanks

  6. June 22, 2011 at 2:05 am

    so, if i have several sites to use https and i want to make redirects from http to https i should make several rules?

    for example:
    i have svn and git repos with addresses https://svn.blahblah.com and https://git.blahblah.com
    so i have to make 2 “deny” rules to make redirects from http://svn.blahblah.com and http://git.blahblah.com ?

  7. June 22, 2011 at 12:30 pm

    That’s correct. 🙂

  8. Mike V
    August 14, 2011 at 1:52 pm

    Thank you Richard for posting this info and for your other blog regarding upgrading from ISA 2004/2006. I thought I would pass along some critical info that helped me get the HTTP redirection working on our TMG server. After a whole day’s work of frustration I was about to give up and start over with TMG server implementation until I found this blog by Andy Olson:


    He speaks about having IIS installed on the TMG server and how it will cause problems.

    Thank you.


  9. August 18, 2011 at 8:09 pm

    Thanks for the tip, Mike. It certainly underscores what we typically preach with the TMG firewall; don’t install unnecessary services on the TMG firewall! Not only does it introduce additional attack vectors, as you discovered it can also cause conflicts that can impact proper operation of the firewall too.

  10. Klaus Ringe Nielsen
    September 19, 2011 at 5:20 am

    Hi Richard.

    Thank you for this article. I’m new to TMG so forgive me my (possible) ignorance! 🙂
    We have two url’s to our OWA: The “real” url which is: https://mobile.company.com, and a url (http://wmail.company.com) which should redirect to the real one.

    We only have one listener on the TMG (for OWA and EAS).
    The people who (tried) to set up the redirect deny rule have used “Perimeter” instead of a listener.

    When I go to http://wmail.company.com it tries to redirect me to https://wmail.company.com instead of https://mobile.company.com/owa (which is specified in the deny rule)

    I can see that you have a HTTPS and a HTTP listener in your example. Could the missing HTTP listener be the reason my redirect doesn’t work?

    Best regards
    Klaus Ringe Nielsen

  11. September 21, 2011 at 8:59 am

    Most likely. Try creating an HTTP listener as outlined in this article. Should work perfectly after that. 🙂

  12. November 20, 2011 at 10:13 am

    is it possible to save url path after redirection?

    i mean how to teach TMG to do that:
    http://ddd.ddd.dd/dd.ss.dd/ddd/sss/dd -> https://ddd.ddd.dd/dd.ss.dd/ddd/sss/dd

    instead of:
    http://ddd.ddd.dd/dd.ss.dd/ddd/sss/dd -> https://ddd.ddd.dd/

  13. November 20, 2011 at 4:05 pm

    I don’t believe it is possible using the method I described in this post to capture the URL. You could accomplish this by adding each URL as a separate deny rule, but that would likely be cumbersome and ineffective. Something like you are looking for would be better handled at the web server using ASP code.

  14. Brandon
    January 25, 2012 at 7:01 am

    Unfortunately your solution will not work for ADFS Trunk examples where you have purchased just UAG. You cannot use the TMG to do the redirect because it is not supported and you cannot do the UAG method because it isn’t supported for ADFS trunks. At this point, we are kind of stuck in trying to get this part to work properly.

  15. January 25, 2012 at 9:47 am

    Thanks for making that point. Perhaps one of my readers has encountered this scenario and has a workaround?

  16. Nazir Hussain
    March 11, 2012 at 4:08 am
  17. March 13, 2012 at 6:12 pm

    Not using the techniques described in this post. You might be able to do this using an access rule that denies requests to http://www.facebook.com/ and redirects to https://www.facebook.com/, however, this is not something that I’ve ever been asked to do and I’m not certain it will even work as you expect. You can certainly try it though. 🙂

  18. mobadder
    May 28, 2012 at 5:58 am
  19. May 31, 2012 at 12:14 pm

    Look closely at your redirect rule. Make sure that the rule matches the incoming request and redirects correctly. Keep in mind that if you want to redirect HTTP and HTTPS, that will require two separate rules.

  20. mobadder
    June 6, 2012 at 1:45 pm

    yes that what i did, two rules one for HTTPS(Working) with HTTPS Listener and another one for HTTP(Not working) with HTTP listener !!! but should i redirect traffic in HTTP -> HTTPS only for authentication or all traffic !!! in HTTP rule

  21. June 8, 2012 at 1:32 pm

    No need to worry about authentication for the rule. Just redirect everyone and you’ll be fine, trust me. 🙂

  22. mobadder
    June 8, 2012 at 10:01 pm

    I did, now the message Network Access Message: The page cannot be displayed.
    Technical Information (For support personnel)
    Error Code:403 Forbidden, Forefront TMG denied the specified Uniform Resource Locator(URL).(12202)

    any advice thanks for ur support

  23. June 9, 2012 at 9:40 am

    Not sure what the trouble is. All I can tell you is that if you follow the steps in this article it should work. It does for me every time. 🙂

  24. manek
    July 31, 2012 at 4:09 am

    Hi richard,

    Nice article…if the users are accessing via only https itself like the webmail address known to the outside world is https://webmail.contoso.com how can we redirect this https request or how can we append /owa to this from tmg.
    HTTP port is closed from the firewall right now re direction done from IIS bcoz owa directly hits cas. iam configuring tmg have configured publishing rule and https://webmail.contoso.com/owa works but without /owa no luck.any work around you can suggest in this will be helpful.


  25. August 11, 2012 at 12:09 pm

    Using the method I described in this article won’t work for redirecting only the path of an HTTPS request. Honestly, if a user is going to type in the correct protocol, they are typically going to enter the path as well. The redirect method I’ve demonstrated works in the most common scenario in which a users fails to enter the correct protocol.

  26. Chandra
    December 27, 2012 at 8:08 am

    Very good article. Helped me twice 🙂

  27. Mikko I
    February 24, 2013 at 7:42 am

    Tried the UAG HTTP to HTTPS redirection and it works with OWA, but now Outlook Autodiscover is prompting users about the redirection with “Allow this server to configure..” prompt. I can see that UAG replies with 302, and that causes the prompt. Has anyone experienced the same and has a workaround?

  28. February 25, 2013 at 4:04 pm

    Yes, the redirection feature can have some unintended side effects. You may have to create another trunk for your Outlook Anywhere clients to workaround this conflict.

  29. Naresh Summan
    April 5, 2013 at 3:27 am


    Richard, great guide.

    I hope someone can help on my issue.

    Is there a simple way to redirect an old HTTPS to a new HTTPS site on UAG 2010?
    e.g. https://Test.old.com > https://Test.new.com

    Its very simple on ISA using the Action Tab and selecting Deny. UAG, I can see is on the Trunk is Manual Redirection but its very complex due to the applications in use.


  30. April 9, 2013 at 12:11 pm

    In UAG, no. At least not that I’m aware of. 😦

  31. Bryan C
    April 15, 2013 at 9:07 am

    Hi Richard, nice guide,

    I know this is a diferent topic but maybe u can help me

    I need to publish lync in UAG but i have already used the port 443 with direct access, the question is can i assign the same port for lync?


    PD. Sorry for my english!!

  32. April 24, 2013 at 8:07 am

    No, you can’t use the same port on the same IP address. You can, however, assign another IP address to the UAG server’s external network interface. Once you’ve done that you can create another trunk for which you can publish Lync web components on TCP port 443.

  33. August 28, 2013 at 11:14 am

    Hi Richard,

    Just to add some information on the redirection. It seems there is a different way also, which allows it outside “Trunk only”. Spent quite a few hours trying to figure out something, so I will be trying the referenced in given time 🙂


  34. September 2, 2013 at 7:09 am

    Excellent. Thanks for sharing that, Jesper! 🙂

  35. Ragu
    June 11, 2014 at 9:32 pm

    redirection is working fine for my setup. But when i enabled for user must change password in first logon. It’s ending with SSL error. when i entered http://webmail.test.com it takes me to https://webmail.test.com/owa after entered the user name password which set as password must change it takes me to https://webmail.test.com:80/owa/auth/expiredpassword.aspx?url=/owa/auth.owa which you can see 80 port is getting added automatically and it’s ending with SSL error. If i remove manually 80 from url it’s taking me to password change screen with out any issue. I believe something i’m missing in my configuration. Any idea?
    intranet it’s working fine. it’s takes me to password change screen with out any issue. Only the issue over the internet. thanks in advance

  36. June 22, 2014 at 1:52 pm

    I’m not sure what could be causing this. However, if you take a network trace on both sides of the TMG firewall you should be able to identify who is appending the :80 to the URL. I don’t know if there’s a good way to resolve this using TMG though. If you’re using an external load balancer like F5, you could create an iRule to remove this from the response to resolve the issue.

  37. shabeer
    January 18, 2015 at 8:03 am

    Same issue i am also having,
    I tried all those mentioned steps,
    But no luck…
    Is there any other way to make it possible?

  38. January 20, 2015 at 11:22 am

    Not to my knowledge. One of the methods described in this post should work though. It has for me countless times. 🙂

  39. Pir Hamed Ali Shah
    March 31, 2015 at 2:27 am

    how to aalow http://www.google.com in forfront tmg 2010 ?
    please help me . I instal tmg 2010 and allow all sites trafic and all are working good but GOOGLE cant open and not working so please elp me I shell be very thankfull to you for that …..

    Regards : Pir Hamed Ali Shah

  40. April 2, 2015 at 6:31 am

    Allowing access to Google should be as easy as creating an access rule that allows access to that domain for all users on ports 80 and 443 (HTTP and HTTPS).

  1. January 12, 2011 at 5:07 am
  2. July 18, 2012 at 9:00 am
  3. January 11, 2015 at 1:50 am
Comments are closed.