Which Linux Packet Path Should Enforce Proxy Use?
Place network proxy-enforcement controls on the packet path they are meant to govern instead of filtering only connections to the gateway itself.
A Linux gateway can run the proxy process and also route traffic past it. Those are not the same packet path.
| Connection | Relevant local role |
|---|---|
| Client reaches the proxy on the gateway | Traffic addressed to the local host |
| Client reaches another host through the gateway | Forwarded traffic |
| The proxy opens a website connection | Traffic generated by a local process |
Netfilter distinguishes input, forward, and output paths. A rule governing access to the gateway's own proxy listener does not automatically constrain every routed connection through that machine.
Define what must be enforced
If clients must use the approved proxy, the policy needs to address their alternate outbound routes as well as allowing the intended listener. Allowing connections to any remote service merely because it uses the familiar proxy port is not the same as allowing only your proxy endpoint.
Keep the proxy's own onward access separate. For Squid, distinguish local socket ownership from LAN user identity before applying an egress allowance. Denying all useful outbound connections from the proxy would make the required path unavailable. Management traffic, name resolution, and supported non-web operations also need deliberate treatment in the deployment's policy.
Protocol scope matters. A TCP rule does not by itself describe UDP traffic, including QUIC. Intercepting traffic is another design again; an explicit HTTPS proxy can provide CONNECT without decrypting the website session.
Map the intended connections before editing a ruleset. A browser preference selects a route for participating clients. Network enforcement decides which other routes can succeed. Neither should be inferred solely from a working login to the proxy.