NAT broken on initial run?

I just set up a simple server on a VM and was trying it out. Setup was a breeze, I installed it on my server and it was up and running quickly. Getting the config into my test devices (A Macbook and an Android phone, running the standard Wireguard UIs) was similarly easy. Access to the hosts on the remote local network worked, but while connected, connectivity to the wider network dropped. I tried a couple things, but ultimately - I rebooted, and it worked. :man_shrugging:

Hey @GauntletWizard

Thanks for the report! Yeah we’ve seen some weirdness with VMs.

May I ask for a little more information about what your VM environment is like?

  • What version of Firezone are you running?
  • What VM software you’re using (Virtualbox?)
  • What kind of network adapter you’ve assigned the VM? (NAT, bridge, etc)
  • Any other firewall rules active on the VM?

I have a couple ideas on what it could be but haven’t had enough data points to be able to reproduce locally. My first thoughts would be that either masquerading didn’t get turned on or ip forwarding wasn’t enabled after being set in sysctl.conf by the configure script and needed a reboot to be activated.

Thanks for your help!

0.1.19; Latest from your releases page.
VM was on Digitalocean. Ubuntu 20.04. No specific configuration, though it’s worth noting that Digitalocean automatically provisions two network adapters and three IPs; One public IP, and two management IPs, one on the public network adapter and another on a private network adapter. Each are configured for both v4 and v6.
The only other thing I can think of that was affecting firewall rules beyond the default installation was Docker.

I checked that IP Forwarding was on, did not see anything unusual in the IPTables rules, but I didn’t check very long either.

Thanks for the info! I’ll spin up a VM on DigitalOcean and see if I can replicate the issue.

So I did spin up a fresh Digital Ocean droplet with Ubuntu 20.04 and two interfaces: eth0 and eth1. The public IP was assigned to the eth0 adapter and the private IP assigned to eth1.

I then installed Firezone 0.1.19, ran firezone-ctl reconfigure, and left the default settings (my hostname was already my FDQN). I then installed Docker CE using the instructions here: Install Docker Engine on Ubuntu | Docker Documentation

After connecting with the standard WireGuard client on macOS, I was able to access the internet fine, and ping the eth1 private address as well.

My bet is something was funky with your iptables rules and got fixed after a reboot. Firezone uses nftables which may conflict with the iptables rules Docker uses. You can view the nftables rules Firezone creates with /opt/firezone/embedded/sbin/nft list ruleset.

I did discover a bug where the Device configuration’s Endpoint is not shown correctly and opened an issue for that here: Endpoint is misconfigured when multiple IP addresses are present on the server · Issue #330 · firezone/firezone · GitHub