Who owns a QUIC connection?

A mental model for QUIC through firewalls, NAT, and CGNAT — and the precise sense in which the network does, and does not, see a “connection.”

Start with the thing that feels weird

You open an HTTP/3 connection from your laptop to a server. QUIC normally rides over UDP, commonly to port 443. From an ordinary router's perspective, these are simply unicast IP packets going one way and unicast IP packets coming back.

laptop:53124  ───── UDP/443 ─────▶  server:443
             ◀───── UDP/443 ─────

So yes: it is unicast in both directions. There is no magical broadcast or side channel. The interesting part is what each box along the path knows about those packets.

TCP trained us to conflate two different kinds of state

With TCP, the endpoints have transport state: sequence numbers, receive windows, retransmissions, congestion control, and so on. But a firewall can also watch the network-visible TCP state machine:

SYN  →  SYN-ACK  →  ACK  →  ...data...  →  FIN / RST

That makes it tempting to think a NAT “understands the connection.” In reality, a NAT's essential job is simpler: remember an address/port translation long enough to send reply packets back to the correct internal host.

Now replace TCP with QUIC

QUIC implements reliability, streams, loss recovery, congestion control, connection setup, and migration above UDP. Most of that protocol machinery is encrypted from the network.

That last row is the big one. A stateful firewall can still say “I have recently seen traffic belonging to this UDP/QUIC flow,” but it does not get the same exposed transport state machine that TCP gives it.

What a NAT — including CGNAT — actually does

Suppose your laptop sends this:

10.0.0.5:53124  →  server.example:443

Your home NAT might allocate an outside mapping:

10.0.0.5:53124  ↔  100.64.12.8:40011

Then your ISP's carrier-grade NAT can do it again:

100.64.12.8:40011  ↔  198.51.100.27:62001

When the server replies to 198.51.100.27:62001, the CGNAT consults its mapping and sends the packet inward. The home NAT does the same thing again.

Nothing about this requires the NAT to understand QUIC. Ordinary stateful UDP NAT behavior is enough.

But how does the NAT know when the “connection” ends?

It doesn't, in the QUIC sense.

TCP gives a middlebox explicit FIN/RST signals. QUIC intentionally does not expose a comparable end-of-flow signal. So NAT/firewall mappings are generally aged out with an inactivity timer or resource-pressure policy.

packet arrives
     ↓
refresh UDP mapping timer
     ↓
more packets? ── yes ──▶ keep mapping
     │
     no
     ↓
timeout → forget mapping

This is why long-idle UDP-based protocols have to care about middlebox timeout behavior. The IETF's UDP NAT guidance specifies timers, but real deployed boxes are not perfectly uniform.

The payoff: QUIC does not define the connection by the 4-tuple

A conventional TCP connection is strongly tied to:

(source IP, source port, destination IP, destination port)

QUIC instead gives endpoints Connection IDs. That lets the server recognize the logical QUIC connection even if the network path changes.

Imagine your NAT forgets a mapping and allocates a new source port:

before: 198.51.100.27:62001 → server:443
after:  198.51.100.27:48192 → server:443

To the NAT, this can simply look like a new UDP mapping. To the QUIC endpoint, a Connection ID can say: same logical connection, new path. The endpoint then validates that new path before fully trusting it.

The same machinery is what makes client migration possible when, say, a phone moves from Wi-Fi to cellular.

So what can a firewall still do?

Plenty. It can allow or block UDP/443, rate-limit traffic, keep per-flow state, and in more QUIC-aware deployments identify QUIC/version/handshake characteristics. It can also simply refuse UDP, in which case an application such as a browser may choose another transport such as HTTP/2 over TCP.

But QUIC was deliberately designed so that arbitrary middleboxes do not get to depend on lots of transport internals. TCP accumulated decades of boxes that inspected and modified visible details; that made protocol evolution brittle. QUIC encrypts most transport metadata partly to avoid repeating that ossification.

The mental model to keep

                  TCP                         QUIC
             ─────────────               ─────────────
endpoint     rich TCP state              rich QUIC state

middlebox    mapping/filter state        mapping/filter state
             + visible TCP semantics     + limited QUIC visibility

identity     usually 4-tuple             Connection ID at endpoints

ending       FIN/RST visible             no comparable visible end signal

path change  usually kills connection    can survive via migration

So when you ask, “there is no connection state like TCP that a router/NAT can see, right?” the precise answer is:

A plain router never needed transport connection state. A NAT/firewall still keeps state for the UDP flow. What QUIC removes from the middlebox is most of the transport's meaningful internal state machine — while preserving enough network-visible information for packets to get through.