docs/faq.md

Ref: main v0.0.5   Size: 2.8 KiB   History

# FAQ

## How do VMs get network access?

Outbound works out of the box: guests are NAT'd through their host and reach
the internet like any process on it. That NIC is unconditional—the guest's
egress, its way to the other guests on that host, and where the SSH
[jump gate](connecting.md) meets it.

Inbound has two answers. The gate works from anywhere: it authenticates every
connection against your tenant's CA and tunnels you in. The other is to put the
VM on your own network—declare a bridge on a Linux host, name it to the agent
(`--host-network lan=br0`), pick that name at create. Your own DHCP server
addresses the guest's second NIC, and it is then a machine on the network:
every port, every device, nothing of eitri's in front of that NIC. The
[networking](networking.md) has the recipe.

For reach beyond that LAN it is still a normal Linux machine, so install
[Tailscale](https://tailscale.com) (or WireGuard) inside it. A public gateway
is on the [roadmap](../ROADMAP.md).

## Is an exposed port authenticated?

No. The SSH [jump gate](connecting.md) 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 socket 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.

A published UDP port is the same posture carried one step further. Nothing in
UDP proves where a datagram came from, so the host answers the address the
datagram claimed—someone else's, if that is what it said. A UDP exposure can
therefore be pointed at a third party, and a guest service that answers larger
than it is asked makes that worse. Publish UDP the way you would publish
anything else here: onto a network you are content to serve.

## VMs boot and SSH works, but have no outbound network—why?

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:

```sh
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.