# Warden Networking Troubleshooting

Use this file when Clawdie or `controlplane` cannot reach the network.

## Quick checks

### Bridge exists

```sh
ifconfig warden0
```

Expected:
- interface exists
- `inet 192.168.100.1`

### Jail exists

```sh
jls
jexec controlplane /bin/sh -c 'hostname && ifconfig'
```

Expected:
- jail `controlplane` running
- jail IP `192.168.100.100`

### Forwarding

```sh
sysctl net.inet.ip.forwarding
```

Expected:
- `net.inet.ip.forwarding: 1`

### pf state

```sh
pfctl -sn
pfctl -sr
```

Expected:
- NAT rule for `192.168.100.0/24`

## Common failure signatures

### Jail starts, but no outbound internet

Likely causes:
- missing `pf` NAT
- forwarding disabled
- wrong bridge/gateway assignment

Response order:
1. confirm `sysctl net.inet.ip.forwarding` is `1`
2. if not, set `gateway_enable="YES"` and `sysctl net.inet.ip.forwarding=1`
3. confirm the jail has a default route to `192.168.100.1`
4. then validate `pf` NAT

### `pfctl -sr` shows `block drop all` and no `warden0` rule

Likely cause:
- host firewall blocks jail traffic before NAT and DNS can work

Response:
- add:
  - `pass quick on warden0 inet from 192.168.100.0/24 to any keep state`

### `pfctl -sn` is empty

Likely cause:
- no NAT rules are loaded

Response:
- add:
  - `nat on vtnet0 from 192.168.100.0/24 to any -> (vtnet0)`

### Bastille creates jail, but `pfctl` complains about missing table

Likely cause:
- Bastille expects `pf` structures not yet present
- host firewall config is incomplete

Response:
- create and load the canonical Warden `pf` table and NAT rules first
- then retry Bastille stop/destroy or lifecycle operations
- do not treat this warning as proof that the jail itself is malformed

### Clawdie says jail not found

Likely causes:
- Bastille jail not created
- jail not started
- wrong `JAIL_NAME`

### Jail can resolve DNS but cannot reach APIs

Likely causes:
- NAT missing
- upstream filtering issue
- wrong egress interface

### Jail `resolv.conf` contains `nameserver 100.100.100.100`

Likely cause:
- Bastille copied the host resolver file from a Tailscale-enabled host
- that is not the right default for Warden VNET jails

Concrete wrong-state example:

```conf
# Generated by resolvconf
search taile682b7.ts.net openstacklocal
nameserver 100.100.100.100
```

Response:
- create a dedicated Bastille resolver file, for example:
  - `/usr/local/etc/bastille/resolv.conf`
- use public resolvers there, e.g.:
  - `1.1.1.1`
  - `9.9.9.9`
- set `bastille_resolv_conf` to that file
