Current FZ docker auto install script; caddy not listening on 80/443:IPv4 (Ubuntu 20.04)

Hello,

I’ve used firezone for a while now on my vps at Kamatera. I’m running Ubuntu 22.04 there. I recently opened a new VPS at IONOS. I’ve used them for a long time and never run into any funky install issues.

It’s a clean install of Ubuntu 20.04. I installed docker-ce, git, python3, npm, yarn, certbot. I run through the auto install script, enter the appropriate info including proper FQDN. I choose the option to automatically handle cert. It installs, I go to the https://url and get a 502. I check caddy, it’s running. I pull a netstat -lp and nothing is listening on ports 80 or 443 on IPv4; only on IPv6. Logically, I should be getting a connection refused or timeout since the ports are open and not blocked by iptables, and there’s nothing listening on them.

I only have an A record assigned for my host/domain for firezone and I don’t have an IPv6 address assigned to the hostbon my vps console (they used to provide an IPv4 and ipv6 public IP, but only option is an IPv4 now). Without an AAAA record, there shouldn’t be any way for it to route even if I was getting a public dynamic assigned.

I took a short look and couldn’t immediately find any cause. I normally don’t post things until I’ve exhausted all my own efforts, but I’ve had a real busy week and this weekend will be the same, so I’m hoping it’s acceptable for me to post this here and take a chance that maybe someone else has encountered it or someone knows the cause off the top of their head.

When I had this problem with the first install, I had initially attempted the docker compose up -d method first with an .env file. When I had the issue, I rm’d the containers, rmi’d the images, autopurge’d docker-ce, rm -rf’d /opt/containers and /var/lib/docker, var/lib/containerd to be sure I was clean, then reinstalled docker-ce. Same issue. I’m an EL Linux guy by preference so if it runs on fedora downstreams that would be my preference anyway.

I thought about just rcloneing it over from my Kamatera host, too. My only experience with caddy is from automated installs via Dockers with no manual config needed. I always use nginx when setting up manual reverse proxies. I’ll actually probably just reimage the vps with CentOS 7 or alma 8 and try that, but I’m still curious about this issue. Thanks in advance!

The 502 must be coming from caddy. If not, there’s another proxy in front of your server. If caddy is serving a 502 then firezone service is probably down. Check the logs from that container and post here.

thanks for the reply. So apparently firewalld got enabled (maybe when i installed fail2ban for my ssh port) and that was dropping the packets. so all is good there and with caddy and the front end. i don’t know what was causing it on the ubuntu install though. they do have cloud console firewall policies but its set correctly, with 80/443 and my ssh port tcp open and 51280 udp open and i didn’t change it between images. oh well.

and just now i couldn’t get a handshake to occur… then i realized i had 2 digits in the udp port number transposed! oops. corrected it and now everything is working great!