4

From the Windows Mystery Caves:

a user trying to access a Windows Server 2008 R2 Remote Desktop Session Host is getting network timeouts upon connection establishment attempts. The Remote Desktop exception has been enabled and restricted (among other subnets) to the remote subnet 192.168.202.0/23. The user host's IP address is 192.168.203.63. The firewall log does not contain dropped connection attempt entries with this IP address.

If I change the Windows Firewall Logging settings for the domain profile and enable the logging of successful attempts like this,

enter image description here

connections start to establish successfully and are logged with "ALLOW" entries in the firewall log. Disabling the logging of successful attempts breaks the user's connection establishment again. Another user's machine with a host IP address of 192.168.203.71 seems unaffected and can initiate connections even with logging disabled.

WTH? What exactly is the logging setting changing aside from actually enabling logging?

the-wabbit
  • 40,737
  • 13
  • 111
  • 174
  • +1 - Always the mysterious ones with you. I am completely unaware of any actual policy/setting that is changed beyond just logging itself, so it is odd that it wouldn't work without logging enabled. – TheCleaner Jan 20 '14 at 14:06

2 Answers2

1

Try to lower security settings for Remote Desktop connection at Control Panel - System and Security - (section System) Allow remote access. It opens windows System Properties on tab Remote. On the lower part of window is group Remote Desktop, where you can set Remote Desktop security level. Try to change it from Allow connections only from computers running Remote Desktop with Network Level Authentication (more secure) to Allow connections from computers running any version of Remote Desktop (less secure)

Jan Papež - honyczek
  • 101
  • 1
  • 9
1

It seems that this just have been either a coincidence or a side-effect. After having analyzed the connection timeouts using network traces from the client side, it became clear that the root cause has been a generic negotiation timeout of 60 seconds at the client. The timeout clock seems to wait for the TLS handshake as well as the x.204 handshake to complete and it has expired repeatedly.

The reason for this was the client's inability to fetch the current certificate revocation list for the server's certificate's CA due to the fact that the client only is allowed to access the Internet through a proxy. The proxy configuration method of choice is PAC on the given site, and apparently the CRL update method does not support PAC. It is trying to do a direct connection or get proxy information via WPAD instead, which both have own timeout timers and sum up to more than 60 seconds in total, failing the entire remote desktop connection attempt as a result. The workaround was to manually configure a proxy in IE Internet Options.

I have no idea why I got a correlation with enabling / disabling firewall logging for connection failures, though.

the-wabbit
  • 40,737
  • 13
  • 111
  • 174