Iran ISPs use plain DNS to drop TCP connections and block proxies

[arandomgstring]

Forgive me for opening a new topic regarding this issue, however I think it is worth of a topic of its own. At the beginning, findings of @alirezaac in this topic https://github.com/net4people/bbs/issues/153 made no sense to me. But after further investigation I found some very useful information that I like to share. This issue https://github.com/net4people/bbs/issues/154 is related too.

Tl;dr: So in a nutshell ISPs expect their users establish connection with IPs that which was requested through plain DNS, if that doesn't happen; TCP connections are severed by RST packets.

As @free-the-internet correctly puts it

AFAIK, DNS should be used in the beginning of a any communication, so I didn't get it from your post that how DNS is related to TLS handshake. Unless, here you are talking about Encrypted SNI and DoH, right? Here, we can have Blocking in 2 stages. If Domain is blocked, using normal DNS, you can not even open a connection towards the server (TCP SYN).

Indeed, DNS resolution happens at the very beginning of every domain related connection so what causes blockage of TLS Handshake to proxy server, when IP and domain of proxy server is not blocked? Why DOH alleviates this problem; but it cannot solve it completely? And why TLS fingerprint does not help?

1. First of all, note that DNS resolution has nothing to do with IP & domain of proxy server itself. Why?! Because from @alirezaac or my images we can clearly see that TCP connection is already established to proxy server. If it were the case of DNS poisoning or something, we couldn't even establish connection to proxy server itself to begin with. Moreover, we can simply add IP & domain of proxy server in host file (or DNS configuration of client proxy) to resolute proxy's domain locally, and believe it or not, it solves nothing which further proves my point.

2. Secondly, DOH and other types of encrypted DNS resolutions are completely or partly blocked in Iran. I have personally checked Google and Cloudflare DNS DOH servers in YogaDNS and can confirm this on Mokhaberat and Irancell ISPs. Please do share your finding. So DOH in itself is not much of help; unless we somehow get access to it (I will explain more down below).

3. So inevitably, users are forced to use plain DNS on normal circumstances. Either of ISP's DNS resolver, which gives bogon IPs for blocked servers https://github.com/net4people/bbs/issues/154, or plain DNS google & Cloudflare or other configured DNS servers are used. There is a catch with plain DNS requests. ISPs can monitor these plain DNS requests and this is a big problem. According to my investigations (please share your findings regarding this issue), when a user wishes to visit a domain I hypothesis:

