New Question
 
 
PRTG Network Monitor

Intuitive to Use.
Easy to manage.

200.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free PRTG
Download >>

 

What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

 

Top Tags


View all Tags


PRTG Install attempting to connect to 216.58.204.36 on port 445

Votes:

0

Your Vote:

Up

Down

Hi,

I've just performed a fresh install of PRTG onto a Windows Sever 2012 R2 VM.

The network discovery has just finished however I have just noticed that the VM is attempting to connect to IP address 216.58.204.36 (appears to be a Google owned IP address) on port 445 (SMB I'm guessing) on a number of occasions.

Our Firewall is blocking this traffic due to SMB being blocked to the internet however does anyone know why PRTG is attempting this connection?

Many thanks.

prtg sensors smb

Created on Dec 7, 2018 2:46:31 PM by  jamesdrake24 (10) 1



Best Answer

Accepted Answer

Votes:

0

Your Vote:

Up

Down

Do you have an HTTP sensor that points to a website that might have some kind of internal content that it would pull from Google, like your INTRANET ?

If you do have e.g. a Google-Logo there and a sensor is trying to see if the whole page can be loaded including this logo then this might explain what is happening. I admit that I don't know if those sensors would follow such data-sources - still - port 445 is not explainable to me - what might just be a typo in such a web-site and you aren't even aware of it.

Did you check your FW logs if any other system in your network is trying to go out on 445?

Did you search your whole PRTG for the keyword google as well to make sure nothing points there? (this would be independent from what I said before).

Florian

Created on Dec 17, 2018 2:39:47 PM by  Florian Rossmark (3,373) 2 2



18 Replies

Votes:

0

Your Vote:

Up

Down

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

SensorsBy TypeC...Common SaaS Sensor

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


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

Kind regards,
Stephan Linke, Tech Support Team

Created on Dec 10, 2018 11:06:24 AM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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

Created on Dec 11, 2018 10:54:03 AM by  jamesdrake24 (10) 1



Votes:

0

Your Vote:

Up

Down

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

Created on Dec 11, 2018 12:23:11 PM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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?

Created on Dec 11, 2018 12:30:15 PM by  jamesdrake24 (10) 1



Votes:

0

Your Vote:

Up

Down

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

Created on Dec 11, 2018 3:03:21 PM by  Florian Rossmark (3,373) 2 2



Votes:

0

Your Vote:

Up

Down

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

Created on Dec 11, 2018 3:07:54 PM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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....

Created on Dec 12, 2018 9:34:23 AM by  jamesdrake24 (10) 1



Votes:

0

Your Vote:

Up

Down

Let us know how that went :)


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

Kind regards,
Stephan Linke, Tech Support Team

Created on Dec 12, 2018 12:01:45 PM by  Stephan Linke [Paessler Support]

Last change on Dec 12, 2018 12:01:52 PM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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!

Created on Dec 13, 2018 9:34:20 AM by  jamesdrake24 (10) 1

Last change on Dec 13, 2018 10:51:31 AM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

So, how did it go? :)


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

Kind regards,
Stephan Linke, Tech Support Team

Created on Dec 14, 2018 12:56:42 PM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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

Created on Dec 14, 2018 1:05:59 PM by  jamesdrake24 (10) 1



Votes:

0

Your Vote:

Up

Down

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

Created on Dec 17, 2018 10:37:42 AM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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?

Created on Dec 17, 2018 11:00:04 AM by  jamesdrake24 (10) 1



Accepted Answer

Votes:

0

Your Vote:

Up

Down

Do you have an HTTP sensor that points to a website that might have some kind of internal content that it would pull from Google, like your INTRANET ?

If you do have e.g. a Google-Logo there and a sensor is trying to see if the whole page can be loaded including this logo then this might explain what is happening. I admit that I don't know if those sensors would follow such data-sources - still - port 445 is not explainable to me - what might just be a typo in such a web-site and you aren't even aware of it.

Did you check your FW logs if any other system in your network is trying to go out on 445?

Did you search your whole PRTG for the keyword google as well to make sure nothing points there? (this would be independent from what I said before).

Florian

Created on Dec 17, 2018 2:39:47 PM by  Florian Rossmark (3,373) 2 2



Votes:

0

Your Vote:

Up

Down

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

Created on Dec 17, 2018 4:26:25 PM by  jamesdrake24 (10) 1



Votes:

1

Your Vote:

Up

Down

  • 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

Created on Dec 17, 2018 7:25:53 PM by  Florian Rossmark (3,373) 2 2



Votes:

0

Your Vote:

Up

Down

Thanks for the detective work, Florian! :)


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

Kind regards,
Stephan Linke, Tech Support Team

Created on Dec 18, 2018 6:38:29 AM by  Stephan Linke [Paessler Support]



Votes:

1

Your Vote:

Up

Down

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

Created on Dec 18, 2018 11:32:27 AM by  jamesdrake24 (10) 1



Please log in or register to enter your reply.


Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.