I’d like to use Caddy to proxy traffic between a Mac/Windows Remote Desktop Clients and a Remote Desktop Gateway using a subdomain. It looks like this has been discussed without resolution here, and more recently here.
I currently have Caddy running on Windows and successfully passing traffic to various internal resources using multiple subdomains for nextcloud and vpn but I can’t seem to get the rd subdomain proxying Remote Desktop Connections. The terminal window where i’m running Caddy says it’s serving the remote desktop subdomain but none of my various remote desktop clients will connect. Bypassing Caddy and port forwarding via the router allows my remote desktop clients to connect perfectly.
Here’s a sample from my caddyfile…
rd.example.com {
proxy / https://10.10.10.10 {
insecure_skip_verify
transparent
}
header / {
# Enable HTTP Strict Transport Security (HSTS) to force clients to always
# connect via HTTPS (do not use if only testing)
Strict-Transport-Security "max-age=31536000;"
# Enable cross-site filter (XSS) and tell browser to block detected attacks
X-XSS-Protection "1; mode=block"
# Prevent some browsers from MIME-sniffing a response away from the declared Content-Type
X-Content-Type-Options "nosniff"
# Disallow the site to be rendered within a frame (clickjacking protection)
X-Frame-Options "DENY"
}
ipfilter / {
rule allow
database GeoLite.mmdb
country US
}
}
Other things i’ve tried:
Removing ‘header’ and ‘ipfilter’ subsections from caddyfile.
Adding a combination of the following to the caddyfile under ‘proxy’…
health_check_timeout 0s
header_upstream Host {host}
header_upstream X-Real-IP {remote}
header_upstream X-Forwarded-For {host}
header_upstream X-Forwarded-Proto {scheme}
health_check_timeout 0s
Using ‘net’ instead of ‘proxy’, but ultimately had no idea what I was doing even after reviewing the help documentation for ‘net’. I also believe that i’m not able to run ‘proxy’ and ‘net’ at the same time. So using ‘net’ might be a dealbreaker if it kills proxy to my existing subdomains.
Looked into the remote desktop gateway logs but couldn’t correlate a log entry with an attempted remote desktop connection.
My understanding is that while it uses HTTPS on port 443 to secure the connection, RD Gateway still uses RDP to communicate. Caddy’s HTTP server doesn’t talk RDP, so that would be a no go. The net server type is likely the only way to go about it. There’s a link to the docs here:
Edit: To follow up on this a bit, it looks like RD Gateway (and Exchange/Outlook Anywhere) use a pretty non-standard setup to handle this. Definitely beyond Caddy’s HTTP proxy capability, and based off what I found after some quick searching, beyond Apache’s as well - at least by default:
Unfortunately, RPC-over-HTTP compatibility in Apache looks like a “will not fix”. Its behavior doesn’t jive with how mod_proxy handles communication, and they aren’t inclined to bend over backwards for Microsoft’s non-standard HTTP behavior.
There’s a third party Apache module that is built to handle this that explains a bit about how it works:
Outlook and Exchange use an extended version of DCE RPC called MSRPC to communicate with each other. When Outlook Anywhere is in use, the MSRPC messages are wrapped into HTTP alike requests and responses. The mod_proxy_msrpc module detects these MSRPC messages and forwards them to the server or client as needed. As soon as the initial handshake completed, i.e. Exchange accepted the connecting client, the mod_proxy_msrpc module switches into tunnel mode and forwards all data from client to server and vice versa.
@Whitestrake Thank you for linking those resources and submitting a feature request. I didn’t think to research remote desktop issues with other reverse proxies in order to identify a common underlying issue. Much appreciated.