Setting Up TUN-based Global Transparent Proxy on Windows

This article is currently an experimental machine translation and may contain errors. If anything is unclear, please refer to the original Chinese version. I am continuously working to improve the translation.

Some built-in Windows applications, such as SMB or RDP, cannot be configured to use a Socks5 proxy.

This makes it inconvenient to access home server resources like SMB file shares over the public internet.

Additionally, certain applications (e.g., QQ or git) don’t use the system proxy by default and require manual configuration, which can be cumbersome.

The transparent proxy setup based on a soft-router gateway, discussed in the previous article, can solve these issues.

However, laptops are often used across various network environments rather than staying under a fixed router. In such mobile scenarios, setting up a TUN-based global proxy becomes much more convenient.

First, install a VPN client. Clash for Windows (“Clash Verge” or commonly known as “little cat”) is used here because it’s relatively easy to configure.

In this case, Clash serves to establish an encrypted tunnel from the public internet to your home network, while leveraging its built-in features to create a TUN device for traffic proxying—functionality similar to the internal-resource-access VPNs provided by universities or enterprises.

1. Enable TUN Mode and Service Mode in the GUI. Do not enable System Proxy.

   Settings

2. In Settings, configure the profile mixin with the following YAML content:

   mixin: # object
     tun:
       enable: true
       stack: gvisor
       dns-hijack:
         - 198.18.0.2:53
       auto-route: true
       auto-detect-interface: false
     interface-name: WLAN  # Change "WLAN" to match your actual internet-facing network interface name
   
     dns:
       enable: true
       enhanced-mode: fake-ip
       listen: 127.0.0.1:53
       nameserver:
         # - 114.114.114.114  Use plain DNS instead of DoT/DoH if you prefer faster responses
         # - 8.8.8.8
         - tls://223.5.5.5
         - tls://223.6.6.6
         - tls://dot.pub
       fake-ip-filter:
         - "dns.msftncsi.com"
         - "www.msftncsi.com"
         - "www.msftconnecttest.com"

3. Add your available proxy servers in the configuration file, define a proxy group, and set routing rules for your local network segments.

   # For reference only — modify according to your actual setup!
   proxy-groups:
     - name: LAN192
       type: select
       proxies:
         - DIRECT
         - home-ipv6
   
   rules:
     - IP-CIDR,192.168.1.0/24,LAN192
     - MATCH,DIRECT

With the above configuration, Clash should now be able to route local network traffic through the virtual TUN interface to your designated server.

Connection

Now let’s break down how this works.

When accessing a website via domain name:

1. The user makes a DNS request for a domain. This request is intercepted by Clash’s virtual network interface. Instead of forwarding it immediately, Clash assigns a fake IP address from its reserved fake-IP range (198.18.0.0/16) and returns that to the system. Meanwhile, Clash sends a real DNS query to the configured upstream DNS server(s) to resolve the actual IP.
2. When the user attempts to connect to the fake IP, the packet is again intercepted by the TUN interface. Clash maps the fake IP back to the original domain name, checks the domain against proxy rules, and decides whether to proxy the connection. If proxying is required, the connection (along with the domain) is encapsulated—typically as a SOCKS5 request—and forwarded through the established proxy tunnel.
3. If no proxy is needed, the traffic goes directly to the real IP address and proceeds normally.

When accessing via IP address directly:

1. The destination IP is matched directly against the routing rules. If the rule indicates proxy usage, the packet is encrypted and sent to the remote proxy server.

I don’t fully trust the chaotic university intranet or password-free public Wi-Fi networks. I also prefer to avoid sending any data in plain text—even though most traffic today is already HTTPS. Establishing a full encrypted tunnel is thus a practical solution.

Note: I noticed that Clash’s DNS hijacking doesn’t actually block the original DNS requests. Using Wireshark, you can still see responses coming back from the DNS servers assigned via DHCP. Therefore, if you’d prefer not to use the school-provided DNS at all, you can manually set the Wi-Fi connection’s DNS server to 127.0.0.1. This ensures only DoT/DoH upstreams are used for name resolution.

This article is licensed under the CC BY-NC-SA 4.0 license.

Author: lyc8503, Article link: https://blog.lyc8503.net/en/post/configuring-tun/
If this article was helpful or interesting to you, consider buy me a coffee¬_¬
Feel free to comment in English below o/