Hi,
I stumbled upon an issue with the Softnetwork disconnection of Windows in combination with the Windows Defender Firewall with Advanced Security.
It seems not always the correct network profile is assigned, and hence not the correct firewall rules.
The setup:
Windows 10 1803
Firewall rules deployed via GPO
In this scenario, we have 2 types of connection: A 4G cellular connection, which is considered as Public. And cabled network via ethernet, which is internal and so Domain.
On public we explicitly deny/block RDP on port 3389, but on domain we allow it. This for management and support reasons. (Inbound rule)
Now, when you don't explicitly disable "soft disconnect", which is an added value to windows when using it, and you have for your cellular connection the box "let windows manage this connection" checked, it seems the firewall isn't correctly working.
You launch your machine, which will automatically connect to the cellular network, and the Network Profile "Public" is attributed to this connection, and also the Firewall rules for this profile are applied.
Then you plug-in the networkcable, and the NLA services will detect a network change and a new Network Profile gets assigned: Domain. This means the firewall rules for the profile Domain get applied...
Now, al good and well you would say. But it isn't!
Due to the softconnect, the cellular connection keeps its connection and IP-address assigned.
Since now the firewall rules for the profile Domain are applied, the explicitly blocked port 3389 is exposed as and vulnerable on this public connection, and reveals itself in portscans on this public internet connection. This also results in active attempts to abuse this port, although we explicitly blocked it on the profile Public.
For me this seems a security issue, because you would expect the firewall rules for the profile Public would still be applied on this kept-alive network connection... But it isn't...
The windows defender firewall with advanced security considers now both connection to be the same: Domain....
So, this means restrictions you put in place for inbound or outbound rules on the public network profile aren't applied.
This case was reproduced multiple times, and all traces can be found in the eventlog to support this.
This doesn't seem a configuration issue of the firewall, since when only having this public cellular connection, the connection attempts on port 3389 are blocked. When having the network + cellular connection, connection attempts on 3389 aren't block anymore.
