Selfhosted

If you’re behind a CG NAT (carrier grade NAT), you’ll be doubly in trouble as it will be essentially impossible to get a forwarded port since your “IP” is essentially a LAN address within your ISP’s CG NAT, if that makes sense.

Many ISPs block some traffic on those ports for residential customers in order to force you to use a much more costly business account to be able to host your own website.

why do you forward the port of the webui?

If you're already using cloudflare, I'd recommend a cloudflare tunnel to your reverse proxy.

As was said, many ISPs will block port 80/443, but they won't be seeing it that way with a tunnel. You'll also get some cloudflare protections in front of your services.

There's not really enough to give an conclusive answer from "it's not reachable". All I can do is tell you what I'd probably do to try to troubleshoot further.

My first steps in troubleshooting connectivity would probably be something like this:

• Fire up something on the HTTP server (I'm assuming it's running Linux) like sudo tcpdump port 80. That should let you see any packets that are reaching the HTTP server.

• From a Linux machine on an outside network

a tethered cell phone might make a reasonable machine, if you don't have another machine you control out there somewhere in the ether

running something like mtr --tcp -P 80 <hostname>. That'll tell you, at an IP-hop-by-IP-hop level, whether there's anything obstructing reaching the machine. Could be that your ISP blocks 80 inbound, for example.

• So the next step is probably to see whether you can get regular ol' HTTP through. Also from an outside network, running curl --verbose http://<hostname>/. That'll let you see what's happening at the HTTP level.

I'm guessing that you're probably going to have something along here break. It could be that the packets are being blackholed at a hop prior reaching your router, in which case your ISP may be firewalling inbound on that port. It may be that they're reaching your router, but that your router is trying to forward to the wrong machine. It may be that you have some kind of firewall on the HTTP server that's blocking connections that aren't coming locally or from the WireGuard side. But at least it'll probably give you a better idea as to how far it's getting.

Once you've got that up and running, can look at HTTPS:

• If this is working, if you want to test the TLS certificate handshaking, see if there are any issues, again, from an outside network: openssl s_client -connect <hostname>:443 -prexit. That'll let you see the TLS handshake and any issues that happen during it.

• Also from an outside network, running curl --verbose https://<hostname>/. That'll let you see what's happening at the HTTPS level.

EDIT: Oh, yeah, and someone else pointing out confirming that the DNS resolution is what you expect is probably also a good first step. host <hostname> from an outside network.

See to what IP your domain points, and if that's really the external IP of your router. Might also help to put in your IP address into the webbrowser instead of the domain, to see if port 80 / 443 really go somewhere. Another possibility, do a portscan from the internet.

Btw, how do you access Wireguard? I mean that's also somehow able to access your network from outside...

How did you get the certs? Was it though a DNS challenge or web server on port 80?

my router and my reverse proxy (traefik) is able to receive the necessary SSL/TLS certificates however

From something like LetsEncrypt?
As an HTTP-01 Challenge? Not an DNS-01 challenge?
Http challenge means that port 80 is accessible from the public internet (because that's how LE can confirm it can reach your server via the public DNS records, proof of server ownership).
DNS-01 is about proof of DNS record ownership, and doesn't prove public internet access.

Also, what are you self hosting?
Does it really need to be publicly accessible? Or just accessible by you and people you trust?