Monday, June 16, 2014

The one with the Network Profile

Hi there,

It's been a while since I posted something. I blame my employer for keeping me busy :)

So I'm on this project for few days where I have to build some physical servers, install the OS on them, patch them to the switches, etc.
Part of the build requires setting up a DC and joining the other servers to the domain. Done and dusted in no time. After joining the servers to the domain I moved from using the KVM in the datacenter to managing the servers remotely. Not that before it wasn't possible but I usually do things in one shot: set IP & join to the domain.

To my surprise I wasn't able to RDP to the boxes. The firewall in Windows was turned on so I said to check if the rule to allow RDP is on. It was on but only for Domain and Private networks. I checked the Network profile I was on and what do you know - I was on a Public Network profile. That is not right - it should've been Domain  Network profile.

After some more digging around to understand how the Network profile is set I fired up Process Monitor (When in doubt run process monitor :) ) to have a look at the network traffic. I used Wireshark at the same time but in this case it's easier to spot the problem in Process Monitor.

I noticed that after plugging the network cable in the server, Windows (2012 R2) was starting to identify the network type. It does this by by opening a connection to the domain controller on port 389 and performing some queries (I will not go into details).

As seen below - there are plenty of UDP send packets but no response:


I plugged the DC and a client into another switch (a 5 port - 10 year old one) and the network type was set to Domain right away. The only thing that could create such a problem is if for some reason the switch doesn't start forwarding packets right after the cable is plugged in. Aha - spanning tree protocol...:) What Windows does is that it tries to identify the network right away without actually knowing if the switch/switch port is in a state to process/forward packets.
After a chat with the networking admin and changing the ports' spanning tree state to "portfast" the problem went away. Now I can see replies to the outgoing packets and the network profile is set to the correct one. This means the firewall profile Windows is using is also the correct one.



No comments:

Post a Comment