Location in the TP-link router: Advanced → NAT Forwarding → ALG

A) Primer: Why Plain NAT Is Not Enough

To understand why routers require Application Layer Gateways (ALGs) and Pass-Through settings, we must first deconstruct the mechanics of "Plain NAT" and examine the architectural assumptions it makes.

When we say "Plain NAT" in the context of home and SOHO (Small Office/Home Office) routers, we are actually referring to NAPT (Network Address Port Translation), also known as PAT (Port Address Translation). While Plain NAT was designed to solve IPv4 address exhaustion by mapping multiple private IP addresses to a single public IP, it inadvertently broke the End-to-End Principle of the internet.

Here is an expert-level analysis of why standard NAT translation fails when confronted with complex network protocols, categorized by the specific OSI layer where the breakdown occurs.

1. The Core Assumption of NAPT: The 5-Tuple

To map traffic correctly, a standard NAPT router relies on a state table built around a 5-tuple:

Source IP Address (Layer 3)
Destination IP Address (Layer 3)
Source Port (Layer 4)
Destination Port (Layer 4)
Protocol (Layer 4 - TCP or UDP)

Plain NAT assumes that every communication session is defined by TCP or UDP ports. It opens a "pinhole" in its stateful firewall only when an internal device initiates an outbound connection on a specific port, and it expects the return traffic to match that exact 5-tuple.

When a protocol violates these assumptions, Plain NAT fails in one of three distinct ways.

2. Failure Mode A: Portless Protocols (The Layer 3/4 Blind Spot)

Not all IP traffic uses TCP or UDP. Some protocols operate directly on top of the IP layer (Layer 3) using their own IP Protocol Numbers. Because they lack Layer 4 headers, they do not have port numbers.

The Problem: Loss of Demultiplexing

If two internal computers (PC-A and PC-B) both connect to the same external corporate VPN server using a portless protocol, the NAT router strips their private IPs and replaces them with the router’s single Public IP. When the return traffic arrives at the router, it looks at the packet and asks: "This packet is destined for my Public IP, but it has no port number. Which internal PC does this belong to?" Without a port to differentiate the sessions, the NAT router cannot demultiplex the traffic. The state table overwrites itself, and the connection drops or misroutes.

The Culprits:

GRE (Generic Routing Encapsulation - IP Protocol 47): Used by PPTP for data tunneling.
ESP (Encapsulating Security Payload - IP Protocol 50): The primary data protocol for IPSec.
AH (Authentication Header - IP Protocol 51): Used for IPSec authentication.
ICMP (Internet Control Message Protocol - IP Protocol 1): Used for Ping and Traceroute.

The Workaround: Encapsulation (NAT-T)

Because ALGs cannot easily rewrite portless Layer 3 headers, the industry solved this via NAT-Traversal (NAT-T). Instead of asking the router to understand GRE or ESP, NAT-T encapsulates the portless protocol inside a standard UDP packet (usually UDP port 4500). By wrapping ESP in UDP, the protocol suddenly gains "ports," allowing Plain NAT to track it normally. This is why IPSec Pass-through on your router is essentially a toggle that permits UDP 4500 and ESP through the firewall.

3. Failure Mode B: Payload-Embedded Topologies (The Layer 7 Blind Spot)

This is the most common reason ALGs exist. Plain NAT is a Layer 3/Layer 4 technology; it inspects and rewrites IP headers and TCP/UDP headers. It does not look at Layer 7 (the Application Payload).

However, many legacy protocols were designed in an era where every device had a globally unique, public IP address. These protocols embed IP addresses and port numbers inside the actual data payload to negotiate secondary connections.

The Analogy: The Mailroom Interception

Imagine Plain NAT as a corporate mailroom clerk. The clerk intercepts outgoing mail, crosses out the internal employee's name, and writes the company's public address on the envelope (Layer 3/4 translation). However, inside the letter itself (Layer 7), the employee wrote: "Please send the reply documents directly to my desk at Room 402." The external recipient receives the letter, reads the instructions, and tries to ship a package to "Room 402" at the public street address. The package arrives at the company loading dock, but the external shipping company has no idea what "Room 402" is, and the mailroom clerk didn't read the letter to update the internal instructions. The package is rejected.

