Cloudflare tunnel can't reach container

I’ve had a MicroOS server ticking away with barely a hiccup for a year but today I decided to have a play by ditching docker/podman-compose files and try going the quadlet way.

I haven’t tried the pods I’ve got yet (just the containers not in a pod) and it has all gone well… except I can’t access my containers through a cloudflare tunnel. I can go to 192.168… and everything is good but when I try www.blah.blah.com I get ‘Bad Gateway’. The tunnel can’t reach the IP:port it’s supposed to.

I can’t copy/paste from the log but in sections it reads “Unable to reach origin service”… “connect: connection refused”.

Does anyone know where I might need to look? My only thought is to put a cloudflared container and my ‘container to be accessed’ in a pod, but I’ve never had to do this before (I’ve wondered why not, but…).

Thank you for any help

edit: no selinux errors, btw

I can not really follow your story, was everything working before using a cloudfare tunnel?

If so, is the cloudfare connector running on your MicroOS server?

If not, please better subscribe how you did set up things.

I think what I was saying is that a cloudflared tunnel set up using podman-compose works on both quadlet and podman-compose containers, but a cloudflared tunnel setup using quadlets doesn’t work. When using quadlets, Does cloudflared + container need to be in a pod?

I’ll try to re-word what I originally attempted to explain…

I’ve got a bunch of containers that are all accessible through a cloudflared tunnel.

Originally I setup my containers (inc cloudflared) using podman-compose, except for nextcloud-aio which used docker-compose. I never liked that nextcloud wasn’t also podman so a few days ago I tried setting up nextcloud (non-aio) using quadlets. Everything worked as it should without any tinkering. I then tested podlet on one of my compose files (I think it was Baikal) and that also worked without any fuss.

For one reason or another I reinstalled MicroOS and planned on using podlet on all my compose files. First up, Baikal and cloudflared. Both containers startup as they should and I can access Baikal using my 192.168…:… IP and it works fine. cloudflared container also seems happy. But when I try to access Baikal through the tunnel I get the ‘Bad gateway’ page. cloudflared tunnel can’t reach the Baikal container.

I then tried using podlet to put both Baikal and cloudflared in a pod but podlet fails… it might be a podlet bug because I can’t get it to create a pod even if I copy/paste the example from the podlet github page.

So, I began to look into setting up my .container files manually but kind of got lost and tired and reverted back to podman-compose but I’d really like to know why the quadlet method failed for me.

Ultimately, I’ll have to find the time to learn to use pods and quadlets manually and see what happens.

Here is read the connector will appear in your Cloudfare account, is that the case?

Thanks for you reply but it’s nothing at the cloudflare end. I’ve given up. I got Baikal working by adding the cloudflared container to a network but none of my other containers were accessible. I’ve just gone back to podman-compose.

Below are the .container files that get all three containers up and running but only Baikal is accessible through the tunnel. I don’t understand why Gitea isn’t accessible.

Cloudflared

[Container]
ContainerName=cloudflare-messy
Environment=TUNNEL_TOKEN=xxx
Exec=tunnel --no-autoupdate run
Image=cloudflare/cloudflared:latest
Network=podman-compose_default

[Service]
Restart=always

Baikal

[Container]
ContainerName=baikal
Image=ckulka/baikal:latest
PublishPort=8100:80
Volume=/home/server/storage/baikal/config:/var/www/baikal/config:Z
Volume=/home/server/storage/baikal/data:/var/www/baikal/Specific:Z

[Service]
Restart=always

Gitea

[Container]
ContainerName=gitea
Image=gitea/gitea:latest
PublishPort=3000:3000
PublishPort=2222:22
Volume=/home/server/storage/gitea:/data:Z

[Service]
Restart=always

The problem was networks. I ended up putting each container in their own network and also realised that systemctl --user daemon-reload doesn’t update current networks. They all needed removing first.

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