TCP Forwarding

How TCP Forwarding Works

TCP forwarding is a transport relay pattern: one process accepts an incoming TCP connection and opens a second connection to the target endpoint, then moves bytes between the two streams. It preserves the client’s TCP session semantics while shifting where the traffic terminates.

That simple relay behavior makes it useful in port forwarding, tunnelling, proxying, and bastion-like access paths. The forwarding layer may be local, remote, or transparent, but the core idea is the same, a new socket is created on the far side and the intermediary passes traffic through.

Where TCP Forwarding Is Used

TCP forwarding appears anywhere teams need to reach a service through an intermediate hop without exposing the destination directly. Common examples include SSH port forwarding, cloud access tunnels, reverse proxies, and controlled access to internal databases, admin interfaces, or legacy services.

In cloud environments, forwarding often becomes part of a larger access design. For example, Identity-Aware Proxy Guide covers using TCP forwarding to replace bastions and add access checks before a tunnel is established, while Compute Engine Security Guide shows how forwarding fits into hardened VM access patterns.

It also sits within broader network policy and routing decisions. Google Cloud VPC and Cloud NGFW Security Guide is relevant because forwarding only makes sense when firewall rules, segmentation, and egress paths are designed to allow the relay while still constraining lateral movement.

Security Implications of TCP Forwarding

TCP forwarding changes the trust boundary. The intermediate host or service can see connection metadata and becomes part of the path that must be trusted, monitored, and restricted. If the relay is overpermissive, it can expose internal systems that were otherwise unreachable from the client network.

Because forwarding can bypass normal network reachability, it can also weaken the value of perimeter controls if it is deployed casually. A forwarding path that is intended for a narrow administrative use case can become a general-purpose bridge into sensitive environments when routing, authentication, or authorization are not tightly scoped.

In identity-aware designs, forwarding is often paired with device checks, user reauthentication, or session policy so that access to the tunnel is governed separately from raw network connectivity. That matters because the tunnel itself is not the security decision, it is the transport mechanism after the access decision has already been made.

Operational Trade-Offs and Control Points

TCP forwarding is lightweight and flexible, which is why operators use it for troubleshooting, secure admin access, and private service exposure. The trade-off is that flexibility can hide risk if teams treat the relay as a harmless plumbing detail rather than an access path that needs ownership.

The important control points are where the connection is accepted, what destinations are permitted, how the forwarding service is authenticated, and whether the destination sees the original source identity or only the intermediary. Those choices determine whether forwarding is a narrow conduit or a broad implicit trust channel.

Well-designed forwarding should have clear scope, clear logging, and clear termination conditions. If those are absent, it becomes difficult to tell whether a connection was legitimate administration, accidental exposure, or an abused path into a protected network segment.

Related resources from NHI Mgmt Group

• When does SSH forwarding create more risk than value?
• How can organisations control mailbox forwarding risk in Exchange Online?
• How should teams configure DNS forwarding in segmented environments?
• Why does DNS forwarding matter to security teams?