The Culprits and Their Mechanics:

1. FTP (File Transfer Protocol)

Active Mode (PORT command): The client tells the server, "Send the data to my IP 192.168.1.50 on port 4000." The server tries to connect to the unroutable 192.168.1.50. Connection fails.
Passive Mode (PASV command): The server tells the client, "Connect to my data port at 203.0.113.5:50000." If the server is behind NAT, it accidentally advertises its private IP (e.g., 10.0.0.5) inside the payload. The client tries to connect to 10.0.0.5 over the public internet and times out.
The ALG Fix: The FTP ALG performs Deep Packet Inspection (DPI). It reads the text of the PORT or PASV commands, translates the private IP to the router's public IP, recalculates the TCP checksums, and dynamically opens a pinhole for the negotiated data port.

2. SIP (Session Initiation Protocol) and SDP

SIP is used for VoIP. While the signaling happens on port 5060, the actual audio (RTP) happens on random, dynamically negotiated ports.
The client sends a SIP INVITE containing an SDP (Session Description Protocol) payload. Inside the SDP text, the client writes its local IP address (192.168.1.10) and a random port (16384) to receive audio.
The ALG Fix: The SIP ALG parses the SIP headers (Via, Contact, Record-Route) and the SDP body, rewrites the private IPs to the public IP, and opens the stateful firewall for the RTP audio stream.

4. Failure Mode C: Dynamic Secondary Channels (The Stateful Firewall Trap)

Even if a protocol doesn't explicitly embed IP addresses, many protocols use a "Control Channel" to negotiate a completely separate "Data Channel."

The Problem: Asymmetric State Tracking

Plain NAT and its integrated Stateful Firewall operate on a strict rule: Only allow inbound traffic that is a direct response to an outbound request.

TFTP (Trivial File Transfer Protocol): A client requests a file from a TFTP server on UDP Port 69 (Control). The server acknowledges the request, but then initiates the actual file transfer from a completely random, ephemeral port (e.g., UDP 54321) back to the client. The router's firewall sees an unsolicited inbound packet on port 54321, assumes it's an attack, and drops it.
H.323 / RTSP: Similar to SIP, these protocols establish a control link (e.g., TCP 1720 for H.323 or TCP 554 for RTSP), negotiate a media stream, and then the server attempts to push the video/audio stream over a newly opened, unrelated port.
The ALG Fix: The ALG monitors the control channel. When it sees the negotiation for the secondary channel, it preemptively programs the router's stateful firewall to expect and allow the inbound traffic on the negotiated ephemeral ports.

5. Summary Matrix: Why Plain NAT Fails and How It Is Patched

The following table maps the protocol failure modes to the specific router settings required to fix them.

Protocol Category	The NAT/Firewall Failure Mechanism	OSI Layer Affected	The Router Fix (Settings)
PPTP / IPSec / ESP	Lack of L4 ports prevents the NAT table from distinguishing multiple concurrent internal sessions to the same external destination.	Layer 3 / 4	Pass-through / NAT-T: Permits portless protocols or encapsulates them in UDP (Port 4500).
FTP / SIP / H.323	Private IP addresses are hardcoded inside the application payload. External peers try to route traffic to non-routable RFC1918 addresses.	Layer 7 (Payload)	ALG: Performs Deep Packet Inspection (DPI) to rewrite embedded IPs/Ports and recalculates checksums.
TFTP / RTSP / H.323	The application opens a secondary, dynamic data channel that was not part of the original outbound connection request. The stateful firewall drops it.	Layer 4 / 7	ALG: Sniffs the control channel to preemptively open "pinholes" in the firewall for the secondary data ports.

6. The Modern Reality: Why ALGs Are Becoming Obsolete

While understanding ALGs is critical for maintaining legacy networks, modern network engineering actively tries to disable ALGs (especially SIP ALG) whenever possible. This is due to the Encryption Catch-22.

The Death of Deep Packet Inspection

