Foundations: Networking
This page is here to explain the networking concepts behind obacht for everyone who is new to the topic. We start with how a home network is addressed, then how the public internet routes traffic around, and why hosting a service from home is way harder than it looks in the first place. After that we get into what obacht actually does to make self-hosting work — without manual port forwarding, dynamic DNS or exposing your device to the open internet.
No prior networking knowledge is needed here. If you already know how NAT and public IP addresses work, just skip ahead to What obacht does.
1. Your local network
When you plug a device into your home network — over Ethernet or Wi-Fi — your
router gives it a local IP address. This address only has a meaning inside of
your home. Typical local addresses look something like 192.168.1.42,
192.168.0.15 or 10.0.0.7.
These ranges are reserved for private networks and are never used directly on the
public internet. Every household uses the same ranges, so the 192.168.1.42 in
your home is a completely different machine than the 192.168.1.42 in your
neighbours home. The address is only unique inside of your own network, nowhere
else.
Your router hands out these addresses and keeps a small table of which device has got which address. Devices on the same local network can talk to each other directly — your laptop can reach your Raspberry Pi at its local IP — but nothing from the outside can use that address to reach in.
2. The public internet and global IP addresses
The public internet uses a different set of addresses, called global (or
public) IP addresses. Unlike the private ones, a global address is unique
across the whole internet at any given moment. So if a website's server has the
address 203.0.113.5, there is exactly one machine on the internet which is
reachable at that address.
Your internet provider (ISP) assigns a global address to your connection. In the simplest case that single global address represents your whole household on the public internet. Every request that leaves your home — loading a web page, sending a mail — appears to the outside world as coming from that one global address.
The difference between the two kinds of address is more or less the root of everything that follows:
| Address type | Example | Unique where | Reachable from the internet |
|---|---|---|---|
| Local / private | 192.168.1.42 | Only inside your network | No |
| Global / public | 203.0.113.5 | Across the whole internet | Yes (in principle) |
3. NAT: how many devices share one address
Usually you have many devices at home but only one global IP address. The mechanism that lets them all share it is called NAT (Network Address Translation), and it runs on your router.
So when your laptop (local address 192.168.1.42) requests a web page, the router
rewrites the outgoing request so that it appears to come from your single global
address. It notes down, in a translation table, that "this particular outgoing
connection belongs to 192.168.1.42". When the reply comes back to the global
address, the router looks up the table again and forwards the reply to the right
local device.
NAT works really well for traffic that starts from inside your network. The router always has a table entry to match the reply to the device which asked for it.
The problem starts with traffic that starts from outside. If someone on the internet sends a request to your global address out of nowhere, the router has no table entry telling it which internal device the request is meant for. By default it has nowhere to send it, so it just drops the request. This is exactly why home networks are safe by default — unsolicited inbound traffic simply does not get through — but it is also the reason why hosting a service from home is so difficult.
4. Why hosting from home is hard
To host a service — a website, a dashboard, a small app — something on the public internet has to be able to start a connection to you. And that is exactly the inbound direction NAT blocks. On top of that there are two more realities at home which make it even harder.
Dynamic IP addresses
Most home connections do not get a fixed global address. The ISP assigns one from
a pool and may change it again — after a reconnect, a router reboot or on a fixed
schedule. A service is normally reached through a domain name (for example
example.com), which is mapped to an IP address in the DNS system. So if your
global address keeps changing, this mapping goes stale and visitors get send to
the wrong place, or nowhere at all.
Carrier-grade NAT (CGNAT)
There are way fewer IPv4 global addresses than there are internet connections, so many ISPs don't give each household its own global address anymore. Instead they run a second, bigger layer of NAT inside of their own network — carrier-grade NAT — where many customers share one single global address.
So under CGNAT you don't control the address that faces the internet at all, your provider does, and it is shared with strangers. Inbound connection tricks that depend on having your own global address just don't work here, because there is no public address which belongs only to you.
5. How a data center is different
A data center is built for the exact opposite situation. A server in there gets a static global IP address — one that is fixed and belongs to that server alone. It is not behind NAT, and nothing changes the address away under its feet.
Because the address is global, fixed and unshared, a domain name can be pointed at it once and stays valid. Anyone on the internet can start a connection to it, which is exactly what a public service needs. So this is the reason why hosting "in the cloud" is so straightforward: the hard networking problems were already solved by giving the server a permanent, reachable address.
| Home connection | Data center server | |
|---|---|---|
| Global address | Often shared (CGNAT) | Dedicated to the server |
| Address stability | Often dynamic | Static |
| Inbound connections | Blocked by NAT | Allowed |
| Pointing a domain at it | Unreliable | Reliable |
The trade-off is, that a data center server is, by design, exposed to the open internet and managed as part of a big shared facility. Your device at home is not — and for a lot of people that is exactly the point of self-hosting.
6. The traditional workarounds
People have been self-hosting from home for a long time using a few techniques, and each of them adds some manual setup and has its limits:
Port forwarding tells your router to send inbound traffic that arrives on a specific port straight to one internal device, which creates the table entry NAT is otherwise missing. It requires changing router settings, it exposes that device directly to the internet, and it does not work at all under CGNAT.
Dynamic DNS (DynDNS) works around the changing global address by running a small program which notices when your address changes and updates the DNS record to match. It solves the dynamic-IP problem but not NAT or CGNAT, and it still leaves your device exposed once the traffic does get through.
And on top of those, you would normally also have to get and renew a TLS certificate yourself so that the service is reachable over HTTPS instead of plain, unencrypted HTTP.
So in the end you have this whole chain of moving parts — port forwarding, dynamic DNS, certificate management — which all have to be set up correctly and kept running. obacht exists to remove exactly this chain.
7. What obacht does
obacht avoids the whole inbound problem by simply never relying on an inbound connection to your device. Instead, your device starts an outbound connection to obacht and keeps it open.
Outbound connections are exactly the kind that NAT, CGNAT and dynamic addresses all allow without any configuration — it is the same direction your laptop uses to load a web page. And because the connection is started from your side, none of the home-network obstacles apply anymore. There is nothing to forward, no router setting to change, and CGNAT is not in the way any longer.
The obacht network
This always-on outbound connection forms what we call the obacht network: a private, encrypted tunnel between your device and obacht's central gateway. Technically this tunnel is built with WireGuard, a modern and well-audited VPN protocol — but throughout this documentation we refer to it just by its product name, the obacht network.
Once a device has joined the obacht network, it has a stable internal address on that private network. This address never changes, even though your home's global address might. The gateway can now reach your device through the tunnel anytime, because the tunnel is already open — without ever having made an inbound connection through your router.
A router, not a data center
When a visitor opens your service, their request arrives at obacht's gateway, and the gateway forwards it through the existing tunnel to your device. The device produces the response and sends it back the same way.
The important point here is what the gateway actually is. It behaves like an ISP or a router that just passes traffic through — not like a data center which stores or runs your service. Your service does not live on obacht's servers, it lives on your device at home. The gateway only routes the packets between the visitor and your device.
And this distinction also shapes the privacy side. TLS encryption is terminated on your device, not on the gateway. The certificate for your domain is obtained and held by your device, and the encrypted connection runs from the visitor all the way down to it. So the traffic passing through obacht's gateway stays encrypted end to end, which means obacht routes your traffic without being able to read its contents — pretty much like an ISP carrying packets it can not open.
8. Ports and domains
A single device can run several services at the same time — for example a website,
a dashboard and a database tool. Each service listens on its own port, which is
basically a numbered channel on the device. A port is kind of like an apartment
number at a building address: the address gets you to the device, and the port
number gets you to the specific service inside of it. Web services commonly use
ports like 8080 or 3000 internally.
You should not have to know or type any port numbers to reach a service, so obacht maps domains to services per device. When you attach a domain to a device, you choose which internal port (which service) that domain should reach. From then on it goes like this:
- A visitor opens
https://app.example.com. - The request travels to the obacht gateway and through the obacht network tunnel to your device.
- On the device, obacht routes the request to the port the domain is bound to.
- The service on that port answers, and the encrypted response travels back to the visitor.
You can bind several domains on the same device, each one pointed at a different port, so a single Raspberry Pi can serve multiple independent sites. Setting up a certificate, verifying the DNS and binding a domain to a service is all handled through the dashboard — have a look at Templates & Domains for the step-by-step flow.
9. The mental model
So putting it all together:
- Your home network gives devices private addresses which the internet can not reach directly.
- NAT lets those devices share one public address for outbound traffic, but blocks unsolicited inbound traffic.
- CGNAT and dynamic addresses make traditional home hosting unreliable or even impossible, because you don't have a stable, dedicated public address.
- A data center solves this with a static, dedicated, reachable address — at the cost of exposure and of running your service on someone else's infrastructure.
- obacht reaches the same result from home by letting your device open an outbound tunnel — the obacht network — so no inbound connection, port forwarding or dynamic DNS is ever needed.
- The obacht gateway acts like a router that passes encrypted traffic through, not like a host of your service. TLS is terminated on your device, so your service stays yours and your traffic stays private.
- Domains map to ports per device, so one single device can serve several services under different domain names.
With this model self-hosting from home more or less comes down to plugging in a device and attaching a domain — the addressing, the tunnelling and the certificate work all happens for you.