Anonymized DNSCrypt doesn't work in WSL2 or Hyper-V on Windows

[awebeer256]

In my .toml I have:

log_level = 1
dnscrypt_servers = true
doh_servers = false
odoh_servers = true
require_dnssec = true
require_nolog = true
require_nofilter = true

I've also uncommented the section to use the lists of ODOH servers and relays.

Under the anonymization section, I've made sure every server has a valid route, and I have this:

skip_incompatible = true
direct_cert_fallback = false

The problem is that ODOH servers work, but Anonymized DNSCrypt ones don't.

In the log, for every Anonymized DNSCrypt server, I get this:

[NOTICE] Anonymizing queries for [<server>] via [<relay>]
[NOTICE] [<server>] OK (DNSCrypt) - rtt: XXms
[INFO] [<server>] couldn't be reached anonymously, it will be ignored

[klutchell]

Hey @awebeer256, do you have this issue if you install the application directly from https://github.com/DNSCrypt/dnscrypt-proxy?

I feel like this isn't an issue with the docker container, but maybe something that could be answered on the official repo regarding your congfiguration?

[awebeer256]

do you have this issue if you install the application directly from https://github.com/DNSCrypt/dnscrypt-proxy?

Nope, it's all fine if I install it natively.

[klutchell]

Thanks for confirming! I assume you are using the same configuration toml file for both local and docker installations, just to rule out a configuration issue?

Can you try turning up the log_level and including some more logs before the warning?

I'm not sure what this container could be missing to prevent it working like any other OS. Maybe the certificates need updating or there is a docker permission we need to adjust to allow fragmented packets re: DNSCrypt/encrypted-dns-server#58?

[awebeer256]

Yep, the config is the same.

Here's the first few lines after starting the container, with log_level = 0:

[NOTICE] dnscrypt-proxy 2.1.1
[NOTICE] Network connectivity detected
[NOTICE] Now listening to 0.0.0.0:5300 [UDP]
[NOTICE] Now listening to 0.0.0.0:5300 [TCP]
[NOTICE] Source [public-resolvers] loaded
[NOTICE] Source [relays] loaded
[NOTICE] Source [odoh-servers] loaded
[NOTICE] Source [odoh-relays] loaded
[NOTICE] Anonymized DNS: routing [<server>] via [<list>]
[NOTICE] Anonymized DNS: routing [<server>] via [<list>]
[NOTICE] Anonymized DNS: routing everything else via [<list>]
[NOTICE] Firefox workaround initialized
[NOTICE] Anonymizing queries for [<server>] via [<relay>]
[NOTICE] [<server>] OK (DNSCrypt) - rtt: XXms
[INFO] [<server>] couldn't be reached anonymously, it will be ignored

No message about fragmented packets 😕.

I'm using this container as part of https://github.com/losuler/pihole-dnscrypt-docker. Here's my docker-compose.yml:

version: "3"

services:
  dnscrypt:
    container_name: dnscrypt-proxy
    image: klutchell/dnscrypt-proxy:latest
    networks:
      pihole_net:
        ipv4_address: 10.0.1.2
    expose:
      - "5300/udp"
      - "5300/tcp"
    environment:
      TZ: '<redacted>'
    volumes:
      - './etc-dnscrypt-proxy:/config'
    #dns:
    #  - 1.1.1.1
    restart: unless-stopped

  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    networks:
      pihole_net:
        ipv4_address: 10.0.1.3
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "80:80/tcp"
      - "443:443/tcp"
    environment:
      TZ: '<redacted>'
      WEBPASSWORD: '<redacted>'
      PIHOLE_DNS_: "10.0.1.2#5300"
      WEBTHEME: 'default-darker'
      IPv6: 'false'
    volumes:
       - './etc-pihole/:/etc/pihole/'
       - './etc-dnsmasq.d/:/etc/dnsmasq.d/'
    #dns:
    #  - 1.1.1.1
    restart: unless-stopped
    depends_on:
      - dnscrypt

networks:
  pihole_net:
    driver: bridge
    ipam:
      config:
        - subnet: 10.0.1.0/24    

[klutchell]

Sorry I haven't had much time to investigate this further yet. Can you try running the container in host networking mode to rule out any issues with the docker bridge and NAT?

Do you have an example configuration including some actual servers I can test this with?

[awebeer256]

I tried with just klutchell/dnscrypt-proxy. Compose:

services:
  dnscrypt:
    container_name: dnscrypt-proxy-solo
    image: klutchell/dnscrypt-proxy:latest
    
    ports:
      - "5300/udp"
      - "5300/tcp"
    volumes:
      - './etc-dnscrypt-proxy:/config'
    restart: unless-stopped
    network_mode: "host"

…and had the same problem. Should I open an issue in that repo instead?

[klutchell]

…and had the same problem. Should I open an issue in that repo instead?

They are the same repo. I renamed klutchell/dnscrypt-proxy to klutchell/dnscrypt-proxy-docker some time ago.

[awebeer256]

Oh, oops. As I said, I'm wanting to use this container in the context of pihole-dnscrypt-docker. As I was writing the previous comment, I misremembered and thought this issue was in that repo, so I was suggesting moving the discussion to…this one. But my past self was smarter than that, and opened it here in the first place.

[klutchell]

Thank you for testing with host networking, that actually rules out a whole bunch of issues I was considering.

[awebeer256]

My host machine is Windows 10 (amd64), and I'm using the WSL2-based Docker engine. I have the same containers running with no problems on another machine, but it's in another physical location (many kilometres away), and its host OS is Ubuntu 22. 🤷

[klutchell]

My host machine is Windows 10 (amd64), and I'm using the WSL2-based Docker engine

This sounds related, since WSL2 does a bunch of interesting stuff with networking for Docker. Can you reproduce the issue at the same location in a Linux VM or another device running Linux?

[awebeer256]

I booted into an Ubuntu 22 live session on the same machine, installed Docker, and ran the containers with copy-pasted docker-compose.yml and dnscrypt-proxy.toml (not in "host" network mode). The problem didn't appear.

It's not just WSL2, though; back in Windows, I switched to Hyper-V and the problem persisted.