1) What ALG is doing on this router

Role on this router

The TP-Link WiFi AX/BE Router is a typical IPv4 NAT gateway. Every LAN device shares one public address. The connection tracker can follow a normal TCP or UDP flow because the reply comes back to the same 5-tuple the router already recorded. Several protocols do not behave that way. They open a control session, then name a second address and port inside the payload, or they carry a protocol that has no ports at all.

ALG (Application Layer Gateway) is the router’s built-in inspector for those cases. When a matching session leaves the LAN, the helper reads the control messages, replaces the private address with the WAN address, and installs a short-lived mapping so the return traffic reaches the right host. TP-Link describes it as customized NAT traversal filters for application-layer control/data protocols, and the on-screen note says to leave the defaults in place.

Nothing on this page opens the LAN to the internet by itself. A session still has to start from inside, or be allowed by Virtual Server, Port Triggering, UPnP, or DMZ.

Settings on the page

Setting	Protocol it helps	Typical ports / transport	What the helper does	Practical effect when enabled
PPTP Passthrough	Point-to-Point Tunneling Protocol	TCP 1723 plus GRE (IP protocol 47)	Associates the GRE tunnel with the control session so NAT can forward it	A LAN PC can dial a PPTP VPN through the router
L2TP Passthrough	Layer 2 Tunneling Protocol	UDP 1701, often with IPsec	Keeps the L2TP session mapping intact across NAT	L2TP or L2TP/IPsec clients on the LAN can connect outbound
IPSec Passthrough	IPsec	UDP 500, UDP 4500 (NAT-T), ESP (IP protocol 50)	Tracks IKE and ESP so the tunnel is not dropped as an unknown protocol	LAN clients can build outbound IPsec tunnels
FTP ALG	File Transfer Protocol	TCP 21, then a negotiated data port	Rewrites the PORT/PASV address inside the control channel and opens the data port	Active and passive FTP clients and servers behind NAT can transfer files
TFTP ALG	Trivial File Transfer Protocol	UDP 69, then a negotiated port	Creates the return mapping for the ephemeral UDP data flow	PXE boot, firmware pulls, and TFTP clients work through NAT
RTSP ALG	Real Time Streaming Protocol	TCP 554, then RTP/RTCP ports in the SDP	Opens the media ports announced in the session description	Some IP cameras and older media players can stream
H323 ALG	H.323	TCP 1720 and dynamically negotiated H.245/RTP ports	Rewrites call-signaling addresses so both sides can reach each other	Legacy video-conferencing clients, including old NetMeeting-style endpoints, can call through NAT
SIP ALG	Session Initiation Protocol	UDP/TCP 5060, plus RTP ports in SDP	Rewrites IP and port fields inside SIP and SDP so the provider sees the public address	Some desk phones register and place calls without STUN; many modern apps break when this rewrite is wrong

How the two groups differ

VPN passthrough (PPTP, L2TP, IPSec). These helpers exist because GRE and ESP are not port-based. Without passthrough, a laptop on Wi-Fi often authenticates and then stalls, or the tunnel never comes up. They do not create a VPN. The router’s own VPN Client and VPN Server menus are separate features. Passthrough only lets a device on the LAN run its own client toward a remote concentrator. Leaving them on is harmless if you never use those protocols. Turn one off only to diagnose a conflict with the router’s own VPN server on the same protocol.

Application ALGs (FTP, TFTP, RTSP, H.323, SIP). These parse payload. FTP ALG is the one most home users still need: without it, a client can log in on port 21 and then fail on the data connection, especially in active mode. TFTP ALG matters for network boot and some router or phone firmware updates. RTSP and H.323 are legacy; most current cameras and meeting apps use HTTPS, WebRTC, or their own NAT traversal and ignore these helpers.

What changes in the packet path

For an ordinary web connection the router only rewrites the IP header and the TCP or UDP ports. ALG adds a payload step for the protocols listed on the page.

1. A LAN client sends a control packet, for example FTP on TCP 21 or SIP on UDP 5060.
2. The connection tracker creates the usual outbound mapping.
3. The matching ALG parses the payload and finds an embedded private address, an announced data port, or a companion protocol such as GRE or ESP.
4. It rewrites that embedded address to the router’s public address and opens a temporary pinhole for the negotiated channel.
5. Reply traffic hits the pinhole and is forwarded to the original LAN host. When the control session ends, the extra mapping is removed.

That is the whole function. There is no encryption, no user authentication, and no policy based on device or website.

What it is not doing

• It is not the SPI firewall. Blocking or allowing traffic by rule is elsewhere under Security.
• It is not port forwarding. An FTP server, camera, or PBX that must accept unsolicited inbound connections still needs an explicit forward.
• It is not the router VPN. A phone running WireGuard, OpenVPN, or a modern IPsec client with NAT-T often works with or without these helpers.
• It does not inspect HTTPS, QUIC, or most current calling apps. Teams, Zoom, and similar clients use their own NAT traversal and never hit these helpers.
• It does not improve throughput or Wi-Fi. The helpers sit idle until a matching protocol appears.

---

2) The PPTP Passthrough and its applications

What the toggle controls

PPTP has two parts. The control channel is TCP port 1723. After the start-control-connection exchange, the actual tunnel is Generic Routing Encapsulation, IP protocol 47, which has no ports. A normal NAT table keys flows by protocol, source address, source port, destination address, and destination port. GRE fails that model, so the reply packets have nothing to match unless the router remembers which LAN host owns the TCP 1723 session and binds the following GRE packets to it.

PPTP Passthrough is that binding. TP-Link’s description is that, when enabled, Point-to-Point sessions can be tunneled through an IP network and passed through the router. The helper does four things:

• Watches outbound TCP 1723 from a LAN client.
• Associates the GRE tunnel that follows with that control session.
• Rewrites the addresses so return GRE reaches the same client.
• Drops the extra mapping when the control session ends.

Leave the switch on and a laptop, phone, or NAS on Wi-Fi can dial a remote PPTP concentrator. Turn it off and the client often authenticates, then stalls with no tunneled traffic. The router’s own VPN Client and VPN Server menus are unrelated. Passthrough does not create a tunnel to TP-Link’s cloud, and it does not accept inbound PPTP from the internet unless a separate port forward or the router’s VPN Server is configured.

How a session crosses this router

