Go for it. Might as well open it to default security level so folks searching key terms will be able to find it.

HTTP/1.0 vs HTTP/1.1 is what I missed. Thanks for figuring this one out.

Should we close this one as Configuration then?

I figured out what this report is about, and it's easily demonstrated by bringing up OpenNMS on a Vagrant box and connecting to the webapp via the forwarded port:

In the Location: header above, the IP address of the VM's guest operating system is exposed. If we imagine that we're looking at an OpenNMS instance behind e.g. a load balancer rather than a Vagrant box, the complaint starts to make sense. For additional context, the instance against which the customer reported this problem is in an environment that is subject to heightened security measures.

I identified a small change that we can make to jetty.xml to hide the local IP address:

With this change applied and services restarted, the Location: header now shows the configured hostname rather than the local IP address:

This change is unlikely to break things even if the hostname configured in jetty.xml is not resolvable from the outside world, because the hostname is used only for HTTP requests that lack a Host: header, i.e. HTTP/1.0 requests. Any HTTP/1.1 requests will have a Host: header, which Jetty will use in the URLs it produces for its Location: headers when needed.

If the jetty.xml adds an HTTPS listener, the customizer configuration will need to be added to that section of the file as well.

I don't think this change or anything like it needs to be applied to the default configuration files.

Still unable to reproduce this.

I know nothing more than Nessus is reporting this as a vulnerability against OpenNMS.

My guess is that when you use a hostname that is NAT'd, this vulnerability will return the internal (real) IP address.

I can try to set up an instance here and have Chris set up a NAT if that would help.