ALGs rely on reading the payload to rewrite IP addresses. However, modern security mandates encryption:

FTPS / SFTP: Encrypts the FTP control channel. The ALG sees encrypted gibberish and cannot rewrite the PASV commands.
SIPS / TLS / SRTP: Encrypts VoIP signaling and media. The SIP ALG cannot read the SDP payload to rewrite the IPs. Furthermore, if the ALG attempts to alter the encrypted payload, it breaks the cryptographic hash, causing the receiving endpoint to drop the packet as "tampered."

The Architectural Shift: ICE, STUN, and TURN

Because routers cannot reliably hack their way through encrypted payloads, the internet architecture shifted the burden of NAT traversal away from the router and back to the application.

Modern protocols use ICE (Interactive Connectivity Establishment):

STUN (Session Traversal Utilities for NAT): The internal application asks a public STUN server, "What is my public IP and Port from your perspective?" The application then embeds this public mapping into its own payload before sending it.
TURN (Traversal Using Relays around NAT): If symmetric NAT prevents direct peer-to-peer connection, the traffic is relayed through a public TURN server.

Because the application itself handles the NAT translation mathematically before encrypting the payload, the router's ALG is no longer needed—and if left enabled, a "dumb" ALG will often blindly overwrite the correct public IPs with private IPs, breaking the connection.

7. Conclusion

Plain NAT was designed as a simple, stateful IP-and-Port swapping mechanism. It fundamentally assumes that applications do not care about network topology. When applications embed topology data inside their payloads, utilize portless IP protocols, or open dynamic secondary channels, Plain NAT's strict 5-tuple tracking shatters the connection.

ALGs and Pass-through settings act as middleware patches—inspecting, translating, and encapsulating traffic to force complex protocols through a mechanism that was never designed to support them. In legacy environments, they are mandatory; in modern, encrypted environments, they are often the very thing that breaks the connection.

B. The Architectural Shift: ICE, STUN, and TURN — How Endpoints Defeated the Middlebox

In the previous section, we established why Application Layer Gateways (ALGs) are fundamentally incompatible with modern, encrypted network traffic. When payloads are encrypted via TLS, DTLS, or SRTP, the router’s ALG is blinded; it cannot inspect the data to rewrite IP addresses, and if it attempts to blindly alter encrypted packets, it breaks the cryptographic checksums, causing the endpoints to drop the connection.

This created an architectural crisis for real-time communications (VoIP, Video Conferencing, WebRTC). The solution was not to build smarter routers, but to move the intelligence to the endpoints.

This paradigm shift birthed the ICE/STUN/TURN framework. Instead of relying on the network edge (the router) to fix NAT traversal, the applications themselves (browsers, softphones, mobile apps) collaboratively map the network topology and negotiate the most efficient path through the NATs.

Here is an deep dive into this architectural shift, dissecting the mechanics of STUN, TURN, and the ICE framework that orchestrates them.

1. The Core Philosophy: Endpoint-Driven Traversal

The traditional ALG model violates the End-to-End Principle of internet architecture, which dictates that network-specific features (like NAT translation) should not interfere with application-layer logic.

The ICE/STUN/TURN model restores this principle by treating NATs as "black boxes." The endpoints do not need to know how the router translates ports; they only need to discover what the public-facing IP and port appear to be from the outside, and then test if those external mappings can receive traffic.

This is achieved through three distinct but deeply integrated protocols:

STUN: The scout that discovers public addresses.
TURN: the fallback relay when direct peer-to-peer (P2P) connection is impossible.
ICE: The orchestrator that gathers all possible paths and races them to find the fastest, most direct connection.

2. STUN: The Scout (Session Traversal Utilities for NAT)

RFC 5389 defines STUN. Its primary job is simple: allow a client behind a NAT to discover its public IP address and the public port that the NAT has assigned to its outbound traffic.

How STUN Works