Step	What happens	What fails if passthrough is off
1	LAN client opens TCP 1723 to the remote PPTP server	Nothing yet; the control channel can still connect
2	Start-control-connection request and reply negotiate the call	Usually still succeeds
3	Client and server exchange GRE packets for PPP, authentication, and data	GRE has no port; NAT cannot map the return traffic
4	PPP comes up inside GRE and IP packets ride the tunnel	Tunnel never passes traffic, or drops after a few seconds

Multiple LAN clients can dial out at once only if the helper keeps each GRE call-ID pair tied to the right control session. That tracking is the real content of the feature. There is no per-device list and no port field on this page.

Applications that still use it

PPTP is obsolete as a security protocol. MS-CHAPv2 and the MPPE encryption historically wrapped inside it are cryptographically broken, and current operating systems have removed or buried the client. The passthrough toggle remains because old equipment and a few carrier or appliance workflows have not moved.

• Legacy remote-access clients. Older Windows deployments, some industrial PCs, and embedded devices still have a PPTP dialer and no OpenVPN, WireGuard, or IKEv2 stack. Passthrough is what lets those clients connect from behind this router.
• Old NAS and camera “VPN” features. Several consumer storage and NVR products exposed PPTP as their only remote-access method. A client on this LAN reaches that remote box only if GRE is passed.
• ISP or vendor diagnostic tunnels. A few access concentrators and managed CPE still accept PPTP for provisioning. Field tools expect the home router not to strip GRE.
• Lab and migration work. Moving a site off PPTP requires the old path to work until the new tunnel is proven. The helper keeps that path available during the cutover.
• Accidental enablement in router VPN menus. Some third-party firmware and older gateways still list PPTP as a client type. The router passthrough switch is what those clients depend on if the tunnel is terminated on a LAN device rather than on the TP-Link itself.

Modern remote access does not need this helper. WireGuard, OpenVPN over UDP, and IKEv2 with NAT traversal use ordinary UDP and their own keepalives. L2TP/IPsec and pure IPsec depend on the neighboring L2TP and IPSec Passthrough switches, not on PPTP.

When to leave it on or turn it off

Leave it on in the default state. An unused helper does not open an inbound listener, and disabling it does not harden the LAN against internet scans. Turn it off only for a narrow reason:

1. The router’s own PPTP VPN Server is in use and outbound passthrough conflicts with the local service on TCP 1723 or GRE.
2. A troubleshooting step requires proving that a failed VPN is not a GRE-mapping bug. Disable the toggle, retry, then restore it.
3. A security policy forbids PPTP anywhere on the network. The enforceable control is to stop deploying PPTP, not merely to hide the helper. Clients can still attempt TCP 1723; they just cannot complete the tunnel.

Inbound PPTP to a server on the LAN is a different problem. Passthrough will not publish that server. It needs an explicit forward for TCP 1723, and the router must also pass GRE to that host. Even then, PPTP is the wrong protocol to expose.

Practical boundary

PPTP Passthrough is a compatibility shim for a retired tunneling method. Enabled, it lets LAN-originated PPTP calls carry GRE back through NAT. Disabled, those calls die at the data channel. It has no role in Wi-Fi, ordinary browsing, or current VPN clients, and it should not be treated as a security feature or as a replacement for the VPN Client and VPN Server pages

---

3) The L2TP Passthrough and its applications

What the toggle controls

L2TP encapsulates PPP frames so a remote-access or site-to-site session can cross an IP network. The native control and data channel is UDP port 1701. Unlike PPTP, L2TP does not need GRE. It fails behind NAT for a different reason: the tunnel identifiers and the advertised endpoints inside the control messages are tied to the addresses the client and server believe they are using. A many-to-one NAT rewrites the outer UDP packet, and without a helper the inner call can be aimed at the private address or lose its return mapping.

L2TP Passthrough is that helper. TP-Link’s description is that, when enabled, Layer 2 Point-to-Point sessions can be tunneled through an IP network and passed through the router. The switch does three things:

• Recognizes outbound L2TP on UDP 1701 from a LAN client.
• Keeps the NAT mapping stable for the control and data packets of that tunnel.
• Forwards the return traffic to the same LAN host until the session ends.

It does not terminate the tunnel. The router’s VPN Client and VPN Server menus are separate features. Passthrough only lets a device on the LAN run its own L2TP client toward a remote concentrator.

How it relates to the IPSec toggle

Most real deployments are L2TP/IPsec, not bare L2TP. L2TP itself has no encryption. IPsec wraps it: IKE on UDP 500, NAT traversal on UDP 4500, and ESP as IP protocol 50. On this page those pieces are split.

Piece	Toggle that covers it	Port or protocol	Needed for
L2TP control and data	L2TP Passthrough	UDP 1701	Bare L2TP, and the inner tunnel of L2TP/IPsec
IKE	IPSec Passthrough	UDP 500	Negotiating the IPsec wrapper
NAT-T	IPSec Passthrough	UDP 4500	IPsec through this NAT, which is the normal case
ESP	IPSec Passthrough	IP protocol 50	Encrypted packets when NAT-T is not encapsulating them in UDP

A Windows, macOS, or mobile “L2TP” VPN almost always means L2TP/IPsec. Both L2TP Passthrough and IPSec Passthrough need to stay on. Bare L2TP on UDP 1701 is uncommon on the public internet because it is clear text; it shows up on private backbones and inside another already-encrypted path.

How a session crosses this router

1. The LAN client sends L2TP control traffic to the remote server on UDP 1701. If the profile is L2TP/IPsec, IKE on UDP 500 runs first and NAT-T usually moves the encrypted packets to UDP 4500.
2. The connection tracker creates the outbound UDP mapping.
3. L2TP Passthrough keeps that mapping bound to the tunnel identifiers so SCCRQ, SCCRP, and the later data messages return to the correct host.
4. PPP authenticates inside the tunnel, commonly with MS-CHAPv2, and IP traffic then rides the session.
5. When the control channel closes, the mapping is removed.

Multiple clients can dial out at once only if each tunnel’s identifiers stay tied to the right LAN address. That tracking is the content of the feature. There is no per-device list and no port field on this page.

Applications that still use it

L2TP/IPsec is past its prime. IKEv2, OpenVPN, and WireGuard are the usual replacements, and current phone platforms have dropped or hidden the built-in L2TP client. The helper remains because a large installed base still dials it.

