I’ve just released Gatekeeper 1.6.0. It’s a single executable that turns any Linux machine into a home gateway. Now with realtime traffic graphs, LAN autoconfiguration, full cone NAT and better looks.

It sounds like it's just an actual router, but I can't find any information if it actually can route any traffic.

Either way it seems like just setting up a real router with something like opnsense would be easier and more feature complete.

My questions exactly. Furthermore ISP router typically also have wifi, so wifi clients on that won't be even visible to this... please clarify is this is supposed to be yet another openwrt / router solution or what you're doing here... BUT I fucking love the UI :)

Read the documentation.

"Generally speaking Gatekeeper needs to sit between your LAN network and the internet. It can either completely replace the router provided by ISP, or sit between the ISP router and your LAN network."

In terms of types of users I agree with what you're saying but I also think that there are some shades of gray in between. There are people who love to tinker and would manually configure every service on their router, compiling everything from scratch, reading manuals, understanding how things work (they'll probably choose dnsmasq, systemd-networkd, graphana over Gatekeeper). In my experience this approach is pretty exciting for the first couple of years & then gradually becomes more and more troublesome. I think Gatekeeper's target audience are the people who would like to take ownership of their network (and have some theoretical understanding) but don't want to fully dive into the rabbit's hole and configure everything manually.

In terms of problem solved: I agree that Gatekeeper solves a similar problem. I think it's different from those projects because it tightly integrates all of the home gateway functions. While this goes against the Unix philosophy, I think it creates some advantages:

1. Possibility of cross-cutting features.
2. Better performance (lower disk usage, lower RAM usage, lower CPU load).
3. Seamless integration.

Functions of home routers are conventionally spread out over many components (kernel & a bunch of independently developed userspace tools) which talk to each other. Whenever we want to create a cross-cutting feature (for example live traffic graphs) we must coordinate work between many components. We need to create kernel APIs to notify userspace apps about new traffic, create userspace apps to maintain a record of this traffic & a web interface to display it. It's difficult organizationally. In a monolith, where all code is in one place, such cross-cutting features can be developed with less friction.

From the performance point the conventional approach is also less efficient. The tools must talk to each other. Quite often through files (logs & databases). It's wearing down SSDs & causing CPU load that could be otherwise avoided. A tightly integrated monolith needs to write files only periodically (if ever) - because all data can be exchanged through RAM.

From the complexity standpoint the conventional approach is also not great because each of the tools needs to know how to talk with the others. This is usually done by administrator, configuring every service according to its manual. When everything is built together as a monolith, things can "just work" and no configuration is necessary.

Edit: Please don't be offended by my verbosity. From your question I see that you know this stuff already but I'm also answering to the fresh "selfhosted" audience :)

Yeah, if I wanted a router, I'd just use opnsense. This feels like it's in that weird middle ground between doing one thing well and being a swiss army knife, where it does a lot of things, but when there's something else you need it's not there and you can't easily add it.

Unfortunately explicit, stable port redirections is something that is still missing. I'll have to implemnt them (with a proper UI) eventually because under the hood they are also a necessary building block for other features. At the moment there are only "ephemeral" port redirects which may be sufficient for you. They are created automatically when a LAN machine sends out a packet from some source port. That port is then implicitly forwarded back to that machine. This is actually a part of the "Full Cone NAT" thing.

This can be triggered manually for example with something like:

nc -p 80 1.2.3.4 1234 # send a dummy TCP packet from port 80

Ephemeral port redirections don't expire but can be taken over if another LAN host also uses the same source port for outgoing traffic. This may happen randomly because source ports are usually picked at random by the OS. Generally ports below ~32k should be fairly stable because Linux doesn't use those by default (I don't know about Windows). Redirecting ports below 1024 should be even more stable because they're reserved for specific well-known services.

I understand that your goal is to learn something new.

In my opinion ambitious, goal-oriented projects may either backfire or turn you into a legend. There will be many issues along the way and while they are all ultimately solvable, the difficulty may kill your motivation. Alternatively, if you manage to power through, then after some period of learning (potentially years) and keeping the fixation on specific problem you might emerge as a domain expert. Either way it's a risky bet.

If I might leave some advice for newcomers it would be to learn how to perform some simple tasks & focus on creating projects that you're confident can be built from things you already know. Over time you'll increase the repertoire of tasks that you can perform, and therefore be able to build increasingly advanced projects.

Thank you for the feedback! I have to admit I wasn't aware of how important port forwarding is. Stepping back I guess I'll need a better way of gauging how important specific features are to people. I'll have to think about this a little bit more...

Your question about security is something that I think about a lot. I don't think of LAN & internet as significantly different in terms of security. I also worry about potentially malicious LAN devices attempting to exploit local DNS, DHCP or web UI. I've profesionally worked on anti-malware and I've seen malware preloaded on new phones by factory workers & resellers, suspiciously exploitable flaws in stock firmware (which I guess was a backdoor with plausible deniability), fake monetization SDKs that are actually botnets (so application developers have been unknowingly attaching bots to their apps). There is also the problem of somebody gaining the physical access to your LAN network (for example by connecting a prepared device to an ethernet port for a couple of seconds). While those things may seem far fetched and commercial routers ignore them, I'd like to do something better here.

In terms of preventing C++ footguns, I'm relying on compilation arguments (-fstack-protector, -D_FORTIFY_SOURCE=2), safe abstractions (for example std::unique_ptr, std::span, std::array...), readability (single-threaded, avoiding advanced primitives or external libraries) & patience (I think that time pressure is the biggest source of bugs).

In terms of protocol level security, so far I've been able to secure the update path (so that MITM attackers can't inject malicious code). The web UI is a big problem for me because to do any privileged operations I'll have to authenticate the user first. Firstly I'm not exactly sure how to even do that. Password seems like the best option but I'm still trying to think of something better. There is this new WebAuthn thing which I'll have to look into. Second issue with web UI is that I need to protect the authentication channel. This means that local web UI will need TLS. And this in turn means that I'll have to somehow obtain a TLS cert somehow. Self-signed certs produce nasty security warnings. Obtaining one from LetsEncrypt seems easy - assuming the router has public IP (which may not always be the case). But even if I obtain a LetsEncrypt cert, any LAN device can do the same thing, so the whole TLS can still be MITM-ed. It would be really great if web browsers could "just establish encrypted channel" and not show any security warnings along the way...