Hey folks, Raj here. Longtime lurker, first time poster. I run a decently complex homelab — a mix of Proxmox, Docker, and bare metal — and I've been using OpenClaw to secure a few critical services, like my home automation and file server.
I deployed the OpenClaw agent on an Ubuntu 22.04 VM that handles my internal DNS (it's running a Pi-hole instance). My goal was to lock down its outbound traffic so it *only* talks to the OpenClaw mothership for reporting, and nothing else. I set up what I thought were pretty strict egress firewall rules on the agent itself, blocking all outbound except for the specific IP and port for the management plane.
But here's the head-scratcher: I'm still seeing DNS queries from this agent's IP hitting my Pi-hole, asking for things like `time.google.com` and `pool.ntp.org`. The firewall rules should be dropping those packets. I even verified with `tcpdump` on the agent VM that the packets are originating from the `openclaw-agent` process.
My current agent network config looks like this:
```yaml
network:
egress:
allowed_hosts:
- "management.openclaw.example.com:443"
firewall:
default_outbound: "deny"
```
And my iptables rule (on the agent host) is:
```bash
-A OUTPUT -p tcp -d --dport 443 -j ACCEPT
-A OUTPUT -j DROP
```
So, why is the agent making these DNS queries? Is it something the agent does independently of the data channel? Is there a health check or NTP sync I missed in the config? Or could the DNS be happening *before* my host firewall rules are applied? I'm used to wrestling with Tailscale exit nodes and reverse proxy weirdness, but this one has me stuck. Any ideas are appreciated.
iptables -A INPUT -j DROP
Your iptables rules might not be intercepting traffic from the openclaw-agent process if it's running with specific capabilities or network namespaces. Check if the agent binary itself is statically linked or has any embedded DNS client libraries that bypass local firewall rules.
A more likely culprit is the dependency tree. Can you share the pinned versions and the software bill of materials for the exact agent build you're using? Transitive dependencies, particularly for telemetry or NTP synchronization, often have their own network timeouts and retry logic.
You should also inspect the agent's configuration for any default time-sync or diagnostics settings. The network egress YAML config you posted is for the agent's policy engine, but the underlying service might have its own runtime configuration file that needs explicit directives to disable system time lookups.
sbom verify --attestation