• Built-in operating-system clients. Older Windows “VPN” connections, macOS L2TP profiles, and some Android builds use L2TP/IPsec with a pre-shared key. From this LAN they need both passthrough switches.
• Remote access to a company concentrator. Firewalls and VPN gateways that have not been migrated still present an L2TP/IPsec listener. A laptop connected to the the TPlink router reaches that listener only if UDP 1701 and the IPsec ports pass.
• NAS, firewall, and router “dial out” profiles. Some storage devices and edge routers still offer L2TP as a client protocol toward a central office. Passthrough matters when that client sits behind the TP-Link rather than on it.
• Carrier and managed-CPE leftovers. A few broadband and enterprise CPE stacks used L2TP to hand off a subscriber session. Field tools and remaining concentrators expect the home gateway not to break UDP 1701.
• Migration windows. Cutting a site over to IKEv2 or WireGuard requires the old L2TP path to work until the new tunnel is proven.

Modern clients do not need this helper. WireGuard and OpenVPN over UDP are ordinary UDP flows. IKEv2 with NAT traversal uses UDP 500 and 4500 and is covered, if at all, by IPSec Passthrough rather than by the L2TP switch.

When to leave it on or turn it off

Leave it on in the default state. An unused helper does not open an inbound listener, and disabling it does not harden the LAN. Turn it off only for a narrow reason:

1. The router’s own L2TP VPN Server is in use and outbound passthrough conflicts with the local listener on UDP 1701.
2. A failed L2TP/IPsec dial needs to be isolated. Disable L2TP Passthrough, retry, then restore it. Also test with IPSec Passthrough off and on; a one-way failure is often the IPsec half, not the L2TP half.
3. A policy forbids L2TP. The enforceable control is to stop deploying it. Clients can still send UDP 1701; they just cannot complete the tunnel. L2TP/IPsec with a pre-shared key is also a weak design: the key is shared, and the inner authentication is often MS-CHAPv2.

Inbound L2TP to a server on the LAN is a different problem. Passthrough will not publish that server. It needs an explicit forward for UDP 1701, and for L2TP/IPsec also UDP 500 and 4500, plus ESP handling. Even then, a current VPN protocol is the better choice to expose.

Practical boundary

L2TP Passthrough is a NAT compatibility shim for UDP 1701. Enabled, it lets LAN-originated L2TP calls keep a stable return path. Disabled, those calls fail even when the IPsec wrapper is healthy. Paired with IPSec Passthrough, it is what makes legacy L2TP/IPsec clients on this network able to connect. It has no role in ordinary browsing or in WireGuard and OpenVPN, and it is not a substitute for the VPN Client and VPN Server pages.

---

4) The IPSec Passthrough and its applications

What the toggle controls

IPsec is a family of protocols, not a single port. A typical client uses IKE to negotiate on UDP 500, then protects the data with ESP, which is IP protocol 50 and has no ports. If the path contains NAT, the client usually switches to NAT traversal and encapsulates ESP inside UDP 4500. AH, IP protocol 51, is rare on home networks because NAT breaks its integrity check.

A normal NAT table can track UDP 500 and UDP 4500. It cannot track ESP. The reply packets have no port to match unless the router remembers which LAN host owns the IKE session and binds the following ESP packets to it. IPSec Passthrough is that binding. TP-Link’s description is that, when enabled, IPsec can be tunneled through an IP network and passed through the router, using cryptographic security services for private communications over IP.

The helper does four things:

• Watches outbound IKE from a LAN client on UDP 500.
• Tracks the move to UDP 4500 when the peer detects NAT.
• Associates ESP with that negotiation so protocol 50 returns to the same host.
• Removes the extra mapping when the IKE security association ends.

It does not terminate the tunnel. The router’s VPN Client and VPN Server menus are separate. Passthrough only lets a device on the LAN run its own IPsec client toward a remote gateway.

How the pieces map to this page

Piece	Standard port or protocol	Covered by IPSec Passthrough	Also needs another toggle
IKEv1 or IKEv2 negotiation	UDP 500	Yes	No
NAT traversal	UDP 4500	Yes	No
ESP data	IP protocol 50	Yes	No
AH	IP protocol 51	Generally not used here	No
L2TP inside IPsec	UDP 1701	No	L2TP Passthrough

A pure IPsec client, including most IKEv2 remote-access profiles, needs only this switch. A Windows or macOS “L2TP” profile is L2TP/IPsec and needs this switch and L2TP Passthrough together. PPTP is unrelated.

How a session crosses this router

1. The LAN client sends IKE to the remote gateway on UDP 500. Vendor IDs in that exchange tell the peer whether NAT traversal is supported.
2. If either side sees a changed address, negotiation continues on UDP 4500 and ESP is encapsulated in UDP. The connection tracker can follow that UDP flow, and the helper keeps the mapping stable.
3. If the peer does not use NAT-T, data leaves as raw ESP. Passthrough binds those protocol-50 packets to the IKE session so replies reach the correct LAN host.
4. Child security associations come up, and IP traffic rides the tunnel. Dead-peer detection or NAT-T keepalives hold the mapping open.
5. When the IKE association closes, the extra state is removed.

Multiple clients behind the same public address can dial out at once only if each IKE security-association pair stays tied to the right LAN host. That tracking is the content of the feature. There is no per-device list and no port field on this page.

Applications that still use it

IPsec remains a current protocol. The passthrough helper is the legacy piece: it exists so clients that still emit ESP, or that negotiate poorly through NAT, can work behind a consumer router.

• IKEv2 remote access. Current Windows, macOS, iOS, and Android built-in VPN profiles often use IKEv2 with a certificate or EAP. NAT-T on UDP 4500 usually carries the tunnel. Passthrough keeps that path reliable when the client also emits ESP.
• Site-to-site tunnels from a device on the LAN. A firewall, lab gateway, or NAS behind the router can build an IKEv1 or IKEv2 tunnel to a central office. The helper matters most when that device does not encapsulate ESP in UDP.
• L2TP/IPsec clients. Older operating-system VPN entries negotiate IKE, then carry L2TP inside the IPsec wrapper. IPSec Passthrough covers the wrapper; L2TP Passthrough covers UDP 1701.
• Carrier and vendor diagnostic IPsec. Some managed CPE and appliance onboarding flows still use IKEv1 with a pre-shared key. Field tools expect the home gateway not to drop ESP.
• Migration and dual-running. A site moving from IKEv1 or L2TP/IPsec to WireGuard or OpenVPN may keep the old IPsec path up until the new tunnel is proven.

