1

Following instructions, tried to circumvent network censorship. In the instructions, it was said to add these records in the name's register configuration panel and set these:

A tns.example.com points to 203.0.113.2 AAAA tns.example.com points to 2001:db8::2 NS t.example.com is managed by tns.example.com

I set them in the DNS part of the Cloudflare account Then started "Tunnel server setup":

tunnel-server$ cd dnstt/dnstt-server tunnel-server$ go build tunnel-server$ ./dnstt-server -gen-key -privkey-file server.key -pubkey-file server.pub privkey written to server.key pubkey written to server.pub tunnel-server$ ./dnstt-server -udp :5300 -privkey-file server.key t.example.com 127.0.0.1:8000 tunnel-server$ sudo iptables -I INPUT -p udp --dport 5300 -j ACCEPT tunnel-server$ sudo iptables -t nat -I PREROUTING -i eth0 -p udp --dport 53 -j REDIRECT --to-ports 5300 tunnel-server$ sudo ip6tables -I INPUT -p udp --dport 5300 -j ACCEPT tunnel-server$ sudo ip6tables -t nat -I PREROUTING -i eth0 -p udp --dport 53 -j REDIRECT --to-ports 5300

And finally:

tunnel-server$ sudo apt install ncat tunnel-server$ ncat -l -k -v 127.0.0.1 8000 Ncat: Version 7.70 ( https://nmap.org/ncat ) Ncat: Listening on 127.0.0.1:8000

After that, the Tunnel client setup on my local Windows downloaded the most recent DNSTT source from: and in the tunnel-client folder ran these:

tunnel-client$ cd dnstt/dnstt-client tunnel-client$ go build ./dnstt-client -doh https://mozilla.cloudflare-dns.com/dns-query -pubkey-file server.pub t.example.com 127.0.0.1:7000

It did not connect, and this was the result:

uTLS fingerprint iOS 12.1 effective MTU 135 begin session 814d2b5f sendLoop: Post "https://mozilla.cloudflare-dns.com/dns-query": dial tcp 10.10.34.35:443: connectex: No connection could be made because the target machine actively refused it.

I tried to use DOT, but the result was:

./dnstt-client -dot dot.cloudflare-dns.com:853 -pubkey-file server.pub t.example.com 127.0.0.1:7000 2025/08/17 12:27:17 uTLS fingerprint Firefox 65 dial tcp 10.10.34.35:853: connectex: No connection could be made because the target machine actively refused it.

I searched a lot to find the solution and tested different dnstt-client commands This is the response I received when running the dnstt command:

Downloads\dnstt-20220208\dnstt-client>.\dnstt-client -doh https://dns.quad9.net/dns-query -pubkey-file server.pub t.example.com 127.0.0.1:7000 2025/09/05 16:53:20 uTLS fingerprint iOS 12.1 2025/09/05 16:53:20 effective MTU 135 2025/09/05 16:53:20 begin session 3a6c32db 2025/09/05 16:53:23 sendLoop: Post "https://dns.quad9.net/dns-query": dial tcp 10.10.34.35:443: connectex: No connection could be made because the target machine actively refused it. Downloads\dnstt-20220208\dnstt-client>.\dnstt-client -dot 9.9.9.9:853 -pubkey-file server.pub t.example.com 127.0.0.1:7000 2025/09/05 17:04:45 uTLS fingerprint Firefox 65 read tcp 182.188.8.24:13591->9.9.9.9:853: wsarecv: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

When I use VPN and set Google DNS resolver as DOH, it does not show any error, and when I run this command in PowerShell, it indicates that the connection is established.

\dnstt-client>.\dnstt-client -doh https://8888.google/dns-query -pubkey-file server.pub t.example.com 127.0.0.1:7000 2025/09/07 12:06:17 uTLS fingerprint Firefox 65 2025/09/07 12:06:17 effective MTU 135 2025/09/07 12:06:17 begin session 8a847510 ncat -v 127.0.0.1 7000 Ncat: Version 7.80 ( https://nmap.org/ncat ) Ncat: Connected to 127.0.0.1:7000.

But if a real connection is established, whatever I type in the client terminal should show in the server terminal and vice versa. But this does not happen. I checked if the dnstt server is running by:

ps aux | grep dnstt-server

and the result is:

root 234768 0.0 0.6 17136 5552 pts/2 S+ Aug03 0:00 sudo ./dnstt-server -udp :5300 -privkey-file server.key tns.example.com 127.0.0.1:22 root 234769 0.0 0.2 17136 2164 pts/3 Ss Aug03 0:00 sudo ./dnstt-server -udp :5300 -privkey-file server.key tns.example.com 127.0.0.1:22 root 234770 0.0 1.1 1526456 10164 pts/3 Sl+ Aug03 0:16 ./dnstt-server -udp :5300 -privkey-file server.key tns.example.com 127.0.0.1:22 azureus+ 573809 0.0 0.2 7080 2216 pts/8 S+ 11:12 0:00 grep --color=auto dnstt-server

I used sudo ufw allow 53/udp to ensure that UDP traffic on port 53 is allowed. Checked out that the ncat server listener is running:

 ncat -l -k -v 127.0.0.1 8000 Ncat: Version 7.94SVN ( https://nmap.org/ncat ) Ncat: Listening on 127.0.0.1:8000

But even when using a VPN, although a connection is established, there is no transfer of information between client and server!!!

Improve this question
5
  • Servers typically refuse TCP connections when the connection is to a server port that has no process listening for connections. Is your server listening for connections on the port that your client is trying? (According to the error message the client is trying to connect to port 443) Commented Sep 5 at 17:54
  • "Downloads\dnstt-20220208\dnstt-client>.\dnstt-client"? Backlash? Is this in Windows, and inappropriate on this site? Commented Sep 5 at 19:24
  • @waltinator There are two sides in this tunnelling server-side and client-side. Linux is the server side, and in this case, I wanted to use my Windows computer to connect to a Linux server. Commented Sep 5 at 20:31
  • @SottoVoce, I updated my question with more detail Commented Sep 5 at 20:40
  • @lachin can you point out where in your question you wrote the command and output that confirms the DNS server has an active listener on port 443? For example, a search suggests invoking the command netstat -b -a -o on the Windows DNS server and looking for an output line where the "Local Address" column shows an IP address with ":443" appended. If there is no such line, there's no process on the DNS server waiting to accept the connections your client program is making to port 443. Commented Sep 6 at 9:18

1 Answer 1

Reset to default
0

The reason they are failing is that the domains dot.cloudflare-dns.com and dns.quad9.net are blocked in Iran.

One way to test if you are following the instructions correctly is to use a client machine that is not within a country where there is internet censorship. If you could not connect there, you know that you need to find the issue with the instructions. If you can connect from that machine, you know it is because of the filtering.

For example, the following shows that the domain name used here is blocked in Iran because nslookup is returning 10.10.34.34 for the IP of dns.quad9.net. This IP is a private IP address. The Iranian DNS returns a private IP for the web addresses that are blocked.

# nslookup dns.quad9.net Server: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: Name: dns.quad9.net Address: 10.10.34.34 Name: dns.quad9.net Address: 2001:4188:2:600:10:10:34:34 #
Improve this answer
1
  • 1
    As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center. Commented Sep 6 at 0:14

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.