Teams often overestimate how selective a steering method can be and underestimate its permission and maintenance burden. DNS alone cannot control ports well. TUN can capture broad traffic, but it is not selective when using a default gateway. eBPF may look attractive, yet it can be excessive for simple steering and too limited for a full Layer 7 proxy.
Why proxy steering fails when teams assume one mechanism can do everything
Redirecting traffic to an internal proxy is really a question of control scope, not just redirection. Teams often mix up path selection with policy enforcement, then discover the steering method can only influence some traffic shapes while leaving others untouched. The practical mistake is treating DNS, tunnels, or kernel filtering as interchangeable when each has different granularity, operating cost, and failure modes.
DNS is coarse because it resolves names, not sockets or application flows. TUN can capture broad traffic, but a default gateway style setup is closer to blanket rerouting than selective interception. eBPF can be precise, yet that precision comes with implementation complexity that may be unnecessary if the objective is simply to steer a manageable subset of traffic to a proxy.
The deeper issue is that teams usually want three different outcomes at once: broad capture, selective exclusion, and stable policy enforcement. Those are not the same problem. If the proxy strategy is not explicit about which layer owns routing, which layer owns policy, and which layer owns exception handling, the design tends to become brittle fast.
What the common steering methods are actually good at
DNS works best when the goal is to influence destination selection at the name level, such as steering hostnames through a resolver-controlled path. It does not decide whether a connection to the same host should go through one port or another, and it cannot express application intent beyond the lookup stage. That makes it useful as a coarse input, but weak as a complete proxy control plane.
TUN-based interception is stronger because it operates at the packet or interface layer. That is why it can capture large portions of traffic without application changes. The trade-off is that once traffic is broadly funneled through the tunnel, selective routing becomes harder, especially when the default route is involved. The result is often either too much capture or too much exception logic.
eBPF can solve problems the other approaches cannot, particularly when teams need fine-grained steering logic or selective exclusion at runtime. But it is not a free upgrade. If the use case is simple proxy redirection, the operational overhead, testing burden, and policy debugging complexity can outweigh the benefit. In practice, the more selective the steering, the more you need to validate correctness under real traffic patterns.
Where teams underestimate the real cost of internal proxy redirection
Redirection is not only about moving packets, it is about ownership of every edge case. Once traffic is forced through a proxy, teams must account for bypass paths, protocol exceptions, local services, DNS dependencies, certificate trust, and the behavior of applications that do not tolerate interception well. The maintenance burden grows whenever the environment changes faster than the steering logic.
Another common error is choosing the mechanism before defining the control objective. If the purpose is simple outbound inspection, the design should stay simple. If the purpose is selective enforcement across mixed protocols, then the solution may need more than DNS or a basic tunnel. If the purpose is deep traffic policy at the application layer, then the steering method has to support that outcome end to end, not just get traffic “close enough” to the proxy.
Teams also underestimate permission and blast-radius issues. Any steering mechanism that can redirect traffic broadly can also disrupt legitimate flows broadly. That means rollout strategy, exception handling, and rollback need to be part of the design, not an afterthought. The right question is not “Can we redirect it?”, but “Can we redirect only what we intend, and prove we have not broken the rest?”
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | Proxy steering changes network boundary enforcement and traffic routing. |
| AC-4 — Information Flow Enforcement | Internal proxy redirection is an information-flow control problem across hosts and ports. | |
| Recommendation — Define and enforce traffic boundaries so only intended flows are redirected through the proxy. Enforce information-flow rules that distinguish allowed proxy-bound traffic from direct paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity and Access Management | Steering mechanisms often depend on controlled permissions to alter routing or trust paths. |
| Recommendation — Limit who can change steering and proxy policy so redirection remains tightly governed. | ||
| ISO/IEC 27001:2022 | A.8.20 — Network security | Traffic redirection to an internal proxy is a network security design and control issue. |
| Recommendation — Document and test network redirection paths to ensure proxy enforcement behaves as intended. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | Proxy redirection depends on correct routing, segmentation, and network control maintenance. |
| Recommendation — Manage routing and segmentation changes so proxy steering does not create uncontrolled bypasses. | ||
Practitioner Guidance
What to prioritise: Start by defining the exact steering objective in terms of protocol, port, destination, and exception scope. If the design cannot state what should stay outside the proxy, it is usually already too broad.
What to verify: Test real traffic, not just happy-path hostnames. Validate how the method behaves for non-HTTP protocols, local services, split tunnelling, and applications that pin trust or expect direct connectivity.
Decision rule: Use the least powerful steering method that still meets the policy goal. Prefer coarse methods for coarse goals, and reserve more invasive controls for cases where selectivity is truly required.
Practitioner takeaway: The best proxy steering design is the one that matches the enforcement problem exactly, because every extra layer of control increases the chance of silent bypass, overcapture, or operational drag.
Related resources from NHI Mgmt Group
- What do teams get wrong when they try to scale access to many internal applications with shared credentials?
- What do teams get wrong when they try to record or proxy API mocks?
- What do teams get wrong when they try to automate threat modeling too early?
- What do teams get wrong when they try to test agent memory with simple replay?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
