So I managed to smash a few buttons randomly again, and get this solved.

There are a few things to be aware of:

• Oracle doesn’t like ufw. So I disabled it and uninstalled it. Having ufw installed may result in bad stuff. Link
• I decided to flush all rules in ip-tables to start on a clean slate: sudo iptables -F
• While I’m at it, I’ve changed ip-tables to allow ALL. THE. INBOUND. TRAFFIC: sudo iptables -I INPUT -j ACCEPT
• One last thing, I’ve changed the state of the firewall to go from stateful to stateless, still with no restrictions on the ingress / egress traffic.

This is, of course, not a recommended setup for a host to be used in production or to have critical data, but it gave me a host in a working state that I can work with.

Some posts that helped me in this:

• https://smalldata.tech/blog/2021/09/08/how-to-open-ports-on-oracle-cloud-vm-running-on-ubuntu-20-04
• https://old.reddit.com/r/oraclecloud/comments/dghuz2/unable_to_access_compute_instance_from_http_but/

Correct - that was a typo in this post. The output from sudo ufw status verbose is however correct.

I think I’ve solved the issue, will write it in a seperate post and link it to the original post.

Correct - that was a typo, I’ve corrected the original post. Not a good idea to write a report when you’re angry and tired… 🤣

The firewall (Network Security Group in Oracle lingo) is indeed attached to the subnet. I think I’ve solved the issue, will write it in a seperate post and link it to the original post.

Good find.

I am running Caddy through docker (with sudo docker-compose up, yml is listed above). I know, sudo:ing docker isn’t best practice, but I’m learning the ropes in a non-production enviorment 🙃 Also, I verified that docker is running as root by ps -eo euser,ruser,suser,fuser,f,comm,label |grep caddy

As for the docker version, I verified it by inspecting the image ID and saw that the image version is 2.7.2:

           "Labels": {
                "org.opencontainers.image.description": "a powerful, enterprise-ready, open source web server with automatic HTTPS written in Go",
                "org.opencontainers.image.documentation": "https://caddyserver.com/docs",
                "org.opencontainers.image.licenses": "Apache-2.0",
                "org.opencontainers.image.source": "https://github.com/caddyserver/caddy-docker",
                "org.opencontainers.image.title": "Caddy",
                "org.opencontainers.image.url": "https://caddyserver.com",
                "org.opencontainers.image.vendor": "Light Code Labs",
                "org.opencontainers.image.version": "v2.7.2"
            }

It seems that my next step is to look into the issue why dockerized-Caddy can’t communicate with Tailscale. Now I have a direction to investigate further into 🙂

Is there a reason why you’d recommend Ngnix over Caddy, as Caddy also have the capability to act as a reverse proxy?

And if you have any recommendations on resources where I can expand me knowledge on this topic, I’ll be happy to read more.

Thanks again!

Please do, I’d be most grateful for it.

If you have any better suggestion for how I should handle reverse proxying (maybe there’s a easier way than through Caddy?), I’m all ears.

If you like roguelikes, you’re in for a treat. Check out Brogue and DCSS.

And if you want to witness some TUI eyecandy without it being a game, ssh git.charm.sh.

YES! Quite entertaining kingdom-sim with lots of weirdness and fun.