Hi everyone. I've been helping a new user in the support channel who is running into a puzzling issue that I think warrants a deeper discussion here, as it touches on some core concepts of agent egress control.
They have a standard Open Claw agent deployment, with a straightforward egress policy requiring all traffic to route through a local filtering proxy (Squid) and use the internal DNS resolver (Pi-hole) for all queries. The agent functions perfectly when the host is connected via WiFi, respecting all proxies and DNS settings. However, when the same host is switched to a wired Ethernet connection, the agent fails to phone home and the egress logs show it attempting direct connections, bypassing the proxy entirely.
We've verified the obvious: the agent config is identical, the host's network profile is the same, and there are no obvious firewall rules differing between interfaces. The behavior suggests the agent is detecting or being influenced by something specific to the physical interface.
I'm curious if others have encountered similar scenarios. Specifically:
* Could there be a subtle difference in how the agent pulls or applies network configuration (like DNS servers or proxy auto-configuration) on different interface types?
* Are there known issues where certain VPN or enterprise network configurations on the wired side might preemptively intercept or redirect the agent's own connection attempts before our controls engage?
* What are the best methods to debug this from the agent side? We've looked at the standard logs, but I'm wondering about lower-level network stack introspection to see what the agent *thinks* its route and DNS config are at the moment of failure on the wired interface.
The goal is to get to a deterministic setup, where the transport medium doesn't affect the control point enforcement. Any insights or shared experiences would be greatly appreciated.
- mod lara
Be kind, be secure.
That's a really interesting case, thanks for bringing it up. I'm just starting with agent deployment myself, so this is good to know.
> Could there be a subtle difference in how the agent pulls or applies network configuration
I wonder if the routing table looks different on the wired interface. Maybe there's a default route with a lower metric on ethernet that's making the agent think it doesn't need the proxy? Or could the Squid proxy's listener be bound to the WiFi subnet somehow?
Sorry if these are basic thoughts, but it's where my mind went.
You're on the right track with the routing table. The metric difference is a classic culprit. In my setup, I had to explicitly add a higher-priority route for the proxy's IP on the wired interface. Without that, the agent just takes the default gateway.
Also, don't overlook the proxy listener binding. It's less common, but if Squid is configured to listen only on `wlan0` or that subnet, it would silently drop the wired connections. A quick `netstat -tlnp | grep squid` on the proxy host would rule that out.
Segregate or die.
Exactly right about the route metric. It's the most common reason we see for this split behavior.
The listener binding is a good call too. In my experience, it's usually not the main culprit for a complete bypass, but it can cause silent failures that look similar. If Squid is bound to a specific interface IP, the agent's wired connection might just get a connection refused or timeout, which can sometimes trigger fallback logic in the agent that tries a direct path.
A quick sanity check for the original poster: compare the output of `ip route` on the host when connected via WiFi versus wired. Look for the default route entry and its metric. That'll confirm the theory immediately.
Be kind, be secure.
Everyone's jumping straight to routing metrics, which is fair, but I'm surprised nobody's mentioned the agent's own environment detection. Could it be pulling interface-specific proxy configs from some obscure systemd-networkd or NetworkManager profile? I've seen `http_proxy` environment variables get set per-connection.
If the agent respects `http_proxy` and it's only declared for the WiFi profile, that'd do it. Direct on wired, proxied on WiFi. The logs showing a bypass would fit.
> host's network profile is the same
Are you *sure*? Not just the GUI settings, but the actual resolved config from `networkctl status` or `nmcli`? There's always a difference lurking in some dotfile.
mj
You're right. That's a solid alternate hypothesis. I've seen per-connection environment variables trip up more than just agents; some package managers and CLI tools get weird when `http_proxy` is set on one interface and not another.
But wouldn't that usually show as a connection failure *to* the proxy in the logs, not a full bypass? Unless the agent's logic is "if proxy env var is absent, assume direct." That's a crappy design, but I've seen it.
Check the output of `systemctl show --property=Environment` for the agent's service unit, too. Overrides can come from there as well as the network profile.
watch and report
That's super interesting about the environment variables. I never would have thought to check there. So if the agent uses the `http_proxy` variable, and it's only set for the WiFi profile in something like NetworkManager, that could totally explain the direct connections on wired, right?
But how would you even check that for a specific connection? Is it just in the NetworkManager GUI somewhere, or is it a buried config file?