Cloudflared proxy-dns behind a http proxy

proxy

#1

I’m trying to utilise cloudflared proxy-dns (Win64) from behind a corporate http proxy. I figured that when cloudflared makes a https request to 1.1.1.1 it will traverse via the http proxy server. However, from what I can tell it doesn’t honour any proxy settings and tries to establish the TCP directly which fails. I’ve set proxy settings via environment variables (http_proxy & https_proxy), netsh winhttp set proxy as well as IE proxy settings. I have also tried dnscrypt-proxy with the same outcome.

Are there any suggestions as to how to use the proxy-dns service from behind a http proxy? Or is it simply not supported?

Thanks!


#2

Have I misunderstood a concept or something???


#3

Anyone???


#4

Is the corporate proxy under your control or are you trying to bypass DNS requests?

Connection timeout I guess?


#5

Thanks, Mark. The corporate proxy is not under my control, unfortunately. However I am able to run up a local proxy server in case that helps? We don’t have a DNS server internally, which is why I’m keen to utilise cloudflared proxy-dns. We have other services which access external HTTP servers via IP address through our proxy no worries.

Should cloudflared proxy-dns honour http proxy settings? Or is has it not been a consideration?

Thanks again,
Matt.


#6

At this point it seems to me that this is more a security policy. Usually a proxy hast it’s own DNS configured which is used to resolve the requests. Sure you can set your own DNS servers on you workstation if you have the permission to do.
I don’t know the proxy dns unfortunately. But there are several ways to block normal users on a corporate network.

Usually for a good reason: security.

Possibly you are simply not allowed to use own DNS servers. I was on many public WiFi networks that forced me to use their DNS servers even though I have my own running within a VPN and DNSD requests are made through the tunnel.

This is all speculative as I don’t know your corporate network.


#7

Take a look at the configuration parameters at https://developers.cloudflare.com/argo-tunnel/reference/arguments/

I am not sure either specifies a proxy but maybe url would do the trick.


#8

Do you mean the proxy could be restricting access to https://1.1.1.1? I can browse to it through the proxy no probs which tells me it is not a blocked URL.

Here is the error message from cloudflared proxy-dns when it tries to contact 1.1.1.1 for a lookup:

ERRO[0032] failed to connect to an HTTPS backend “https://1.1.1.1/dns-query” error=“failed to perform an HTTPS request: Post https://1.1.1.1/dns-query: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)”

I am assuming it uses standard HTTP GET requests to access 1.1.1.1?

Cheers,
Matt.


#9

Thanks, Sandro. But that argument seems to be for the argo-tunnel rather than the proxy-dns. I’m pretty sure it tells the argo tunnel which web server will be listening on the local side of the tunnel.


#10

As I said, I am not sure any of that applies to a proxy. It simply is the link I found at https://developers.cloudflare.com/1.1.1.1/dns-over-https/cloudflared-proxy/

My understanding is url seems to be the connection endpoint where cloudflared will connect to, if you configure your proxy to act on behalf of Cloudflare it might just work, but no guarantees of course :smiley:


#11

So this is what is happening at an IPv4 level when proxy-dns tries to make a request to https://1.1.1.1:

192.168.160.1 is the gateway rejecting the TCP request to an outside IP. This is indicating that the request is attempting to be made directly instead of via the proxy.

This is a curl request to https://1.1.1.1 (curl https://1.1.1.1) which has found the proxy (192.168.160.175). This is run from the exact same console as cloudflared proxy-dns was, so it has access to the same environment variables which designate the proxy server:

It seems to me as though cloudflared proxy-dns is ignoring the proxy config and trying to establish a connection directly. If this is the case, it is either a bug in proxy-dns, a feature not implemented yet in proxy-dns or it is intentionally not implemented. Either way, it would be helpful to know.

Any further clues on this?