Nice work! This was the reason I moved my homelab stack to k8s with Cilium.

edit: this is way funnier with the original title: Your containers are leaking (and how to plug the holes)

Very interesting, thank you for the work and sharing it. When I have some time I’ll have a look if I can use this with my rootless podman setup.

I’ve just use iptables rules which default block all docker containers any network access. I assign static ranges to those I permit access, though. It does occasionally throw me off when adding new services and not understanding why sometimes they don’t work right away, but I prefer it that way.

I found an 8-year-old project on GitHub that had similar ideas but is unmaintained and not quite what I needed.

In the back on my mind I was thinking ‘I could have sworn I had seen Dockwell somewhere before’.

It’s one night of work, so take that for what it is

The honesty is refreshing.

It’s interesting for sure. I was intrigued when I saw OG Dockwell, but like you, saw it was quite stale.

This blog post comes to me at an interesting time, for I’ve been gathering info to rebuild my router using FreeBSD. Specifically, I bought a hard-copy of The Book Of PF, 4th Edition, for configuring PF for routing and firewalling. Like with all good firewalls, the PF rulesets start with blocking all traffic. But unlike the VyOS-based rules used by my outgoing Ubiquiti router, PF does not implicitly include rules for common use-cases, such as enabling hairpin NAT for Legacy IP. Nor does the syntax assume that rules are only for inbound, as the shortest syntax will actually apply a rule in both directions on every interface.

To that end, one of the tenants for configuring a PF firewall is to also filter outbound traffic, as a matter of: 1) asserting control over the network, and 2) implementing the principle of least privilege. I can reasonably accept that my home’s guest WiFi network should be fairly free flowing for outbound traffic, but that shouldn’t apply to my IoT VLAN. Quite frankly, my IoT VLAN only allows outbound connections to four specific NTP servers hosted by ntp.org, because my thermostat has a badly-designed real-time clock and I refuse to allow network access for devices that historically never needed it.

Before containers, firewalls implemented the DMZ idea, where any host that runs an externally-accessible service would be within the DMZ, to prevent infiltrating the broader LAN if something goes wrong. Your solution achieves a sort-of DMZ, but does it at the Docker host. Whereas a true DMZ would segment the rest of your network off, so as to further reduce risk, since iptables is the only line of defense.

That said, zooming out, this caught my attention:

The breaking point came when I wanted to host Gemini FastAPI, a project that wraps Google’s internal Gemini API into an OpenAI-compatible interface, useful for using your Gemini Pro subscription outside Google’s walled garden. The catch: it needs your browser cookies, which means full access to your Google account.

The very premise of Gemini FastAPI seems flawed to me, if it’s trying to create a wrapper when Google clearly does not want that to exist. The challenges that you observed, such as the brittleness of IP allowlists, would suggest to me that the overall endeavor is going to be brittle, by Google’s design.

To be clear, that doesn’t mean you shouldn’t pursue this, in the same way that yt-dlp exists for the legitimate use for accessing YouTube. But what both yt-dlp and Gemini FastAPI will never escape is that they only exist because Google hasn’t cracked down on it further. When every indication is showing that this is the road with even more trouble beyond the next curve, is this what you want to invest time and effort into? There are other platforms and protocols that replace YouTube, or at least minimize one’s dependency on a clearly antagonistic host.

At bottom, I think the question is whether connecting to Gemini is really worth all of this trouble, when they evidently don’t want you to do this, and it adds yet another dependency upon Google. Even if you believe Google is 100% benevolent and their lack of a built-in support for using Gemini externally is just a minor oversight, you will have to pick which services you will base your own infrastructure upon. This is, after all, c/selfhosted.

Also, an interesting thing is using systemd-resolved for DNS-over-TLS or hosts blocking.

I configure it to my nextdns account and podman uses it for all requests, so I can block dns records from anywhere and use some tracking, mining, NSA, minimum domain age, etc, blocklists.

Very minor note. The blog mentions that the attacker was unlikely to have gained anything by Monero mining. However the Monero page itself says:

Monero can be mined by both CPUs and GPUs, but the former is much more efficient.

https://www.getmonero.org/get-started/mining/

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:

[Thread #282 for this comm, first seen 10th May 2026, 02:00] [FAQ] [Full list] [Contact] [Source code]