Connection Tracking, States, and Helpers

Connection Tracking, States, and Helpers

Connection tracking (conntrack) is the foundation of stateful packet inspection in RouterOS. It maintains a table of active network connections so the firewall can make decisions based on the state of a flow rather than examining each packet in isolation. Without connection tracking, you would need explicit rules for both directions of every permitted connection.

RouterOS also includes Application Layer Gateway (ALG) helpers — protocol-aware modules that extend connection tracking to complex protocols like FTP and SIP that negotiate secondary connections on dynamic ports.

How Connection Tracking Works

When a packet arrives, RouterOS inspects the connection table and either associates it with an existing tracked flow or creates a new entry. The packet receives a connection-state classification before reaching your filter rules. Rules matching connection-state=established,related can then accept all return traffic for permitted connections with a single rule.

Connection tracking operates transparently — you configure the firewall rules that consume connection state, and RouterOS maintains the table automatically.

Connection States

RouterOS classifies every packet into one of five connection states.

State	Description
new	First packet of a flow not yet in the connection table
established	Packet belonging to a tracked flow that has seen traffic in both directions
related	Packet initiating a secondary connection spawned by an existing tracked flow
invalid	Packet that cannot be associated with any known connection
untracked	Packet explicitly excluded from tracking via a raw table notrack rule

new

The new state applies to the first packet of a flow — a TCP SYN, the first UDP datagram to a destination, or an ICMP echo request. RouterOS creates a connection table entry to track the flow. Subsequent packets in the same flow transition to established once traffic is seen in both directions.

In a default-deny firewall, new packets represent connection initiation attempts and require explicit per-service rules to permit them.

established

Once a TCP three-way handshake completes, or once a UDP or ICMP exchange receives a reply, both directions of the flow are marked established. All subsequent packets in that flow — including return traffic from the server — carry this state.

Accepting established traffic with a single early rule is the standard stateful firewall pattern. It avoids writing explicit rules for every possible response packet.

related

The related state covers secondary connections spawned by an existing tracked flow. Common examples:

• FTP data channel: The control connection on port 21 negotiates a data connection on a dynamic port. The FTP helper registers this expectation and marks the data connection related.
• SIP media streams: SIP signaling negotiates RTP media channels that are tracked as related.
• ICMP error messages: An ICMP “destination unreachable” or “time exceeded” response to an existing TCP/UDP flow is related to that flow.

Connection helpers (ALGs, configured under /ip firewall service-port) are responsible for detecting and registering related connections. If a helper is disabled, the secondary connections appear as new instead and must be permitted by explicit rules — or blocked if unintended.

invalid

Packets that cannot be associated with any known connection are invalid. Common causes:

• A TCP RST or FIN arrives for a connection that has already closed or never existed
• Out-of-sequence packets or incorrect TCP flags
• The connection table entry expired but traffic continues arriving
• Asymmetric routing — the router sees only one direction of a flow

Drop all invalid packets at the top of every chain. Invalid packets serve no legitimate purpose and may indicate scanning, spoofing, or misconfiguration. Allowing them can cause unpredictable behavior in applications and NAT.

/ip firewall filter add chain=input  connection-state=invalid action=drop comment="drop invalid"
/ip firewall filter add chain=forward connection-state=invalid action=drop comment="drop invalid forward"

untracked

The untracked state is assigned by a raw table notrack rule. Packets excluded from tracking bypass the connection table entirely. Use this for high-throughput trusted transit traffic where connection tracking overhead is undesirable.

/ip firewall raw add chain=prerouting src-address=10.0.0.0/8 dst-address=10.0.0.0/8 \
    action=notrack comment="Bypass tracking for internal transit"

When a packet is untracked, NAT rules and ALG helpers do not apply to it because both depend on the connection table.

Connection Tracking Configuration

Global connection tracking settings are managed under /ip firewall connection tracking.

Properties

