DNSCrypt newest version not working?

Note: I hope this is the proper place to expose the problem I'm having.

I've been using the non-graphical version of OpenDNS DNSCrypt -https://github.com/opendns/dnscrypt-proxy. It has always worked. I downloaded the newest version yesterday. I didn't keep up with the updates... Anyway, after replacing the previous version with this new version, I no longer could connect to the Internet. I checked Windows firewall logs, and it's blocking it from connecting out to OpenDNS IPs to remote port 443, over TCP.

Having that in mind, I created a rule allowing that connection, but it still can't connect, and the logs still report the connection has been blocked.

The previous version works fine. Anyone using the non-GUI version faced this same problem? I wonder if this new version works different, and I need to do some extra step? From what I could see at DNSCrypt page, the info there is pretty much the same as before... so...

I wonder if this is some issue with Windows firewall itself... or due to something I need to do, DNSCrypt fails to work properly and the firewall blocks the connection?

Thanks!

 

Hi,

If you are having issue with dnscrypt, please open a ticket on Github instead.

Old versions used UDP port 53 by default. But since a lot of routers and ISPs are hijacking this, recent versions use port 443 by default, but still over UDP. So you need to open that on your firewall.

If you need to use port 53, you can always start dnscrypt with --resolver-port=53. And if you absolutely need to always use TCP, which is a terrible idea, add --tcp-only.

 

I managed to solve it, though. I had made a mistake. I thought the firewall log showed that it was blocking TCP, but was actually blocking UDP; which was the reason why I wasn't understanding what was happening.

Thanks for the info.

 

Could you explain how ISP's are "hijacking" requests via 53 when they are supposed to be encrypted? The whole point is to prevent MITM-type modification, so I'm unsure how this could happen.

 

I was actually wondering about that just now.

 

Was really hoping for some kind of explanation...

 

They could be breaking the SSL handshake.

 

I'd find it hard to believe that "a lot" of routers and ISPs are breaking SSL handshakes!

 

m00n, I didn't notice any firewall issues myself, here's what I did:

Downloaded the latest version of the proxy for Windows (dnscrypt-proxy.exe)
Disabled DNSCrypt in the GUI
Overwrite the proxy file with the newer version
Enable DNSCrypt in the GUI
Restarted PC for good measure

Working same as before, I assume it's because you actually make strict firewall rules where as mine are mostly default which allows the communication.

On a positive note the proxy dropped from ~400KB to ~100KB so I assume the author has done some work on optimizations. Hopefully we'll see some optimizations on the service/gui because the memory usage is dreadful.

 

Yes, indeed. The issue I was having was related to my strict firewall rules. When I checked the firewall logs I mistakenly associated Protocol 17 has being TCP, when in fact it's UDP. So, I created a rule allowing TCP, not UDP, which is why dnscrypt was being blocked. It was a very stupid moment, because I should know better.

 

I wonder if 'jedisct1' was talking about strict firewalls filtering out any non-DNS (unknown) data over port 53? He/she used the word "hijacking" originally which got me worried.

I could see that happening in routers, no so sure about ISPs though.

 

Anyone using the non-GUI version also has issues with it randomly terminating?

I automate the whole process of running it using a scheduled task. The task is successful, and it always has been; but, dnscrypt-proxy.exe randomly stops. So, I don't think this is an issue with the task itself, rather with the newest version of dnscrypt-proxy.exe.

So, I looked in Event Viewer and I get the following two error messages...

and

I'm going to look for more info on these error codes, but it would be great if anyone could also provide some feedback about what's happening.

Could it be a bug in dnscrypt-proxy.exe?

I will replace the new version with the previous version and see if it happens as well.

 

I monitored dnscrypt with Process Explorer, and it's in fact dnscrypt-proxy.exe that crashes. I can't even check for updates in Windows Update, without it crashing.

This new version is simply a mess. It's no longer fun.

 

I replaced the newest version with the previous version, and no more issues. So, the problem is definitely the new version. Something else that I noticed with the new version is that, when disconnected from the Internet, it won't crash. I can be disconnected for like half an hour, it won't crash, but as soon as I reconnect, it crashes.

 

It appears to be working fine for me (with the GUI) so far. Unfortunately when I looked at my Event Viewer I discovered a lovely ATI error occurring every 20 seconds since the 26th of last month! Odd.

 

I am also having problems with dnscrypt -- it no longer retrieves server certificates according to the proxy. Wireshark indicates that the proxy's initial connection to get "transaction id" (port 53) is successful but is not authenticated. I also updated the proxy, per elapsed's procedure. No change.

Coincidentally, I have changed router's firewall rules to default deny and this could be source of problem. Yet, dns and https are allowed on router. OS firewall always allowed dnscrypt and was not adjusted. Have searched the forum at OpenDns, no help (could not find a way to begin an account, even.) A bit confused as *what* ports need to be opened. Always worked on tcp:443 for me, but jediect1 says UDP:443?

Anyone have router firewall adjustments they can share?

 

You actually need to allow both UDP:443 and UDP:53. If having only UDP:443, I can't connect to the Internet with the newest proxy version. So, you need both.

You didn't need to allow either TCP/UDP:443 with the previous, unless you wanted to force TCP:443, which is why I believe it worked in your situation.

Create an additional rule in your firewall for DNSCrypt allowing UDP:443 out.

 

M00nbl00d. Your instructions re: TCP/UDP:443 and UDP:53 was much clearer than what I've seen so far. Will try it. Thanks.

 

A new version came out two days ago. It no longer crashes, and it actually made my PowerShell script go crazy.

Considering that the previous version was constantly and randomly crashing, I had created a PowerShell that ran in the background, and it would monitor when dnscrypt-proxy was not running and would restart it whenever needed.

But now, the newest version actually makes my script run dnscrypt-proxy in a loop.

 

Thanks for the heads up, updated from v0.10.1 to v0.12 (apparently I missed the v0.11 update)

Did it manually as before and it seems to be performing ok.

 

So I got fed up of no updates to the badly coded GUI client. I've uninstalled the GUI and I'm now running the proxy "manually" like I did before they announced the launch of the GUI program.

It's currently auto-running at startup on a separate, restricted account, with some extra tips from m00n (thanks!). It's also running under EMET as it was before.

 

Where did you get the update? OpenDNS site has v0.0.5 for download.

 

I'm talking about the proxy itself not the GUI, which can be acquired from GitHub.

But um, anyone else's DNSCrypt failing today? For me it's failing to fetch the server certificates, no idea why. Had to fall back to standard DNS for now.

 

Not sure if it's related to what you're experiencing, but according to OpenDNS status page, London servers are under maintainance. Users using these servers are being re-routed to other locations.

I'm also having issues with OpenDNS. The only way to access Wilders was to add it to the hosts file and map to the IP. I don't want to go back to my ISP's.

I hope they fix it soon.

 

I don't see how, also according to the status page it's been under maintenance for several days, this only started today. If it was a server issue it should re-direct.

edit: server side issue they are (hopefully) fixing https://github.com/opendns/dnscrypt-proxy/issues/24