NAT Helpers: SIP ALG, H.323, and FTP Passive Mode

NAT Helpers: SIP ALG, H.323, and FTP Passive Mode

RouterOS NAT helpers (also called ALGs — Application Layer Gateways) are protocol-aware modules that extend connection tracking to handle protocols that embed IP addresses and port numbers inside their payloads. Standard NAT rewrites IP headers, but leaves payload references unchanged — helpers fix that gap for SIP, H.323, and FTP.

Helpers are managed under /ip firewall service-port. See Connection Tracking, States, and Helpers for the underlying related connection model.

How Helpers Work

When a protocol negotiates secondary connections (RTP media ports for VoIP, data channels for FTP), the helper:

1. Inspects the control channel payload and extracts embedded addresses/ports
2. Rewrites those addresses to work through NAT where needed
3. Registers a connection expectation in the conntrack table
4. When the secondary connection arrives, conntrack matches it as related

The related state is what lets a single firewall rule permit all secondary traffic:

/ip firewall filter
add chain=forward connection-state=established,related action=accept comment="Permit reply and helper-opened flows"
add chain=forward connection-state=invalid action=drop

Without this related accept rule, helpers cannot do their job even if enabled.

SIP ALG (VoIP through NAT)

What it does

SIP carries call setup and teardown. SIP messages (INVITE, OK, BYE) contain Contact:, Via:, and SDP body lines that advertise the sender’s IP address and RTP media port. Behind NAT, these contain the private IP — useless to the remote endpoint.

The SIP helper:

• Rewrites Contact:, Via:, and SDP c=/m= lines to use the public IP
• Registers RTP/RTCP port expectations so media flows are classified related
• Opens conntrack entries for the media streams

When to enable

Enable the SIP helper when:

• SIP phones or PBXs behind NAT have no built-in NAT traversal (no STUN, no ICE, no keepalive)
• You are using a basic SIP provider without a SIP proxy/SBC handling NAT
• Endpoints use standard SIP over UDP on port 5060

/ip firewall service-port set sip disabled=no
/ip firewall service-port print where name=sip

When to disable

Disable the SIP helper when:

• Phones or ATAs use STUN or ICE — they advertise the correct public IP themselves; ALG rewriting creates conflicts
• You route SIP through a SBC (Session Border Controller) — the SBC manages NAT; double rewriting corrupts headers
• SIP is carried over TLS (port 5061) — encrypted payload cannot be inspected; the helper is ineffective anyway
• You see registration failures, one-way audio, or cannot establish calls — these are classic double-ALG symptoms

/ip firewall service-port set sip disabled=yes

Tip

Most modern VoIP deployments using cloud PBXes (3CX, FreePBX with a SIP trunk, hosted Zoom Phone) include an SBC at the provider side. Disable the SIP helper in these deployments.

VoIP troubleshooting behind NAT

Symptom: one-way audio (caller hears nothing, or callee hears nothing)

The RTP media path is broken. The most likely cause is SDP body containing a private IP that the remote side cannot reach, or ALG rewriting conflicting with endpoint NAT traversal.

# Step 1: Check helper state
/ip firewall service-port print

# Step 2: Check active SIP connections and related RTP flows
/ip firewall connection print where dst-port~"5060"
/ip firewall connection print where connection-type=sip

# Step 3: Toggle the helper and retest
/ip firewall service-port set sip disabled=yes     # try without ALG
# or
/ip firewall service-port set sip disabled=no      # try with ALG

Symptom: SIP registration fails or drops intermittently

The SIP registration keepalive is not maintaining the NAT mapping. Check:

# Confirm NAT is applied to outbound SIP
/ip firewall nat print where action~"masquerade|src-nat"

# Confirm forward rule accepts related
/ip firewall filter print where connection-state~"related"

If registration drops after a timeout, the SIP phone’s keepalive interval may exceed the NAT table timeout. Shorten the conntrack timeout for UDP or configure keepalive on the phone (SIP OPTIONS ping or re-registration interval).

Symptom: calls work on LAN but fail when the phone is on the WAN

Double-check whether the WAN interface is in the masquerade/src-nat chain and that the SIP helper is monitoring the correct port:

/ip firewall service-port print detail where name=sip
# Confirm ports include 5060 (and 5061 if TLS is used — though TLS cannot be inspected)

---

H.323 Helper

What it does

H.323 is an older VoIP and video conferencing protocol used by legacy PBXes, Cisco CallManager (older versions), and video endpoints (Tandberg, Polycom). H.323 uses TCP port 1720 for the initial call control channel (H.225/Q.931), then negotiates additional ports for:

• H.245 control channel (dynamic TCP port)
• RTP/RTCP audio and video (dynamic UDP ports)
• T.120 data collaboration (optional)

The H.323 helper tracks the port negotiations in H.225 and H.245 and registers all negotiated channels as related.

When to enable

Enable when you have H.323 endpoints (IP phones, video conferencing systems, legacy PBX gateways) behind NAT. Without the helper, only the H.225 control channel on port 1720 reaches the endpoint; H.245 and media are blocked.

/ip firewall service-port set h323 disabled=no
/ip firewall service-port print where name=h323

When to disable

Disable H.323 helper when:

• No H.323 devices are deployed (reduce attack surface)
• H.323 traffic is managed by a gatekeeper or proxy that handles NAT
• All VoIP has migrated to SIP

