insightVM console not updating

InsightVM
1

Hi, I currently have a problem with our insightVM console where it’s not updating from 7.0.1. I do have a ticket logged with Rapid7 support, but I’m hoping by laying it all out here in a single place I can widen the audience and see if anybody else has any ideas.

  • The system was migrated to an up-to-date Linux OS in around October 2024 - all seemed fine.

  • I then noticed that the console was not updating - all our additional scan engines were fine, but the console and local scan engine were not updating.

  • I logged a ticket with R7 support who suggested a repair installation, which I performed with their assistance in December - this updated the console to the version from the installer, but the system continued to not update so I then logged a new ticket when i noticed this in January 2025.

  • There are no errors shown when either clicking the Manual Update or running ‘update now’ in the console - we simply just get a message saying no updates are available.

  • The update.log file shows a more verbose version of this, showing what appears to be a successful connection but it shows that there are no updates available from the current version.

  • Rapid7, understandably, are suggesting a connectivity issue, but our firewall logs show the server connecting to updates.rapid7.com approx every hour and I see corresponding events when i test that appear successful with no block events at all occurring for the source IP of the console.

  • From the console, when pinging updates.rapid7.com i get a fail on the ICMP test but a pass on the TCP test

  • To remove any possibility of a firewall issue, the host firewall is disabled and I’ve bypassed the main firewall - this makes no difference.

  • Running traceroute updates.rapid7.com in the command console results in a ‘check the log’ message. In nsc.log I can see 48 hops with no results.

  • However, these timing of these tests appear to match ICMP events in the firewall logs which seems to match the failing ping tests (does the traceroute test from the console run an ICMP traceroute? If so, then it will fail because updates.rapid7.com does not respond to pings)

  • Running traceroute updates.rapid7.com from the OS itself fails to connect using the defaults but it passes when using the -T flag.

  • Multiple servers, including R7 collectors and orchestrators, exist in the same network segment and have no connectivity issues, and also show the same traceroute behaviour.

  • I’ve noticed when running’ show host’ in the console that the console is showing a host address of 127.0.1.1 loopback address and not it’s actual address (10.x.x.x) - I’m not sure if that’s expected\normal

Any ideas would be greatly appreciated!

Thanks

2

First thing I’d try is connecting from the console’s command line:
wget https://updates.rapid7.com/

This should return a 301 redirect.

If you are using a proxy to connect (check in Administration->Console->Proxy Settings) then you’ll need to set the proxy environment variable in your shell before running the above wget command: 'export https_proxy=“http://your.proxy.host:port”

FYI Output of ‘show host’ on our console shows the host’s IP, not loopback.

3

We had a similar issue last year. Our console would not auto-update but could be manually via console commands. We ended up having a time zone conflict with our database backup and update windows. The backup scheduler’s time zone was UTC while the update scheduler does not give a time zone. We later learned it was set to local time and therefore overlapping with our backup.

Some steps that helped us track this down:

  1. ‘show diag’ console command. Useful for verifying network connectivity and licensing. Helps prove to support your firewall is not the issue. More on commands here: https://docs.rapid7.com/nexpose/using-the-command-console/

  2. Set the logging level to debug and attempt updates. Again, via console commands you can use ‘log list’ to view the current verbosity of logs and ‘log set [log] ’ to increase them. If you set them to DEBUG make sure you reset them after troubleshooting to not eat up disk space.

4

Hi Dave and kszuta,

Many thanks for your suggestions - I used your ideas as further troubleshooting and could find nothing wrong. wget instantly connected but failed to return any data and the DEBUG on the update logs and show diag showed nothing unusual (i.e. successful connections but no updates required.)

R7 Support then reset our licensing (even though everything looked OK on the console) and the console appears to have now updated, so looks like something went wrong or didn’t happen relating to that when the system was migrated to a new OS late last year.