Take Advantage of Reverse Proxies and Load Balancers for PRTG: How It Works

In the current environment, with its ever-growing threat of hackers, viruses, and all kinds of intruders, protecting your infrastructure is becoming more and more important. Many companies employ load balancers and security appliances to improve security and reliability of their customer-facing sites. 

These devices are specifically designed to improve reliability by distributing the load across multiple servers. Most of the appliances can also do offloading of encryption and some even do deeper packet inspection to eliminate threats. Like all services in your infrastructure, you want to know how the device is performing. With PRTG you can do that. But, before we get into the monitoring of the security appliances, let’s talk about how to utilize them with PRTG and how to configure them correctly.

This article is part of series on PRTG and reverse proxies: how to monitor and utilize them. In this first part, we will talk about how that is accomplished in general terms. Each security appliance has its own way to configure reverse proxies, so the following articles will cover the specifics for some popular platforms.

To monitor the security appliance, if there are no native sensors, we will utilize a set of custom sensors that can be configured to query any device. There are some SNMP Custom (SNMP Custom Advanced and SNMP Custom Table) sensors that allow you to query up to 10 custom values. Once the sensors are created, PRTG allows you to create a template with those sensors which you can then apply to other devices of the same type. The templates can also be used in auto-discoveries to find these devices in your network. The mechanics of creating these custom sensors and templates is beyond the scope of this article, but if you are interested, we have a recording of a webinar that demonstrates the process: “SNMP MIB basics – Monitoring with PRTG” 

Reverse Proxying PRTG, in General Terms

PRTG, like any other well-behaved web site/application, relies on the HTTPS (TLS/SSL) protocol for security. Like most applications that encrypt communications, PRTG utilizes a revision of OpenSSL for the encryption/decryption of the data streams. There are three separate loads in PRTG that rely on encryption:

• Web serving (HTTPS / Layer 7 – TCP/443 or TCP/8443)
  • PRTG Web GUI (Ajax)
  • Dashboards/Maps
  • API usage (including Mini Probes)
• Remote probes (TCP tunnel / Layer 4 – TCP/23560)
• Intra-cluster communication, which cannot be offloaded at this time (TCP tunnel/L4 – TCP/23570).

Referring to the graphic of PRTG interfacing with "Remote and multiple Probes".

We see that all remote probe interaction that traverses a network is encrypted. In larger environments with many remote probes, the overhead of encryption/decryption of the data streams can be significant. An advanced processor that supports the AES-NI instruction set boasts up to a 60% performance increase in SSL. During my testing, I found it to be more like 40%. In order to remove the load completely, short of switching to HTTP, you have to employ a service in an external device or application. This service, called a "reverse proxy" (we’ll refer to it as "Rproxy"), is provided by either software packages or security appliances. 

Please note: We have carefully compiled this information and it is provided to the best of our knowledge. As the solution is not part of PRTG itself, it is not officially supported by Paessler or PRTG Technical Support. Yet, we wanted to share it with you as it might be of interest for many PRTG users.

You must also be aware, that if you configure any of the parts incorrectly, you may leave yourself open to an intruder gaining access to anything configured within PRTG. This includes User ID’s, Passwords, ip’s names, etc. IE no warranties expressed or implied. Paessler, its employees or partners cannot be held liable for any damages that you may incur as a result of employing a Reverse Proxy.

Since the user enters sensitive information through the user interface, all traffic between PRTG and the client should be secured. The Rproxy will encrypt and decrypt the web traffic going between the PRTG server (PRTG Core) and the client (Browser). Essentially, the client (browser) talks HTTPS between itself and the Rproxy, and Rproxy translates the conversation to HTTP between itself (Rproxy) and the PRTG Core.

The Rproxy is indicated by the lock graphic in front of PRTG core on the network

There are a couple of standard software packages that supply reverse proxy services. On the Paessler Knowledge Base site, there some articles on how to configure and use them:

• NginX Reverse Proxy
• Microsoft IIS
• Apache

How Reverse Proxying Works with PRTG, in General Terms

Proxying the PRTG Web-based Graphical User Interface (Web-GUI)

The PRTG Web GUI is implemented as a web server and can be configured to run either over unsecured HTTP or secured HTTPS protocol. If your PRTG instance is exposed to any unsecured network, secured communications protocols are strongly recommended. When it is secured, PRTG does all the encryption and decryption of the communications internally. To use a Rproxy, you have to turn off the encryption on the PRTG web server, essentially making all the Web GUI interaction plain text. 

Configured either through the Admin Tool or Web GUI Menu | Setup | System Administration | User Interface

• On the machine running the PRTG core server, open the PRTG Administration Tool on your core server system and configure the PRTG web server to run without SSL on http (a custom http port may be used) or using the Web GUI as referenced above.
• In the PRTG web interface, configure the same DNS name, let’s call it MyPRTGServer.xx (Setup | System Administration | User Interface | option DNS name) as you will use for the rproxy later.

Once PRTG is in plain HTTP mode, you can configure the Rproxy with the following:

• A secured (HTTPS) interface (port) that the client will use.
• The IP and port of PRTG’s unsecured interface to forward the client requests to.
• Select encryption methods
• A SSL certificate, preferably a verified one for your organization.

Configure the DNS record for MyPRTGServer.xx to point to the IP address of the secured interface on the Rproxy the clients will use.

A Note on Proxy Cache

Most proxies do content caching, which also helps offloading work from the web server. Unfortunately, most of the proxies will not cache any URL that has a parameter (the URL as “…xxx?field=value,…” or a header directive to disable caching (Cache-Control: no-cache). As it happens, PRTG uses both, so caching is limited to things like icons and other “static” files.

It is important to re-iterate the importance of restricting access to the PRTG server interfaces in this configuration. All direct access to PRTG will leave the conversations vulnerable to snooping the conversations between the Rproxy and PRTG core. The best thing to do is to only accept conversations coming in on the IP the Rproxy is talking to. Or better yet, put the PRTG server in a vlan that has restricted access.

We will present a series of articles with details on how to implement the Rproxy with different security appliances.

• Kemp Loadmaster
• FortiGate
• BigIP f5