I am working on to access the Solarwind webGUI externally.
I already have the following things configured for this setup:
I opened the ticket with support, but I got response saying, Solarwinds doesn't support it.
I am sure this is the industry wide setup and lot of people must have implemented this. Is there anything I am missing here?
Thanks in Advance,
Hi, I know this is an old topic but its the same issue im having.
I set up an additional web server in a DMZ off our firewall and im trying to access it via a public IP. Port 443 on our Firewall listens for SSL connections so i have port forwarding set up..
So i hit our external IP 00.00.00.00:18787 and that translates to internal server IP 188.8.131.52:443. I get the login screen and can login fine however certain parts of the web console dont work. The menu bar does not show up, alerts widget and the left navigation dont work. But the majority works fine.
I have open up the firewall to everything but no joy. Solar winds support said its a FW issue but FW vendor Fortinet said they can see no issue.
Has anyone seen a similar issue?
We have 2 additional web servers and load balance then with an F5 load balancer to give access to SolarWinds. We secure it with the load balancer. About to put DUO on it for 2-factor auth.
hpatelow what you have configured should work fine. I have a single Orion server set up with a NAT to an external ip address. Port 443 (https) is allowed through the firewall. Make sure you use the same FQDN for internal and external DNS. Then go to Settings->All Settings->Web Console Settings and set your Orion Web Server Address to the FQDN.
Let me know if you have any questions and I'll try to answer them.
If you use Azure AD you can setup an Azure AD app proxy. Very easy and not additional network configuration is required.
I know I had one client who was setting that AD proxy up while i was working with them. He had said he got it working as far as a POC but I never sat down with him to see all the details.
To be fair I haven't done a lot of in depth testing, but it does work. Also if you have Azure MFA turned on it requires you to use MFA to login before you launch the web app.
MFA has proven fast and reliable for my organization (so far). I rely on it for ALL external access into my organization and it hasn't let me down since implementing it over a year ago.
While there's nothing (that I can see) that would stop your configuration from working, a better (more robust) way to do it is to use the Additional Web Server. This server (which can be a VM) exists anywhere on your network (including in a DMZ) and uses minimal ports to connect back to the primary poller on the "inside" of your environment.
Alerts will need to be slightly modified to point to this server, but once you do, the links will send the recipient to the AWE rather than the primary poller.
Let me know if I'm on the right track here.
Can you guys fix this: Configure website URL for Alerts and Reports - SolarWinds Worldwide, LLC. Help and Support
If you use this to configure your URL for a load balancer, then the health check on "My Orion Deployment" fail because it thinks that URL is a real server and can't find the services running on it.
We don't allow staff or customers to VPN into us for SolarWinds access anymore unless they use our MFA solution for VPN, and we encourage them to use the Virtual Desktop Portal instead of VPN.
Anything else is insecure.
Thanks for the recommendations.
but what if the customer is not using the Citrix VDI or F5 products??
Also, my concern is not related to the access to the Solarwinds server itself. The Solarwinds access is through AD, so that is not an issue.
My problem is when I get the alerts, I have the direct links to that alerts in Solarwinds WebGUI. When I click the link, it will redirect me to the Solarwinds WebGUI, but I don't see the web page. My connection times out and I get the error saying "This page can't be reached"
To get to your specific point about changing the URL that comes across in the email alerts, see this KB article
I second the other recommendations to be very careful about exposing the orion server itself to the public internet without at least passing it through some kind of DMZ/proxy.
The polling engines will have typically holes punched through all your ACL's so if it were compromised in any way it has extremely wide reach, not to mention having a mountain of information regarding the structure of the environment, and saved credentials that could be potentially hijacked if someone were to gain access to the server, it's often white listed from many types security alerts since it is not unusual for the Orion server to be doing things like port scans and reaching into servers and network gear all over the place. It is the ideal recon and attack location if it were to be compromised through something like an unknown bug in Orion itself or something in IIS. There is a reason that DMZ's are a standard part of the security layers for organizations that present public facing websites.
They need to fix this. This issue with putting in the website URL is that many of the built-in health checks fail because it thinks that URL is a real server and is missing services.
You'll have to provide a virtual desktop environment to give secure access into your internal network for SW access--or do without, apparently.
Sure, you could write a firewall rule that would allow you direct access from a specific IP address into your network, and have it redirect to the NPM home page. But from there the rule would also have to allow all the subpages of SolarWinds.
I bet others have alternate suggestions, but a secure portal or an AnyConnect clientless connection, either using MFA, is the only way to go.
The problem I find using a smart phone to remotely access anything SolarWinds is the scale is too small. I work around that by modifying my alerts so they include more than the basic data--they must include enough data for me to make decisions and act on what I see in my Inbox without having to remotely access SolarWinds. Things I include in alerts include, but are not limited to:
The sky's the limit for the useful information you put into an alert's subject line, and it makes it so I don't even have to open the e-mail to know what's going on. This helps me avoid needing to remote into work to discover the network's condition and to be able to talk intelligently about the situation with my peers and support staff.
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process.