OPNsense may be overkill for this, but I wanted to spin up a DNS server that didn’t rely on my home network being up 24/7, and I also was curious to see if I could get OPNsense to work on a cloud VPS. So I tried it out!
I’m writing this about a week after the fact, so it will be less detailed than my typical configuration posts, but it was a fun experience and I wanted to document what I remember.
The struggle was really how to configure OPNsense. In my experience, many of these specific operating systems - OPNsense, TrueNAS, OpenMediaVault, Proxmox (to a lesser extent) - really put the emphasis on the web GUI, and the CLI is an afterthought. I don’t know enough to really be coherent about this topic, but I think with OPNsense it has to do with how the config files are stored. It’s not enough to just know how the FreeBSD networking stack works; you’d need to edit a bunch of OPNsense-specific configuration files by hand, which the GUI generally will validate before writing to the config file.
I’ll mostly brush over the actual install, as most of it has escaped me. Suffice it to say it was easier than I expected. I do remember that to get the custom ISO, I had to download it, unzip it, and then upload it to my public webserver so that I could download it in an ISO format directly - Vultr didn’t like the fact that it was a .bz2 file. After that, it was a fairly straightforward process of loading it up and going through the TUI installer in the console.
Anyway, typically on a home LAN setup, installing OPNsense on a proper firewall, you have at least two ports. One will be the WAN port, connected to your modem; the other will be the LAN port, connected to your switch or WAP (or PC I suppose). The thing about installing it in the cloud is that you get one port, the public IPv4. If you mark that as your WAN port (which it should be, at least eventually), you won’t be able to access the web GUI (which is, ultimately, good). But you have to go through the web GUI to get any sort of configuration done. Sure, I’ve got access to the shell via a console, but 1) FreeBSD is tricky to a BSD noob like me and 2) OPNsense’s aforementioned GUI-preferred configuration. You can set some basic options via the CLI menu, but honestly not much. After locking down the web GUI - I had to turn it off with some command I found buried on the OPNsense forums somewhere - I struggled with trying to get the SSH server up and running via the console for like an hour.
Eventually I just gave up - set a sensibly secure password, started the web GUI, logged in via the public IP, set up 2FA as quickly as I could, and then proceeded to configure.
After I got Tailscale installed for a secondary interface, my eventual configuration ended up being this:
- Public IP / interface treated as the WAN port, TAIL interface treated as the LAN port
- Web GUI only accessible via the TAIL interface
- Unbound DNS running on the TAIL interface
- Certificate for the GUI generated
- In the Tailscale admin panel, set the new OPNsense machine as your preferred DNS
That’s pretty much it. Nothing fancy with NAT-PMP or hybrid outbound NAT since this isn’t running on the LAN.
I will say I do have the odd drop, where I have to disconnect from Tailscale then reconnect, but it hasn’t been annoying enough yet to really do anything about, and I’m not sure where to start troubleshooting. It’s not consistent enough to establish a pattern, and this happened before, too, so it isn’t a unique to the cloud machine issue. I’ll probably end up following up on this, though.
EOF