Is it possible to use the Windows IIS webserver as SSL proxy for PRTG?
This article applies to PRTG Network Monitor 12 or later and IIS 7 and above
This article does NOT describe a full configuration of the IIS. You might need to apply some security adjustments!!!
Using Windows IIS web server as SSL Proxy for PRTG
There are some prerequisites that must be met if you plan to follow this article:
- Basic knowledge of the IIS web server and the URL Rewrite module
- A running IIS web server
- Activated modules: URL Rewrite 2, AAR 2.5, WFF 2.0
- Make sure the machine running PRTG is accessible from the machine running IIS.
Note: The mentioned modules are not part of the IIS by standard. For further reference see end of the article.
- On the machine running the PRTG core server, open the PRTG Server Administrator tool and configure the PRTG web server to run without SSL on http (a custom http port may be used).
- In the PRTG web interface, configure the same DNS name (Setup | System Administration | User Interface, option DNS name; in previous PRTG versions: Setup | System & Website) as you will use for the IIS later.
Note: For reasons of simplicity we used the SSL certificates which were created directly by the IIS.
- Create a empty folder somewhere on your system (will be the webroot resp Physical Path for the later site)
- Create a SSL certificate using the IIS Server Certificates feature (just choose "Create Self-Signed Certificate" and use the name of the site as name).
- Create a new site in IIS and fill in the site name. In the Binding section, choose Type: https. Then select the previously created SSL certificate from the dropdown.
- Open the URL Rewrite module from your site and add a new rule
- Choose Reverse Proxy from the selection screen
- Fill in the DNS name or IP address to the Forwarding Address in Inbound Rules (leave the Outboud Rules untouched)
- Additional set the tick for "Enable SSL Offloading"
- if needed, place a blank file called index.htm in your webroot
Note: All external PRTG applications (Enterprise Console, PRTGdroid, iPRTG) should work with this solution as well.
Any feedback on the article or further suggestions are highly appreciated.
Reference on used non-standard modules of IIS:
hi, i have tried this today. .htm pages will be forwarded correct to my prtg webserver and i can login. but i have problems with .css and .png files. they are missing. here are the logfile from iis.
can you find what is going wrong?
2015-01-05 22:30:16 192.168.7.141 33649 192.168.7.241 80 HTTP/1.1 GET /css/prtgmini.css?prtgversion=126.96.36.19989__ - 5 Connection_Dropped www 2015-01-05 22:30:16 192.168.7.141 33654 192.168.7.241 80 HTTP/1.1 GET /css/prtgmini.css?prtgversion=188.8.131.5289__ - 5 Connection_Dropped www 2015-01-05 22:30:16 192.168.7.141 33655 192.168.7.241 80 HTTP/1.1 GET /images/prtg_network_monitor.png - 5 Connection_Dropped www 2015-01-05 22:30:16 192.168.7.141 33657 192.168.7.241 80 HTTP/1.1 GET /images/prtg_logo_gray.png - 5 Connection_Dropped www 2015-01-05 22:30:16 192.168.7.141 33656 192.168.7.241 80 HTTP/1.1 GET /images/paessler.png - 5 Connection_Dropped www 2015-01-05 22:30:16 192.168.7.141 33667 192.168.7.241 80 HTTP/1.1 GET /images/prtg_logo_gray.png - 5 Connection_Dropped www
I have exactly the same problem. Are there any solutions?
@Ilya Nastenko: Do you have setup the failed request tracking as suggested above?
I solved this problem. I disabled Output Caching for the site and now everything works.
Note: you need to disable the kernel cache.
I was sure I left a comment here before upgrading, but I guess I didnt post it properly. Anyway, problem came back after upgrading so was reminded of this, which is why Im back here.
Log story short, the file webroot/includes/reportheader.htm contains this line:
<base href='<#system type="requesthttpurl">' target='_top'>
It cause the following code to be inserted to the header of of page that uses this include file:
<base href='http://127.0.0.1:8081' target='_top'>
By setting this as a base, all URL references, for things such as images, use this as a prefix, so my browser sends a get for something like this:
Can I remove the <base> completely from this file, which seems to be just fine? Shoud it use something other than <#system type="requesthttpurl">?
reportheader.htm is the only file containing the text requesthttpurl
@ckayfish: The tag <#system type="requesthttpurl"> is needed so all relative links are working. If everything is working for you, removing the line should not be an issue. However, you would have to do this after every update because currently we are not planning on removing the same.
What use cases require the relative links to be different than the the URL of the page, which is causing this issue for anyone using Reverse Proxy? Anyway, is there another variable maybe I/we could use other than requesthttpurl, or alternatively is there a way for me to tell PRTG what this should be, rather than it building it for me from the IP/PORT?
The reports in this case need relative links to work. A workaround is not possible currently as we would have to change the code within PRTG.
I will take your word for it that there is a case where the relative links on the reports page need to be different than the base of the page being loaded (which is used by default as the base for all relative links). I guess if the HTML for the report is hosted on a different site/host. It will certainly break the reports for anyoone using RP following the instructions here. I would use on outbound re-writing rule, but cant since using SSL.
I will simply continue to remove this from reportheader.htm, and if I ran into any problems will hardcode my actual base
One more thing, the links in the email are have the wrong protocol & port. There are liike http://prtg.mycompany.com:8081/report.htm?id=2713 & http://prtg.mycompany.com:8081/report.htm?id=2713), when the base should be like https://prtg.mycompany.com/. At least it get the hostname correct here, Im presuming from the DNS name entered
If we want to support using RP, perhaps in some future release there can be a spot where we enter a base URL, or somehow identify the protocol hostname and port that is actually used to access the website. This couple optionally replace how these links are currently built.
Am I missing something, or does everyone who uses RP experience these same issues?
The links in PRTG are built form the http/https configuration, the set up port and provided DNS name which in most cases works as the normal PRTG web interface is used instead of a Reverse Proxy. I forwarded your request to the development as well regarding full support of Revers Proxies.
Can i use xxx.yyy.nn/prtg url with URL rewrite? I add in Defaul Web Site new virtual part and create url rewrite in it as outlined above. But when I go to the link, I get a 404 error, always. In order to validate this design, I created another virtual directory to web interface of router. Redirection to the router works flawlessly. Why do I need this? I have SSL certificate for xxx.yyy.nn and I want use url rewrite for other services besides prtg.
@palyich: we currently have only tested forwarding a complete domain/subdomain to PRTG. An URL path has not been tested as currently there are some restrictions in PRTG itself which don't allow this. So currently it is only possible to forward the whole (sub)domain.
@palyich, If not using SSL you could do an outbound re/write. It would change the outgoing HTML from "http://mydomain.com/" to "http://mydomain.com/prtg/" (unless prtg is already there?). This may be the only way. You could have another proxy site in front of it to offload SSL to.
I was thinking a rewrite rule on the root of the site may be able to be crafted to catch only and everything incoming to the root for PTRG, but I wouldn't want to attempt or manage that.
@ckayfish: You can sort of get around this as follows:
1) Ensure PRTG only listens on IP 127.0.0.1 (and is bound to port 80).
2) Ensure IIS only listens on your other IPs as described here: https://support.microsoft.com/en-gb/kb/954874
3) Bind the IIS site that you use for reverse proxying to port 80 (and 443 for HTTPS, I assume)
4) If you want to enforce HTTPS: Use URL Rewrite to redirect any HTTP traffic to HTTPS
5) Obviously proxy any request on port 443 (HTTPS) to 127.0.0.1:80
Now, PRTG thinks you are on http://yourdomain.com:80 and puts that link (sans the port number, as it's the default) into your ticket and notification emails. Technically that is still sort of wrong, but at least you can follow the link, as when you visit http://yourdomain.com this gets redirected by IIS to https://yourdomain.com, which then gets proxied to PRTG.
The crucial step here is step 2 as IIS by default listens on all IP addresses, even if you don't have a site bound to it. So, you would want to ensure it doesn't listen on 127.0.0.1. (Obviously if you still need IIS to listen on 127.0.0.1 you'll need to find another unused IP address which may be somewhat more tricky ...)
Just another vote for the "disabling the Output Cache resolved the issue" thing.
I'd missed that in the details, then spent a happy hour or two trying just about everything else I could to get ARR/URL Rewrite to deal with this correctly. That fixes it in two ticks (you have to entirely disable the output cache, which requires you to untick both boxes in the section of the site).
What's the status of <base href='' > tag? I have similar issues on the historic data page.
- prtg on my homeserver - IIS + ARR
but on the page
https://my.domain.sample/historicdata_html.htm, I couldn't see the graphics.
So I had to remove following line:
<base href='<#if value="@aspdf" is="true" then="@srvurl" else="@requrl" varexpand="value,then,else">' target='_top'>
from the file:
C:\Program Files (x86)\PRTG Network Monitor\webroot\includes\printhead.htm
C:\Program Files (x86)\PRTG Network Monitor\webroot\includes\reportheader.htm
and everything works fine now.
Is it possible to implement this in your code?
Many thanx! kind regards, Bart Plessers
For all who having trouble in ARR 3.0 i've found the solution for the error "Sorry, the request cannot be processed, because the object ID is missing" when going to devices.
Make sure your URL Rewrite (on top level) have the Append Query string checked!