The Binding Request: The endpoint (Client A) sends a simple, unencrypted UDP packet (a STUN Binding Request) to a publicly accessible STUN server on the internet.
The Mapped Address: The STUN server looks at the source IP and source port of the incoming packet. Because the packet just passed through Client A's NAT router, the source IP/Port represents the Public IP and the NAT-assigned external port.
The Response: The STUN server sends a Binding Response back to Client A, containing this "Mapped Address" in the payload.

The Result: Server Reflexive Candidates

Client A now knows two things about itself:

Host Candidate: Its local, private IP and port (e.g., 192.168.1.50:5004).
Server Reflexive Candidate (srflx): Its public IP and the specific external port the router opened for it (e.g., 203.0.113.10:45000).

Client A will eventually share this srflx candidate with its peer (Client B) via a signaling channel (like SIP or WebSockets), essentially saying: "If you want to reach me, try sending packets to 203.0.113.10 on port 45000."

The STUN Limitation: NAT Topologies

STUN works perfectly for Cone NATs (Full, Restricted, or Port-Restricted). In a Cone NAT, if the router opens port 45000 for the STUN server, it will also accept inbound traffic on port 45000 from any external IP (or at least from the specific peer IP).

However, STUN fails completely against Symmetric NATs.

In a Symmetric NAT, the router assigns a unique external port for every distinct destination.
The port mapped for the STUN server (45000) will not be the same port mapped for Client B (45001).
When Client B tries to send media to 45000, the Symmetric NAT drops it because it is only expecting traffic from the STUN server on that port.

When STUN fails, the architecture must fall back to TURN.

3. TURN: The Fallback (Traversal Using Relays around NAT)

RFC 5766 defines TURN. If STUN is the scout, TURN is the heavy lifter. It is used when both peers are behind restrictive Symmetric NATs or strict corporate firewalls that block direct P2P UDP traffic.

How TURN Works

A TURN server is essentially a STUN server with packet-forwarding (relay) capabilities enabled.

Allocation: Client A sends an "Allocate" request to the TURN server.
Relay Address: The TURN server opens a public port on its own interface and assigns it to Client A. This is called the Relay Candidate (relay). (e.g., TURN-Server-IP:3478).
Encapsulation/Forwarding: Client A sends its media (RTP/Video) to the TURN server. The TURN server receives it, strips the outer headers, and forwards the raw media payload to Client B. Client B does the same in reverse.

The Economic and Technical Cost of TURN

While TURN guarantees a connection (success rates approach 100%), it is the least desirable option for two reasons:

Latency: Traffic is no longer taking the shortest path between peers. It is routing through a centralized data center, adding significant jitter and latency to real-time audio/video.
Bandwidth Costs: The TURN provider must pay for the ingress and egress bandwidth of every single byte of media. For a large-scale video conferencing platform, TURN infrastructure is a massive operational expense.

Architectural Rule of Thumb: A well-optimized WebRTC or VoIP platform aims for an 80-90% P2P success rate (using STUN/ICE) to minimize TURN relay costs, using TURN strictly as a last resort.

4. ICE: The Orchestrator (Interactive Connectivity Establishment)

RFC 8445 (which obsoleted RFC 5245) defines ICE. ICE is not a transport protocol; it is a state machine and negotiation framework that utilizes STUN and TURN to find the best possible path between two endpoints.

Phase 1: Candidate Gathering

Before a call begins, the ICE agent inside the application gathers every possible network interface and address it can use. These are categorized into four types:

Candidate Type	Abbreviation	Source	Description	Priority
Host	`host`	Local OS	The physical/virtual NIC's local IP (e.g., `192.168.1.x`, `10.0.0.x`).	Highest (Fastest, no NAT)
Server Reflexive	`srflx`	STUN Server	The public IP/Port as seen by the STUN server. Represents the NAT mapping.	Medium (Direct P2P via NAT)
Peer Reflexive	`prflx`	Discovered during checks	A NAT mapping discovered dynamically during the ICE checks, not known beforehand.	Medium-High
Relayed	`relay`	TURN Server	The public IP/Port of the TURN server allocated for this session.	Lowest (Highest latency/cost)

Phase 2: Signaling and SDP Exchange

