New Question
 
 
PRTG Network Monitor

Intuitive to Use.
Easy to manage.

200.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free PRTG
Download >>

 

What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

 

Top Tags


View all Tags


Using Windows IIS as SSL Proxy for PRTG

Votes:

1

Your Vote:

Up

Down

Is it possible to use the Windows IIS webserver as SSL proxy for PRTG?

iis ssl ssl-proxy

Created on Dec 11, 2012 2:08:53 PM by  Konstantin Wolff [Paessler Support]



19 Replies

Accepted Answer

Votes:

4

Your Vote:

Up

Down

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.

Configure PRTG

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

Configure IIS

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. Add new site in IIS
  • Open the URL Rewrite module from your site and add a new rule
  • Choose Reverse Proxy from the selection screen Add Reverse Proxy
  • 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" Add reverse proxy target
  • 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.

See also

Reference on used non-standard modules of IIS:

Troubleshooting

  • If the PRTG web interface looks broken due to missing Javascript/CSS try deactivating the Ouput Cache of the IIS

Created on Dec 11, 2012 2:32:06 PM by  Konstantin Wolff [Paessler Support]

Last change on Nov 9, 2015 3:30:02 PM by  Konstantin Wolff [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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?

thank you.

2015-01-05 22:30:16 192.168.7.141 33649 192.168.7.241 80 HTTP/1.1 GET /css/prtgmini.css?prtgversion=14.4.14.3789__ - 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=14.4.14.3789__ - 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

Created on Jan 5, 2015 10:57:49 PM by  schtebo (0)

Last change on May 4, 2017 11:49:03 AM by  Luciano Lingnau [Paessler Support]



Votes:

0

Your Vote:

Up

Down

@schtebo: Could you try activating Failed Request Tracing in IIS and dig a little deeper? Also, please check the PRTG web server logs to check why the connection is dropped.

Created on Jan 7, 2015 9:06:41 AM by  Konstantin Wolff [Paessler Support]



Votes:

0

Your Vote:

Up

Down

I have exactly the same problem. Are there any solutions?

Created on Mar 2, 2015 9:09:33 AM by  Ilya Nastenko (50) 1 1



Votes:

0

Your Vote:

Up

Down

@Ilya Nastenko: Do you have setup the failed request tracking as suggested above?
Best regards

Created on Mar 4, 2015 6:51:23 PM by  Konstantin Wolff [Paessler Support]



Votes:

0

Your Vote:

Up

Down

I solved this problem. I disabled Output Caching for the site and now everything works.

Created on Mar 7, 2015 5:07:04 AM by  Ilya Nastenko (50) 1 1



Votes:

0

Your Vote:

Up

Down

Note: you need to disable the kernel cache.

Created on Mar 7, 2015 5:11:11 AM by  Ilya Nastenko (50) 1 1



Votes:

0

Your Vote:

Up

Down

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:

http://127.0.0.1:8081/chart.png?graphid=-1&id=1002&avg=3600&sdate=2016-02-01-16-39-00&edate=2016-02-02-16-39-00&clgid=&width=850&height=270&graphstylefile=graphstyling.htm&animationandinteraction=1&datastylefile=graphdatastyling.htm&animationstylefile=graphanimationstyling.htm&graphstyling=baseFontSize=%2711%27%20showLegend=%270%27%20tooltexts=%271%27&datastyling=drawAnchors=%271%27%20anchorRadius=%271%27%20lineThickness=%272%27&refreshable=true

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

Created on Feb 3, 2016 12:45:06 AM by  Curtis Kayfish (20) 2



Votes:

0

Your Vote:

Up

Down

@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.
Best regards

Created on Feb 3, 2016 2:23:07 PM by  Konstantin Wolff [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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?

Created on Feb 5, 2016 11:37:05 PM by  Curtis Kayfish (20) 2



Votes:

0

Your Vote:

Up

Down

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.
Best regards

Created on Feb 8, 2016 3:46:37 PM by  Konstantin Wolff [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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?

Created on Feb 8, 2016 7:03:15 PM by  Curtis Kayfish (20) 2



Votes:

0

Your Vote:

Up

Down

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.

Created on Feb 11, 2016 2:18:18 PM by  Konstantin Wolff [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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.

Created on Mar 26, 2016 7:31:41 PM by  palyich (0) 1



Votes:

0

Your Vote:

Up

Down

@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.
Best regards

Created on Mar 29, 2016 1:15:02 PM by  Konstantin Wolff [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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

Created on May 12, 2016 8:22:32 PM by  Curtis Kayfish (20) 2



Votes:

0

Your Vote:

Up

Down

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

Created on Jul 13, 2016 9:03:56 AM by  nanos (0) 1



Votes:

0

Your Vote:

Up

Down

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

Created on Aug 8, 2016 12:41:08 PM by  philw (0)



Votes:

0

Your Vote:

Up

Down

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

Created on Apr 16, 2018 10:26:28 AM by  bartplessers (10)



Please log in or register to enter your reply.


Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.