Bringing a FortiGate lab firewall online (without chaos)
A walkthrough of how I set up a FortiGate in a lab environment, from cabling and basic access to initial policies and logging.
Blog
Labs, lessons, and things I’m thinking about.
These posts are part lab notebook, part “how I’d explain this to a busy engineering manager or CISO.” Everything here is safe to share, but still grounded in real technology.
Latest posts
How I built and self-hosted this website
From a blank folder on my Mac to a working site ready for Ubuntu hosting — and why I wanted to do it the hard way on purpose.
Packets, people, and business: why security is a team sport
Thoughts on moving from startups and sales into network security, and why technical work only lands if it makes sense to the business.
Bringing a FortiGate lab firewall online (without chaos)
One of the first things I wanted in my home lab was a proper firewall. Since I work at Fortinet, a FortiGate was the obvious choice — but I treated this like any good lab: separate from production, documented, and safe to experiment with.
My goal for this setup was simple: get a clean FortiGate online, configure basic WAN and LAN interfaces, create a sensible first security policy, and start sending useful logs somewhere I could actually read them. Nothing fancy, just a solid foundation.
At a high level, the process looked like this:
- Rack and cable the FortiGate into a lab switch and WAN connection
- Perform initial login, change defaults, and register the appliance
- Configure basic interfaces (internal LAN, WAN/uplink) with clear IP addressing and documentation
- Create a simple “inside to internet” policy with NAT and basic security profiles
- Enable logging so I could actually see what traffic was being allowed or blocked
A couple of things became obvious very quickly. First, naming matters. Calling an interface “LAN-Test-10.10.10.0/24” is a lot more helpful than “internal1” three weeks later when you’re trying to remember what that subnet was for.
Second, even in a lab, it’s worth thinking about the story your logs tell. Sending logs to a central place — even if it’s just a lightweight collector or a simple dashboard — makes it much easier to answer basic questions like, “What changed?” or “Is this just one noisy host?”
The main lesson for me: treat your lab like a mini version of production. The habits you build there (naming, documenting, logging) are the ones you’ll carry into real environments where the stakes are higher.
How I built and self-hosted this website
This site started as a simple idea: I wanted a place that represented me as a network and security engineer, not just another social profile. Instead of using a site builder, I decided to build it from scratch with HTML, CSS, and a tiny bit of JavaScript.
I develop on my Mac using VS Code, keeping the files in a project folder and running a simple Python HTTP server for local testing. That gives me quick reloads without any heavy tooling, and it forces me to understand what the browser is actually loading.
The structure is intentionally straightforward: a home page, an about page, a blog, and a resume. Each one is just a clean HTML file with shared styling and a consistent header. When I’m happy with changes, I can sync the project to an Ubuntu server, put Nginx in front of it, and expose it safely to the internet.
From a security perspective, I like that this setup is simple. Fewer moving parts means fewer places for vulnerabilities to hide. There’s no database, no dynamic code running requests, and no plugins to keep patched — just static files served by a hardened web server.
Could I have used a framework or a CMS? Sure. But for this stage of my journey, understanding the basics deeply matters more than shipping something “fancy.” When a future colleague or hiring manager looks at this, I want them to see that I know what’s happening under the hood, not just which template I picked.
Packets, people, and business: why security is a team sport
Before working as a network engineer, I spent time in startups and in sales roles. That experience permanently changed how I look at technology. It’s not enough for something to be “technically correct” if it doesn’t fit the business, the people running it, and the users depending on it.
In security and networking, it’s easy to focus on configs, logs, and diagrams. Those matter — a lot. But the most successful changes I’ve seen are the ones where everyone understands why we’re doing something, not just what is being deployed. That means taking time to translate risk and reliability into language that leadership can actually act on.
My business background helps me ask questions like: “What problem are we truly solving?”, “Who is impacted by this change?”, and “How will we know this made things better instead of more complicated?” Those questions are just as important as subnet masks and policy order.
Long term, I want to stay at that intersection: deep enough in the technology to be useful, but always aware that behind every packet there’s a person, a customer, or a team depending on us to get it right.