A few months ago I had one goal: get around my university's wifi restrictions so I could play Roblox at university. What actually happened is I ended up learning Terraform, Ansible, and a decent chunk of cloud networking, and came out the other side with a self-hosted VPN running on Oracle Cloud.
This is the writeup of how that happened, what broke along the way, and what I'd tell someone trying to build the same thing.
Why a VPN, and why Oracle Cloud
Once I realized a VPN would solve my actual problem, I figured I might as well not just download a random VPN app and call it a day. I wanted to understand how one actually works under the hood, so I decided to build and host my own.
I picked Oracle Cloud Infrastructure mainly because of its Always Free tier, which gives you a real VM to work with at no cost, which mattered a lot as a student. Worth flagging early though: "Always Free" does not mean "always available." Oracle's free ARM VMs can run out of capacity in certain regions, so if you're trying this yourself, don't be surprised if your first provisioning attempt fails and you need to retry or switch shapes.
Provisioning with Terraform
I used Terraform to provision the actual infrastructure rather than clicking through the Oracle Cloud console manually. This meant defining:
- A private Virtual Cloud Network (VCN)
- Firewall rules that only allow traffic on the SSH port and the WireGuard port, nothing else
- The VM itself
The appeal of doing this with Terraform instead of the console is that the entire setup is defined as code. If I ever need to tear it down and rebuild it, or replicate it somewhere else, it's a matter of running the same configuration again instead of remembering which buttons I clicked six months ago.
Configuring WireGuard with Ansible
Once the infrastructure existed, I needed WireGuard actually installed and configured on the server. This is where Ansible came in, handling the server-side setup so I wasn't SSH-ing in and manually editing config files every time something changed.
This is also where I hit the most annoying bug of the entire project.
WireGuard setup involves generating a public/private key pair. My first version of the Ansible playbook generated these keys as part of the automated run, but I didn't account for what happens on a second run. The key generation step would fire again, silently overwrite the existing private key, and corrupt the whole setup, without throwing an obvious error that pointed to what had gone wrong.
It took a while to trace the failure back to that step. The fix was to make key generation idempotent: check if a key already exists before generating a new one, instead of assuming every run starts from a blank slate. It was a good reminder that automation doesn't remove the possibility of mistakes, it just changes what kind of mistakes are possible. A bug in a playbook can silently corrupt data just as easily as a manual slip can, the difference is that automation does it faster and more consistently.
Making it a real project, not just a working VPN
Getting a working VPN connection running was the milestone I originally cared about, but I kept going and turned it into something closer to an actual infrastructure project:
- CI/CD for infrastructure changes: instead of running Terraform commands from my own machine whenever I wanted to change something, changes now go through a pipeline that reviews and applies them, closer to how this would work on a real team.
- Encrypted secrets management: credentials and keys aren't sitting around in plaintext anywhere in the repo.
- A documented threat model: writing out what I was actually protecting against, and what was explicitly out of scope, forced me to think about the setup as a security-conscious system, not just "a thing that works."
What I'd tell someone starting this
If you're thinking about building something similar, a few honest takeaways:
- Start with the thing you actually want to solve, even if it's small or silly. Mine was wifi restrictions. That's a fine reason to start.
- Expect the free-tier infrastructure to be flaky sometimes. Build in the assumption that provisioning might fail and need a retry.
- Automation bugs are still bugs. Test your playbooks against being run more than once, not just the first clean run.
- Once the core thing works, look for the parts that would make it resemble real infrastructure work: how are changes reviewed, how are secrets handled, what happens if something goes wrong. Those are the parts that turn a weekend project into something worth writing about.
If you want to see the actual code, it's on my GitHub: github.com/ailanoor13/Oracle-VPN-Project
Happy to answer questions if anyone's trying to build something similar or gets stuck on the same key-generation bug I did.
Top comments (0)