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.