WireGuard and OpenVPN over UDP do not use this helper. They are ordinary UDP flows. An IPsec tunnel terminated by the router’s own VPN Client is also outside this toggle: the router originates that session on the WAN, so there is no LAN-side ESP to pass through.

When to leave it on or turn it off

Leave it on in the default state. An unused helper does not open an inbound listener, and disabling it does not harden the LAN. IPsec itself is a sound design; the weak cases are old settings, not the passthrough switch. Turn it off only for a narrow reason:

1. The router’s own IPsec VPN Server is in use and outbound passthrough conflicts with the local listener on UDP 500 or 4500.
2. A failed dial needs to be isolated. Disable IPSec Passthrough, retry, then restore it. If the profile is L2TP/IPsec, test L2TP Passthrough the same way. A tunnel that authenticates and then passes no traffic is often an ESP-mapping failure.
3. A policy prefers that LAN clients not build IPsec. The enforceable control is client configuration. Clients can still send UDP 500; they just cannot complete a non-NAT-T tunnel.

Inbound IPsec to a gateway on the LAN is a different problem. Passthrough will not publish that gateway. It needs an explicit forward for UDP 500 and 4500, and the router must also deliver ESP to that host. Clients behind this NAT should use NAT-T. Aggressive-mode IKEv1 with a pre-shared key is a poor choice to expose.

Practical boundary

IPSec Passthrough is a NAT compatibility shim for IKE, NAT-T, and ESP. Enabled, it lets LAN-originated IPsec calls keep a return path, including raw protocol-50 traffic that a port-based NAT table would drop. Disabled, NAT-T clients may still work, and ESP-only clients fail. Paired with L2TP Passthrough, it is what makes legacy L2TP/IPsec clients on this network able to connect. It has no role in ordinary browsing, WireGuard, or OpenVPN, and it is not a substitute for the VPN Client and VPN Server pages.

---

5) The FTP ALG and its applications

What the toggle controls

FTP splits every transfer into two TCP sessions. The control channel is normally port 21 and carries commands such as USER, PASS, PORT, PASV, LIST, and RETR. The file, directory listing, or resume data moves on a second connection whose port is negotiated in clear text inside that control channel. A normal NAT table rewrites the outer IP header. It does not rewrite the 192.168.x.x address embedded in the payload, so the data connection is aimed at an address the public internet cannot reach.

FTP ALG is that payload rewrite. TP-Link’s description is that, when enabled, FTP clients and servers can transfer data via NAT. The helper does four things:

• Watches outbound FTP control sessions, normally TCP 21.
• Parses PORT, PASV, EPRT, and EPSV replies.
• Replaces the private address with the router’s WAN address and opens a short-lived mapping for the announced data port.
• Removes that mapping when the control session ends.

It does not accept inbound FTP by itself. A server on the LAN that must receive connections from the internet still needs Virtual Server, Port Triggering, or DMZ for TCP 21, plus a working ALG if active mode is required.

Active mode and passive mode

Mode	Who opens the data connection	Command that carries the address	What the ALG must fix
Active	The server connects back to the client	PORT or EPRT from the client	The client’s private address and ephemeral port, otherwise the server’s callback never arrives
Passive	The client connects to the server	PASV or EPSV from the server	The server’s advertised address if the server sits behind NAT; less critical when the server is already on a public address and the client only needs the outbound data port opened

From a client on this LAN to a public FTP server, passive mode is the usual success path: the client opens both connections outbound. Active mode is the case that fails without the helper, because the server tries to call back to a private address. From the internet to an FTP server on this LAN, the helper matters in the other direction: the PASV reply must advertise the router’s public address, not 192.168.0.x.

How a transfer crosses this router

1. The LAN client opens TCP 21 to the FTP server. The connection tracker creates the normal outbound mapping, and the login proceeds in clear text.
2. The client sends PASV, or the server requests active mode and the client sends PORT 192,168,0,10,200,15, which means address 192.168.0.10 and port 200 × 256 + 15.
3. FTP ALG rewrites that address to the WAN address and installs a temporary data-port mapping.
4. The data connection carries the listing or file. The control channel stays open for the next command.
5. When the control session closes, the extra mapping is removed.

Multiple clients can transfer at once only if each announced port stays tied to the right LAN host. That tracking is the content of the feature. There is no port field on this page; the helper assumes the standard control port.

Applications that still use it

FTP is a clear-text protocol from 1971. Credentials and file contents are visible on the path. It remains in production because devices and workflows were built around it.

• Clients on this LAN reaching a public FTP server. Web-hosting accounts, software mirrors, and some vendor download sites still accept FTP. Passive mode often works anyway; active mode and broken PASV advertisements need the helper.
• NAS, camera, and printer “FTP upload” jobs. Recorders and multifunction printers push snapshots or scans to an FTP server. If the client uses active mode, the upload logs in and then fails without FTP ALG.
• A LAN FTP server published to the internet. Some NAS boxes and legacy web hosts still serve files on port 21. Virtual Server forwards the control port; FTP ALG rewrites PASV so remote clients receive a reachable data address.
• Embedded and industrial file drop. PLCs, data loggers, and older building-management systems often have an FTP client and no SFTP stack. The helper is what lets those transfers finish.
• Browser and scripted clients. ftp:// URLs and simple scripts still negotiate PORT or PASV. A login that succeeds and a listing that hangs is the typical ALG symptom.

SFTP does not use this toggle. It is SSH on TCP 22, with one encrypted channel and no embedded address. FTPS is the awkward middle case: once the control channel is encrypted with TLS, the router cannot read PASV or PORT, so FTP ALG cannot help and sometimes interferes. Explicit FTPS clients should have the helper off if transfers stall after AUTH TLS. Implicit FTPS on port 990 has the same limitation.

When to leave it on or turn it off

Leave it on in the default state. An unused helper does not open an inbound listener, and disabling it does not make FTP safe. Turn it off only for a narrow reason:

1. An FTPS client logs in, then hangs or fails the data connection. Disable FTP ALG and retry. If plain FTP then breaks, the network has both flows and the durable fix is to move the plain-FTP jobs to SFTP.
2. A troubleshooting step requires proving that a failed listing is a payload-rewrite problem. Disable the toggle, retry the same PASV transfer, then restore it.
3. A policy forbids FTP. The enforceable control is to stop deploying it. Clients can still open TCP 21; they just cannot complete the data channel in active mode.

Inbound FTP remains a separate exposure. Passthrough-style rewriting will not publish a server. Forwarding port 21 to a NAS also exposes clear-text passwords. SFTP or a VPN onto the LAN is the better remote-access design.

Practical boundary

FTP ALG is a NAT rewrite for the FTP control channel. Enabled, it lets active-mode clients and NAT-hosted servers finish the data connection that PORT and PASV negotiate. Disabled, logins can still succeed while listings and file transfers fail. It has no role in SFTP, HTTPS downloads, or ordinary browsing, and it does not replace a Virtual Server rule for an FTP server on the LAN.

---

6) The TFTP ALG and its applications

What the toggle controls

TFTP (Trivial File Transfer Protocol) uses a single UDP exchange rather than FTP’s two TCP channels. The client sends the first request — read (RRQ) or write (WRQ) — to UDP port 69. The server must not reply from port 69. It picks a new ephemeral port and sends the first data or acknowledgement packet from that port back to the client’s source port. Every later block follows that new pair.

A strict NAT or stateful firewall often expects the reply to come from the same port the client contacted. The packet from the server’s ephemeral port then looks unrelated and is dropped. The transfer times out after the initial request. TFTP ALG is the helper that understands this handshake. TP-Link’s description is that, when enabled, TFTP clients and servers can transfer data via NAT.

The helper does four things:

• Watches outbound TFTP requests to UDP 69.
• Treats the server’s reply from a newly chosen port as part of the same transfer.
• Installs a short-lived mapping so those return packets reach the LAN client that sent the RRQ or WRQ.
• Removes the mapping when the transfer completes or times out.

It does not accept inbound TFTP by itself. A TFTP server on the LAN that must answer unknown clients still needs an explicit forward for UDP 69, and the helper must also pass the ephemeral return port.

Why the port change breaks NAT

Step	Packet	What a normal NAT entry expects	What TFTP actually does
1	Client to server, UDP 69, RRQ or WRQ	Creates a mapping for replies from server port 69	Server accepts the request and leaves port 69
2	First data or acknowledgement	Reply from server port 69 to the client’s source port	Reply from a new server port, often above 1023
3	Following 512-byte blocks	Same 5-tuple for the whole transfer	Continues on the new pair until the last block, which is shorter than 512 bytes
4	End or error	Mapping expires	TID (transfer identifier) pair is discarded

The helper’s job is step 2. Without it, firmware pulls and boot files fail with a timeout even though the request reached the server. There is no login and no directory listing. TFTP either moves the file or it stops.

How a transfer crosses this router

1. A LAN device sends an RRQ or WRQ to the TFTP server on UDP 69. The connection tracker records the outbound mapping.
2. The server answers from a new ephemeral port with block 1, or with an acknowledgement if the client is writing.
3. TFTP ALG binds that new port to the original request and forwards the packet to the LAN device.
4. Client and server exchange numbered blocks. Lost blocks are retransmitted on the same pair. The last block is shorter than 512 bytes, which marks the end.
5. The temporary mapping is removed.

Multiple clients can transfer at once only if each server-side ephemeral port stays tied to the right LAN host. That tracking is the content of the feature. There is no port field on this page; the helper assumes the standard request port.

Applications that still use it

TFTP is clear text, has no authentication, and is limited to simple file copies. It survives because firmware and boot code can implement it in a few kilobytes.

• Network boot. PXE and similar loaders fetch a bootloader or configuration with TFTP after DHCP option 66 or 67 names the server. A PC on this LAN booting from a TFTP server on the internet, or on the far side of a VPN, needs the helper for the data blocks.
• Router, switch, and access-point firmware. Vendor recovery menus and upgrade tools often pull an image with TFTP. The device can contact the server and then stall if the ephemeral reply is dropped.
• Desk-phone and ATA provisioning. Some VoIP phones still fetch their configuration or firmware from a TFTP server named in DHCP. A phone on this Wi-Fi network fails provisioning when the ALG is off and the server is off-subnet.
• Embedded and industrial file drop. PLCs, printers, and building controllers use TFTP because the stack is small. Writes of logs or reads of config files depend on the return-port mapping.
• Lab and recovery work. A laptop serving TFTP to a device in recovery, or a device on the LAN pulling from a public recovery server, uses the same handshake.

SFTP, HTTPS, and modern device-management agents do not use this toggle. They run over a single TCP session whose reply port matches the connection tracker’s expectations.

When to leave it on or turn it off

Leave it on in the default state. An unused helper does not open an inbound listener, and disabling it does not harden the LAN. TFTP is unsafe to expose, but the risk is the server, not this switch. Turn it off only for a narrow reason:

1. A troubleshooting step requires proving that a timed-out transfer is a return-port problem. Disable TFTP ALG, retry the same RRQ, then restore it.
2. A policy forbids TFTP anywhere on the network. The enforceable control is to stop serving and fetching with it. Clients can still send UDP 69; they just cannot complete the block exchange.
3. An unusual server replies from port 69 and a broken helper is interfering. That behavior is non-standard. Test with the toggle off, then return it to the default if ordinary clients regress.

Inbound TFTP to a server on the LAN is a different problem. Passthrough-style tracking will not publish that server. Forwarding UDP 69 also exposes an unauthenticated write path. Keep TFTP on a dedicated recovery VLAN, or reach the server through a VPN, instead of publishing it on the WAN.

Practical boundary

TFTP ALG is a NAT helper for UDP 69’s port-changing handshake. Enabled, it lets LAN clients finish read and write transfers whose replies come from an ephemeral server port. Disabled, the request can leave and the data blocks never return. It has no role in FTP, SFTP, or ordinary browsing, and it does not replace a forward rule for a TFTP server on the LAN.

---

7) The RTSP ALG and its applications

What the toggle controls