ISP matches IP address of requested domain (ISP knows it through plain DNS) with the IP of newly established connections. If they are the same, nothing out of ordinary happens. However, lets assume a scenario where the user requests Youtube.com on their browser through plain DNS. ISP sees that the requested IP is 142.250.185.110 (youtube's ip); however user sends no sync packet to 142.250.185.110 at all, rather it continues to take data from another IP (IP of proxy server). It is a very clear sign of using a proxy; when this happens ISP sends RST packets to user and destroys the connection; user tries to reestablish connection to proxy server but ISP sends RST packets to proxy server and we receive no server hello. Since the network traffic is mixed up, ISP won't block proxy IP at the beginning, because consider this scenario: User download a file from a whitelisted website and at the same time opens a blocked site, the traffic is similar to former case, and if ISP were to block that IP many whitelisted Iranian websites would be affected at the same time. But by utilizing this method they can artificially "pause" a traffic, especially if that traffic comes from other countries. I personally tested this by downloading Ubuntu ISO (which is whitelisted) on client side and opened a blocked site. The downloading process stopped abruptly in the mid way, and no matter how many times I used download manager to continue the download, I saw the error of "the web-server refuses connection". I pinged the link which I was download from, and it was fine. I used a VPN and successfully continued downloading the file. I assume the fact that web-server was refusing to give me more packets is a clear sign of ISP sending RST packet to Ubuntu server and download manager not receiving server hello under hood. Caching all user DNS requests is wasteful and costful on ISP part, so after a certain timeout (maybe a few seconds), when no sync packet is sent by user to the requested IP address of a certain domain, they destroy TCP connections and forget previous DNS requests. Another thing that which probably further proves my point, is the fact 2 years ago, when all VPNs stopped working a VPN called "Your Freedom VPN Client" could work on DNS mode, presumably using private DNS resolver for IPs.

Solution: I might be very wrong about the whole procedure of blockage, after all it's all but guesswork. That said, it's very clear that when DNS requests are encrypted we face not such problems. But again we return to the very first problem, DOH is blocked, at least for well known servers.

1. Client potentially put all correct IP addresses and domains of their favorite websites on host file so that DNS resolution happens locally. The problem is not all applications respect host file and I know no way of forcing apps to use host file. Let me know if there is any. It seems to me that browsers randomly use host file sometime and some times not.

2. Using DOH of not very well known web-servers might be a temporary solution, but they will eventually be blocked.

3. Perhaps running DNSencrypt server on proxy server would be optimal solution. I haven't done this yet, let me know if anyone has done this and what results were.

[Mohammad-ipv6]

Hello,

Interesting! Some intuition behind your description may be true; however, we need to be sure that we are on the same ground.

As far as I’m concerned, what you state is that the main FW(ISP) shall check the flow of information including DNS requests in plain text. If the connection request is established with any proxy instead of the IP stated in DNS response message saved earlier, then the connection will be torn down. Besides the computational cost of this method, what happens if the DNS requests are also tunneled to the proxy? We can normally check it via DNS Leak or 1.1.1.1/help. If the DNS requests are sent over the proxy, then the initial DNS request will not be visible to FW (ISP), and the above-mentioned scenario will not occur (the connection to the proxy will not be noticed!). Do you affirm this case? Valid assumption? With Xray, and V2ray, I can confirm that all DNS requests are sent over the proxy. If yes, why this solution does not work based on what you described above?

Moreover, Would you elaborate more on the below lines? I don’t seem to parse it!

Since the network traffic is mixed up, ISP won't block proxy IP at the beginning, because consider this scenario: User download a file from a whitelisted website and at the same time opens a blocked site, the traffic is similar to former case, and if ISP were to block that IP many whitelisted Iranian websites would be affected at the same time. But by utilizing this method they can artificially "pause" a traffic, especially if that traffic comes from other countries.

[alirezaac]

Thanks someone else saw the weirdness here, it's hard to produce it on someone who is tech savvy enough, the problem with xray part was that i had a lot of people using my servers, and im connected and talking people running servers, but the problem is some(not all) android phones went dark first, so i tought its TLS FP which i expected, some of them were that but not on all net providers, so i randomly suggested them that change some dns stuff, i didn't know that android still has no good dns features, so they picked up weird methods like turning phone on/off and other weird things that looked unrelated, i didn't take that as dns flush but they could connect again for like one week, the others didn't tried for dns could not with same server and network. so i assumed that TLS FP is on the table so me and the some other guys tried to test naiveproxy with our own ways and configs, to face its problems to find best ways to mitigate TLS FP, me and one of them self hosted some dnscrypt server and we were using all along could connect to Naiveproxy, but some other claimed that its fingerprint is blocked in iran, which led to this and you can test it too, you can't connect to it until you fix dns, which in android clients no matter what you its still falling back to plain dns. and this behavior is like one device stuck in it and one is working on same network. so someone told me he could managed forcing his dns through the proxy with the trick of choosing local http of nekoray as dns server and his problem solved but he could not do the same in matsuri due to different design of tun2sock.

in terms of strategy for blocking all solution, this and tls fingerprinting can block both those V cores and those browser stacks mitigations of newer solutions.

[free-the-internet]

@arandomgstring

ISP matches IP address of requested domain (ISP knows it through plain DNS) with the IP of newly established connections. If they are the same, nothing out of ordinary happens. However, lets assume a scenario where the user requests Youtube.com on their browser through plain DNS. ISP sees that the requested IP is 142.250.185.110 (youtube's ip); however user sends no sync packet to 142.250.185.110 at all, rather it continues to take data from another IP (IP of proxy server). It is a very clear sign of using a proxy; when this happens ISP sends RST packets to user and destroys the connection; user tries to reestablish connection to proxy server but ISP sends RST packets to proxy server and we receive no server hello.

Here:

1. You assume that your DNS is sent out of your proxy tunnel and directly to your ISP in Iran? OR
2. You mean that this happens on your setup that uses some kind of domain-fronting?

In this first case it is easy to configure the client to pass the DNS traffic through your proxy. Other than this, why would you change the IP address [for doing TLS] after opening the connection? Could you please tell what is your proxy setup?

Also, I could not understand your example in "Ubuntu download" case.

[free-the-internet]

@arandomgstring So let me also clarify these things:

• Your proxy domain and IP is not blocked at all.
• Your server's SNI is not blacklisted.
• Fingerprint other than chrome doesn't help.
• Only when you use a self-hosted DNSCrypt, you can successfully connect to your proxy. Did I understand your status correctly?

[arandomgstring]

@alirezaac Yes they are blocking normal Chrome TLS fingerprint + doing some dirty things on DNS resolution.

@Mohammad-ipv6

As far as I’m concerned, what you state is that the main FW(ISP) shall check the flow of information including DNS requests in plain text. If the connection request is established with any proxy instead of the IP stated in DNS response message saved earlier, then the connection will be torn down

No, it is stateless (they don't care about flow of information) and honestly, I think it is computationally as heavy as TLS fingerprint blocking, maybe a little more but not much. Note that ISP have no idea whether you have established a connection through a proxy, or directly to a website; they are totally the same on packet level (as long as you use TLS + WS I assume). What they do is a bit different I presume. Let me elaborate a little:

1. ISP actually doesn't care what IPs you are connected to, unless that IP is already blocked and ISP refuse to send packets to it.
2. Every time that a user does a DNS look up, their request is cached in ISP for a few seconds (Actually they DO cache DNS for longer amount of time to make the networking faster, but let's put that aside). And with a simple regex, they can extract all IPs that user recently has asked for in those DNS responses. It is as computationally expensive as looking at TLS fingerprints. Here they look for IPs. They don't look at flow of information or something, just DNS responses.
3. Now they give the user a certain time, so that user establish connection with those IPs. User has to send sync packet to those IPs (or at least some of them) in say 5 seconds or something. If he/she does, everything is fine. If he/she doesn't, ISP will send RST packet to all established TCP connections of the user. It might be a proxy connection, or even a direct connection doesn't matter. Even a healthy connection will die. That's it. I think it is less sophisticated than TLS fingerprinting which needs keeping track of all usual TLS fingerprints without breaking anything. (Actually they broke Chrome by TLS fingerprint blocking but never mind)

We can normally check it via DNS Leak or 1.1.1.1/help

Note that DOH of 1.1.1.1 (cloudflare) is blocked; just its plain text mode works. Same goes for Google DOH. You can simply test this by going to chrome://settings/security?search=dns and setting Use secure DNS 1.1.1.1 in Chrome. 1.1.1.1/help won't open. meaning this DOH is blocked. You can do the same in Firefox and get the same result. Even better, I set 1.1.1.1 on IPV4 settings of my user network and checked Wireshark. All packets sent to 1.1.1.1 were blocked :). It seems that sometimes Cloudflare and Google understand this, and they switch to plain mode automatically, but I haven't seen such a thing personally.

If the DNS requests are sent over the proxy, then the initial DNS request will not be visible to FW (ISP), and the above-mentioned scenario will not occur (the connection to the proxy will not be noticed!). Do you affirm this case? Valid assumption? With Xray, and V2ray, I can confirm that all DNS requests are sent over the proxy. If yes, why this solution does not work based on what you described above?

Correct. There is a catch however. When you use an application, along with an arbitrary V2ray client (for example V2rayN), the application itself will "resolve domain address" before sending its packets to Socks5 proxy (i.e V2ray Client). I have already checked this in Wireshark, you can check it too; it is easy. This is indeed the case for browsers. V2ray Client may resolve domains on proxy server, but note that it only does so if and only if it receive a domain in the first place! (not an ip). If you set socks5 on Firefox to v2rayclient, it will still resolve domains with ISP DNS resolver, DNS look up won't go through the tunnel. Fortunately in Firefox you can simply set "network.proxy.socks_remote_dns" to true and by doing so you will actually resolve domains on proxy server. If you don't they will be resolved on ISP dns resolver, even if you have set V2ray Client to resolve domains remotely. That said, you don't have the luxury of this option on other applications; Firefox has it. What about a game?. I have tried Proxifier with its Name Resolution mode to force resolution of domains remotely. Unfortunately, it does not work, perhaps because we are dealing with a local socks5 proxy which is chained to another proxy on VPS server.

Now comes the fun part. On smartphone devices we are totally busted, because we are essentially proxifing all traffic, except DNS look ups. I don't have a rooted android device so I cant check packets (pcap doesn't work with another vpn), but from what @alirezaac says, it seems to be indeed the case.

Moreover, Would you elaborate more on the below lines? I don’t seem to parse it!

What I am trying to say is, they don't understand if you have established a connection to a proxy, or you are simply downloading a file. If you don't obey their rules, they will block the connection temporarily. If a connection get blocked a few times they assume its a proxy and it will be blocked on a longer period, maybe permanently.

@free-the-internet

Here: You assume that your DNS is sent out of your proxy tunnel and directly to your ISP in Iran? OR You mean that this happens on your setup that uses some kind of domain-fronting? Also, I could not understand your example in "Ubuntu download" case.

Neither (Or maybe the first case if I understood you correctly), really. If you could send DNS request to proxy tunnel, everything would be fine. In practice however, many applications (even browsers) do the DNS lookup themselves outside of proxy tunnel. After DNS resolution they will use proxy tunnel, which is too late. And no domain-fronting doesn't work as far as I am aware. Not only Cloudflare block it (it gives Gateway Forbidden message) but also Iran ISPs have blocked many Cloudflare IPs in the first place. My setup is VLESS + TLS + WS + NGINX with a real website on front. As for Ubuntu case, what I meant is you can download anything from any server outside of Iran, then If you try to access youtube or something (if you manage to get its real IP not just a bogon IP) and not connect to it, your download will stop abruptly. So they can't distinguish between a proxy packets, or simply downloading a file. They just block whatever you have.

Your proxy domain and IP is not blocked at all.
Your server's SNI is not blacklisted.
Fingerprint other than chrome doesn't help.
Only when you use a self-hosted DNSCrypt, you can successfully connect to your proxy.
Did I understand your status correctly?

No and No. My server SNI is my domain, neither are blocked. Yeah it has nothing to do with Fingerprinting. Of course Chrome fingerprint in particular gets blocked on some ISPs (Irancell, sometimes Mokhaberat) but what I have said in this topic has nothing to do with fingerprints. I have used different variation of TLS fingerprints, nothing helps I can successfully connect to proxy server without that setup. It gets disconnected or temporarily gets blocked however. But by activating "network.proxy.socks_remote_dns" on firefox, everything on Firefox has gone smoothly so far. But not other apps.

If anyone has any idea how we can force DNS look ups for all applications through proxy on either of Windows, Linux, Mac, Android, IOS, they will be more than welcome. Maybe there is a V2rayClient that can do that? Tell me about it. Thank you.

[free-the-internet]

@arandomgstring Okay, See this: https://github.com/2dust/v2rayN/issues/2725 and https://github.com/net4people/bbs/issues/143#. Basically you need a TUN or TAP device so that your proxy work like a VPN. There is many tools to do it. If I understood you correctly, your problem is not connecting to your proxy, but possible disruptions or blocking you from reconnecting for certain amount of the time; which means that after some time you can try again and connect. But the problem for @alirezaac is other than this. He just could not even connect to his proxy server as I remember.

[alirezaac]

@arandomgstring Okay, See this: 2dust/v2rayN#2725 and #143. Basically you need a TUN or TAP device so that your proxy work like a VPN. There is many tools to do it. If I understood you correctly, your problem is not connecting to your proxy, but possible disruptions or blocking you from reconnecting for certain amount of the time; which means that after some time you can try again and connect. But the problem for @alirezaac is other than this. He just could not even connect to his proxy server as I remember.

well im having like a 1 or 2 minutes of ssl handshake error until GOOGLE DOH anycast change the ip and relays the dns, which i use the self hosted dns for now to be one step ahead of google blockage in my isp. and that TUN is not handling dns specially in mobile devices. so i mentioned several times that on nekoray someone made such experiments and could connect(still not getting the website because of dns some are opposite getting website not connecting to proxy)when you come to masses experience @arandomgstring 's logic seems working for the censorship side of this story. and the problem is device wise, my pc is always connect, no protocol is down till now, but phones and some other machines goes dark, and when i come to other people and their servers, which their setups are differing but the results and solutions are same, all i saw on that pc i had done was alive DOH, so they change that and they back up too.

[free-the-internet]

I see now that using V2rayN with 8.8.8.8 or 1.1.1.1 in custom DNS options, and Windows 10, after setting the V2rayN to "set system proxy", if I use Microsoft Edge, I can NOT see DNS requests/responses in Wireshark sniffing on ethernet interface. If I clean the proxy, I see them. See this, it is important to do this. (I don't know what I am doing yet!). Please test and tell me.

This memans that the option works fine and DNS traffic originated from Edge goes through V2rayN. I didn't test with Google Chrome or Chromium. Please note that still I have some DNS requests in the first case, I think they are related to Windows stuff because I see somethings related to microsoft. It also could be some other software have their own proxy configurations (like Firefox) which prevents them to sending DNS through v2RayN, unless if you set it manually. I remember Internet Download Manager has its own proxy settings independet from Windows Proxy settings. If this is a problem, you need to find some solutions

Firefox has its own setup to redirect the DNS request to SOCKS.

[alirezaac]

@free-the-internet

well i guess you didn't get the point of @arandomgstring subject. and as i said it's hard to reproduce the problem for us first,and it's harder to get the context of it (took me one week to know what i was looking at)

[free-the-internet]

@free-the-internet

well i guess you didn't get the point of @arandomgstring subject. and as i said it's hard to reproduce the problem for us first,and it's harder to get the context of it (took me one week to know what i was looking at)

Then, it would be nice if you type in Persian and explain again. We are trying to understand the problem, but referring to protocols, at least I can't understand what and where is the problem. Maybe you can make an example. For example:

lo: DnsReq --> ISP      // request to resolve the IP of my proxy
ISP DnsRes --> lo       // IP of my proxy resolved
lo: SYN --> proxy       // opening the connection to my proxy server (e.g. naiveproxy)
proxy: SYN-ACK --> lo
lo: ACK --> proxy
lo: ClientHello --> proxy

and you can comment exactly where is the problem.

[alirezaac]

Tl;dr: So in a nutshell ISPs expect their users establish connection with IPs that which was requested through plain DNS, if that doesn't happen; TCP connections are severed by RST packets.

1. First of all, note that DNS resolution has nothing to do with IP & domain of proxy server itself. Why?! Because from @alirezaac or my images we can clearly see that TCP connection is already established to proxy server. If it were the case of DNS poisoning or something, we couldn't even establish connection to proxy server itself to begin with. Moreover, we can simply add IP & domain of proxy server in host file (or DNS configuration of client proxy) to resolute proxy's domain locally, and believe it or not, it solves nothing which further proves my point.

well this is were people connect to naive proxy even on android phones, working 1 hour or so normally first time, in a sudden dns things begins, see its the same problem we had, some people are just 1 minute(maybe seconds afterward read his writings complete plz(after before client hello its random for me dude)) some are 1 hour, that might be depend on processing power talked in this conversation . but so we got to fix the dns(must be anycast) to get it back. so it is a complete solution for censorship with combination of these two method of profiling, and putting you all to weird ports and older protocols that should not be working, gaining false confidence on them so they can stop usage those processing power.

in the end it's the same scenario, if you feel confident on X V ray stuff they need to become something like naiveproxy to prevent TLS FP. and after that you will face this problem i guess. nothing is for sure its like to know how heuristic antiviruses detecting files.

[arandomgstring]

@alirezaac I tested Nekoray in 4 different ways, ALL of them leaked DNS queries on windows 10 64bit.

1. VPN mode + Routing settings on 1.1.1.1 (cloudflare)
2. VPN mode + Routing Settings on 127.0.0.1:2082 (The proxy socket which all packets are directed to)
3. Proxy mode + Routing settings on 1.1.1.1 (cloudflare)
4. Proxy mode + Routing Settings on 127.0.0.1:2082

I didn't even check packets, I went straight to https://www.dnsleaktest.com/results.html and https://www.expressvpn.com/dns-leak-test both of them showed 2 Iranian DNS resolver. Can you reproduce this? Express VPN website is more accurate. I also experienced that 1-2 min of SSL handshake you already said, that I assume is due to the DNS leaks but who knows. I mean when I use remote DNS option on firefox, I don't experience such delay, so perhaps these two issues (DNS leak & SSL handshake) are not really separated.

@free-the-internet Presumably, modifying packets on TAP/TUN interface should solve the problem. However, Neko on VPN mode does use TUN interface under-hood and still leak DNS queries for some reason! I will check tun2socks thoroughly and tell the results; but they will painfully slow the connection I am pretty sure of it. As for setting 1.1.1.1 and 8.8.8.8 on V2rayN I already did that, and tested it on Firefox & Chrome. It leaks DNS. I have deleted EDGE thoroughly and has blocked its leftover access in registery so I cannot test it. Can you please check those two websites that I mentioned to see if you leak DNS?

lo: DnsReq --> ISP     // request to resolve the IP of my proxy
ISP DnsRes --> lo   // IP of my proxy resolved

lo: DnsReq --> lo  //Or alternatively you can add IP address of proxy and its domain in host file
lo  DnsRes --> lo   // so that domain of proxy resolve locally, something like this.

lo: SYN --> proxy       // opening the connection to my proxy server (e.g. naiveproxy)
proxy: SYN-ACK --> lo
lo: ACK --> proxy
lo: ClientHello --> proxy 
proxy: Server Hello (changing ciphers) ??? --> lo // Here we may or may not receive Server Hello.
If we don't there are two possibilities.

Either SSL connection is temporally blocked to proxy server or maybe TLS fingerprint is blocked.  
Let's assume that changing TLS fingerprint does solve the issue. Now you browse youtube.com on your favorite Browser, say
Edge. Now This happens:

Edge: DnsReq youtube.com --> lo
lo --> ISP
ISP DnsRes --> lo // We might get fake (bogon) IP here, or we might not!
lo DnsRes --> Edge 
EDGE (packets with fake or real youtube IP address) --> lo --> proxy 
Proxy  --> ??? 
//Here we see that proxy doesn't open the website. We check the Wireshark and we will see that
there are many retransmission TCP packets from lo --> Proxy. See my and @alirezaac images here
https://github.com/net4people/bbs/issues/153 (they are the same). You see that at the end of retransmissions packets, 
lo has sent FIN/ACK to proxy server to end the connection. But why? It means that ISP uses MITM attack, it sends
FIN packet to us (as if proxy sends it, but in reality it's ISP messing with us) to abort the connection. But After FIN/ACK
we might continue our connection with proxy server. But ISP sends RST packet to us  and the webserver as well
to forcefully shut the whole connection down; afterward we have to re-establish TCP connection
from the very beginning (since TCP connection is ended)

lo: SYN --> proxy       // opening the connection to my proxy server (e.g. naiveproxy)
proxy: SYN-ACK --> lo
lo: ACK --> proxy
lo: ClientHello --> proxy 
proxy: Server Hello -- > ?? //But this time we receive NO server hello no matter what!!!

Hopefully everything is clear now. We may never receive Server Hello packet from the sever. It might be the case that
the first situation has already happened and since then, we can't establish SSL connection with proxy server. 
Sometimes it happens in a few seconds, sometimes in minutes, sometimes in hours. Read @alirezaac comments. Now if we 
somehow do this

Edge: DnsReq youtube.com --> lo --> proxy
proxy: DnsRes -- > lo - -> Edge

or

Edge: (packet with youtube domain, not youtube ip address) --> lo -->proxy
proxy --> lo --> Edge

Everything would be alright. 

I tried to explain the situation from plain DNS point of view above. If you add 1.1.1.1 in the middle of DNS requests,
it will solve nothing. Either Edge (or any other application) completely ignore it and this happens:

Edge: DnsReq youtube.com --> lo
lo --> ISP
ISP DnsRes --> lo // We might get fake (bogon) IP here, or we might not!
lo DnsRes --> Edge 

Or maybe it does respect it and this happens:

Edge: DnsReq youtube.com --> lo
lo --> ISP --> 1.1.1.1
1.1.1.1 DnsRes  --> ISP ??? --> lo // We might get NO result since 1.1.1.1 doh is blocked. 
We might get Fake ip or We might get true IP, but even if we get the true IP, ISP knows that IP, since 1.1.1 has sent
the answer in plain DNS mode.
lo DnsRes --> Edge 

And above scenario repeats. Now please explain what's going on. I tried my best to explain the situation,
but my guess might not be true at all. 

Feel free to speak Persian btw, I can understand it but I cannot speak it. However our Chinese brothers won't understand you (Maybe use google translate to write in English and Persian at the same time?)

[free-the-internet]

A NAT rule in windows or linux may work for you? I mean redirection of outgoing packets to lo:53 to proxy:port, just after the proxy is connected. There are some tools. See: linux: https://0day.work/tunneling-all-traffic-over-dns-with-a-socks-proxy/ linux: https://unix.stackexchange.com/questions/200195/does-ssh-d-proxy-dns-request/317603#317603 windows: https://www.privoxy.org/

Foe Edge browser: https://learn.microsoft.com/en-us/deployedge/edge-learnmore-cmdline-options-proxy-settings

By providing a single uri with optional port to use for all URLs. For example, --proxy-server="proxy2:8080" will use the proxy at "proxy2:8080" for all traffic.

[Mohammad-ipv6]

@arandomgstring

If anyone has any idea how we can force DNS look ups for all applications through proxy on either of Windows, Linux, Mac, Android, IOS, they will be more than welcome. Maybe there is a V2rayClient that can do that? Tell me about it. Thank you.

One small question: Do you think that some V2ray Clients on Android, and iOS may not tunnel all DNS to the remote server? For instance, I checked the DNS query check (with ExpressVPN you mentioned) in V2rayNG (the latest Android installed) and the setting of V2rayNG configured to be working on VPN mode and 8.8.8.8 VPN DNS, all the android browser (Chrome) DNS query has been sent to my remote server.

Have you ever checked the other apps' behavior with V2rayNG or any other V2ray client? I reckon that maybe one simple solution, other than capturing the android packets via root access, is to enable an interface with promiscuous mode (e.g., in Kali Linux) and connect all devices to your same WIFI to see all the packets in the network and trace them.

I have Shadowrocket/Oneclick app on iOS and can also check them.

[free-the-internet]

A NAT rule in windows or linux may work for you? I mean redirection of outgoing packets to lo:53 to proxy:port, just after the proxy is connected. There are some tools. See: linux: https://0day.work/tunneling-all-traffic-over-dns-with-a-socks-proxy/ linux: https://unix.stackexchange.com/questions/200195/does-ssh-d-proxy-dns-request/317603#317603 windows: https://www.privoxy.org/

See this for windows: https://yogadns.com/docs/interfaces/ This software can resolve the problem for windows. But the problem for the public who don't know what is wrong and don't have enough knowledge remains with DNS leak. Perhaps a very fast way to prevent disruption of proxy connection is simply telling people to use only Firefox and set DNS settings in proxy settings correctly.

Checking Android and V2rayNG is also a must. Please if you have time, test it. I would like to re-write the problem and explain as simple as possible to developers so that they take this serious.

[free-the-internet]

I think the guys writing the proxy2tun/tap tools, need to use WPF (windows packet filter). see this: https://github.com/ValdikSS/openvpn-fix-dns-leak-plugin/blob/master/testfw/testfw/PacketFilter.cpp one that is a plugin for OpenVPN.

[alirezaac]

Perhaps a very fast way to prevent disruption of proxy connection is simply telling people to use only Firefox and set DNS settings in proxy settings correctly.

yogadns can't, but simplednscrypt can, cause it needs it as a service for interface yoga is just like two Parallel proxifier. but the problem is they are blocking secure dns, and yogadns is not a good tool to check it, some anycast types are working now but its temp, and you are correct i'm not solving my problem here i did it before, average users and phone clients are in trouble for this, They can not run a dns server. the more your connection behave like a real browser the more you are affected .

[free-the-internet]

yogadns can't, but simplednscrypt can, cause it needs it as a service for interface yoga is just like two Parallel proxifier. but the problem is they are blocking secure dns, and yogadns is not a good tool to check it, some anycast types are working now but its temp, and you are correct i'm not solving my problem here i did it before, average users and phone clients are in trouble for this, They can not run a dns server. the more your connection behave like a real browser the more you are affected .

If you use YogaDNS to create rules for your interfaces, and not using it as a DNS server; it should work? Am I correct?

I see the problem. Obviously this is a DNS leak problem and it is very stupid indeed to use such a method to censor! It's a massive attack against users traffic and brutal! Eventually, the complexity of this method can be very high. Detection of a user proxy usage, adding dynamic rules to kill whole user traffic, sending custom packet, preventing the user to do handshake again, etc.

[free-the-internet]

@arandomgstring

If anyone has any idea how we can force DNS look ups for all applications through proxy on either of Windows, Linux, Mac, Android, IOS, they will be more than welcome. Maybe there is a V2rayClient that can do that? Tell me about it. Thank you.

One small question: Do you think that some V2ray Clients on Android, and iOS may not tunnel all DNS to the remote server? For instance, I checked the DNS query check (with ExpressVPN you mentioned) in V2rayNG (the latest Android installed) and the setting of V2rayNG configured to be working on VPN mode and 8.8.8.8 VPN DNS, all the android browser (Chrome) DNS query has been sent to my remote server.

Have you ever checked the other apps' behavior with V2rayNG or any other V2ray client? I reckon that maybe one simple solution, other than capturing the android packets via root access, is to enable an interface with promiscuous mode (e.g., in Kali Linux) and connect all devices to your same WIFI to see all the packets in the network and trace them.

I have Shadowrocket/Oneclick app on iOS and can also check them.

FYI, I tested v2rayNG and latest Orbot in VPN mode, and I see my DNS servers changed from my ISP to my server. I tested with dnsleaktest website. So probably in recent versions of Android (10+), we don't have this problem. Could you confirm please? If you have older phones with android 5+, please test.

The problem remains in Windows, Linux. Iphone not tested yet. Linux is easy to manage. But Windows is a problem.

[Mohammad-ipv6]

@arandomgstring

If anyone has any idea how we can force DNS look ups for all applications through proxy on either of Windows, Linux, Mac, Android, IOS, they will be more than welcome. Maybe there is a V2rayClient that can do that? Tell me about it. Thank you.

One small question: Do you think that some V2ray Clients on Android, and iOS may not tunnel all DNS to the remote server? For instance, I checked the DNS query check (with ExpressVPN you mentioned) in V2rayNG (the latest Android installed) and the setting of V2rayNG configured to be working on VPN mode and 8.8.8.8 VPN DNS, all the android browser (Chrome) DNS query has been sent to my remote server. Have you ever checked the other apps' behavior with V2rayNG or any other V2ray client? I reckon that maybe one simple solution, other than capturing the android packets via root access, is to enable an interface with promiscuous mode (e.g., in Kali Linux) and connect all devices to your same WIFI to see all the packets in the network and trace them. I have Shadowrocket/Oneclick app on iOS and can also check them.

FYI, I tested v2rayNG and latest Orbot in VPN mode, and I see my DNS servers changed from my ISP to my server. I tested with dnsleaktest website. So probably in recent versions of Android (10+), we don't have this problem. Could you confirm please? If you have older phones with android 5+, please test.

The problem remains in Windows, Linux. Iphone not tested yet. Linux is easy to manage. But Windows is a problem.

FYI,

I can confirm for latest Android stated in my previous comment.

For the case of iOS (Ipad iOS), I can confirm that "Oneclick" uses google plain-text DNS, and "ShadowRocket" tunneled the DNS query to the proxy server and use its DNS.

[poorp]

In my recent experience, vmess's DNS problem is totally fixed somehow or another in recent versions of Xray-core (check v1.6.1). For desktop use nekoray with default settings and mobile is fine with whatever client. They seem to be lifting some restrictions as well for some reason and that could be related too.

[reethikar]

I tested Nekoray in 4 different ways, ALL of them leaked DNS queries on windows 10 64bit.

Hello everybody, I wanted to introduce our VPNalyzer tool to help you test for DNS leaks and in general understand if the VPN has issues. We test for aspects of service like bandwidth overhead when using a VPN, security and privacy essentials like checking what DNS resolvers are used (and more). Importantly, we also test for misconfigurations and leakages such as IPv6 leaks and data leaks during tunnel failure (i.e., when the tunnel fails, either due to bad connection or an intentionally induced tunnel failure, does the data leak to the user's network/ISP?). Our application is cross-platform and you can download it for Windows, MacOS, and Linux. All installation instructions can be found on our webpage.

We conduct our tests by asking the user to test both via the VPN and your regular ISP connection. So, a word of warning: anyone monitoring your internet activity (e.g., ISP, government, employer, VPN provider) will be able to see that you are running the VPNalyzer application.

NB: In the final step, if the data upload fails because our storage bucket and analysis is done on GCP, please TURN ON your VPN and try again.

We present you some results on the application itself and more results can be found on our website a few minutes after the results are uploaded using the unique link we present to you. Read more about our work and the research paper on this topic.

[free-the-internet]

@arandomgstring Okay, See this: 2dust/v2rayN#2725 and #143. Basically you need a TUN or TAP device so that your proxy work like a VPN. There is many tools to do it. If I understood you correctly, your problem is not connecting to your proxy, but possible disruptions or blocking you from reconnecting for certain amount of the time; which means that after some time you can try again and connect. But the problem for @alirezaac is other than this. He just could not even connect to his proxy server as I remember.

well im having like a 1 or 2 minutes of ssl handshake error until GOOGLE DOH anycast change the ip and relays the dns, which i use the self hosted dns for now to be one step ahead of google blockage in my isp. and that TUN is not handling dns specially in mobile devices. so i mentioned several times that on nekoray someone made such experiments and could connect(still not getting the website because of dns some are opposite getting website not connecting to proxy)when you come to masses experience @arandomgstring 's logic seems working for the censorship side of this story. and the problem is device wise, my pc is always connect, no protocol is down till now, but phones and some other machines goes dark, and when i come to other people and their servers, which their setups are differing but the results and solutions are same, all i saw on that pc i had done was alive DOH, so they change that and they back up too.

@alirezaac According to this https://github.com/MatsuriDayo/nekoray/issues/151, if you enable Strict Route in VPN Settings of Nekoray, using the VPN mode will mitigate the problem of DNS leak. I used a setup consisting of a VM running Windows 10, and I sniffed Nekoray's TUN, guest Ethernet and host Ethernet. I can confirm that DNS Leak only mitigated when you enable Strict Route.

[alirezaac]

@arandomgstring well i've tested the dns leak, it may raise some other confusions too but i know that the problem is deeper than we think. i need to remove my secure dns setup too, to make sure of the problem. but for now its good that we are aware of problem.

@free-the-internet thanks for the solution but any solution for android users? cause windows is not that bad for now to fix problems. android is worst in terms of dns now.

@poorp well thanks for sharing stats on the restrictions, from the some twitter users stats i'm getting now, the interruptions are coming back, idk maybe that arvan stuff was real and now they are coming back at it again. the xray is fine for now, but we need to agree on that they have contested the interruptions and for some of those weeks it was success for them.

[free-the-internet]

@free-the-internet thanks for the solution but any solution for android users? cause windows is not that bad for now to fix problems. android is worst in terms of dns now.

As I said, android 10+ is completely safe with v2RayNG. Do you have any tests for android users? Since we have to have enough evidence, we need tests for Android 5+.

[arandomgstring]

@free-the-internet Thank you for your active participation. I tested nekoray-2.4-2022-11-15-windows64 on VPN mode with Strict Route enabled. This was the result:

While it was unnecessary to hide IPs of Google's DNS servers I did it anyway. As you can see, even in that mode it leaks DNS. Needless to say, I tested in on Mokhaberat ISP on https://www.dnsleaktest.com/ with extended test.

A NAT rule in windows or linux may work for you? I mean redirection of outgoing packets to lo:53 to proxy:port, just after the proxy is connected.

Windows does not support IPTable rules as far as I am aware; only Linux does. So no easy NAT for Windows (yeah I hate Windows because of it) unless someone modify packets directly with WFP or windivert; and it is extremely hard; if someone goes to that point he might as well write a whole VPN from scratch; note that we are talking about a very low programming on C language. I tried to use Privoxy but I didn't understand much of its configuration; however I think it is not much different from YogaDNS. As for Linux, I presume TProxy (in newer versions of Linux kernel) and RedSocks do the trick; but almost all of our clients use Windows anyway.

Using SSH tunnel for DNS traffic is actually a good idea, but not with our setup (anything related to v2ray, xray, etc core). Iran ISPs don't like SSH traffic coming from foreign servers for normal users. Even a healthy normal ssh access for running commands on port 22 to foreign servers is blocked on Mokhaberat! So one has to chain 2 ssh servers, one VPS from Iran and one from another country, and tunnel traffic like user -> Iranian VPS - > Non Iranian VPS to make it work. Actually; it is the ultimate solution for everything, and at that point we might as well tunnel the whole traffic with -D command of SSH (we won't need V2ray or any third party application for network packets, SSH will act as a SOCKS5 proxy itself). Iran ISPs can counter this by limiting the amount of SSH traffic for every user or limit its bandwidth; but by doing so they will ruin other things. For example, a user who wishes to backup their file on his personal VPS server, can not do that any longer. Or many web-application developers will struggle. That said, do you think they ultimately care? Haven't they already destroyed many people's life by censoring Instagram, Telegram, etc? So normally I don't suggest people to use SSH traffic for this particular purpose, nevertheless it is a good option.

On Android 8+ I can confirm that at very least Browsers don't leak DNS on V2rayNG. I cannot say for other applications for sure since I cannot see their packets. However, I am fairly familiar with Kotlin/Java programming of Android Devices, and It is very easy to modify packets on fly using official google libraries; so I don't worry much about Android Devices leaking DNS.

That said, not leaking any DNS is actually a problem in itself and can be easily taken advantage of! You see, from ISPs' point of view, a normal user traffic consist of DNS requests, Https traffic, FTP, etc. Wouldn't it be too suspicious if a user doesn't request any DNS resolution at a certain period of time at all? To make matters even worse, android, macos, iphone and windows are all "noisy", meaning they randomly send data to their providers (e.g Windows sends tons of user's information to Microsoft and even registry and other tricks cannot disable it completely. All installed third party application potentially do DNS lookup sometimes) If you don't believe me, just open WireShark and close all applications on background. You still see random DNS lookup, some of them coming from Windows core itself directly, I presume. Same goes for Google collecting data from android devices, Apple from IPhone. Linux itself is silent (and of-course it should be) but still since normal users tend to install applications on it, those application send DNS requests sometimes. Especially if we install Windows app on linux using Wine or something. They can be silenced ofcourse (with a simple host file) but what I am trying to say is either a user should be inactive completely (no traffic of any kind should be sent to ISP) or their traffic has to be mixture of Https, DNS, and other protocols to look normal.

If I were in charge of censorship, perhaps the very first rule of mine would be looking at the volume of traffic used by a user on each protocol. If a user has moderate to heavy traffic, on https but not on other protocols, and if their https traffic comes from a single IP, that would be the most clear sign of using VPN. First I block that IP temporarily and then permanently depending on the number of times something like this happen for that particular IP. I'd then laugh my ass off, since I have free access to internet but I am ruining other people life; what a real joy indeed!

Hopefully I got my point across. Actually I think they have done something like this already, since my partners have told me that their naiveproxy or v2ray proxy servers are getting blocked after a few days when they are accessed by smartphones. Perhaps, because V2rayNG redirects all DNS lookups, even the ones that comes from android core itself, its traffic becomes "special", not in a good way of-course.

@alirezaac Yes, I confirm this. Yesterday was a relatively good day and some restrictions was lifted. Today however, almost all of those restrictions has come back.

[alirezaac]

@alirezaac I tested Nekoray in 4 different ways, ALL of them leaked DNS queries on windows 10 64bit.

1. VPN mode + Routing settings on 1.1.1.1 (cloudflare)
2. VPN mode + Routing Settings on 127.0.0.1:2082 (The proxy socket which all packets are directed to)
3. Proxy mode + Routing settings on 1.1.1.1 (cloudflare)
4. Proxy mode + Routing Settings on 127.0.0.1:2082

I didn't even check packets, I went straight to https://www.dnsleaktest.com/results.html and https://www.expressvpn.com/dns-leak-test both of them showed 2 Iranian DNS resolver. Can you reproduce this? Express VPN website is more accurate. I also experienced that 1-2 min of SSL handshake you already said, that I assume is due to the DNS leaks but who knows. I mean when I use remote DNS option on firefox, I don't experience such delay, so perhaps these two issues (DNS leak & SSL handshake) are not really separated.

well i just tested and no dns leaks, cause im ok for now, but that 1-2 min SSL HS is still happening, just same time with that retransmissions you mentioned, and there are some dns domain in packets resolved as 10.10.34.35 and going through proxy server(weird AF and that's gonna be monitored in that retransmissions too 👍 ) which i was seeing since xray in v2rayn month ago and now seeing it in naiveproxy in nekoray too. i will look in to this another weird behavior but the problem still is not the leakage i'm saying, its that MITM and the tcp drops(RST) we should look forward to it after the solving leaking dns.

[free-the-internet]

@free-the-internet Thank you for your active participation. I tested nekoray-2.4-2022-11-15-windows64 on VPN mode with Strict Route enabled. This was the result:

While it was unnecessary to hide IPs of Google's DNS servers I did it anyway. As you can see, even in that mode it leaks DNS. Needless to say, I tested in on Mokhaberat ISP on https://www.dnsleaktest.com/ with extended test.

A NAT rule in windows or linux may work for you? I mean redirection of outgoing packets to lo:53 to proxy:port, just after the proxy is connected.

Windows does not support IPTable rules as far as I am aware; only Linux does. So no easy NAT for Windows (yeah I hate Windows because of it) unless someone modify packets directly with WFP or windivert; and it is extremely hard; if someone goes to that point he might as well write a whole VPN from scratch; note that we are talking about a very low programming on C language. I tried to use Privoxy but I didn't understand much of its configuration; however I think it is not much different from YogaDNS. As for Linux, I presume TProxy (in newer versions of Linux kernel) and RedSocks do the trick; but almost all of our clients use Windows anyway.

Using SSH tunnel for DNS traffic is actually a good idea, but not with our setup (anything related to v2ray, xray, etc core). Iran ISPs don't like SSH traffic coming from foreign servers for normal users. Even a healthy normal ssh access for running commands on port 22 to foreign servers is blocked on Mokhaberat! So one has to chain 2 ssh servers, one VPS from Iran and one from another country, and tunnel traffic like user -> Iranian VPS - > Non Iranian VPS to make it work. Actually; it is the ultimate solution for everything, and at that point we might as well tunnel the whole traffic with -D command of SSH (we won't need V2ray or any third party application for network packets, SSH will act as a SOCKS5 proxy itself). Iran ISPs can counter this by limiting the amount of SSH traffic for every user or limit its bandwidth; but by doing so they will ruin other things. For example, a user who wishes to backup their file on his personal VPS server, can not do that any longer. Or many web-application developers will struggle. That said, do you think they ultimately care? Haven't they already destroyed many people's life by censoring Instagram, Telegram, etc? So normally I don't suggest people to use SSH traffic for this particular purpose, nevertheless it is a good option.

On Android 8+ I can confirm that at very least Browsers don't leak DNS on V2rayNG. I cannot say for other applications for sure since I cannot see their packets. However, I am fairly familiar with Kotlin/Java programming of Android Devices, and It is very easy to modify packets on fly using official google libraries; so I don't worry much about Android Devices leaking DNS.

That said, not leaking any DNS is actually a problem in itself and can be easily taken advantage of! You see, from ISPs' point of view, a normal user traffic consist of DNS requests, Https traffic, FTP, etc. Wouldn't it be too suspicious if a user doesn't request any DNS resolution at a certain period of time at all? To make matters even worse, android, macos, iphone and windows are all "noisy", meaning they randomly send data to their providers (e.g Windows sends tons of user's information to Microsoft and even registry and other tricks cannot disable it completely. All installed third party application potentially do DNS lookup sometimes) If you don't believe me, just open WireShark and close all applications on background. You still see random DNS lookup, some of them coming from Windows core itself directly, I presume. Same goes for Google collecting data from android devices, Apple from IPhone. Linux itself is silent (and of-course it should be) but still since normal users tend to install applications on it, those application send DNS requests sometimes. Especially if we install Windows app on linux using Wine or something. They can be silenced ofcourse (with a simple host file) but what I am trying to say is either a user should be inactive completely (no traffic of any kind should be sent to ISP) or their traffic has to be mixture of Https, DNS, and other protocols to look normal.

If I were in charge of censorship, perhaps the very first rule of mine would be looking at the volume of traffic used by a user on each protocol. If a user has moderate to heavy traffic, on https but not on other protocols, and if their https traffic comes from a single IP, that would be the most clear sign of using VPN. First I block that IP temporarily and then permanently depending on the number of times something like this happen for that particular IP. I'd then laugh my ass off, since I have free access to internet but I am ruining other people life; what a real joy indeed!

Hopefully I got my point across. Actually I think they have done something like this already, since my partners have told me that their naiveproxy or v2ray proxy servers are getting blocked after a few days when they are accessed by smartphones. Perhaps, because V2rayNG redirects all DNS lookups, even the ones that comes from android core itself, its traffic becomes "special", not in a good way of-course.

@alirezaac Yes, I confirm this. Yesterday was a relatively good day and some restrictions was lifted. Today however, almost all of those restrictions has come back.

This is really strange. I've tested heavily, multiple times with Wireshark and online services like https://ipleak.net, I hadn't any leaks. In nekoray you should consider the following:

1. Once you closed (exited) from it, you need to go again and check for Restrict Route option.
2. After checking Restrict Route, you need to diisconnect from VPN mode and connect to it again. (un-check the box near VPN mode, and check again)
3. Make sure there is no errors in the logs.

[free-the-internet]

If I were in charge of censorship, perhaps the very first rule of mine would be looking at the volume of traffic used by a user on each protocol. If a user has moderate to heavy traffic, on https but not on other protocols, and if their https traffic comes from a single IP, that would be the most clear sign of using VPN. First I block that IP temporarily and then permanently depending on the number of times something like this happen for that particular IP. I'd then laugh my ass off, since I have free access to internet but I am ruining other people life; what a real joy indeed!

This is what is happening now in Turkmenistan. Nobody is allowed to use more than 3GB(?)! They arrest people who use VPN. But the Volume model is a very trivial model that you, as a VPN user, can imagine. It is just too simple to decide if a user is using VPN or not. Otherwise China, Russia, and Iran's regime should have been developed such model before than you think.

[arandomgstring]

@alirezaac

and there are some dns domain in packets resolved as 10.10.34.35 and going through proxy server(weird AF and that's gonna be monitored in that retransmissions too 👍 )

Well I think retransmissions in this scenario happens because when your proxy server sends your TCP packets to nowhere (10.10.34.35) it receives no packets, but it has to somehow answer you back but it doesn't because it can't; so you send psh packet (retransimation) to proxy server to tell it "hurry up! give me data". But it simply can't. In that case, you may lose your TCP connection. As for why you are getting bogon IPs, I can say that maybe you are subject to DNS leakage after all. Don't trust those websites, because they can only check your Browser client, not your whole system. Or Maybe you have been subject to DNS poisoning, some domains are cached to false IPs. In that case, simply flushing DNS cache should solve the problem. And finally, maybe you are using an adblocker or something that prevents some ads to open up. These type of plugins interfere with DNS resolution. Nevertheless, if you see a particular real domain is resolved to a bogon IP you can simply write it in DNS settings of v2ray client or host file of your system so that it resolves correctly.

Also I believe Iran ISPs has limited the number of simultaneous TCP connections you have with an IP. So they send RST packet to you, everytime that you try to go beyond that limit. So turn on MUX option to see if it solves the problem. Actually change its number to 1 (which is pathological but anyway) to check if it is the origin of problem.

@free-the-internet

I hadn't any leaks. In nekoray you should consider the following

Actually when you said that option prevents DNS leaking, I unziped nekoray and followed your instruction. I didn't exit the application even once. Perhaps our browsers are different that's why? or there is some application on my side that does this? Or maybe Mokhaberat ISP in this region is like this?

Otherwise China, Russia, and Iran's regime should have been developed such model before than you think.

Let me put my two cents in. First of all how do you know they don't do this? I mean for all we know,

1. The simplest models are less error prone. Everyone who has done a little bit of programing knows this. The more complex your model becomes, the more intact and healthy stuff you break. When we are talking about government level, breaking even the tiniest thing is very unforgivable. Because the scale of it is unknown.
2. The cost of maintaining very complex models, is not worth it. I mean sure, they can use AI to map users traffic to trained models to find VPNs in the most efficient way. But do you think they do something like this?! I believe not. It is not cost efficient.
3. Complex models introduce latency. In networking latency means a lot. They can do lots of inspections and other stuff. But if they actually do this, the networking becomes painfully slow. So they had to stick with relatively simple models. Especially in a country such as Iran where technology has yet to become mature; they had to speed things up
4. As you can see, in ALL of v2ray clients there is an option to direct China's (or the country of our choice) traffic without using tunnel. Why do you think that is? Sure maybe some Chinese websites are only opened by Chinese IP. But from what I have read in their topics, they have actually added this option to simply prevent my model of censorship from happening. I mean even here https://github.com/net4people/bbs/issues/148 you see such explanations.
5. Using pre-existing data is very efficient. We know that they monitor the volume of traffic, that's how they make money! So why not using this simple model as a cherry on top?
6. Finally I didn't mean that in actuality they do this. I don't know, no ones except them knows. What I said above is just a "toy model". Something to think about, but not taken literally. If we can't dodge these simple models, how are we supposed to deal with more complex censorships?

[free-the-internet]

1. The simplest models are less error prone. Everyone who has done a little bit of programing knows this. The more complex your model becomes, the more intact and healthy stuff you break. When we are talking about government level, breaking even the tiniest thing is very unforgivable. Because the scale of it is unknown.

How do you want to decide if I am downloading a huge software from a foreign server, or I have my storage for my cameras abroad, or I am watching a video on a non-blocked foreign server, or as a company I deliver my video calling service with combination of external and internal servers? (Of course this is possible after that there is just so called Intranet, and all the services are available inside the country). Furthermore, ISPs are just counting the size based on your IP. Hopefully, currently, they do not profile your IP and usage in detail which could be a correlation table of IPs your are visiting. I know that they do what they want, because simply people are not important for them! But also consider the complexity that it would bring to every ISP and to the nodes which is responsible for making a table for every single user.

Anyway, Thanks for the information. I don't have any other comments on the censors decision part.

Actually when you said that option prevents DNS leaking, I unziped nekoray and followed your instruction. I didn't exit the application even once. Perhaps our browsers are different that's why? or there is some application on my side that does this? Or maybe Mokhaberat ISP in this region is like this?

It can't be the ISP. I tested with Edge. You do it with Chrome?

[alirezaac]

as i'm gathering more information from public, the more complains about dns poppin up, some indicated as dns_probe_started on their browsers. so for non blocked websites and services they have to change DNS to fix their connection.

[mehdifirefox]

دوستان ساده توضیح میدید داستان چیه نشت dns مشکلی بوجود اورده ؟ مرورگر های کرومیوم که dns رو میزنه گوگل . فایرفاکس هم dns خاموش باشه میزنه ایران و مشکلی نبوده , کلوفلر هم فعال میکنی بازم باز میشه و مشکلی نیست

یک مشکلی که از اول بعضا داشتن اینستاگرام وب برای بعضیا باز نمیشد

---

Simple friends explain what the story is DNS leakage caused a problem? Chromium browsers that hit DNS Google. Firefox is also a DNS off Iran and there is no problem, you activate the clofler again and no problem.

A problem that somebody has some web Instagram from the beginning is not open to some

[poorp]

دوستان ساده توضیح میدید داستان چیه نشت dns مشکلی بوجود اورده ؟ مرورگر های کرومیوم که dns رو میزنه گوگل . فایرفاکس هم dns خاموش باشه میزنه ایران و مشکلی نبوده , کلوفلر هم فعال میکنی بازم باز میشه و مشکلی نیست

یک مشکلی که از اول بعضا داشتن اینستاگرام وب برای بعضیا باز نمیشد

سلام، برای من هیچ مشکلی نیست با آخرین ورژن xray-core و از vmess استفاده می‌کنم کاملا اوکی و نشت dns نداره

Hi, there is no problem for me with the latest Xray-Core version and I use VMess completely Okay and DNS leak

[mehdifirefox]

نشت رو که خیلیا دارن منم فایرفاکس رو دارم ولی من مشکلی ندارم ولی بعضا فک کنم مشکل دارن

The leaks that are very much I have Firefox too But I have no problem, but sometimes I think they have trouble

[poorp]

@mehdifirefox با vmess نشت دارید؟

Do you have a leak with VMess?

[mehdifirefox]

اره ، فقط با فایرفاکس ، تروجان هم تست کردم داشتم کلا طبیعیه ، حتی بعضی vpn ها هم نشت رو دارن

Yeah, only with Firefox, I also tested Trojan It is generally natural, even some VPNs have leaks

[poorp]

@mehdifirefox من با هیچ کدوم ستاپا مشکل dns ندارم هم فایرفاکس تست میکنم هم کروم نمیدونم چرا نشت میکنه برا شما؟ مطمئنید آپدیته سرورتون نسخه آخر xray-core؟

I have no DNS problem with any of the sisters I have a Firefox and Chrome I don't know why it leaks for you? Are you sure the server update the last version of Xray-Core?

[mehdifirefox]

نسخه اخر که هیچ ، حتی نسخه پیش نمایش دیدم ویژگی های امنیتی خوبی اضافه کرده منتظر اپدیت نموندم اونا رو دانلود کردم جایگزین کردم حتی من دارم از تروجان استفاده میکنم دیگه من‌از تهشم رفتم اونورتر

The last version that I even saw the preview version has added good security features Waiting for the update I didn't download them. I replaced Even i'm using Trojan I went out of my hand.

[poorp]

@mehdifirefox vmess+ws ipleak.net dnsleak.com dnsleaktest.com extended test client: nekoray ubuntu vpn settings strict route no leak at all working perfectly fine.

[mehdifirefox]

فک کنم فهمیدم مشکل از کجاست شما از این سایتا تست نگیر اینو امتهان کن دقیقتره https://www.expressvpn.com/dns-leak-test

I think I found out where the problem is You don't test this site This is the precise https://www.expressvpn.com/dns-leak-test

[poorp]

@mehdifirefox هیچ لیکی نشون نمیده، یعنی نشون میده ولی کشورش مربوط به سرورمه کشور ایران نشون نمیده.

It does not show any leak, that is, it shows, but its country does not show Iran.

[alirezaac]

عشقای داداش، یه مسئله ای تو بررسیاتون دقت کنید، اینجا اینطور فرض کنید که ما میخوایم ببینیم چه استراتژیی دارن برای سانسور، نه اینکه برای من کار کرده برای بقیه ام باید بکنه، به طور مثال همینطور فک میکردم منم، فکر میکردم بقیه سر در نمیارن، تا اینکه رفتم یه گوشی اندروید گرفتم ببینم چه خبره، الان مثلا: 1-پی سی کانکتم و اوکیه، وبسایت فیک، چمیدونم ریورس naive راحت باز میشه رو هر مرورگری. پس دو حالت داره کار میکنه.

2-اون اندروید رو اعصاب، نه کانکت میشه مثلا(اوکی vless همه کانکت میشه اوکیه این قضیه) نه فیک وبسایت و اون بساط با مرورگر باز میشه(صد در صد یا ارور DNS PROBE میاد) نه کانکت میشه به naive خب تابلوئه naive درست وقتی که داره کم کم میاد بالا اسمش تو ایران این داستان استارت میخوره جلوش گرفته بشه . اما این اتفاق کی میوفته، یک ساعت اینطوریا استفاده کردن از naive روی گوشی.

حالا اتفاقی که الان میگین مثلا آیپی بلاک شده، sni بسته شده، فلان شده، میدونم خودم اینارو تست کردم قبلش که اومدم اینجا بازم با احتیاط گفتم. چیزی که شنیدم رو تونستیم پس دوباره خطارو تکرار کنیم. اما خب از کجا میفهمیم یه جای کار میلنگه، جفت پیسی و گوشی با یک نت یکسان تست میشه، چه تفاوتی ایجاد میشه که یک دامنه روی گوشی بلاک باشه، روی پی سی نه، از عمد نکوری و ماتسوری انتخاب کردم، که یه دولوپر یقه بشه، اما بحث مرورگر، که باید وبسایت حداقل درست کار میکرد. که ما همون مراحل که تو کپچر وایرشارک دیدین داریم، یعنی مرورگر هم چندبار ناموفق میشه ارتباطش تا اینکه باز dns زور میزنه با anycast مدام آیپی رو عوض میکنه. پس بحث من به این خاطر کلاینت و نشتی و این داستانا نیست. رفتار عجیبه تا اینکه dns درست میشه. حالا بدبختیی که داریم اینه که اندروید در حال تستم که چرا این بساط dns شه، بعد مثلا یه هفته این طوریا ول میکنه و کانکت میشن، اما هر دیوایس یه رفتاره، میگین نه، کانفیگ هاتونو شیر کنید ، ازشون دقیق آمار بخواین چی شده، اگر بحث tlsfinger باشه که کلا اون ورژن باید بره تو تاریکی. نه مثل چیزی که الان دارم میبینم، دوتا دیواس مختلفی با یه نتورک دوتا رفتار متفاوت دارن. حتی میشنوم سوییچ هم میشن یه روز مثلا یه نفر میگه اون سرورت کانکت شد، همزمان یکی دیگه میره تو قطعی. شک اصلیم به اینه که کچ های dns مشکل داره، چون میدونم چه ساگر چه ماتسوری مثلا از کچ استفاده میکنن مدام. در کل خودم استفاده نمیکنم از هیچ گوشیی بیشتر به خاطر بقیه دارم تست میکنم، اگر نکته ای دیدن، راهی دارین برای یه مقدار تغییر راحت تر dns یا اگه میتونید issue باز کنید تو رپو کلاینتها برای dns، چیزیه که بلاخره باید فیکس و درست باشه حالا اصلا کمکی کنه به وضعیت یا نه. به نظرم بهتره انگلیسی تایپ کنید، چون دولوپر میاد بخونه مشکلو شما جای اون باشید میشینید ترجمه گوگل رو بخونید باهاش مشکلی حل کنید؟.

---

Brother's love, take a look at your review, here's suppose we want to see what strategy they have for censorship, not to work for me for the rest, for example I thought I was, I thought the rest of the head at the door. They can't, until I went to get an Android phone to see what's going on, for example:

1. PC Connectors and Okia, Fake's website, Naive River's Chamidon River will open easily. So two modes are working.
2. Android is nervous, not a connection, for example (Oki vless all the connection, Okia, not a website, and it opens with the browser (100% or DNS PROBE error). When he is slowly coming up, his name in Iran is starting to get a starting story. But when this happens, it is an hour to use naive on the phone.

Now what you are saying now, for example, the IPBlock is blocked, the SNI is closed, so, I know I tested it before I came here with caution. We could hear what I heard then repeat the error again. But how do we find out that a place of work, a pair of Pace and the phone is tested with the same note, what is the difference to be a domain on the block phone, on the PC, I chose intentionally Necori and Matsuri, which is a collar dollar But the browser talk, which the website had to work at least. That we have the same steps you see in Captain Wires, that is, the browser fails several times until DNS is forcing it with Anycast constantly changing the IP. So my discussion is not because of the client and leakage and these stories. Strange behavior until the DNS is made. Now the misery we have is that Android is trying why this DNS is, then for example, it leaves it and connects, but every device is a behavior, no, the configuration of Hutono, what is exactly the statistics, what's going on, If it is a TLSFinger debate that that version should go into the dark. Not like what I am now seeing, two different demonstrations have a different behavior. I even hear the switch one day, for example, one says that server was connected, at the same time one is going to be definitive. The doubt is that DNS has a problem, because I know what mats are used for example. I do not use any more handsets for the rest, if you see a point, you have a way to make it easier to change DNS or if you can open it in the Rop Clients for DNS, something that must finally be fixed and correct. Now helps or not. I think you should type in English, because developers are going to read it, you can read the Google translation.

[mehdifirefox]

عشق داداش خب ما هم داریم همینو بررسی میکنیم تا به یه نتیجه درست برسیم. اگر از نشتی باشه حلش کنیم اگر کسی نشتی داره مثل من که گفتم با فایرفاکس دارم ولی سایتا برام باز میشه (البته بعضی کانفیگ ها واسه نسخه وب اینستاگرام باز نمیشه)

بعضا مشکلات برمیگرده به اینطرف قضیه یه سری لینک اشتراک سرور رایگان رو من تست میکنم . میبینم تو نکورای که پینگ نداره . تو کلش هم باید ادیت کنم بخش dns رو پاک کنم تا پینگش بیاد . تو v2ray ولی خوب کار میکنه واسه دردسر ادیت کانفیگ من از خیلی افزونه ها مثل NaïveProxy استفاده نمیکنم

ولی در کل به نظرم مشکل اونقدرا حاد نیست اگر گروه تلگرامی زدید برای تستی و آموزشی من مبتدی رو هم خبر کنین من که هر مشکلی رو به چینی ها گزارش میکنم یه چیزی میگن و حلش نمیکنن

---

The love of my brother, well, we are looking at this to get the right result. If it is a leak, if someone has a leak like I said I have a Firefox but the sites will open to me (of course some configurations will not open for the Web version of Instagram)

Sometimes the problems come back to the point I test a series of free server subscription links. I see in the Nakora that has no ping. I also have to edit the DNS section to get it. In v2ray but doing well I don't use many extensions like NaïveProxy for the hassle of editing.

But overall, I think the problem is not that acute If you have a telegram group for my test and training I report any problems to the Chinese say something and do not solve it

[alirezaac]

دوتا مسئله باید حواسمون باشه، tlsfp شدید بشه کم کم، بعدش نیاز به همچون افزونه هایی داریم،مشکل naive مثلا با همین dnsشه که بررسی میکنیم فقط تو ایرانه، اینا همونو با dns کمبو کنن قشنگ کامل پشت در میمونیم. مشکل ویندوزش کامل حل شدس از نظر ما، تنها مشکل گوشیاس مخصوصا اندروید، که دیگه خیالمون راحت باشه مشکلی پیش نمیاد. این نکته ای که گفتی درباره کلش جالب بود. @poorp اگه میتونی روی سرورت dns رو فیکس کن بعدش تست بگیر، احتمالا dns روی خود سرور مشکل داره.

---

Two things should be careful, tlsfp becomes more and less, then we need to be as plugins, the naive problem, for example, with the same dns that we are looking at only in Iran, these are the same with dns. The problem of his Windows is completely resolved, the only problem with the ear, especially Android, is no problem. This was interesting about the stash. @poorp If you can fix the dns on the server then test it, the dns may have a problem with the server itself.

[arandomgstring]

@free-the-internet

How do you want to decide if I am downloading a huge software from a foreign server, or I have my storage for my cameras abroad, or I am watching a video on a non-blocked foreign server, or as a company I deliver my video calling service with combination of external and internal servers? (Of course this is possible after that there is just so called Intranet, and all the services are available inside the country).

Isn't this decision like, super easy peasy (without intranet)? First of all, how many Iranian people have camera abroad and use their personal PC/IP to save that data? Yes, no one. Besides, cameras shouldn't be using https protocol at all, it would be very slow and inefficient. They use UDP from my understanding, which is already almost blocked (or rather heavily limited) from/to foreign servers in Iran; quic protocol works from google though. Wireguard is not working.

And just how many video calling services from outside of Iran are allowed? Even back then, when Telegram was not censored, its video calling was censored. Now almost everything with some very few exceptions in some regions are censored. I have heard Skype works sometimes for some people but it gets disconnected very frequently. The same goes for video streaming services. Youtube, dailymotion, twitch, hulu, netflix, crounchy roll, just to name a few, are all already blocked. If you are aware of any video streaming service outside of Iran that is not already blocked let me know!

As for downloading a huge software from a foreign server, that's actually a valid question. The answer is, they have already limited this. You can't download a huge file from foreign server, you get completely disconnected from Internet after a few gigabytes (~2-3) for a few seconds to a few minutes; and you might be reconnected after a while but that needs a DNS resolution in itself, therefore, the volume of DNS resolution wouldn't look weird; and you can resume your download, automatically or manually. Not to mention as I said, all operation system along with their third party application do DNS resolutions randomly. If from a client, no DNS resolution comes that would be very weird indeed, no? Which is why if you turn on V2RayNG on an android device which leaks no DNS, you might get your proxy server blocked, because no DNS resolution would come out of that device which looks interesting.

Of-course, if they match IP address of DNS resolutions that would be much better than volume; and I started this topic with that assumption, in the very first post.

Also I restarted Windows and reinstalled nekoray. This time I saw no leaking on Firefox; but some games couldn't be opened.

[alirezaac]

Also I restarted Windows and reinstalled nekoray. This time I saw no leaking on Firefox; but some games couldn't be opened.

well am i seeing cache poisoning here too?

anyway, the thing i was preparing for was a massive block like today, the crazy phone can't even check it connectivity status, all connections blocked except google, github, other important websites, so they evolved to keep the search engines and other websites alive, well looks like they are heavily reliant on this new dns method, but it has weakness which is a custom dns server, which can bypass most of their efforts but im still testing and cant say it out loud publicly. but i think you get my point @arandomgstring

[wkrp]

به نظرم بهتره انگلیسی تایپ کنید، چون دولوپر میاد بخونه مشکلو شما جای اون باشید میشینید ترجمه گوگل رو بخونید باهاش مشکلی حل کنید؟.

I think you should type in English, because Dolopper is going to read it, you can read the Google translation.

Please feel free to write in whatever language is most comfortable for you. We will do our best to translate. The translation from Google is bad, but there are also some bilingual developers who can help English speakers understand.

[arandomgstring]

@alirezaac

Perhaps. I always use ipconfig /flushdns before any test. Unless Firefox has some kind of inner-caching for dns requests I can't find any other explanation for what I have demonstrated about dns leaking. Also to re-verify your findings, I have added these rules to my host file and I can open youtube without VPN connection, although watching videos sometimes work sometimes not; because there are at least hundreds of servers for youtube and we cannot switch them manually. I have tested these rules on Irancell, Mokhaberat on different systems and yup it's confirmed. Although now that I am sharing it, they might get blocked at IP level, but who cares? Also you can always send me emails. arandomstring@airmail.nz

142.251.36.14 youtube.com
216.58.209.206 www.youtube.com
216.58.210.150 i.ytimg.com
216.58.210.142 i1.ytimg.com
173.194.182.74 rr5---sn-4g5e6ns7.googlevideo.com
74.125.104.73 rr4.sn-4g5lznlz.googlevideo.com
173.194.0.137 rr4---sn-25glenld.googlevideo.com
62.212.254.13 rr2.sn-qxau5-btqd.googlevideo.com
74.125.105.230 rr1.sn-25ge7nzz.googlevideo.com
74.125.11.9 fra24s23-in-f9.1e100.net

[Hadi-1624]

Guys I don't know what's exactly up with nekoray, I don't know the technical details, but it makes very odd issues with windows applications and some games. Try out the following project and the problems with gaming goes away; however, the ping fluctuations, which have become worse since a few days ago, still occur https://github.com/MetaCubeX/Clash.Meta There is an example configuration file in this issue: https://github.com/net4people/bbs/issues/150