Property	Default	Description
enabled	yes	Enable or disable connection tracking globally. auto disables when no firewall or NAT rules use connection state.
max-connections	200000	Maximum simultaneously tracked connections. When the table is full, new connections are dropped.
tcp-syn-sent-timeout	5s	Timeout for TCP connections where only a SYN has been sent
tcp-syn-received-timeout	5s	Timeout for TCP connections in SYN-RECEIVED state
tcp-established-timeout	1d	Timeout for fully established TCP connections
tcp-fin-wait-timeout	10s	Timeout for TCP connections in FIN-WAIT state
tcp-close-wait-timeout	1m	Timeout for TCP connections in CLOSE-WAIT state
tcp-last-ack-timeout	30s	Timeout for TCP connections awaiting final ACK
tcp-time-wait-timeout	10s	Timeout for TCP connections in TIME-WAIT state
tcp-close-timeout	10s	Timeout for TCP connections in CLOSE state
tcp-unacked-timeout	5m	Timeout for established TCP with unacknowledged data
udp-timeout	30s	Timeout for UDP flows with no reply seen
udp-stream-timeout	3m	Timeout for UDP flows after a reply has been seen
icmp-timeout	30s	Timeout for ICMP flows
generic-timeout	10m	Timeout for all other protocols

Viewing and Changing Settings

/ip firewall connection tracking print

Example output:

Flags: X - disabled
 0   enabled=yes max-connections=200000 tcp-syn-sent-timeout=5s
     tcp-syn-received-timeout=5s tcp-established-timeout=1d
     tcp-fin-wait-timeout=10s tcp-close-wait-timeout=1m
     tcp-last-ack-timeout=30s tcp-time-wait-timeout=10s
     tcp-close-timeout=10s tcp-unacked-timeout=5m
     udp-timeout=30s udp-stream-timeout=3m icmp-timeout=30s
     generic-timeout=10m

Timeout Tuning

Default timeouts are conservative. Adjust based on your environment:

High-connection environments (NAT gateways, web servers):

# Shorter established timeout frees table entries sooner
/ip firewall connection tracking set tcp-established-timeout=12h

# Faster UDP recycling for DNS-heavy routers
/ip firewall connection tracking set udp-timeout=10s udp-stream-timeout=30s

Long-lived applications (database connections, VPN keepalives):

/ip firewall connection tracking set tcp-established-timeout=2d
/ip firewall connection tracking set udp-stream-timeout=10m

High-traffic routers approaching the connection limit:

/ip firewall connection tracking set max-connections=500000

Check the current count before adjusting:

/ip firewall connection print count-only

Viewing the Connection Table

The connection table (/ip firewall connection) shows all currently tracked flows.

Connection Table Fields

Field	Description
src-address	Source IP and port of the originating side
dst-address	Destination IP and port
reply-src-address	Source of reply packets (reflects NAT rewriting)
reply-dst-address	Destination of reply packets (reflects NAT rewriting)
protocol	IP protocol (tcp, udp, icmp, etc.)
state	Current TCP state (established, time-wait, etc.)
timeout	Time remaining before the entry expires
connection-mark	Mark assigned by mangle rules
assured	Whether traffic has been seen in both directions

Inspecting Connections

# Show all tracked connections
/ip firewall connection print

# Show connections to a specific host
/ip firewall connection print where dst-address~"192.168.88.100"

# Show all TCP connections
/ip firewall connection print where protocol=tcp

# Show connections from a subnet
/ip firewall connection print where src-address~"10.0.0"

# Watch connection table in real time
/ip firewall connection print interval=1

# Count total tracked connections
/ip firewall connection print count-only

Removing Connections

Manually removing entries forces re-establishment — useful when firewall or NAT rules change and existing connections bypass the new rules.

# Remove all connections (disrupts all active traffic)
/ip firewall connection remove [find]

# Remove connections to a specific host
/ip firewall connection remove [find dst-address~"203.0.113.50"]

Caution

Removing active connections disrupts ongoing traffic. TCP sessions must re-establish, causing brief interruptions for affected applications.

