Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Document] TUN interface needs DNS server configuration on Windows #327

Closed
2 tasks done
LorenEteval opened this issue Jan 8, 2024 · 4 comments
Closed
2 tasks done
Labels
documentation Improvements or additions to documentation Stale

Comments

@LorenEteval
Copy link

LorenEteval commented Jan 8, 2024

Verify steps

  • Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.
  • I have searched on the issue tracker for a related issue.

Version

2.5.1

What OS are you seeing the problem on?

Windows

Description

Hi. According to the Windows examples in the wiki: netsh interface ip set address name="wintun" source=static addr=192.168.123.1 mask=255.255.255.0 gateway=none, notice that there's no further DNS server address configured for TUN device, which will leave DNS server address empty (as expected).

After completing the whole configuration steps, however, I observed that the DNS request from my local computer never goes through the TUN. I checked tun2socks log and also used wireshark to monitor traffic on both TUN device and default network card. It all shows that the DNS traffic was sent to my default network card, which somehow not complying with the purpose of tun2socks.

I'm not sure if this is a bug related to tun2socks itself. It's more like some kind of OS(Windows) mechanism since these traffic (UDP) should be sent to the TUN defined by routing tables, where no DNS server address configured results in DNS resolution failure. However I can do test like iptables /flushdns then curl google.com successfully.

I searched related issues and found that in #94 there's one more example step netsh interface ip set dns name="tun00" static 8.8.8.8. After DNS server address is configured, I found that DNS traffic was sent to TUN device (also verified by logs and wireshark).

CLI or Config

The socks5 proxy is a localhost proxy provided by Xray-core and confirmed that UDP option is enabled

Then perform all required steps in the Windows wiki page

Logs

See below

How to Reproduce

After tun2socks started and performed required TUN setup, keep repeating steps with ipconfig /flushdns and curl icanhazip.com

a. No DNS server configured in TUN device

image

b. DNS server (8.8.8.8) configured by netsh interface ip set dns name="tun00" static 8.8.8.8 above

image

The DNS server can also be configured by OS settings(of course) to achieve the same test result. It can also be observed by wireshark(I did not upload wireshark pcap files for simplicity). The test is carried out under Windows 11 22H2. I'm not sure if other platform has this issue.

@xjasonlyu xjasonlyu added the documentation Improvements or additions to documentation label Jan 8, 2024
@iLemonRain
Copy link

it will be much better if it could support remote DNS

Copy link

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days

@github-actions github-actions bot added the Stale label Mar 10, 2024
@shakibamoshiri
Copy link

it is not about just Windows, on Linux the same issue exists

@github-actions github-actions bot removed the Stale label Mar 11, 2024
Copy link

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days

@github-actions github-actions bot added the Stale label May 11, 2024
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale May 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation Stale
Projects
None yet
Development

No branches or pull requests

4 participants