Submit a ticketCall us

Have You Auto Renewed? If not, you're missing out.
The SolarWinds Renewal Program comes with a host of benefits including the most recent product updates, 24/7 technical support, virtual instructor-led training and more. Experience all of this with the convenience of Auto Renewal, and never worry about missing any of these great benefits. Learn More.

Home > Success Center > Archive > 2017December18 - Deletes > 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 Kevin.Swinson on Dec 18, 2017

Views: 752 Votes: 0 Revisions: 5

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

Tags

Classifications

Public