RTSP is the control protocol. A client talks to a camera or media server, normally on TCP 554, with methods such as OPTIONS, DESCRIBE, SETUP, PLAY, and TEARDOWN. The audio and video do not travel on that TCP session. The server answers SETUP with a Transport header that names the RTP and RTCP ports, and the session description from DESCRIBE carries the same information in SDP. Those UDP ports are dynamic. A normal NAT table has never seen them, so the media packets have nowhere to go.

RTSP ALG is the helper that parses that negotiation. TP-Link’s description is that, when enabled, RTSP clients and servers can transfer data via NAT. The helper does four things:

• Watches RTSP control sessions, normally TCP 554.
• Reads the transport ports announced in SETUP and in the SDP.
• Installs short-lived mappings so RTP and RTCP reach the LAN client, or so a LAN camera’s announced ports are reachable if the session is inbound.
• Removes those mappings when the RTSP session ends.

It does not publish a camera by itself. A viewer on the internet still needs Virtual Server, Port Triggering, or a VPN to reach TCP 554 on a LAN device. The helper only repairs the media ports that follow a control session the router has already allowed.

Control channel and media channel

Piece	Typical transport	What the ALG looks for	What fails if the helper is off
RTSP control	TCP 554	SETUP and Transport headers	Nothing yet; DESCRIBE can still succeed
RTP media	UDP, even port negotiated in SDP	client_port / server_port and the matching pinhole	Video never starts, or starts and freezes
RTCP reports	UDP, usually the next odd port	The companion port in the same transport line	Stream may play, then stall without feedback
Interleaved mode	RTP stuffed inside the RTSP TCP session	Nothing to open	Usually works without the helper

Interleaved RTP over the existing TCP connection is the path that does not need this toggle. Many current players request that mode when they detect NAT. Older cameras and players insist on separate UDP ports, which is the case the helper exists for.

How a viewing session crosses this router

1. A client on the LAN opens TCP 554 to a camera or media server. The connection tracker creates the normal outbound mapping.
2. DESCRIBE returns the SDP. SETUP then names the client ports and the server ports for RTP and RTCP.
3. RTSP ALG reads those ports and opens temporary UDP mappings. If the camera is the LAN device, it also rewrites a private address in the transport line to the WAN address.
4. PLAY starts the stream. RTP carries the media; RTCP carries loss and timing reports.
5. TEARDOWN, or a timed-out control session, removes the extra mappings.

Multiple streams can run at once only if each announced port pair stays tied to the right LAN host. That tracking is the content of the feature. There is no port field on this page; the helper assumes the standard RTSP control port.

Applications that still use it

RTSP is still common on cameras. It is no longer the way phones and browsers watch video. HLS, DASH, and WebRTC do not use this toggle.

• IP cameras and NVRs. ONVIF and most budget cameras expose an rtsp:// URL on port 554. A viewer on this LAN can open the control channel and then receive no picture if the camera forces UDP RTP and the helper is off.
• Older media players. VLC, some set-top clients, and legacy surveillance software request UDP transport by default. The symptom is a successful connect and a black window.
• Intercoms and doorbells that predate cloud apps. A few still push an RTSP session to a local monitor or a remote recorder. The media path depends on the announced RTP ports.
• Lab and integration work. Testing a camera’s rtsp://user:pass@host:554/stream1 URL from a laptop on this Wi-Fi network uses the same handshake.

Cloud camera apps, YouTube, and browser players are out of scope. They use HTTPS or their own UDP stacks. A camera that only offers RTSP over TLS also limits the helper: once the control channel is encrypted, the router cannot read the Transport header.

When to leave it on or turn it off

Leave it on in the default state. An unused helper does not open an inbound listener, and disabling it does not hide a camera. Turn it off only for a narrow reason:

1. A known-good stream fails only when the helper rewrites the transport line. Some cameras embed a token or a fixed port that a naive rewrite corrupts. Disable RTSP ALG, force the player to use TCP interleaved transport, and retest.
2. A troubleshooting step requires proving that a black picture is a missing UDP mapping. Disable the toggle, retry the same URL, then restore it.
3. A policy forbids RTSP toward the internet. The enforceable control is not to forward port 554. Clients on the LAN can still open outbound RTSP; they just cannot complete UDP media.

Inbound RTSP to a camera on the LAN is a separate exposure. The helper will not publish that camera, and forwarding 554 exposes a protocol that often carries weak or embedded credentials. A VPN onto the LAN, or the vendor’s cloud relay, is the better remote-viewing design.

Practical boundary

RTSP ALG is a NAT helper for the ports negotiated on TCP 554. Enabled, it lets UDP RTP and RTCP follow an RTSP control session across the router. Disabled, the control channel can still connect while the picture never arrives. It has no role in HLS, DASH, WebRTC, or ordinary browsing, and it does not replace a forward or a VPN for a camera that must be viewed from outside the LAN.

---

8) The H323 ALG and its applications

What the toggle controls

H.323 is a suite, not a single port. Call signaling uses H.225.0, normally on TCP 1720. Once the call is accepted, H.245 negotiates capabilities and the RTP ports for audio and video. Those H.245 and media ports are dynamic, and the messages contain the endpoint’s own IP address. A normal NAT table rewrites the outer header. It does not rewrite the private address inside H.225 or H.245, so the far end tries to open media to 192.168.x.x and the call connects with no audio or video.

H323 ALG is that rewrite. TP-Link’s description is that, when enabled, Microsoft NetMeeting clients can communicate via NAT. NetMeeting is the historical example; the same helper covers other H.323 endpoints. The helper does four things:

• Watches outbound H.225 call signaling, normally TCP 1720.
• Tracks the dynamically assigned H.245 control channel.
• Rewrites embedded private addresses to the WAN address and opens short-lived mappings for the announced RTP and RTCP ports.
• Removes those mappings when the call ends.

It does not accept inbound calls by itself. An endpoint on the LAN that must receive calls from the internet still needs a forward for TCP 1720, or a gatekeeper that keeps a registration open from the inside.

The channels a call uses

Channel	Typical transport	What the ALG must fix	Symptom if the helper is off
H.225.0 call signaling	TCP 1720	Address inside the setup message, and the mapping for the call	Call may not establish, or establishes and then stalls
H.245 media control	TCP, port negotiated in H.225	The announced control address and port	Capabilities never finish; no logical channels open
RTP audio and video	UDP, even ports from H.245 OpenLogicalChannel	Pinholes for each logical channel	Call rings or connects, then one-way or no media
RTCP	UDP, usually the next odd port	Companion mapping	Media starts, then drifts or stalls
RAS to a gatekeeper	UDP 1719	Registration and admission replies	Endpoint cannot register, so calls never start

