Link to home
Start Free TrialLog in
Avatar of ShawnGray
ShawnGray

asked on

137/upd open|filtered netbios-ns

Using an a/v mgt console to scan for computers on the network (from Win server 2008r2).  
Once machines are found I can push install the endpoint protection from the console.
Of 30 machines (mixed win10, win7) 10 are found.  20 are not.  (OS didn't seem to matter, some of each in found and not found).

Using nmap,
the 10 that are found show:
     137/upd open               netbios-ns

The 20 that are not found show:
     137/upd open|filtered netbios-ns

1. I've check the firewall settings on each, the settings are the same.
2. Have imported wfw to a machine that isn't found (using wfw from a found machine)
3. I have "restore default policy" and enabled 137 over the domain

Mgt console still can't find the 20.  It seems I need to remove the "filter" on the port.
Don't know how to make this happen.
Any suggestions?

nmap results of a found machine:
Nmap scan report for xx.xx.xx.73
Host is up (0.016s latency).
PORT    STATE         SERVICE
135/udp open|filtered msrpc
137/udp open          netbios-ns
138/udp open|filtered netbios-dgm
139/udp open|filtered netbios-ssn
443/udp open|filtered https
445/udp open|filtered microsoft-ds

nmap results of machine not found
Nmap scan report for xx.xx.xx.55
Host is up (0.00s latency).
PORT    STATE         SERVICE
135/udp open|filtered msrpc
137/udp open|filtered netbios-ns
138/udp open|filtered netbios-dgm
139/udp open|filtered netbios-ssn
443/udp open|filtered https
445/udp open|filtered microsoft-ds

Thank you
Avatar of Adam Brown
Adam Brown
Flag of United States of America image

Are all systems using the same version of Windows? If so, make sure they are all configured to have Network Discovery enabled. http://www.technig.com/enable-network-discovery-via-group-policy/ explains how.
Avatar of ShawnGray
ShawnGray

ASKER

some Win7, some win10
all have network discovery enabled
The documentation will mention what ports are needed - if it doesn't, ask their support to give them to you. Then, crate a GPO with a firewall policy that has an inbound rule opens up these ports for the management server,
Thanks but I have the necessary ports open.  Recall some machines are found, some are not.
The only difference is port 137 on the machines that are found show "open"
The machines that are not found, nmap returns "open|filtered"
Those "open | filtered" messages mean, that the state cannot be determined - it could be open but not to your scanning station but instead be filtered to be reachable from certain machines, only.
Did you try to open those ports on the firewall by now? It's a matter of seconds. open|filtered should not appear but "open".
Another curiosity is what do those 20 systems have installed on them now that may differ from the other 10?
Thank you for the comments.  I compared two machines firewall in and outbound settings, line by line.
Cleaned up a couple of lines on a machine that couldn't be found, but still can't 'find' it.

Also, I completely shut off the firewall thinking that would result in a different result.
Interestingly, no difference even with no firewall.

The 20 that can not be found have generally all the same apps.  General MS Office machines.
Nothing special or different about any of them.  

Still puzzled.
ASKER CERTIFIED SOLUTION
Avatar of McKnife
McKnife
Flag of Germany image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
I turned the firewall off via the gui - just to see if it made a difference.
I concluded (maybe incorrectly) that if I could reach it with the firewall off that it was a setting I just needed to hunt down.  Since it proved no different, I'm assuming its not a firewall setting?

To your point, I suppose something else could be blocking it (security or a/v).  Seems like the issue must reside outside of the firewall.
Are all the systems on the same ip subnet? And which A/V solution are you using? Windows 7 and 10 both use LLMNR lookups to find systems, which doesn't cross subnet boundaries, usually. Another thing to check is whether systems are configured for WINS. It's really not necessary to have wins for any reason these days, but some people still do, and it may be required by the av console.
"I suppose something else could be blocking it (security or a/v)" - that's what I say. To make sure, uninstall those security softwares if there are more then the one this problem is about.
"Seems like the issue must reside outside of the firewall" - outside of the windows firewall, yes. The win firewall is not prone to errors. 3rd party firewalls and security software with network filtering is often producing errors.
You never did cite whether those machines had an existing security of AV solution on them, just that you were trying to push one to them. What's in place now?

Also, have you checked to make sure that NetBT is enabled on those systems? (I figure that it is enabled, but might as well check to be sure)
a/v is Malwarebytes
Also using MS Intune Endpoint protection
Malwarebytes 1.4 was on each endpoint.
This process of scanning with Malwarebytes Mgt Console was to upgrade each end point with v1.8.

Removed the existing version of Malwarebytes from a machine that could not be found.
Also, removed MS Intune from the same machine.
Scanned to find machine, same result.  

Yes NetBT is enabled.  This is part of the puzzle.  Comparing a 'found' machine with one that is 'not found'
all settings appear similar in the firewall and adapter settings.   Baffling.  Disabled firewall, removed A/V solutions,
still nmap still shows 'open|filtered' on machines that can't be found.  Machines that are found, nmap shows 'open' only.
Can't find the logic in these results.
Ok... open an elevated command prompt on such an machine and launch
netstat -bano | findstr portnumber

Open in new window

You will get a result like this:
C:\WINDOWS\system32>netstat -bano |findstr 135
 TCP    0.0.0.0:135            0.0.0.0:0              LISTENING       304
  TCP    [::]:135               [::]:0                 LISTENING       304
In this example, I verified which process is listening on port 135 - it's process ID 304. Now I can find out, what process/service is behind ID 304: simply open task manager and go to the details or services tab and have the PID listed.

See if that port(s) is being listened on.
UPD  0.0.0.43:137   *:*     4

(Although same result on a 'found' computer)
0.0.0.43? What? That's the output? Should be yourIP:137
Did you compare that with discoverable ones?

Netbios over TCP/IP was turned on in the properties of the NIC, you say?
The other potential interfering products were uninstalled, firewall turned off, for a test?
That would be weird behavior, then
Sorry, detail

upd 10.0.30.43:137   *:*     4

-Same output on discoverable machines
-NIC, NetBIOS over tcp/ip set to "default" on all machines
-Other potential interfering products were uninstalled and firewall turned off to test the system
 10.0.30.43 is a 'hot spare' so I also, had Win 10 reinstalled (removed files just to get a clean environment)
-Agreed, this is all completely weird.
Turn on netbios over tcp/ip, don't leave it at defaults although all others have the same setting.
Had a minor breakthrough.  
When scanning for computers on the network, one option in the Malwarebytes Management Console (MBMC) is to "Scan computers under OU".
This allows me to scan groups under my domain.local accounts.  The other method was IP range only.
When I selected this method it still only returned the same 10.
However, when I select the option in the MBMC to "Enable Serial Client IP Detection"
it returns a total of 20 machines.

Still uncertain why the remaining 10 aren't found.
Beginning to think this may be a DHCP issue (?)  
My DHCP "Conflict detection attempts" was set to 0.  
I've changed to 1.  Believe I need to restart to take affect.
Will do that this evening and try again.
What should DHCP have to do with this? It does not influence the client. I can't follow.
Did you at least try with netbios over tcp/ip enabled?
Grasping on the DHCP thing.  Thought I might have an IP conflict across the network.  Not the case.
Yes tcp/ip was specifically enabled.

I'm going to have to assume, at this point, that it was your original thought with a/v getting in the way.
Only a couple of machines aren't found at this point.  Those machines will be wiped and upgraded from 7 to 10.
Thank you for the thoughts on this.
You are welcome and good luck.