This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Windows Server 2012 R2 Remote Desktop Gateway, Windows 10 Pro 1803 client and UTM 9.510-5 WAF

Good day,

I have been using Sophos UTM for a number of years now and know my way around the solution and its features reasonably well. I have several applications using the WAF feature including MS Exchange (Outlook Anywhere and ActiveSync), and until recently Remote Desktop Gateway (RDG) without any issues. Today I am struggling with RDG installed on Windows Server 2012 R2, and Windows 10 Pro 1803 clients trying to access the service via UTM 9.510-5 WAF.

Examining the WAF logs, I'm finding entries referencing URLs that are non-existent on the RDG server:

2018:09:10-14:26:30 #redacted# httpd[27345]: [url_hardening:error] [pid 27345:tid 3741174640] [client #redacted#:49501] No signature found, URI: https://#redacted#/KdcProxy 2018:09:10-14:26:30 #redacted# httpd[27345]: [url_hardening:error] [pid 27345:tid 3900636016] [client #redacted#:49497] No signature found, URI: https://#redacted#/remoteDesktopGateway/

Thing is, "/KdcProxy" and "/remoteDesktopGateway/" do not exist on the IIS site included in RDG, only "/Rpc" and "/RpcWithCert" are. Adding the URLs to the exceptions list is pointless as this simply results in 404 status codes being returned instead (because they don't exist).

Curiously, using an older Windows version seems to work fine, which leads me to suspect that something changed with the way Remote Desktop clients on Windows 10 communicate with the RDG via WAF; I don't run into any issues when accessing RDG on the internal network, only when accessing via WAF. I'm stumped and would appreciate any guidance from more experienced UTM admins.



This thread was automatically locked due to age.
Parents Reply Children
  • Hi Louis,

    you needed to disable the common threat filtering.

    The last time i tried this, the RDG_Out Data was not known to the Firewall and it was blocked.

  • I did need to disable the commons threat filter as it wasn't logging what was being blocked. By the process of elimination, we discovered it was something within it but never got around to nailing it down as we ran out of time. For now, we're happy that it's running using WAF rather than DNAT although I do appreciate it could do with tightening up a little to bring the common threats filter into play.