Fast Start skips a separate H.245 session and proposes media channels inside the H.225 setup. The helper still has to rewrite those addresses. Tunneled H.245 inside the H.225 TCP session is easier for NAT; separate H.245 is the case that fails without the ALG.

How a call crosses this router

1. A LAN endpoint sends an H.225 setup to a remote endpoint or gatekeeper on TCP 1720. The connection tracker creates the outbound mapping.
2. The setup message contains the caller’s private address and, in Fast Start, proposed RTP ports. H323 ALG rewrites that address to the WAN address.
3. If H.245 is separate, the called party announces a control port. The helper opens that mapping and rewrites the address in the H.245 messages.
4. OpenLogicalChannel names the RTP and RTCP ports. The helper pinholes those UDP ports and PLAY-equivalent media starts.
5. Call release tears down the extra mappings.

Multiple calls can run at once only if each negotiated port stays tied to the right LAN endpoint. That tracking is the content of the feature. There is no port field on this page; the helper assumes the standard H.323 signaling ports.

Applications that still use it

H.323 has been displaced by SIP and by WebRTC. It remains on older video estates and on a few carrier interconnects.

• Legacy video-conferencing endpoints. Older Polycom, Cisco, Lifesize, and similar room systems place H.323 calls to an IP address or a gatekeeper. An endpoint on this LAN can signal and then fail media without the helper.
• Microsoft NetMeeting-style clients. TP-Link names this case because those clients were the consumer H.323 stack. They are obsolete, but the same signaling is what the toggle was built for.
• Gatekeeper-routed estates. A LAN endpoint registering to an external gatekeeper on UDP 1719, then placing calls through it, needs the RAS and H.225 mappings kept intact.
• PBX and trunk leftovers. Some older PBXs still offer an H.323 trunk to a carrier or to another site. A trunk terminated on a device behind this router depends on the address rewrite.
• Migration windows. A room system being moved to SIP may keep an H.323 neighbor dialed until the new path is proven.

Zoom, Teams, FaceTime, and browser calling do not use this toggle. They use WebRTC or proprietary media over HTTPS and their own NAT traversal. A modern SIP desk phone depends on SIP ALG, not H323 ALG.

When to leave it on or turn it off

Leave it on in the default state. An unused helper does not open an inbound listener, and disabling it does not harden the LAN. Turn it off only for a narrow reason:

1. A known H.323 endpoint fails only when the helper rewrites H.225 or H.245. Some stacks embed a token or expect their own NAT traversal. Disable H323 ALG, retest, and keep it off only if that endpoint is the one in use.
2. A troubleshooting step requires proving that a no-media call is a missing logical-channel mapping. Disable the toggle, place the same call, then restore it.
3. A policy forbids H.323 toward the internet. The enforceable control is not to forward TCP 1720. LAN clients can still open outbound signaling; they just cannot complete media.

Inbound H.323 to an endpoint on the LAN is a separate exposure. The helper will not publish that endpoint. Forwarding 1720 also exposes an old stack with a long history of parsing bugs. A VPN onto the LAN is the better remote-access design.

Practical boundary

H323 ALG is a NAT rewrite for H.225, H.245, and the RTP ports they announce. Enabled, it lets legacy video clients complete a call across the router instead of connecting with no media. Disabled, signaling can still start while audio and video never arrive. It has no role in SIP, WebRTC, or ordinary browsing, and it does not replace a forward or a VPN for an H.323 endpoint that must receive calls from outside the LAN.

---

9) The SIP ALG and its applications

What the toggle controls

SIP separates signaling from media. A phone registers and places calls on SIP, normally UDP or TCP 5060. The audio rides RTP on ports named inside the SDP body of the INVITE and the 200 OK. Those messages contain the phone’s own address in headers such as Via, Contact, and Call-ID routing fields, and again in the SDP c= and m= lines. A normal NAT table rewrites the outer IP header. It does not rewrite the private address in the payload, so the provider sends RTP to 192.168.x.x and the call rings with one-way or no audio.

SIP ALG is that payload rewrite. TP-Link’s description is that, when enabled, clients can communicate with SIP servers via NAT. The AX-series manual adds the exception: disable it when voice or video applications fail, because some of them do not work with SIP ALG. On this router the helper does four things:

• Watches outbound SIP on the standard signaling port, normally UDP and TCP 5060.
• Replaces private addresses and ports in the signaling headers and in the SDP with the WAN address and a mapped port.
• Opens short-lived UDP mappings for the RTP and RTCP ports announced in that SDP.
• Rewrites the matching fields in the reverse direction so the phone still sees a coherent dialog.

It does not accept inbound calls by itself. A PBX on the LAN that must receive unsolicited SIP from the internet still needs a forward, a session border controller, or a registration that keeps the mapping alive from the inside.

Signaling and media

Piece	Typical transport	What the ALG rewrites	Symptom if the rewrite is wrong
Registration	UDP or TCP 5060, REGISTER	Contact and Via, so the provider can refresh the binding	Phone never registers, or drops after the first expiry
Call setup	INVITE, 180, 200 OK, ACK	SDP c= address and m= port	Call rings, then no audio or one-way audio
RTP media	UDP, even port from SDP	Pinhole, and sometimes the port itself	Audio in one direction only
RTCP	UDP, usually the next odd port	Companion mapping	Audio starts, then drifts or drops
In-dialog requests	Same signaling socket	Route, Record-Route, and the rewritten Contact	Hold, transfer, or hang-up fails

A correct rewrite is invisible: the provider sees the public address, and the phone still matches its own dialog. A bad rewrite changes a port the phone already set, breaks the authentication response, or fights a second rewrite done by the provider.

How a call crosses this router

1. The phone sends REGISTER to the provider on UDP 5060. The connection tracker creates the outbound mapping. SIP ALG rewrites Contact so later inbound requests return to this NAT entry.
2. An outbound INVITE carries SDP that still says 192.168.0.20 and an RTP port. The helper substitutes the WAN address and opens that RTP mapping.
3. The provider’s 200 OK carries its own SDP. RTP flows on the pinholed ports in both directions.
4. In-dialog requests such as BYE and re-INVITE must use the same rewritten route. A mismatch here drops the call on hold or on transfer.
5. When the registration expires and no dialog remains, the extra mappings age out.

