[Bug] UDP requests mapping from tun0 to eth0 #262
Comments
|
Where did you deploy your dante server? If your dante server is not in the same LAN with tun2socks, it usually causes issue like this. |
|
The dante server was deployed on an external VPS. It was working with linux terminal commands which use UDP but not with mysterium application. |
|
Please find the documentation followed to implement this. https://www.digitalocean.com/community/tutorials/how-to-set-up-dante-proxy-on-ubuntu-20-04 The following reference was used to add extra configs though not required for now to test DNS: https://stackoverflow.com/questions/49855516/telegram-calls-via-dante-socks5-proxy-server-not-working Thank you |
|
Port 53 was bypassed to start the application. On looking further, pinger.go code in logs shows packet length as 32 and some garbage messages were displayed in the logs, where as the direct connection shows packet length as 44. Please find the difference in the logs. Success Logs with direct connection:2023-06-06T21:42:54.881 DBG ../../nat/traversal/pinger.go:460 > Local socket: 0.0.0.0:38576 Failure logs when tun2socks with Socks5 server is used:2023-06-05T09:14:33.987 DBG ../../nat/traversal/pinger.go:460 > Local socket: 0.0.0.0:56437 |
|
Tried enabling UDP over proxy and replicated the code mentioned which was throwing the following error in mysterium. Code link for the Error Message: https://github.com/mysteriumnetwork/node/blob/master/requests/dialer_swarm.go Error message in Mysterium logs:2023-06-07T01:37:42.904 WRN ../../requests/dialer_swarm.go:293 > Failed to lookup host: "discovery.mysterium.network" error="lookup discovery.mysterium.network on 1.1.1.1:53: dial udp 1.1.1.1:53: operation was canceled" Replicated code below on ubuntu docker container through tun2socksThe above code was successful in receiving the response and there were no errors through proxy or without proxy. However dialer_swarm.go is throwing this error when proxy is used on container. If PORT 53 is by passed, it won't show any UDP DNS errors. There seems to be problem with the mysterium container environment when it works with tun2socks. Thank you |
|
Haven't found any issues yet. Can you provide tcpdump/wireshark info about DNS query with tun2socks? |
|
Please find the attachment for PCAP files |
|
Please find the attachment for only UDP logs. This also has packets where garbage values were received as mentioned above. Thank you |
|
Installed the replicated code in Mysterium container which runs on Alpine. Installed go language and build the replicated network test file and the request was successful with response inside the mysterium container. Thank you |
|
If you would like to replicate this issue, simply run the following commands with socks5 proxy. Default DNS may not work. So please use the following to add DNS severs. Thank you |
|
Analyzing the UDP Packets. The packets on eth0 interface have bad checksum for DNS requests where as on tun0 interface there are no bad checksum.
|
The error message "operation was canceled" is present in wireguard service netstack.go file. Providing insights for further investigation on this issue. Thank you |
|
Adding to my observation further on this. If you look at the pinger.go buffer length for UDP is 64. Thank you |
|
any update on this issue? |
|
@xjasonlyu, Thank you |
|
@engageub Thanks for your information. But to be frank, I’m kinda confused about the needs and issues. Is it possible you can check the relevant code and show me the right/expected behavior? |
|
@xjasonlyu,
It's not impossible to debug but it takes time to figure out where the issue is. I need to understand go language, advanced networking and then your code. I also need to setup your code and test it. All this takes lot of time depending on the complexity of the code. The following tests need to be performed on the code. If you are already aware of the following please let me know.
Thank you |
|
Thanks for your summary! It’s kind of strange that I never have UDP receiving issues because I frequently use DNS on it. But yes, you can add some test code to debug:
|
|
Hi @xjasonlyu , What I searched for in the code was the number 32 since the data was truncated to that number to see if this was limited somewhere. I saw lot of lines with that number. I do not know the reason of using that number instead of 64. Although this is working with gluetun, it does not have the capability to use plain socks5 proxies. I appreciate if you could look into this to resolve UDP issues with mysterium containers. Thank you |
|
Hi @xjasonlyu, do you have any update or plan about this? I'm having the same issue and a fix would be greatly appreciated. |
|
Hi, from what I understand, I think this issue maybe related to NAT types. There is an old version of tun2socks that uses ConeNAT, and I feel it may work: https://github.com/xjasonlyu/tun2socks/releases/tag/v2.3.2 |
|
I tried this version and it unfortunately seems to not make any difference |
xjasonlyu
added
bug
Verify steps
Version
Docker latest version
What OS are you seeing the problem on?
Linux
Description
A script has been created which uses tun2socks containers to redirect the proxy requests Internet Income.
The DNS requests are bypassed through port 53 of UDP for the applications to work. Most of the applications require only UDP for DNS queries but Mysterium unlike others requires UDP to establish connections and send data for monitoring.
The problem here is that the application uses the same network interfaces are tun2socks container . So the default interface is eth0 and the IP address is assigned from that interface to Mysterium application.
TCP requests work fine. But UDP requests are not being validated correctly by the application.
A Dante socks5 server was created which serves with both UDP and TCP. Running the commands through terminal works fine with UDP but not through mysterium application. It seems to be validating the destination IP address or the protocol itself.
There are no errors or warnings in Tun2socks container for UDP since the requests are successfully going to the remote server.
To understand further ubuntu container was created over tun2socks network. tcpdump and tshark were installed to capture and analyse the packets going through this container.
This command was run and traffic was captured through tun0 and eth0 interfaces.
With proxy UDP eth0 interface
With proxy UDP tun0 interface
Without proxy eth0 interface (bypassed port 53)
Without proxy tun0 interface
No packets were present since the firewall was bypassed in this case.
With respect to the above outputs the DNS queries were successful in Mysterium application only when firewall is bypassed for port 53. So, it seems to be validating the destination IP address or protocol or something else.
If you look at the destination address for eth0 with and without proxy they are different.
The first one which uses proxy to redirect is using the IP address of the socks5 proxy whereas the bypassed port shows 1.1.1.1
Usually if the default network is eth0, the request first goes to this interface before going to the other interfaces outside this.
If a connection has to be done through socks5 proxy with a request it should be like this
Source Address-->Destination Address-->Socks5 Proxy-->Internet
But the eth0 interface which is default interface shows the following
Source Address-->Socks5Proxy
Socks5Proxy-->Source Address
In addition to the above the requests are being shown as UDP instead of DNS for eth0 interface through proxy.
The tun0 interface shows the destination IP address for 1.1.1.1 which is similar to the eth0 without proxy.
Is it possible to change the default interface to tun0 interface since it shows the correct destination similar to eth0 without proxy or is it possible to clone an interface to achieve this.
The requests are being invalidated when using UDP over eth0 interface by the application which the application shows as timeout since it did not receive the packet it was expecting.
CLI or Config
No response
Logs
No response
How to Reproduce
The text was updated successfully, but these errors were encountered: