Submit a ticketCall us

Webinar: Web Help Desk for HR, Facilities and Accounting Departments
This webinar will focus on use cases for HR, Facilities and Accounting.

Having a unified ticketing and asset management system for all the departments in your company can provide end-users with a seamless experience and make things easier for your IT team. Yet, with different business tasks and objectives, many departments don’t fully understand the capabilities of Web Help Desk and how the software can be customized for effective use in their departments.
Register Now.

Home > Success Center > Network Performance Monitor (NPM) > Unable to resolve HTML scheduled reports when Orion server is behind a NAT

Unable to resolve HTML scheduled reports when Orion server is behind a NAT

Created by Matthew Lamb, last modified by MindTouch on Jun 23, 2016

Views: 24 Votes: 0 Revisions: 4

Overview

This article goes over an issue that can occur when a scheduled report utilising a web address for the report will not resolve as an HTML report action when the Orion server is behind a NATed firewall. The following error is received:

 

2016-03-14 10:41:38,438 [14] ERROR ReportingLogger - Error during fetching url: http://192.168.227.5/Orion/Report.aspx?ReportID=203 using HTML type
System.Net.WebException: Too many automatic redirections were attempted.
at System.Net.WebClient.DownloadDataInternal(Uri address, WebRequest& request)
at System.Net.WebClient.DownloadString(Uri address)
at System.Net.WebClient.DownloadString(String address)
at SolarWinds.Orion.Core.Actions.Impl.Email.EmailUrlExecutor.BuildReportingMailMessage(ISmtpClient smtpClient, EmailConfiguration config, ReportingActionContext reportingContext)

Environment

NPM 10 and later

Cause 

This is because the web address being used for the report and Orion's inability to translate NAT'ed traffice. When report is added per the screenshot below (in the highlighted section), it uses the address pulled from the link itself for the report. Depending on where that link is pulled, it could be from the poller itself or from the web page in front of the NAT.

 

The problem with this, however, is that this information is stored verbatim for the scheduled report. So in such a case where a link is using the IP address behind the NAT, the HTML report will attempt to authenticate with exactly that IP in the address to the NAT. This will be rejected because the IP is supposed to have been converted after the NAT.

 

The same can occur when the IP used in the link utilizes the IP of the Orion server in front of the NAT. In this case, the HTML link can make it through the NAT and the traffic converted to the actual server IP, but the HTML address will still contain the NATed IP address. This in turn is not stored in the database, as the database only records the actual IP address of the server and not the IP address of the server when converted through NAT.

 

Host names can work if utilized in the web address if the NAT rules allow translation through hostname. However, that needs to be configured on the NAT specifically and verified to be configured for resolution on both sides of the NAT.

Resolution

Typically, the means to resolve this is to allow the NAT rules to pass through the traffic based off the IP in the links, use a site to site VPN in the network or utilise a link address that could parse through the rules of the NAT in either direction, such as hostname to hostname.

 

The option you have to try in Orion is to not use the Assign Webpage option in the Report Scheduler, but to use the Assign another Report option and specifically find the report in Orion. This in turn allows the report to generate through Orion itself, which would be the IP to IP conversion of the NAT rule for the server. This would inherently be the same as opening the report through a link based off the hostname of the server allowing it to pass through the NAT reliably.

Last modified
23:52, 22 Jun 2016

Tags

Classifications

Public