The endpoints exchange their gathered candidates via a Signaling Channel (e.g., SIP, WebSocket, XMPP). This exchange happens inside the SDP (Session Description Protocol) payload. Note: This is exactly where the old SIP ALG used to break things by rewriting the SDP. With ICE, the SDP contains a list of candidates, and the endpoints handle the logic, rendering the ALG obsolete.

Phase 3: Connectivity Checks (The "Race")

Once both peers have each other's candidate lists, they form "Candidate Pairs" (one local candidate + one remote candidate). The ICE agent then begins firing STUN Binding Requests directly between the peers across these pairs.

If Peer A sends a STUN request from its srflx candidate to Peer B's srflx candidate, and receives a response, that pair is marked as Valid.
ICE tests multiple pairs simultaneously or in rapid succession.

Phase 4: Nomination and Media Flow

ICE evaluates the valid pairs based on a calculated priority score (favoring Host > Srflx > Relay). It "nominates" the highest-priority valid pair. Once nominated, the application begins sending the actual encrypted media (via SRTP/DTLS) over that specific UDP socket.

5. Modern Optimizations: Trickle ICE

In the original ICE specification (RFC 5245), an endpoint had to gather all candidates (which involves waiting for STUN and TURN server timeouts) before it could generate the SDP and send the initial call setup message (e.g., the SIP INVITE or WebRTC Offer). This caused massive call setup delays (often 3 to 5 seconds of ringing before the phones even started negotiating).

Trickle ICE (RFC 8838) revolutionized this by decoupling candidate gathering from the initial signaling.

The caller immediately sends the SIP INVITE/WebRTC Offer with just the host candidates.
As the STUN and TURN servers respond, the caller "trickles" the new srflx and relay candidates to the callee over the signaling channel in subsequent messages.
The callee begins connectivity checks on the candidates as soon as they arrive.

This reduces call setup times from seconds to milliseconds, making browser-based VoIP and WebRTC feel as instantaneous as a traditional cellular call.

6. The Old World vs. The New World: A Comparison

To fully appreciate the architectural shift, we must compare the legacy ALG approach with the modern ICE approach.

Feature	The Legacy Model (ALG + Plain NAT)	The Modern Model (ICE + STUN/TURN)
Intelligence Location	Network Edge (The Router/Firewall)	The Endpoints (Browsers, Apps, Phones)
Payload Inspection	Required (Deep Packet Inspection)	None (Works perfectly with E2E Encryption)
NAT Awareness	Router must understand the specific protocol (SIP, FTP, H.323)	Router is treated as a "Black Box" (Protocol Agnostic)
Encryption Support	Breaks encrypted payloads (FTPS, SIPS, SRTP)	Native support (DTLS/SRTP is mandatory in WebRTC)
Failure Handling	Silent failure (Router drops packets, app times out)	Graceful degradation (Falls back from P2P to TURN relay)
Protocol Flexibility	Requires a new ALG for every new protocol	Works for any UDP/TCP payload (Video, Audio, Data channels)

7. Strategic Implications for Network Engineers and Architects

Understanding this shift is not just academic; it dictates how modern infrastructure must be designed and secured.

7.1. The Death of the "Smart" Edge Router

For enterprise and SOHO networks, the takeaway is clear: Disable SIP ALG and H.323 ALG. Modern Unified Communications (UC) platforms, Microsoft Teams, Zoom, and WebRTC applications are built on ICE. An enabled ALG will aggressively mangle the SDP payloads, stripping out the ICE candidates or rewriting the encrypted DTLS fingerprints, resulting in one-way audio or immediate call drops. The router should act as a "dumb" pipe, simply forwarding UDP traffic and maintaining basic stateful tracking.

7.2. Firewall Egress Rules

Because ICE relies heavily on UDP for connectivity checks and media transport, strict corporate firewalls that block outbound UDP will force all traffic onto TURN relays (if TCP TURN is configured) or fail entirely. Modern network perimeters must allow outbound UDP to the internet to facilitate direct P2P media flows, reducing reliance on expensive cloud relays.

7.3. The Rise of SFUs and Multipoint Relays

