Windows Discovery and WinRM

DuaneNMore
Kilo Guru

We are running istanbul patch 3; and are attempting to set up the firewalls to allow Windows, Linux and network Discovery. For garden variety discovery we thought that the following ports would be sufficient: UDP-161:162                                   TCP-21   TCP-22   TCP-80   TCP-135                               TCP-139                               TCP-443                               TCP-1433             TCP-1521                         TCP-5480                   TCP-5989                         UDP-137                           TCP/UDP-53.

However a look at the Firerwall log indicates it is attempting 5985 and 5986 which are associated with the WinRM (https://docs.servicenow.com/bundle/istanbul-it-operations-management/page/product/mid-server/task/t_...). I don't know if this is a bug or desired behavior, but the

mid.windows.management_protocol parameter is not configured for the mid server so it shouldn't be using WinRM.

Another thing I stumbled across here is the DCOM behavior where it connects over port 135, and then gets told to go use some port in the TCP-49152:65535 range. I stumbled across some guidance (after the failure) about how this works.

So the real question here is: for those locations that are not going to open up the midserver to communicate over any ports when doing discovery; is there a concise bit of guidance on the ports and protocols actually used?

                                                                                             

UDP-161:162TCP-49152:65535TCP-21TCP-22TCP-80TCP-135TCP-139TCP-443TCP-1433TCP-1521TCP-5480TCP-5985TCP-5986TCP-5989UDP-137TCP/UDP-53
1 ACCEPTED SOLUTION

Stephen Farrar
ServiceNow Employee
ServiceNow Employee

Hi Duane,



In terms of the WinRM comment, it wouldn't surprise me if it tries it to see if it's available, especially if WMI fails for some reason. You might also want to check in case you have other mid servers that do have the parameter configured and it's using one of those unexpectedly.



I gather with DCOM you figured out what was going on there - essentially that after the initial connection it gets assigned a random port to communicate on, but generally as long as your firewall allows the return connection that should 'just work', will depend on your firewall config though for sure.



In terms of the ports/protocls that are used, this page might help:


Discovery ports and protocols



That has a pretty good summary of all the ports etc.



Hope that helps,


Stephen


View solution in original post

3 REPLIES 3

Stephen Farrar
ServiceNow Employee
ServiceNow Employee

Hi Duane,



In terms of the WinRM comment, it wouldn't surprise me if it tries it to see if it's available, especially if WMI fails for some reason. You might also want to check in case you have other mid servers that do have the parameter configured and it's using one of those unexpectedly.



I gather with DCOM you figured out what was going on there - essentially that after the initial connection it gets assigned a random port to communicate on, but generally as long as your firewall allows the return connection that should 'just work', will depend on your firewall config though for sure.



In terms of the ports/protocls that are used, this page might help:


Discovery ports and protocols



That has a pretty good summary of all the ports etc.



Hope that helps,


Stephen


Thanks, I had been using the ports and protocols page you provided the link to. Maybe the thread was a little bit of griping over the fact the WinRM thing was happening, and Microsoft DCE RPC negotiation and the impact on ports was not described.


Fair enough, it's worth providing that feedback on the docs page then it should get improved with that info.