Argo routing ignores no-tls-verify

I followed this article (https://developers.cloudflare.com/cloudflare-one/tutorials/warp-to-tunnel#configure-and-run-the-tunnel) to set up a tunnel to my private network and added the no-tls-verify option to my conf file (https://developers.cloudflare.com/cloudflare-one/connections/connect-apps/configuration/config#no-tls-verify). However, when I tried to connect to an HTTPS site (using IP address) I got the 526 error (Insecure upstream).

It seems the no-tls-verify option was ignored. And a more weird behavior is if I access the same site using a non-standard port (still HTTPS, same certificate), or any https site that runs on non 443 port, I get no error although the certificate is still invalid.

Any insights?

Hi @bfdnd,

It works for me with this config, not sure why the example in the documentation does not work. Can you try this and see if it works?

- hostname: hostname.example.com                                           
    service: https://location                                        
    originRequest:                                                              
      noTLSVerify: true

Hey @domjh - the one you proposed works (in terms of accepting any tls certificate), however it is different from what I want to achieve. I would prefer to use

warp-routing:
    enabled: true

so that I can connect to any ip address on the internal network, whereas if I define ingress, I have to create a separate ingress for each site.

Also when I set cloudflared log level to trace, I see the daemon is connecting to the address I want to visit on port 443. Seems the error is caused by some other cloudflare component (maybe gateway?)

I see, thanks for the extra info. This goes beyond my level with Tunnel, so hopefully someone else can help!

Yes, this sounds like something coming off Gateway (where the L4/L7 filtering happens, before the data is routed to your cloudflared origin). Can you edit your thread/post to be tagged with it?

4 Likes

As a workaround, you can add a L7 Gateway Rule with Action “Do Not Inspect” that matches your upstreams that are causing this problem. That will mean Gateway will not do TLS termination. That is why it works if you use a non-standard HTTPS port, since in that case it does not do TLS termination either.

4 Likes

Thank you! It works perfectly after adding the exception. Thought it might be a good idea to document the no-inspect behavior of non standard ports somewhere, or did I miss it?

Thank you for confirming that it works.

My hypothesis is that your origin is presenting a non-trustable TLS certificate (e.g. a self-signed one). Cloudflare Gateway (which is performing the request to your origin) only accepts TLS certificates that it can validate.

If you confirm that this is your case, i.e., your origin cannot be accessed by default from a client with HTTPS (unless certificate validation is disabled or some root certificate is installed), then this matches a limitation already known internally. Until today maybe that did not make much sense, since origins exposed to the Internet should have valid certificates. But maybe today, with WARP routing to private networks, that can make more sense. The Product Manager for Cloudflare Gateway was informed of this rationale.

If, however, you are sure that your origin’s TLS certificate is valid and signed by a trusted root (or via some chain) that anyone should be able to access it, then you may be hitting some bug and it’d be better to open a ticket with our support with as much detail as possible (namely, the certificate that your origin is presenting).

Correct - my origin is using self-signed certificate.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.