Argo Tunnel 1033, application is available on localhost

Hello all,

First post here because I’m pulling my hair out trying to get my Argo tunnel to work.

Reviewed: https://developers.cloudflare.com/cloudflare-one/connections/connect-apps and am still totally stuck.

I logged into the tunnel and linked it to my domain on Cloudflare’s NS via:

cloudflared tunnel login

I created my tunnel via:

cloudflared tunnel create tun1

I am currently using:

cloudflared version 2022.1.2 (built 2022-01-13-1311 UTC)

My config.yaml which is located at /root/.cloudflared (ref: https://developers.cloudflare.com/cloudflare-one/connections/connect-apps/configuration/configuration-file)

tunnel: tun1
credentials-file: /root/.cloudflared/<UUID.json

ingress:
  - hostname: test.domain.tld
    service: http://localhost:80
  - service: http_status:404

My DNS is as follows:

CNAME domain.tld CONTENT <UUID>.cfargotunnel.com
CNAME test.domain.tld CONTENT domain.tld

I am launching cloudflared as such:

cloudflared tunnel --config /root/.cloudflared/config.yaml run tun1

Output:

2022-01-15T04:01:33Z INF Starting tunnel tunnelID=<UUID>
2022-01-15T04:01:33Z INF Version 2022.1.2
2022-01-15T04:01:33Z INF GOOS: linux, GOVersion: go1.17.5, GoArch: amd64
2022-01-15T04:01:33Z INF Settings: map[config:/root/.cloudflared/config.yaml cred-file:/root/.cloudflared/<UUID>.json credentials-file:/root/.cloudflared/<UUID>.json]
2022-01-15T04:01:33Z INF cloudflared will not automatically update when run from the shell. To enable auto-updates, run cloudflared as a service: https://developers.cloudflare.com/cloudflare-one/connections/connect-apps/run-tunnel/run-as-service
2022-01-15T04:01:33Z INF Generated Connector ID: 87d440f5-64f5-40ac-ab30-682850c86cf1
2022-01-15T04:01:33Z INF Initial protocol http2
2022-01-15T04:01:33Z INF Starting metrics server on 127.0.0.1:42333/metrics
2022-01-15T04:01:34Z INF Connection 5be5ac3b-abeb-446f-9726-2dd3aacbd6fe registered connIndex=0 location=IAD
2022-01-15T04:01:34Z INF Connection 1d0a1ae8-2aec-4c98-a8a6-5a3f568edf6a registered connIndex=1 location=EWR
2022-01-15T04:01:35Z INF Connection 580c49e7-26bd-4be0-85c4-3eb4861ec935 registered connIndex=2 location=IAD
2022-01-15T04:01:36Z INF Connection c5e21957-804b-4cce-b6fc-b0ded1b04146 registered connIndex=3 location=EWR

I can access “http://localhost:80” (NGINX Test) from the serverOS hosting it. I can also access it by IP from another machine on the LAN via http://10.0.0.100

My NGINX File (serving NetData running on the same IP 10.0.0.100)

server {
        listen 80;
        server_name test.domain.tld;

        #Faster resolving, improves stapling time. Timeout and nameservers may need to be adjusted for your location Google>
        resolver 1.1.1.1 valid=300s;
        resolver_timeout 10s;

        gzip on;
        gzip_vary on;
        gzip_min_length 1000;
        gzip_proxied any;
        gzip_types text/plain text/css text/xml application/xml text/javascript application/x-javascript image/svg+xml;
        gzip_disable "MSIE [1-6]\.";

        client_max_body_size 100M;

        proxy_redirect off;
        proxy_buffering off;

        location / {
                proxy_pass http://localhost:19999;

        }
}

When I visit “test.domain.tld” in my browser I am met with Error 1033. I am at a complete loss. The service is accessible, there is no SSL to fail verification or be bypassed with “noTLSVerify: true” directive.

Any advice or steps to troubleshoot further would be greatly appreciated.

I wouldn’t double-hop the “test” CNAME entry. As your config file specifies a the “test” hostname, the “test” CNAME entry should point to the cfargotunnel hostname.

Thank you for the reply, I updated my test CNAME to reference .cfargotunnel.com directly and I am still getting 1033. I have also updated my LIVE NGINX file which should be serving NetData over HTTP.

I don’t think the NGINX conf file would be the culprit. If the site loads over http://localhost:80, then the tunnel should be able to read it.

In tunnel: tun1, is “tun1” the actual UUID? I use the full UUID, not the actual tunnel name.

You might also try validating and testing the ingress rules:
https://developers.cloudflare.com/cloudflare-one/connections/connect-apps/configuration/configuration-file/ingress#validating-your-configuration

I updated the config so that the “tunnel” directive now references the full UUID as opposed to the name instance. I got the same 1033 error. I also tried removing NGINX from the equation as NetData is on the same server (port 19999) and changing the “service” directive to http://localhost:19999 and also received a 1033 error.

[email protected]:~/.cloudflared# cloudflared tunnel ingress validate
Validating rules from /root/.cloudflared/config.yaml
OK

Did you also try the Test right below the validation instructions?

https://developers.cloudflare.com/cloudflare-one/connections/connect-apps/configuration/configuration-file/ingress#testing-your-configuration

My apologies, I missed that step (NGINX has been removed for simplicity, just trying to forward the application)

[email protected]:~/.cloudflared# cloudflared tunnel ingress rule http://test.domain.tld
Using rules from /root/.cloudflared/config.yaml
Matched rule #1
        hostname: test.domain.tld
        service: http://localhost:19999

To clarify, if I didn’t

Nginx is running as a Docker on 10.0.0.100
NetData is running as a Docker on 10.0.0.100

The containers can talk to each other.

I don’t think any of that would matter. If you can curl the “localhost” url from the same command line environment as “cloudflared”, then it should work. Are you sure the tunnel is still connected?

cloudflared tunnel list should show the connections. Here’s one reply (click on the link to see it with better formatting):

[email protected]:~/.cloudflared# cloudflared tunnel list
You can obtain more detailed information for each tunnel with `cloudflared tunnel info <name/uuid>`
ID                                   NAME   CREATED              CONNECTIONS
<OLDATTEMPT-UUID> tun 2022-01-15T02:26:35Z
<UUID> tun1 2022-01-15T03:01:21Z 2xEWR, 2xIAD

Could that stale old tunnel linked to the same domain be causing an issue? The current tunnel is up with connections.

Update: I deleted the stale tunnel with "cloudflared tunnel delete " and confirmed it is no longer showing.

I was able to get it working! I recreated my CNAMES and everything clicked. I guess I had an extra character or some white space. Who knows.

I do have one LAST question.

I want to forward an app running on 10.0.0.119:3000, this config works for the 10.0.0.100 IP’s but will not resolve the 10.0.0.119 IP.

Log

-01-15T05:01:30Z ERR  error="Unable to reach the origin service. The service may be down or it may not be responding to traffic from cloudflared: dial tcp 10.0.0.119:3000: connect: no route to host" cfRay=6cdc8bd79c8b15cb-EWR ingressRule=1 originService=https://10.0.0.119:3000
2022-01-15T05:01:33Z ERR  error="Unable to reach the origin service. The service may be down or it may not be responding to traffic from cloudflared: dial tcp 10.0.0.118:3579: connect: no route to host" cfRay=6cdc8bed49ea15cb-EWR ingressRule=1 originService=https://10.0.0.119:3000

Config.yaml


tunnel: <UUID>
credentials-file: <UUID>.json

ingress:
  - hostname: test.domain.tld
    service: http://10.0.0.100:19999
  - hostname: test2.domain.tld
    service: https://10.0.0.119:3000
  - service: http_status:404

Edit: Everything is solved and working. Thank you very much for you assistance @sdayman - walking through the process was integral to the resolution.

1 Like