skip to content

Why do protocols such as FTP and SIP break through an IPv4 NAT, and what does an application-level gateway do to repair them?

level: middleimportance: should knowfreq 34%

answer

  1. addresses inside the message
  2. PORT versus PASV
  3. SDP names the media endpoint
  4. length changes shift sequence numbers
  5. encryption blinds the gateway

basics

~20 s

FTP's PORT and PASV messages and SIP's SDP bodies carry addresses and ports in the payload, which NAT does not rewrite. An ALG parses that payload, substitutes translated values, opens the matching mapping and fixes TCP sequence numbers.

solid answer

~50 s

A NAT rewrites headers, not application data, but some protocols write "connect to me here" into their own messages. FTP's PORT command and PASV reply carry the data connection's address and port as ASCII text, so in active mode the server tries to connect to the client's private address. SIP carries addresses in fields such as Contact, and its SDP body names the IP address and ports for media, all private after translation. An ALG watches the control channel, rewrites those values to the public address and a port it allocates, creates the mapping for the expected connection, and - because the text length changes - adjusts TCP sequence and acknowledgement numbers and checksums for the rest of the stream (RFC 3027). ALGs fail on encrypted control channels, lag protocol changes and open inbound paths from payload text, so RFC 5382 REQ-6 recommends TCP ALGs other than FTP's be off by default.

go deeper

for a junior

Remember that FTP and SIP put addresses inside their messages, and that NAT only rewrites headers, so those inner addresses stay private and break.

for a middle

Trace active-mode FTP through a NAT, explain what the ALG rewrites and why sequence numbers must shift when the text length changes, and why passive mode avoids it.

for a senior

Weigh ALGs operationally: encryption blinds them, they interfere with NAT-aware applications and open inbound paths from payload text, which is why RFC 5382 recommends them off by default.

for a principal

Argue for protocol designs that never embed addresses and for removing translation where possible, rather than accumulating middlebox logic for each application.

## Why translation misses the payload A NAT rewrites the **headers** it understands - the IP source or destination address and the TCP or UDP port - and fixes the checksums. It does not read application data. That suits most protocols, but some write an IP address or port **inside their own messages** to say "connect to me here". RFC 3027 groups them as protocols with realm-specific addresses in the payload and **bundled-session** applications, where a control session negotiates a second connection whose address appears only as application data. After translation the header says one thing and the payload another, and the payload's private address is meaningless on the far side. ## FTP: the classic case FTP opens a **control connection** to TCP port 21 and moves file data over a separate **data connection**. Its PORT and PASV commands and responses carry the data connection's address and port as ASCII text (RFC 3027 section 4.1). Active mode through a client-side NAT, with documentation addresses: 1. Client `10.0.0.5` connects out through a NAT whose public address is `203.0.113.7`; the control connection works because it is an ordinary outbound flow. 2. The client sends PORT naming `10.0.0.5` and a local port for the data connection. 3. The server at `198.51.100.20` tries to open the data connection to `10.0.0.5` - an address it cannot route to - and the transfer hangs. An **FTP ALG** watches the control connection, replaces the private address and port in the PORT text with the public address and a port it allocates, and creates the mapping that lets the server's inbound data connection through. Because the text changes length (`10.0.0.5` is 8 characters, `203.0.113.7` is 11), the ALG must also shift the TCP sequence and acknowledgement numbers of every later packet in that stream and update the TCP checksum, IP total length and header checksum. RFC 3027 adds that the larger packet can, rarely, exceed the link MTU. **Passive mode** reverses the direction: the server's PASV reply names the address and port the client should connect to, so a client behind NAT simply opens another outbound connection and needs no ALG. A **server** behind NAT running passive mode has the mirror problem - its reply advertises its private address. RFC 3027 also points to RFC 2428's EPSV ALL, which lets a NAT skip ALG processing for the session. ## SIP and SDP SIP runs over TCP or UDP, by default on port 5060. It carries signalling addresses in URLs such as the Contact field, and its **Session Description Protocol** body names the IP address and ports for the media streams. RFC 3027 section 4.5 adds that over UDP a response may go to a port named in the message rather than to the request's source port. Every one of those private values is wrong after translation, so a **SIP ALG** has to parse SIP and SDP, rewrite each value and open media mappings to match. ## Why ALGs are a liability | Concern | What goes wrong | |---|---| | Encryption | A protected control channel (TLS for FTP or SIP) cannot be read or rewritten; RFC 3022 and RFC 3027 both note that encoded payloads disable the ALG | | Protocol evolution | Every extension or new encoding needs an ALG update; a stale ALG mangles messages it half understands | | NAT-aware software | Applications that already handle translation themselves get their payloads "fixed" a second time and break | | Inbound holes | The ALG opens inbound mappings because payload text asked for them, so a forged control message can open a path in | RFC 5382 REQ-6 therefore recommends that a NAT disable every ALG affecting TCP by default, except FTP's, whose default it leaves unspecified because many legacy FTP clients do not use passive mode. ## Better designs - Avoid embedding addresses: passive or extended-passive FTP, or a transfer protocol with no second connection. - Let endpoints learn their own public mapping and negotiate media with traversal techniques instead of relying on a middlebox to rewrite messages. - Run a SIP proxy alongside the NAT, which RFC 3027 lists as an alternative to a SIP ALG. - In IPv6 without translation the problem largely disappears, because the address a host writes is the address its peer sees.

  • Why does passive-mode FTP usually work through a client-side NAT without any ALG?
    In passive mode the server's reply names the address and port the client should connect to, and the client opens the data connection outbound, exactly like the control connection. The NAT creates a mapping for it as for any outbound flow, and nothing in the payload carries the client's private address. The problem moves to the server side: a server behind NAT advertises its private address in that reply.
  • What happens to an FTP ALG when the control channel is protected with TLS?
    The ALG can no longer read the PORT or PASV text, so it cannot rewrite the address or open the matching mapping; RFC 3027 notes that a secured control channel makes the ALG's update impossible. Active mode then fails from behind NAT, so clients rely on passive mode, and a server behind NAT has to advertise a usable address and have its data-port range opened explicitly.

saying these in an interview costs you the question

  • NAT rewrites every IP address in the packet, including those in the payload.
  • Passive-mode FTP needs an ALG on the client's NAT.
  • An ALG only swaps the address text; TCP sequence numbers are unaffected.
  • Enabling every ALG on a NAT is safe and only improves compatibility.
  • Encrypting the FTP or SIP control channel helps the ALG do its job.