PRTG Install attempting to connect to 216.58.204.36 on port 445

This might be the Common SaaS Sensor, monitoring the Google Apps suite availability. When you pause the Sensor(s) via the following menu:

...the requests should stop. Can you verify that?

PRTG Scheduler | PRTGapi | Feature Requests | WMI Issues | SNMP Issues

Kind regards,
Stephan Linke, Tech Support Team

Hi Stephan,

I did suspect that the Common SaaS sensor could be the cause of this however I had already removed the sensor last week and I only have the "Core Health" sensor under "Sensors > By Type > C..." but I still appear to be getting alerts from our Firewall.

Anymore ideas what could be causing it?

Kind Regards,

James

Out of curiosity, are you monitoring a device with the address 216.58.204.36? If so, it might be the sensor recommendation engine that tests if specific ports are opened on a target appliance and then recommends the sensors you could create for that device. In order to stop that for this very device, please open up its settings tab and then scroll to the bottom. Untick "Advanced Network Analysis" and disable the similar sensor detection as well as the recommendation. Do the requests still persist afterwards?

PRTG Scheduler | PRTGapi | Feature Requests | WMI Issues | SNMP Issues

Kind regards,
Stephan Linke, Tech Support Team

Not that I am aware of nor that I can find unfortunately... We are only monitoring our local LAN and another site that is connected via an IPSEC VPN tunnel and a remote probe at that site.

Is there anyway to search for this address specifically to see if it was a sensor recommendation for a device?

Are you certain it is PRTG that is causing this?

Assuming an interval of 5 minutes - due you see those errors from the FW every 5 minutes? or in the respective interval..?

Did you try to do NETSTAT commands to investigate further which process might cause this?

Eventually WIRESHARK might help as well - especially since you look for a very specific target IP address.

The IP itself seems to default out to www.google.com while it is one of Google's IP addresses for sure - there might be other services behind it as well.

Port 445 - mainly used for SMB sounds a bit odd for such a target address, though.

Having said that - I did a few tests and don't even see the IP open / answering on 445 at all..

NETSTAT combined with parameters like -b and -p as well ass an interval should help you to determine what is going on - probably executed with >> to write to a log-file... you should be able to determine the process quickly and hopefully find out if it is PRTG or not - it is possible that it is but I wonder why it would go to 445 on this IP then... #curious now..

Regards

Florian Rossmark

www.it-admins.com

What Florian said :D It's indeed a bit weird that this port is queried for an external address.

PRTG Scheduler | PRTGapi | Feature Requests | WMI Issues | SNMP Issues

Kind regards,
Stephan Linke, Tech Support Team

I'm 99% sure that it's PRTG causing this. Reason being when I first saw the firewall alert I isolated the VM for a period of time and eventually decided to rebuild on a new VM. I didn't receive any new alerts until after I installed PRTG onto this new VM also... (you can probably see why I'm so confused now!)

In terms of intervals it appears to make a 5 attempts per night (roughly 23:30 UK time).

I think I will have to run a netstat with a log output and leave it running overnight....

Let us know how that went :)

PRTG Scheduler | PRTGapi | Feature Requests | WMI Issues | SNMP Issues

Kind regards,
Stephan Linke, Tech Support Team

Okay so I left a netstat command running last night outputting to a log file every 5 seconds and it has confirmed my suspicions!

In the netstat log file I have a line for:

[PRTG Probe.exe]
TCP     $LANIP:60773      216.58.208.132:445    SYN_SENT      4

This is in line with the firewall alert I received last night from the firewall at this time.

The only other reference I can see to this IP is on port 80 as I have a HTTP sensor configured to test internet connectivity to Google... I'm going to pause this sensor and see if it still occurs tonight but I'm still unsure as to why this is happening!

So, how did it go? :)

PRTG Scheduler | PRTGapi | Feature Requests | WMI Issues | SNMP Issues

Kind regards,
Stephan Linke, Tech Support Team

Still the same after pausing the HTTP sensor, alert went off twice last night as before...

This is getting more and more mysterious. The probe itself only connects to servers it has an actual device for, i.e. it doesn't scan devices that are not actually existing within PRTG except there's an auto discovery scanning that very network. Could you check the following file to see if it [the IP] is in there:

C:\ProgramData\Paessler\PRTG Network Monitor\Logs\debug\CoreAutoDiscovery.log

Otherwise, I'm pretty much still riddled on what the cause might be...

PRTG Scheduler | PRTGapi | Feature Requests | WMI Issues | SNMP Issues

Kind regards,
Stephan Linke, Tech Support Team

I agree!

I've checked the CoreAutoDiscovery.log and no trace of that particular IP address nor anything within that range...

www.google.com is listed due to the creation of the HTTP internet sensor but that that's it.

I also forgot to mention that the IP address it attempts to connect to can differ, for example last night it was 216.58.208.132 (still a Google owned IP address).

Based on this I can only assume it's connecting to a hostname?

Now that you mention it I do monitor our intranet site that does have references to Google (coded by a previous member of staff) but not 100% what it could be attempting to pull data wise.

I've performed a search in PRTG for google and nothing appears.

Nothing else in the firewall logs but I think you might be onto something with the intranet site actually so I've paused our internal web server sensor's to see if this makes a difference.

James

• open the link you check with PRTG in your web browser - Chrome if you want
• press F12 on your keyboard
• press CNTRL + F while in the little code-window (ELEMENTS)
• search for 445 is you want... or for google

Alternative - right click anywhere on that page and select VIEW CODE / VIEW PAGE SOURCE and search in that document for 445 or Google.

It should have 445 in there... this should cause this... Try it :-)

Florian

Thanks for the detective work, Florian! :)

PRTG Scheduler | PRTGapi | Feature Requests | WMI Issues | SNMP Issues

Kind regards,
Stephan Linke, Tech Support Team

Seems you were onto something Florian!

I had already paused the sensor for the IIS server before I saw your response but as suspected I had no alert last night...

I think we've narrowed it down now and I will do some further internal investigations.

Thank you Stephan + Florian for your help!

Regards,

James