While STUN/TURN solves 1-to-1 (Peer-to-Peer) NAT traversal, it does not scale to 1-to-Many or Many-to-Many (e.g., a 50-person webinar). Sending 49 separate P2P streams from one browser will melt the client's CPU and upload bandwidth. Therefore, the architecture shifts one step further: instead of connecting to a peer, the ICE agent connects to a Selective Forwarding Unit (SFU) or Multipoint Control Unit (MCU) hosted in the cloud. The SFU acts as a highly optimized, media-aware router that receives one stream from the client and duplicates/distributes it to the other participants. Even in this model, the client still uses ICE/STUN/TURN to establish the initial UDP connection to the SFU.

8. Conclusion

The transition from ALGs to ICE/STUN/TURN represents a fundamental maturation of internet architecture. By acknowledging that middleboxes (routers and firewalls) cannot reliably parse and rewrite encrypted, dynamic application payloads, engineers shifted the burden of connectivity back to the endpoints.

STUN provides the eyes to see outside the NAT, TURN provides the brute-force fallback when the NAT is too restrictive, and ICE provides the brain to negotiate the optimal path. Together, they form a resilient, encryption-friendly framework that allows real-time media to traverse the most hostile network topologies without requiring the network infrastructure to understand the application at all.

C. The Pass-Through Settings (VPN Tunnels)

1 PPTP Pass-through

Protocol profile: TCP 1723 (control) + GRE, IP protocol 47 (data).
Why NAT struggles: GRE carries no ports, so plain NAT cannot map multiple internal clients' tunnels.
What enabling it does: Installs a NAT editor that tracks PPTP call IDs within GRE headers, allowing LAN clients to establish PPTP VPN tunnels to external servers.
Typical applications:
- Legacy corporate remote-access VPNs (Windows built-in VPN client, "PPTP" connection type).
- Older gateway-to-gateway tunnels on inherited equipment.
Recommendation: Enable only if you actually use PPTP. It is considered cryptographically broken (MS-CHAPv2 weaknesses) and should not be deployed for new systems.

2 L2TP Pass-through

Protocol profile: UDP 1701; in practice almost always wrapped in IPSec ("L2TP/IPSec"), adding UDP 500 (IKE), ESP (protocol 50), and UDP 4500 (NAT-T).
What enabling it does: Permits the L2TP/IPSec protocol stack through NAT and tracks the encapsulated sessions so client tunnels survive address translation.
Typical applications:
- Built-in OS VPN clients (Windows, macOS, Android, iOS) connecting to corporate or self-hosted L2TP/IPSec servers.
- Remote-access setups chosen for native client support rather than security strength (pair it with IPSec, never bare L2TP).
Recommendation: Enable if any LAN device dials out via L2TP/IPSec; otherwise leave as shipped (enabled is harmless but unnecessary).

3 IPSec Pass-throug

Protocol profile: IKE on UDP 500, ESP (protocol 50), AH (protocol 51), and NAT-Traversal (NAT-T) on UDP 4500.
Why NAT struggles: ESP/AH have no ports; without NAT-T, translated ESP packets cannot be demultiplexed per host.
What enabling it does: Allows IKE/ESP/AH flows and NAT-T encapsulation through the router so IPSec VPN clients behind NAT can negotiate security associations with external gateways.
Typical applications:
- Corporate remote-access VPN clients (strongSwan, Cisco IPSec client, vendor VPN utilities).
- Client-to-site tunnels from laptops and phones while off-premises.
Recommendation: Keep enabled in most business-adjacent environments; it is a prerequisite for virtually all client VPN software that uses IPSec.

Note: Pass-through makes the router transparent to these tunnels. It does not turn the router into a VPN server or endpoint.

D. The Application Layer Gateway Settings

1 FTP ALG

