Is OpenClash Causing Unstable Remote Desktop Port Mapping? Troubleshooting RDP Return Path and DNS Issues

I've been using it recently OpenClash + MosDNS + AdGuardHome While building the DNS modding system, the overall network experience was excellent, with ad filtering and traffic rerouting for faster speeds performing very well. However, during actual use, I encountered a rather tricky problem:

Accessing Remote Desktop (RDP) via DDNS + port forwarding is very unreliable; sometimes the connection works, and sometimes it doesn't.

I encountered this problem when I was previously using PassWall + AdGuard Home + MosDNS It wasn't present at the time; it's clear that some mechanism in OpenClash was interfering with the remote desktop traffic.

Remote Desktop Configuration

Issue Identification: Source Traffic Control Settings

After some troubleshooting, I finally found a key setting in OpenClash:

Source Traffic Access Control

Simply put, its function is:Allow traffic on certain ports to bypass the Clash core and be forwarded directly through the system. This setting is crucial for services such as Remote Desktop that require a stable connection.

Port Forwarding Settings

Security Reminder: Do not directly map port 3389

Although the connection is stable, mapping port 3389 directly to the public internet is extremely dangerous. We recommend:

  • Switch to a higher port (e.g., 54289 → 3389)
  • Set a strong password and limit the number of failed login attempts
  • Add firewall policies or geographic restrictions
  • Alternatively, you can use tools for bypassing network restrictions—such as VPNs, FRP, and ZeroTier—instead of port forwarding.

Summary

If you're also using OpenClash for bypass routing or transparent proxy and are experiencing unstable remote desktop connections, you might want to try this configuration—it can effectively resolve the interference caused by the Clash core on port traffic. Also, remember to implement proper security measures to avoid exposing your service to the public internet.


???? Link to the original illustrated tutorial :https://kejilaowang.com/openclash-fake-ip-redir-host-ddns/

Related Reading:

Why does port mapping stop working after the proxy is enabled?

Once a public network request enters the internal network, the return traffic must travel back to the user via the correct gateway. If the return path for the RDP host is rerouted by the OpenClash proxy, policy-based routing, or incorrect DNS rewriting, asymmetric routing occurs: connection requests arrive, but responses exit via a different path, ultimately resulting in timeouts, intermittent connectivity, or disconnections immediately after connection.

Recommended Troubleshooting Order

  1. First, temporarily disable OpenClash to verify that port forwarding and Windows Remote Desktop itself are working properly.
  2. Verify the default gateway, static IP address, and primary port-forwarding destination of the RDP host.
  3. Add the domain names, target IP addresses, or internal network devices related to remote access to the direct connection rules.
  4. Check the Fake-IP filter list to prevent LAN domain names and DDNS domain names from being incorrectly mapped.
  5. Check IPv6: If the domain name returns both AAAA records but the IPv6 firewall or backhaul is not configured, connection inconsistencies may occur.
  6. Check the OpenClash, main router, and Windows Firewall logs to determine at which layer the block occurred.

Do not directly expose port 3389

Mapping the default RDP port directly to the public internet will result in constant scanning and password attacks. It is strongly recommended to first connect to your home network via WireGuard, Tailscale, or another trusted VPN before accessing the internal RDP; at the same time, enable network-level authentication, strong passwords, two-factor authentication, and login auditing.

Fake-IP and Local Area Network Services

LAN domain names, NAS devices, printers, and remote desktop targets should typically return their actual internal IP addresses. Add these domain names to the Fake-IP filter or local domain name policy, and ensure there are no circular forwards between dnsmasq, MosDNS, and AdGuard Home.

Original article by Tech.laowang. If you wish to repost this article, please credit the source: https://techlaowang.com/en/openclash-mosdns-adguardhome-rdp/

Like (0)
Tech.laowang's profile pictureTech.laowang
Previous April 12, 2025, 4:38 a.m.
Next April 18, 2025, 2:49 p.m.

Related Recommendations

Explore the world of technology and gain access to software solutions and expert insights on accessing the internet from abroad—your trusted technology resource platform!