MikroTik FastTrack and tunnel traffic

FastTrack (fasttrack-connection) is a RouterOS shortcut that forwards established TCP and UDP connections without running them through the firewall again. A mangle mark, and the routing table chosen from it, depend on that firewall pass. Once a tunnel flow is fasttracked, it loses its mark and leaves by the main table.

What this page shows:

• Which stages a fasttracked packet skips, taken from MikroTik's own list.
• Why a policy route needs an exemption, and where that rule must sit.
• A CHR counter run with and without the exemption, and what it did not show.
• A find-expression trap that made our own exemption install nothing.

What does FastTrack skip on RouterOS?

MikroTik's documentation (read 2026-10-29) says FastTracked packets skip eight things, and that firewall filter and mangle rules are not applied to them. FastTrack itself is a handler for TCP and UDP connections that a rule has marked with the fasttrack-connection action.

MikroTik adds that not every packet of a flagged connection can be fasttracked, so some still take the slow path. That is why the action is normally followed by an identical accept rule.

The table is MikroTik's list, with our reading of the tunnel consequence in the right column. The vendor page ends its description with one sentence we take at face value: it is up to the administrator to make sure FastTrack does not interfere with other configuration.

Is FastTrack the same as FastPath?

No. FastPath is a separate fast-forwarding mechanism that is switched on in the IP settings, and FastTrack is a per-connection decision made by a firewall rule. MikroTik's page states that while both are enabled on a device, only one can be active at a time.

The two names sit side by side in the IP settings. For a tunnel the distinction is practical: you decide FastTrack with a rule you can see and reorder, and that is the rule this page is about.

Why does a tunnel or policy route break with FastTrack on?

A policy route needs the firewall to run on every packet, and FastTrack takes that away. A mangle rule puts a routing mark on the packet, and a route in the table with that name sends the packet into the tunnel. Per MikroTik, a fasttracked packet skips the mangle rule, so it carries no mark.

No mark, so the main table routes it. On a typical home router the main table has a default route out of the WAN link. So a long flow meant for the tunnel can leave over the normal connection.

Two things follow. Both are quiet:

• The flow works. Just over the wrong path.
• A drop rule meant as a kill switch is a filter rule, so it is skipped as well.

Our kill switch test covers where a drop rule must sit relative to the exemption, so we do not repeat that here. The choose-traffic help page states the same warning for the ForestVPN container: a fasttracked connection never reaches mangle or the filter rules again.

How do I exempt tunnel traffic from FastTrack?

Put accept rules for tunnel flows above the fasttrack-connection rule. RouterOS reads the forward chain from the top and stops at the first matching rule, so a flow accepted at rule 1 is never offered to rule 3.

You need one rule for each direction, for established and related connections, matched on the interfaces that face the tunnel side. This is the recipe's form, with our lab's names: br-a is the LAN side and br-b the tunnel side (the recipe uses the LAN bridge and veth-fvpn):

:local ft [/ip/firewall/filter/find where chain=forward and action=fasttrack-connection and !disabled]
:if ([:len $ft] > 0) do={
/ip/firewall/filter/add chain=forward action=accept connection-state=established,related \
    in-interface=br-a out-interface=br-b place-before=($ft->0)
/ip/firewall/filter/add chain=forward action=accept connection-state=established,related \
    in-interface=br-b out-interface=br-a place-before=($ft->0)
}

The full script, with the interface lists and the mangle rules, is on the choose-traffic page and the install page. The routers they are written for are on the MikroTik download page.

Does a FastTrack exemption stop connections being flagged?

On a CHR (Cloud Hosted Router), which is RouterOS running as a virtual machine, the exemption took the number of flagged flows from two to one, and the exempted flow was the one that stopped being flagged. That is the whole claim of this run.

Does the F flag mean packets skipped the firewall?

One caveat matters more than the table. On this CHR the connections were flagged, but no packet was actually fasttracked.

orig-fasttrack-packets and repl-fasttrack-packets read 0 in every run, the fast-path counters in the IP settings stayed at 0, and the mark-routing counters equal each connection's packet count. So every packet still passed mangle.

We can show the flag and the exemption's effect on it. We cannot show a mark going missing, and we did not establish why. Virtual NICs and bridges inside a virtual machine are candidates, and we did not test them.

The second table is a hardware record, not a repeat of the CHR run. It comes from verifying our own recipe on a MikroTik cAP ax, RouterOS 7.24.5. The router's own fasttrack rule was disabled, so two test fasttrack rules stood in. With the exemption disabled, two client flows were flagged; with it enabled, none were, during a 33 s download.

Our recipe is on the choose-traffic page; we saw orig-fasttrack-packets=0 on the router as well, so we did not reproduce the leak the exemption prevents on that hardware. We cite it as our recipe's result, and do not generalise it to other boards.

What does turning FastTrack off cost?

Turning FastTrack off costs the shortcut: every packet of every forwarded connection then goes through connection tracking, the filter chain and mangle. That is the mechanism, and all we claim.

We did not measure the effect on throughput or CPU, so we give no figure. Our virtual router was the wrong place to try, and a hardware router would need its own test.

Which is the case for the exemption over disabling the rule. The exemption removes only the tunnel flows from the shortcut, and everything else stays fasttracked.

How do I check whether a connection is fasttracked?

Read the connection table. In /ip firewall connection print, a connection with the F flag has been marked by the fasttrack rule. The detail view then adds orig-fasttrack-packets and repl-fasttrack-packets, which count the packets that were really fasttracked in each direction.

Two counters tell you the rest:

1. The mangle rule that marks your flow, read with /ip firewall mangle print stats. If it counts every packet of the connection, the flow still passes mangle.
2. The accept rules of the exemption. A rule at zero packets matches nothing.

The flag alone is not proof of skipping, as the CHR run shows. Read the packet counters beside it.

Why does find disabled=no match no firewall rules in RouterOS?

Our script found the fasttrack rule with disabled=no, and that matches only rules that have the flag set explicitly. On the CHR we added rules without a disabled= argument and counted what each form found.

The filter count of 4 includes the dynamic dummy rule that RouterOS adds to show fasttrack counters.

On the R2 router the same trap gave 0 against 5 for filter, 0 against 6 for mangle and 1 against 9 for route. An exemption that looks for the fasttrack rule with disabled=no finds none, so it has nothing to place its accept rules before and installs nothing. The script reports no error. We changed the recipe to !disabled.

This is a finding about our own script and the way it adds rules, not a claim about RouterOS in general. If you write your own, count what your find expression returns before you rely on it.

What should you do with FastTrack on a tunnel router?

Keep FastTrack on for the traffic that is not going through the tunnel, put the two accept rules above it for the traffic that is, and check the rule counters and the F flag afterwards. Do not disable the fasttrack rule to make a tunnel work unless you have decided you can afford the full path for every packet.