Outbound works out of the box: guests are NAT'd through their host and reach the internet like any process on it. Inbound is deliberately minimal: guests live on private per-host bridges, and the only built-in way in is the SSH jump gate.
To serve traffic from a VM, or to reach one directly from another network, install Tailscale (or WireGuard) inside it—it is a normal Linux machine. A public gateway is on the roadmap.
No. The SSH jump gate authenticates every connection against your tenant's CA. A published port has nothing in front of it: whoever can reach the host on that port reaches the service, exactly as if the service were running on the host itself.
That is the LAN trust posture, deliberately. The listener binds every interface on the host, IPv4 only. Publish what you are content to serve to everything that can reach it; put anything else behind the gate, or behind the service's own authentication.
Docker. Installing (or starting) Docker on a host sets the kernel's iptables
FORWARD policy to drop, which silently discards the guests' NAT'd traffic —
the agent's own forwarding and masquerade rules are still in place, and a
drop in any chain wins. The symptoms are exactly this shape: the guest pings
its gateway, the jump gate still works (that path is tunnelled, not
forwarded), but DNS and everything outbound time out.
Docker reserves the DOCKER-USER chain for the host admin. Allow the eitri
bridge through it:
sudo iptables -I DOCKER-USER -i eitri0 -j ACCEPT
sudo iptables -I DOCKER-USER -o eitri0 -j ACCEPT
Docker re-creates its rules on every daemon start, so persist these (e.g.
iptables-persistent, or a systemd unit ordered after docker.service) —
a plain one-off insert is gone after the next reboot.