Protocol profile: Control on TCP 21; separate data channel (TCP 20 or ephemeral ports) negotiated in-band via PORT/PASV (and EPRT/EPSV) commands.
Why NAT struggles: The negotiated IP:port pairs live in the payload. An active-mode client behind NAT advertises its private address; a server behind NAT advertises the same in passive replies.
What enabling it does: The helper parses the control stream, rewrites embedded addresses to the router's public address, and opens pinholes for the resulting data connections.
Typical applications:
- Legacy file-transfer workflows and scripting tools using plain FTP.
- IP cameras, DVRs, and appliances that push recordings or logs to FTP servers.
- Hosting an FTP server behind the router (in combination with port forwarding).
Recommendation: Off by default in your screenshot; enable only when an FTP flow misbehaves (listings time out, transfers stall at "opening data connection"). Note that encrypted FTP (FTPS) hides the payload from the helper — prefer SFTP/HTTPS where possible.

2 TFTP ALG

Protocol profile: UDP 69 for the initial request; the server then switches to an ephemeral UDP port for the actual transfer.
Why NAT struggles: Return traffic arrives from a port the client never contacted, so plain connection tracking drops it.
What enabling it does: Tracks the negotiated ephemeral ports and opens the corresponding pinholes so the transfer completes.
Typical applications:

VoIP desk-phone firmware and configuration provisioning.
PXE/network booting of diskless workstations.
Configuration backup/restore and OS upgrades on switches, routers, and firewalls.

Recommendation: Enable only in networks that provision or boot devices via TFTP; otherwise leave disabled.

3 RTSP ALG

Protocol profile: Control on TCP/UDP 554; media (RTP/RTCP) on dynamic ports negotiated in the SETUP/Transport headers.
Why NAT struggles: Media channels are separate flows whose endpoints are described only inside the RTSP payload.
What enabling it does: Rewrites embedded transport parameters and opens pinholes for the RTP/RTCP streams belonging to each session.
Typical applications:

Remote viewing of IP surveillance cameras and NVRs via RTSP URLs.
Legacy media clients (QuickTime-era players, some VLC workflows) pulling live streams.
Streaming appliances and encoders behind the router.

Recommendation: Enable when remote RTSP sessions connect but show no media. Many modern devices offer "RTSP over TCP (interleaved)" or HTTPS streaming, which removes the need entirely.

4 H.323 ALG

Protocol profile: Q.931 signaling on TCP 1720, RAS on UDP 1719, H.245 and media (RTP/RTCP) on dynamic ports; addresses are embedded in binary ASN.1 (PER) encoding.
Why NAT struggles: Beyond payload embedding, the addresses are binary-encoded, so only a dedicated parser can rewrite them.
What enabling it does: Decodes H.323 signaling, rewrites embedded transport addresses, and pins open the dynamic H.245 and media channels.
Typical applications:

Legacy video-conferencing and telepresence systems (Polycom/Tandberg-class endpoints, Microsoft NetMeeting-era software).
Older VoIP gateways and PBXs that still speak H.323 trunks.

Recommendation: Leave disabled unless you operate H.323 equipment; SIP has largely superseded it.

5 SIP ALG

Protocol profile: Signaling on UDP/TCP 5060 (5061 for TLS); RTP/RTCP media on dynamic ports described in the SDP body; addresses also appear in Via, Contact, and Record-Route headers.
Why NAT struggles: Every call negotiates media endpoints inside SDP; without rewriting, media flows toward private addresses.
What enabling it does: Rewrites SDP and signaling headers to the router's public address and opens pinholes for the RTP/RTCP streams.
Typical applications:

VoIP desk phones, ATAs, and softphones registering to external providers.
SIP trunks terminating on a PBX behind the router.

Recommendation — handle with care: SIP ALG implementations are notoriously inconsistent. Modern endpoints using STUN/TURN/ICE or encrypted signaling/media (TLS/SRTP) often work better with the ALG disabled, because the helper cannot read encrypted payloads and may corrupt already-correct headers. Classic failure symptoms of a harmful SIP ALG include one-way audio, calls dropping after ~30 seconds, and flapping registrations. Test both states with your provider and document the winner.

E. Quick-Reference Matrix

