AMvpn

A self-hosted WireGuard VPN built entirely by hand on Oracle Cloud's free tier. No managed services, no installer scripts doing the thinking for me. What started as a weekend project to avoid paying for a commercial VPN grew into a full security stack: DNS-level ad blocking, a live honeypot, and a custom monitoring dashboard.

Why Build It

A commercial VPN means someone else's client app, someone else's billing, and trusting someone else's abuse policy with your traffic. A self-hosted one is a weekend and a few dollars a month. I picked WireGuard over OpenVPN or IPSec because it's simpler and more modern, and Oracle Cloud's free tier because it's free forever, not a trial, with real bandwidth included.

I provisioned the VM and had WireGuard running the same day, and hit my first real incident before the day was out (more on that below).

What's Running

Tunnel: WireGuard, hand-configured
DNS: AdGuard Home, network-wide ad/tracker blocking
Perimeter: Port knocking + fail2ban, SSH invisible to scanners
Threat data: Honeypot with GeoIP data + Telegram alerts
Dashboard: Custom FastAPI backend, vanilla JS frontend
CVE tracking: CVE Watch page, refreshed daily by cron

AMvpn's admin dashboard showing system health, AdGuard blocking stats, and network peers — The dashboard mid-session. Public IP redacted, everything else is live.

Three Things Worth Knowing

Locked myself out on day one, and knew how to get back in

I moved SSH off the default port during the first hardening pass without opening the new port in the firewall first. Instant lockout, hours into the project. I got back in by spinning up an Oracle rescue VM, attaching the locked server's boot volume as a second disk, and fixing the firewall rules from there before reattaching it. Same day, and I still finished the rest of the hardening.

A week of logs, not a guess, behind "nothing happened"

I pulled a full week of logs (about 50,000 lines) and went through them instead of assuming things were fine. Tens of thousands of auth lines turned out to be scheduled jobs, not failed logins. Thousands of firewall drops traced back to known datacenter scanning ranges, not targeted activity. The port knock sequence held the entire week.

A real audit, and walking something back

I ran a Lynis baseline audit and worked through the findings: SSH and nginx hardening, kernel sysctl settings, and tighter permissions on sensitive configs. I also tried adding CrowdSec, hit a networking issue between Oracle Cloud and its central API, and pulled it back out. It wasn't worth the resources for what this box actually faces.

Amos Horne