Connection Tracking Helpers (ALGs)

Connection tracking helpers — also called Application Layer Gateways (ALGs) or “service ports” — are protocol-aware modules that inspect application-layer control channels to track secondary connections. Many protocols negotiate data channels on dynamic ports that would otherwise be blocked by a stateful firewall.

Helpers are managed under /ip firewall service-port.

/ip firewall service-port print

Example output:

Flags: X - disabled, I - invalid
 #   NAME       PORTS
 0   ftp        21
 1   tftp       69
 2   irc        6667
 3   h323
 4   sip        5060, 5061
 5   pptp

How Helpers Work

When a helper is active, RouterOS inspects the payload of control connections (e.g., FTP PORT commands, SIP INVITE messages) and registers expectations for the secondary connections they negotiate. When the secondary connection arrives, it matches an expectation and is classified as related rather than new. An accept rule for connection-state=related then permits it without any additional per-protocol rules.

If a helper is disabled, the secondary data connections appear as new and must be either permitted by explicit rules (specifying the dynamic port range) or blocked.

FTP Helper

The FTP helper tracks active-mode FTP transfers. In active mode, the FTP client tells the server which port to connect back to for the data channel (via the PORT command). Without the helper, the inbound data connection from the server would be new and blocked by a default-deny forward rule.

The helper parses PORT and PASV command responses and registers expectations for the negotiated data connection.

# Enable (default)
/ip firewall service-port set ftp disabled=no

# Disable if not needed (reduces attack surface)
/ip firewall service-port set ftp disabled=yes

The FTP helper listens on TCP port 21 by default. If your FTP server runs on a non-standard port, add it:

/ip firewall service-port set ftp ports=21,2121

SIP Helper

The SIP helper tracks VoIP signaling and the RTP media streams negotiated by SIP INVITE messages. SIP endpoints exchange Contact: headers and SDP body attributes that specify the RTP ports for audio and video. The helper parses these and registers expectations so that media flows are classified as related.

/ip firewall service-port set sip disabled=no

# SIP typically runs on UDP 5060 and TLS 5061
/ip firewall service-port set sip ports=5060,5061

Note

The SIP helper rewrites Contact: headers in NAT scenarios. If you use a SIP proxy that handles NAT traversal (STUN, ICE, or a SIP-aware proxy), disable the helper to avoid double-rewriting:

/ip firewall service-port set sip disabled=yes

H.323 Helper

The H.323 helper supports the H.323 VoIP and video conferencing protocol suite. H.323 uses a control channel (typically TCP 1720) to negotiate the ports for RTP media, H.245 control, and T.120 data. The helper tracks these negotiations and registers related expectations.

/ip firewall service-port set h323 disabled=no

PPTP Helper

The PPTP helper assists Point-to-Point Tunneling Protocol sessions. PPTP uses TCP port 1723 for control and GRE (protocol 47) for encapsulated data. The helper links the GRE data stream to the TCP control connection so that both are tracked together and the GRE stream is classified as related.

/ip firewall service-port set pptp disabled=no

Without the PPTP helper, a separate explicit rule is needed to permit GRE traffic.

TFTP Helper

The TFTP helper tracks Trivial FTP sessions. TFTP operates on UDP port 69 but the server responds from a random ephemeral port. The helper registers the server’s response port as a related expectation after seeing the initial request.

/ip firewall service-port set tftp disabled=no

IRC Helper

The IRC helper supports Direct Client-to-Client (DCC) file transfers negotiated through IRC. IRC clients use DCC SEND and DCC CHAT commands to negotiate direct connections on dynamic ports. The helper parses these and registers related expectations.

/ip firewall service-port set irc disabled=no

Managing Helpers

Disable helpers you do not use. Each active helper adds CPU overhead for payload inspection and increases the parser attack surface.

# View all helpers and their state
/ip firewall service-port print

# Disable all helpers not in use
/ip firewall service-port set h323 disabled=yes
/ip firewall service-port set irc  disabled=yes
/ip firewall service-port set pptp disabled=yes

