Forum Discussion
Issues with Network Name Resolution
Following a request to disable RDP for NNR, MS Support states telemetry data for our MDI deployment failure rates for RDP is 45% and 77% NetBIOS. I do not have any health alerts for low name resoluti...
Still working with support on getting trace logging to troubleshoot high NetBIOS failure rate but I think we have a good portion nailed down to VPN clients.
We allow NetBIOS and NTLMrpc outbound thru the enterprise firewall and VPN to VPN clients but are blocking inbound UDP137 on the local firewall. I see many drops in those logs and they, from a time perspective, "loosely" correlate to UDP outbound from corporate. Source and destination port in the log are UDP137.
Admittedly I am not a protocol expert, but I find a few things odd:
- the source and destination of these drops are the client IP
- i see about 25 drops in the client FW for every inbound from corp DC
- the timing of the drops vary from 20 - 60 seconds off corp FW timestamp (not consistent enough to state it affirmative as time difference between them)
Any thoughts or is this expected behavior
Here is a sample event from the local firewall.
| date | time | action | protocol | src-ip | dst-ip | src-port | dst-port | size | tcpflags | tcpsyn | tcpack | tcpwin | icmptype | icmpcode | info | path |
| 2/10/2021 | 1:38:46 | DROP | UDP | x.x.x.x | x.x.x.x | 137 | 137 | 0 | - | - | - | - | - | - | - | SEND |
EliOfek
Microsoft
MicrosoftNot sure what clues this is giving us.
Assuming your DC/Sensor machine is in corp network, and the target endpoint is a VPN client, the flow should be:
VPN client endpoint authenticates to the DC.
In response, the Sensor sense this connection, and respond back to the VPN client endpoint IP with a netbios request (this should happen within seconds).
it might try that 2 times if it doesn't get a response.
I don't see how this correlates with the numbers you mentioned...