Multiple phones can register at once only if each rewritten Contact stays tied to the right LAN device. That tracking is the content of the feature. There is no port field on this page. Phones that signal on a non-standard port are often ignored by the helper.

Applications that still use it

SIP is current. SIP ALG is the disputed piece. It helps a simple endpoint that has no NAT traversal of its own, and it harms an endpoint that already does traversal correctly.

• Basic desk phones and ATAs. A phone with no STUN, ICE, or outbound-proxy keepalive can register and place calls only because the helper rewrote Contact and SDP. This is the application the toggle was built for.
• Hosted-PBX phones that expect the router to fix NAT. Some small-business installs were documented with “enable SIP ALG” and no STUN server. They depend on this rewrite.
• Internal SIP between subnets. A phone on this LAN calling an endpoint that is not doing ICE can need the announced address corrected at the NAT boundary.
• Lab and migration. Comparing a phone with the helper on and off is the standard test when audio fails.

These do not use the toggle: Teams, Zoom, FaceTime, WhatsApp, and browser calling use WebRTC or a proprietary tunnel. A softphone that uses ICE and a provider session border controller already learns its public address and should not be rewritten again. SIPS on TLS also limits the helper, because the router cannot read an encrypted SIP body.

When to leave it on or turn it off

TP-Link’s default is on, with an explicit note to disable it if voice or video calls fail. Use that symptom, not a blanket rule.

Leave it on when a simple SIP phone will not register, or registers and has no audio, and the phone has no STUN or ICE setting to enable. Turn it off when any of these appear:

1. One-way or no audio while the call still connects. The provider and the ALG have both rewritten SDP, or the ALG mapped a port the phone is not sending on.
2. Registration drops after the first call, or the phone stays registered and cannot receive calls. The rewritten Contact does not match the binding the provider stored.
3. The provider or the phone vendor documents “disable SIP ALG.” Hosted-PBX platforms commonly require this because their edge already corrects NAT.
4. Hold, transfer, or a second call fails while the first call works. An in-dialog request hit a route the helper altered.

The test is one toggle and one phone. Disable SIP ALG, reboot the phone or wait for re-registration, then place an inbound and an outbound call and confirm two-way audio. Restore the toggle only if that phone gets worse. Other ALG switches on this page do not affect SIP.

Inbound SIP to a PBX on the LAN is a separate exposure. The helper will not publish that PBX. Forwarding 5060 to it also exposes an authentication surface that is scanned constantly. A VPN, or the provider’s own edge with registration from the inside, is the better design.

Practical boundary

SIP ALG is a NAT rewrite for SIP headers and SDP on port 5060. Enabled, it can let a basic phone register and pass audio without STUN. Disabled, phones that do their own NAT traversal stop fighting the router, which is the usual fix for one-way audio. It has no role in Teams, Zoom, or ordinary browsing, and it does not replace a forward or a VPN for a PBX that must receive SIP from outside the LAN.

---

10) Recommended baseline

The factory state is the recommended baseline. Change a switch only to fix a named failure, then put it back if the failure was not that helper.

Baseline

Setting	Recommended state	Why it stays this way	Change it only if
PPTP Passthrough	On	Lets a LAN client finish a GRE tunnel after TCP 1723; idle if unused	The router’s own PPTP server conflicts, or a policy forbids PPTP and you are testing
L2TP Passthrough	On	Keeps UDP 1701 stable for legacy L2TP and L2TP/IPsec clients	The router’s own L2TP server conflicts, or you are isolating a failed dial
IPSec Passthrough	On	Binds IKE, NAT-T, and ESP to the LAN client that started the tunnel	The router’s own IPsec server conflicts, or ESP mapping is the suspect in a failed tunnel
FTP ALG	On	Rewrites PORT and PASV so the data connection is not aimed at a private address	An FTPS client stalls after AUTH TLS because the control channel is encrypted
TFTP ALG	On	Accepts the server’s reply from an ephemeral port after the request to UDP 69	A non-standard server replies from port 69 and the helper interferes
RTSP ALG	On	Opens the RTP ports announced on TCP 554	A camera stream works only with the helper off, or the player is forced to TCP interleaved mode
H323 ALG	On	Rewrites H.225 and H.245 addresses so legacy video calls get media	A known H.323 endpoint fails only when the rewrite is active
SIP ALG	On, until a call fails	Helps a basic phone with no STUN or ICE; harms phones whose provider already fixes NAT	One-way audio, dropped registration, or the provider says to disable SIP ALG

TP-Link’s own note on this page matches that table: keep the defaults. The AX-series manual adds one explicit exception, SIP ALG, for voice and video applications that do not work with the rewrite.

How to apply it

1. Leave all eight switches on if nothing is broken. An unused helper does not open an inbound listener and does not add a meaningful attack path.
2. If a SIP desk phone or ATA has one-way audio, failed inbound calls, or a registration that dies after the first call, turn off only SIP ALG. Reboot the phone or wait for re-registration, then test inbound, outbound, and two-way audio.
3. If plain FTP logs in and then hangs on the listing, confirm FTP ALG is on and prefer passive mode. If the failure starts only after AUTH TLS, turn FTP ALG off for that FTPS client, or move the job to SFTP.
4. If a PPTP, L2TP, or IPsec client authenticates and then passes no traffic, confirm the matching passthrough switch is on. L2TP/IPsec needs both L2TP Passthrough and IPSec Passthrough.
5. Do not use this page to publish a server. Cameras, FTP, TFTP, SIP, and H.323 listeners on the LAN still need Virtual Server, a VPN, or the vendor’s cloud relay.

What the baseline deliberately does not do

• It does not retire PPTP or clear-text FTP. Those protocols are weak; the fix is to stop deploying them, not to hide the helper.
• It does not improve Wi-Fi, browsing, or streaming. Teams, Zoom, WireGuard, OpenVPN, SFTP, and HTTPS never hit these helpers.
• It does not replace the VPN Client or VPN Server menus. Passthrough only lets a LAN device run its own client.

The operating baseline for this router is the screenshot: every toggle on, with SIP ALG as the one switch to clear when a provider-hosted phone misbehaves.

---