FastTrack

FastTrack is a hardware-accelerated packet path that offloads established and related TCP/UDP connections, bypassing the full firewall rule set and dramatically reducing CPU usage on high-throughput routers.

# Place before regular filter rules in the forward chain
/ip firewall filter add chain=forward connection-state=established,related \
    action=fasttrack-connection hw-offload=yes comment="FastTrack established/related"

# Software fallback for packets that miss FastTrack
/ip firewall filter add chain=forward connection-state=established,related \
    action=accept comment="Accept established/related"

Key constraints:

• FastTrack is only available in the forward chain — not input or output
• Mangle rules for established traffic are not processed for FastTracked packets — apply connection marks on the new packet only
• hw-offload=yes requires hardware support; on unsupported platforms it is silently ignored and software FastTrack is used
• Connection marks and the connection table remain valid for FastTracked flows

Stateful Firewall Pattern

The standard rule ordering for every chain:

1. Drop invalid — eliminate malformed or unexpected packets first
2. Accept established and related — allow return traffic for permitted connections
3. Accept specific new traffic — explicitly permit each allowed service
4. Drop everything else — default-deny

This order is correct for both security and performance. The established,related rule is placed early because it matches the majority of traffic in a live network.

Input Chain (Protecting the Router)

/ip firewall filter

add chain=input connection-state=invalid action=drop \
    comment="Drop invalid input"

add chain=input connection-state=established,related action=accept \
    comment="Accept established/related input"

add chain=input protocol=icmp action=accept \
    comment="Accept ICMP"

add chain=input protocol=tcp dst-port=22 in-interface-list=LAN action=accept \
    comment="SSH from LAN"

add chain=input protocol=tcp dst-port=8291 in-interface-list=LAN action=accept \
    comment="Winbox from LAN"

add chain=input in-interface-list=WAN action=drop \
    comment="Drop all other WAN input"

Forward Chain (Protecting LAN Devices)

/ip firewall filter

add chain=forward connection-state=established,related \
    action=fasttrack-connection hw-offload=yes comment="FastTrack established/related"

add chain=forward connection-state=established,related action=accept \
    comment="Accept established/related forward"

add chain=forward connection-state=invalid action=drop \
    comment="Drop invalid forward"

add chain=forward in-interface-list=LAN out-interface-list=WAN \
    connection-state=new action=accept comment="LAN to WAN new"

add chain=forward action=drop \
    comment="Drop all other forward"

Disabling Connection Tracking

For routers handling only transit traffic with no NAT and no stateful filtering, you can disable connection tracking to eliminate its overhead:

/ip firewall connection tracking set enabled=no

When disabled:

• The connection-state matcher is unavailable
• connection-mark and mark-connection do not function
• NAT rules stop working (NAT requires connection tracking)
• The connection table is empty

Troubleshooting

Connection Table Near Capacity

/ip firewall connection print count-only

If the count approaches max-connections, new connections are dropped. Increase the limit or reduce timeouts to free stale entries.

High Invalid Packet Counts

/ip firewall filter print stats

High hit counts on connection-state=invalid drop rules indicate asymmetric routing or active attacks. Check routing with /ip route print and verify traffic is symmetric.

FTP or SIP Not Working Through NAT

If FTP active mode or SIP media fails through NAT, confirm the relevant helper is enabled:

/ip firewall service-port print

If the helper is enabled but transfers still fail, check whether the application or a downstream proxy is already handling NAT traversal — in which case you should disable the RouterOS helper to avoid double-rewriting.

Trace a Specific Connection

# Find a connection by source address
/ip firewall connection print where src-address~"203.0.113.42"

# Find established TCP connections
/ip firewall connection print where protocol=tcp state=established

Related Topics

• Firewall Filter Rules — chains, actions, and rule ordering
• Mangle — packet and connection marking
• Packet Flow — where connection tracking fits in the processing pipeline