How To Resolve Some Argo Tunnel Issues

Not sure if this is allowed, but I wanted to share some of the issues I ran into with getting cloudflared to work, what I learned and how to fix them.

Principally these issues were encountered when working with IIS to ensure the connection between cloudflared and the IIS server was encrypted.

Command Line Syntax Errors

cloudflared does not tell you that it is ignoring an argument.

cloudflared tunnel --url https://localhost:443 --no-tls-verify run TunnelName

The above will initialize cloudflared without warning but it is in fact wrong.

cloudflared tunnel run --url https://localhost:443 --no-tls-verify TunnelName

This is the correct way, run must be the first argument and the tunnel name must be the last argument.

In this example, doing this the incorrect way results in the URL argument not be accepted despite the tunnel starting.

This syntax is actually specified in the documentation, but If you aren’t familiar with how to read the output this is easily missed.

So, in the output of cloudflared, the line that says Settings: map[ . . . . ] must contain the name of the specified hostname in the config file or the --url arugment. If you see the default name localhost:8080 something is misconfigured.

Misunderstanding of cloudflared vs Cloudflare Web Console behaviors

If you have your SSL/TLS settings in the Cloudflare console set to Full and you’re still not getting connections to occur over HTTPS, check the URL.

URL arguments are protocol and port sensitive. Cloudflared will respect the protocol of the connection string. e.g http:// or https://, even if the web console indicates TLS/HTTPS Full-Strict is enforced.

In my case I was using the IIS rewrite Module to automatically redirect HTTP to HTTPS, but saw that I was encountering a redirect loop (a common issue). After viewing many forum post, I learned this behavior occurs when a proxy sends plain text messages, but IIS calls for the proxy to establish an HTTPS connection, which the proxy then decodes and sends plain text messages again ad nauseam.

So I told IIS to simply ignore the fact that the incoming proxy connection was established over HTTP (connecting by localhost so it seemed safe) using {HTTP_X_FORWARDED_PROTO} which is a common resolution for this issue, as typically you trust that the connection between the proxy and client is the one that’s protected, while internally connection behind your firewall or on host proxies are safe from snooping.

However the IIS application I was working with required that the connection to the server be secure in order for outbound SAML authentication request to be sent with an HTTPS:// leading ACS URL, otherwise they were sent with HTTP:// causing failures with our IDP, whenever I would try to use HTTPS:// for the URL I would get “trust” errors which lead me to my final resolution:

Handling Certificate Trust between Origin and Cloudflared

no-tls-verify: true or --no-tls-verify is required in the config.yml file or command line argument to “trust” the certificate presented by the origin server to cloudflared. This is by design in order to get cloudflared to work with an SSL certificate that Cloudflare doesn’t trust. Since this is on a server you control it is not an issue despite the way it sounds.–no-tls-verify

Additionally, the TLS certificate must have a Subject Alternative Name of the hostname/url specified in the config file / command line argument.

I wanted to continue to bind on localhost so that traffic would not leave the device, but what you will find is that cloudflared will not accept the connection if the hostname specified in --url is not on the certificate. You will get “Expected X name on cert” errors. You the will need to acquire a ssl certificate with localhost on it.

Alternatively, a simple way to bind on localhost while also supporting TLS (without yet another certificate) is to edit the server’s host file to have ( point a domain in the TLS certificate and then specify that domain in the config file / command line URL argument. Cloudflared will connect locally (as it checks the host file first), but also now allows the certificate.

Hopefully someone else can have a little easier time in the future now.

Thanks for reporting these detailed points.

About Command Line Syntax Errors, we are likely to make a change soon that will make the application more flexible and parse the arguments even if they come up in different places; it’s currently being discussed internally and seems like it is in a good shape for a near-term cloudflared release.


That’s great! I think I spun my wheels longest because of the syntax error. The tunnel would run, and I would be able to access the site, but I would get such conflicting error messages, so it lead me on a bit of a goose chase for a few hours.