About FortiTales
The short answer
I am Lucas, and I spend my working life designing and defending network security architectures, mostly Fortinet, mostly for organisations large enough that a bad design decision becomes someone's very long week. FortiTales is my notebook, opened to the public.
Why this blog exists
For years I solved the same kinds of problems, fixed the same obscure bugs, and rebuilt the same understanding from scratch every time I had not touched a feature in six months. I also read other people's blogs constantly, the ones written by engineers who took the time to write down what they found, and I lost count of the hours they saved me. At some point the debt felt large enough that I had to start paying it back.
So this is the blog I wish I had found when I was searching. Two kinds of posts live here:
The deep dives are what the title promises minus the storytelling: a problem, a lab, the actual CLI, the actual debug output, and an honest account of what worked, what did not, and what I am still unsure about. If a post claims something works, I tried it. If I could not verify something, I say so. I would rather publish a smaller true thing than a larger confident one.
The FortiTales proper are the longer pieces, the ones that start as a configuration question and turn out to be about something bigger: where your fault domains really are, what you are actually trusting when you trust a vendor, why an architecture that works in the lab betrays you at scale. Fewer commands, more argument. The blog was called FortiTales for a while before it had any tales in it. I am fixing that.
Who I am, professionally
I work as a presales and security engineer focused on Fortinet, which in practice means I live at the intersection of three things: designing architectures that have to survive contact with a real customer network, writing the documents that explain and defend those designs, and doing the hands-on engineering when the design meets reality and reality wins the first round. SASE, SD-WAN, secure remote access, segmentation, the management and logging stack that ties it together: that is the territory.
The presales seat gives me an unusual vantage point for a technical blogger. I see a lot of different networks, a lot of different ways the same product gets deployed well or badly, and a lot of the gap between what a datasheet promises and what an engineer experiences at 02:00. Much of what I write here comes from that gap.
I hold a few NSE 7 certifications and I am perpetually studying for the next one, because this field does not hold still and neither should anyone working in it. (NSE 8 teaser)
How I write
A few principles, so you know what you are getting:
I cite my sources and I mark my uncertainty. When I am reporting lab-verified fact, you will see the output. When I am sharing field experience or opinion, I will say so plainly. The two are different and I try never to blur them.
I am honest about vendors, including the one I know best. I sell and trust Fortinet, and I will still tell you where the sharp edges are, because a blog that only repeats marketing is worth exactly nothing to the person reading it at 2 AM.
I keep customers anonymous, always. Any story here is abstracted beyond recognition. The lesson is the point; the logo never is.
Out in the wild
I do not only write about this stuff, I show up for it. I take part in networking and industry events whenever I can, because the best conversations in this field still happen standing up, with a coffee or a p*rnstar martini, next to someone who just solved the exact problem you are stuck on.
Last summer I was at Fortinet Xperts EMEA 2025 in Vienna, where I made it to the regional finals of the UFC tournament and then, in the grand tradition of overconfident engineers everywhere, lost spectacularly. I have made my peace with it. Mostly. There is a photo, which I am including precisely because it is not a victory lap.
If you are at one of these events and recognise the blog, come say hello. That is genuinely the best outcome this site can have.
Off the clock
Outside of work I travel as much as I can, mostly to experience life rather than to tick off places. I care a lot about the people around me, about good food, and about the kind of evening where a conversation goes somewhere you did not plan. I like meeting people from completely different professions and hearing their stories, because that, in the end, is what humans are: a collection of stories worth listening to. A surprising amount of how I think about engineering comes from conversations that had nothing to do with engineering.
Say hello
The best posts here started as someone else's question or correction, so please send both. You can find me on LinkedIn. If something on this blog saved you an hour, that is the whole point, and I would genuinely like to know.