Starting a few days ago my DNS queries to 1.1.1.1 inside a WARP tunnel stared to time out (no response from server).
dig reports “timed out” for queries:
ubuntu@ubuntu:~$ dig @1.1.1.1 www.cloudflare.com.
; <<>> DiG 9.16.1-Ubuntu <<>> @1.1.1.1 www.cloudflare.com.
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
ubuntu@ubuntu:~$
tcpdump on the WireGuard interface shows no response from the remote side:
root@ubuntu:~# tcpdump -ni wgcf host 1.1.1.1 and udp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wgcf, link-type RAW (Raw IP), capture size 262144 bytes
20:35:15.858886 IP 172.16.0.2.41386 > 1.1.1.1.53: 44197+ [1au] A? www.cloudflare.com. (59)
20:35:20.859508 IP 172.16.0.2.41386 > 1.1.1.1.53: 44197+ [1au] A? www.cloudflare.com. (59)
20:35:25.863512 IP 172.16.0.2.41386 > 1.1.1.1.53: 44197+ [1au] A? www.cloudflare.com. (59)
^C
3 packets captured
3 packets received by filter
0 packets dropped by kernel
root@ubuntu:~#
However, Google’s public DNS (8888) works:
root@ubuntu:~# tcpdump -ni wgcf host 8.8.8.8 and udp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wgcf, link-type RAW (Raw IP), capture size 262144 bytes
20:37:42.187690 IP 172.16.0.2.58804 > 8.8.8.8.53: 41116+ [1au] A? www.cloudflare.com. (59)
20:37:42.281619 IP 8.8.8.8.53 > 172.16.0.2.58804: 41116$ 2/0/1 A 104.16.123.96, A 104.16.124.96 (79)
^C
2 packets captured
2 packets received by filter
0 packets dropped by kernel
root@ubuntu:~#
In fact, I tried these 4 addresses and they all gave no response:
1.1.1.11.0.0.12606:4700:4700::11112606:4700:4700::1001
Strangely enough, TCP and ICMP are fine. Using mtr, I can reach 1.1.1.1 through the WireGuard interface in just 1 hop. Similarly, other Cloudflare IP addresses are also responding in 1 hop.
Using curl I can reach 1.1.1.1 via HTTPS:
ubuntu@ubuntu:~$ ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=64 time=70.7 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=64 time=71.7 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=64 time=78.0 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=64 time=66.8 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=64 time=63.0 ms
64 bytes from 1.1.1.1: icmp_seq=6 ttl=64 time=63.6 ms
^C
--- 1.1.1.1 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5001ms
rtt min/avg/max/mdev = 63.002/68.983/78.006/5.175 ms
ubuntu@ubuntu:~$ curl -s https://1.1.1.1/cdn-cgi/trace
fl=23f436
h=1.1.1.1
ip=<redacted>
ts=1640521591.386
visit_scheme=https
uag=curl/7.68.0
colo=HKG
http=http/2
loc=CN
tls=TLSv1.3
sni=off
warp=plus
gateway=off
ubuntu@ubuntu:~$
WireGuard itself is also fine:
ubuntu@ubuntu:~$ sudo wg show wgcf
interface: wgcf
public key: <redacted>
private key: (hidden)
listening port: 3
peer: bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=
endpoint: [2606:4700:d0::a29f:c001]:1701
allowed ips: ::/0, 0.0.0.0/0
latest handshake: 32 seconds ago
transfer: 1.11 MiB received, 2.10 MiB sent
persistent keepalive: every 20 seconds
ubuntu@ubuntu:~$
I am connecting to WARP using standard WireGuard tools (Ubuntu 20.04 LTS, Linux 5.11, stock wireguard.ko kernel module for support). I have two sources connecting to WARP (two discrete machines using two sets of WireGuard config):
-
2001:da8::/32(AS23910) to[2606:4700:d0::a29f:c001]:1701 -
202.111.192.0/19(AS4809) to162.159.192.5:2408
I could provide traceroute for the outer link (carrier of the WireGuard tunnel) if needed. It may or may not be necessary because both TCP and ICMP works inside the tunnel.
I also have an alternative location (Hong Kong) connecting to WARP but it’s working fine. Only WARP tunnels from mainland China are experiencing this DNS issue. Strangely, all clients are connecting to Cloudflare’s same HKG POP.
Independent from me, several of my friends have also reported the same problem from their equipments. They’re all connecting from mainland China.
Will Cloudflare investigate this?
