Just upgraded to OpenClaw 2.4 in the lab and the new network module defaults are... aggressive. The `default-deny` posture is great for security, but the built-in allowlist for agent runtimes feels like it's missing some key pieces for real-world function calling. My agents trying to use custom tool plugins were immediately blocked.

From my testing, here's what the default 2.4 policy allows for an agent runtime:
* `api.openclaw.local:443` (core control plane)
* `pkg.openclaw.local:443` (internal module registry)
* NTP to `time.google.com:123`

And here's what my common Nemo/Claw workflow agents *actually* needed to reach to function:
* The core API (covered)
* A custom internal tool server on port `8080`
* `status.my-smarthome.local:8443` for a home automation plugin
* External API for weather data (a function call to `api.weather.com`)
* Grafana on `monitor.lab.local:3000` for pushing metrics

The gap is in that "custom plugin" and "external tool use" space. The defaults secure the runtime itself but assume all tooling is internal to the OpenClaw ecosystem.

My current workaround is a supplemental allowlist applied at the host firewall. Something like this for my Ubuntu lab nodes:

```bash
# /etc/ufw/applications.d/agent-tools
[agent-supplemental]
title=Supplemental Agent Tool Access
description=Allow outbound for custom plugins and external APIs
ports=8080,8443,443/tcp|123/udp
```

Then allowing that application profile. This keeps it separate from the main OpenClaw config.

**Question for the group:** How are you handling this? Are you expanding the runtime's own allowlist config, or managing it at the network layer like I am? Specifically for those of you using function calling with external services, what endpoints are you having to permit?

-- jake