This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.

You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

NetPath Missing Many / Most Hops with WAN Optimisation

joshwright10 over 6 years ago

Hi All,

I've recently been getting into NetPath and thought I'd share something in the hope that it helps other who end up with the same head scratching issue.

Now, this problem is document by Solarwinds, but it did take me a while to find the document, so thought I'd add something to THWACK too.

After setting up a new NetPath Service to monitor an external partners service on port 443, NetPath worked perfectly and the route was mapped from the Site, over the MPLS, across various firewalls and then to the destination.

So after that success, I moved on to the next service. This next service uses TCP port 8194 and is allowed through all of the Firewalls, so I assumed this would be just as easy.

Unfortunately, instead of seeing around 10 nodes, including the MPLS & Firewalls, it appears that the path jumps from the Firewall in our node site to the destination!

Example - Path Missing Many Hops

After lots of time trying to work out why the our Firewalls were causing this, I stumbled upon this Solarwinds Article: NetPath graph issue: Missing all intermediate nodes - SolarWinds Worldwide, LLC. Help and Support

Credit to Solarwinds, this was a perfect article, albeit not easy for me to find.

The solution was to add an In-Path Bypass rule to the Steelhead at the source Site for traffic from the Solarwinds Node to any destination (this could be made more specific, but I didn't want to add additional admin work for future paths).

In the example, the Agent Node is in New York, so the rule is added to the New York Steelhead with the Source IP being the IP of the Solarwinds Agent Node doing the polling.

Example - Steelhead Rule

After adding this rule, the Path now shows as expected!

It turns out that the paths using HTTPS/443 only worked because the Steelhead is configured to Bypass encrypted HTTPS traffic.

0 rschroeder over 6 years ago

This is a solution I'd expect--traffic must be allowed this way for Netpath to show all the hops.
Please don't be offended if I offer a gentle and friendly suggestion: If you limit your source or destination ports and protocols to only what you specifically require for this flow, you'll end up with better security. Imagine your 32-bit-addressed server becoming infected or compromised, and begins discovery of whatever it can, looking for holes and open protocols, then spreading to the destination, and on and on.
Opening up all protocols, all source ports, and all destination ports, makes future changes easier. It also makes vulnerabilities open to exploitation--right up until you close down ports & protocols you don't need.
And when you go through a Security audit, your network will pass that obvious inspection with flying colors because you locked it down to only what's needed.
It's a little thing, but if you don't need it to use port 21, 23, 3389, 1443, NetBIOS, Banyan Vines, BACNET, etc., why not block anything you don't need? Yes, it's a little bit more work. You may even need to adjust it in the future to accommodate a new port or app or protocol. But that's pretty simple to do.
And your network will be safer and run more quickly without the unneeded ports & protocols being open, ready to infect or compromise.
Cancel
Vote Up 0 Vote Down

Cancel
0 joshwright10 over 6 years ago

Hey rschroeder, thanks for your feedback.
I think that you are referring to firewall rules, whereas I believe that I wrote about opening up port to be bypassed on the Steelhead / WAN Optimiser.

The above post assumes that traffic is already allowed on the Firewall as per the best practises and only opening up specific ports to specific destinations.
Steelhead / WAN Optimiser bypass rules are not security related, the only issue I could foresee is that if that machine becomes infected and generates a large amount of traffic, this could cause congestion on the WAN.
I agree that even on the Steelhead / WAN Optimiser, the ports should be specific, but in our case we deemed it to be unnecessary admin work with little benefit.
Cancel
Vote Up 0 Vote Down

Cancel