/ip firewall service-port set h323 disabled=yes

H.323 troubleshooting

Symptom: calls connect but no audio or video

The H.245 or RTP channels are not getting through. Verify the helper is active and related is accepted:

/ip firewall service-port print where name=h323
/ip firewall filter print where connection-state~"related"

# Check for active H.323 expectations
/ip firewall connection print where connection-type=h323

Symptom: calls fail to connect entirely (not just no media)

The H.225 control channel on TCP 1720 may itself be blocked. Verify the forward chain permits outbound-initiated established traffic and that a dst-nat rule exists if the H.323 endpoint is being called inbound:

/ip firewall nat print where action~"dst-nat"

---

FTP Passive Mode Helper

What it does

FTP uses two TCP connections:

• Control channel: client → server port 21 (always)
• Data channel: negotiated dynamically, direction depends on mode

In passive mode (PASV, the default for most modern clients), the server picks a random high port and tells the client to connect to it in the PASV response. The client then opens a new connection to that port — a fresh new connection from the firewall’s perspective, easily blocked by a default-deny forward rule.

The FTP helper inspects PASV responses (and PORT commands for active mode), extracts the negotiated port, and registers a related expectation so the data connection is permitted automatically.

When to enable

Enable when:

• FTP clients behind NAT access external FTP servers (and a default-deny forward policy would otherwise block the data channel)
• FTP servers behind NAT accept inbound connections and use passive mode with a dynamic port range

/ip firewall service-port set ftp disabled=no

# If FTP server runs on a non-standard port, add it
/ip firewall service-port set ftp ports=21,2121

When to disable

Disable when:

• No FTP is in use (reduces conntrack load and attack surface)
• FTP clients and servers manage their own passive port range explicitly and you permit that range with static rules
• FTPS (FTP over TLS, explicit or implicit) is used — encrypted control channel prevents payload inspection; the helper is ineffective and should be disabled

/ip firewall service-port set ftp disabled=yes

FTP passive mode troubleshooting

Symptom: FTP login succeeds but directory listing hangs or file transfers fail

This is the classic passive FTP data channel problem. The PASV response reaches the client, but the data connection back to the server’s dynamic port is blocked.

# Step 1: Confirm FTP helper is enabled
/ip firewall service-port print where name=ftp

# Step 2: Check for active FTP expectations
/ip firewall connection print where connection-type=ftp

# Step 3: Confirm forward chain accepts related
/ip firewall filter print where connection-state~"related"

If step 2 shows no FTP connections or only the control connection, the helper is not parsing the payload. Verify:

• The control connection goes through the router (not bypassed via FastTrack)
• The FTP server is on standard port 21 (or the helper ports include the actual port)

Symptom: FTP works from LAN but fails from WAN (inbound to server behind NAT)

For inbound FTP servers, also configure:

• A dst-nat rule forwarding port 21 to the server
• Passive port range on the FTP server itself
• Either: helper enabled, or static forward rules for the passive port range

# Example: forward inbound FTP control to internal server
/ip firewall nat
add chain=dstnat in-interface-list=WAN protocol=tcp dst-port=21 \
    action=dst-nat to-addresses=192.168.1.10 to-ports=21

# If using a defined passive port range (e.g., 50000-51000) on the server,
# also forward those — or rely on the FTP helper for dynamic expectations
add chain=dstnat in-interface-list=WAN protocol=tcp dst-port=50000-51000 \
    action=dst-nat to-addresses=192.168.1.10

Note

FTPS (encrypted FTP) cannot be inspected by the helper. For FTPS servers behind NAT, always define an explicit passive port range on the server and create static firewall/NAT rules for those ports.

Symptom: FTP is FastTracked and the helper does not work

FastTrack bypasses connection tracking for accelerated flows. If an FTP session is FastTracked, the helper cannot inspect it:

/ip firewall filter print where action=fasttrack-connection

Exclude FTP from FastTrack:

/ip firewall filter
add chain=forward protocol=tcp dst-port=21 action=accept comment="Keep FTP in conntrack" \
    place-before=[find action=fasttrack-connection]

---

Enable/Disable Reference

Helper	Default	Enable when	Disable when
sip	enabled	Basic SIP phones with no NAT traversal	SBC/proxy handles NAT; STUN/ICE endpoints; SIP over TLS
h323	enabled	Legacy H.323 PBX/video endpoints behind NAT	No H.323 devices; gatekeeper manages NAT
ftp	enabled	FTP clients/servers with dynamic data channels behind NAT	FTPS in use; explicit port ranges with static rules; no FTP

# Check current helper states
/ip firewall service-port print

---

Common Mistakes

Accepting new but not related — if your forward policy only accepts new connections, helpers open expectations that are never matched:

# Correct baseline — always include related
/ip firewall filter
add chain=forward connection-state=established,related action=accept
add chain=forward connection-state=invalid action=drop

Double ALG — two devices on the path both rewriting SIP headers (e.g., the ISP modem/router in bridge mode is still running SIP ALG, and RouterOS SIP helper is also on). Disable the helper on one device.

FastTrack bypassing helpers — FastTrack accelerates flows by skipping conntrack processing. Protocols that require helper inspection must not be FastTracked. See Connection Tracking.