Setting	Family	Key Ports / Protocols	Effect When Enabled	Typical Applications	Suggested State (Home / SOHO)
PPTP Pass-through	VPN helper	TCP 1723, GRE (47)	Tracks GRE tunnels through NAT	Legacy Windows/corporate PPTP VPN	Off unless required (insecure protocol)
L2TP Pass-through	VPN helper	UDP 1701 (+500/4500, ESP)	Allows L2TP/IPSec client tunnels	OS-native VPN clients	On if L2TP VPN in use
IPSec Pass-through	VPN helper	UDP 500/4500, ESP (50), AH (51)	Enables IPSec NAT-T traversal	Corporate remote-access VPN clients	On (harmless; needed by most VPN clients)
FTP ALG	Payload ALG	TCP 21 + dynamic data	Rewrites PORT/PASV; opens data pinholes	Legacy FTP transfers, camera/DVR uploads	Off unless plain FTP misbehaves
TFTP ALG	Payload ALG	UDP 69 + ephemeral	Tracks port-switched transfers	Phone provisioning, PXE boot, config backups	Off unless provisioning devices
RTSP ALG	Payload ALG	TCP/UDP 554 + RTP/RTCP	Rewrites transport headers; opens media pinholes	Remote IP-camera viewing, legacy streaming	Off unless streams show no media
H.323 ALG	Payload ALG	TCP 1720, UDP 1719 + dynamic	Rewrites ASN.1-encoded addresses	Legacy video conferencing, old VoIP gateways	Off
SIP ALG	Payload ALG	UDP/TCP 5060(-5061) + RTP/RTCP	Rewrites SDP/headers; opens media pinholes	VoIP phones, softphones, SIP trunks	Off by default; test both states with your provider

F. Configuration Best Practices

Apply the principle of least function. Every enabled helper parses live traffic and can open dynamic pinholes; disable anything your network does not use.
Remember directionality. This page fixes outbound-initiated sessions. Inbound publishing still needs Virtual Servers, Port Triggering, or DMZ.
Respect encryption boundaries. FTPS, SIPS/TLS, and SRTP conceal payloads from ALGs. With encrypted stacks, rely on passive modes, ICE/STUN/TURN, or explicit port forwarding instead.
Treat SIP ALG as a variable, not a constant. Benchmark call quality and registration stability with it on and off; keep whichever passes, and record the decision.
Re-verify after firmware upgrades. Helper defaults and behavior can change between builds.
Ignore the page in AP/Bridge mode. With NAT disabled, these helpers have nothing to translate.
Pair pass-through with server-side NAT-T. For IPSec/L2TP clients, confirm the VPN gateway supports NAT-Traversal; pass-through alone cannot compensate for a server that rejects UDP 4500.

G. Troubleshooting Map: Symptom → Setting

Symptom	Likely Cause	Action
PPTP VPN client fails (errors ~806/809)	GRE not tracked	Enable PPTP Pass-through
L2TP/IPSec client error 787/809	Tunnel stack blocked	Enable L2TP + IPSec Pass-through; verify server NAT-T
FTP stalls at "opening data connection" or listing fails	Active-mode FTP behind NAT	Enable FTP ALG, or switch to passive mode / SFTP
IP phones time out downloading firmware/config	TFTP port switch dropped	Enable TFTP ALG
RTSP control connects but no video appears	Media pinholes missing	Enable RTSP ALG, or force RTP-over-TCP on the device
One-way audio, calls drop at ~30 s, registration flaps	SIP ALG mangling SDP	Disable SIP ALG (or enable if provider mandates and no ICE/SRTP); retest
H.323 conference establishes signaling but no media	Binary-encoded addresses untranslated	Enable H.323 ALG

Closing Notes

The ALG page is best understood as the router's protocol interpreter desk: pass-through options let port-less VPN tunnels survive translation, while the five ALGs rewrite address information that legacy protocols hide inside their payloads. In a modern network — SFTP instead of FTP, ICE/SRTP VoIP, HTTPS streaming — most of these helpers can stay disabled, which is both cleaner and safer. Enable them surgically, only when a specific application proves it needs them, and validate behavior after every firmware change. That discipline keeps NAT transparent to the tools that require it, and invisible to everything else.

Understanding the ALG (Application Layer Gateway) Settings of the TP-Link WiFi Router