MikroTik Connection Tracking: NAT & Firewall Troubleshooting

0 Shares

MikroTik connection tracking is the state table that allows RouterOS to understand which packets belong to the same conversation. It is also the foundation for stateful firewall rules and Network Address Translation (NAT). When websites stop loading after a WAN change, port forwarding behaves inconsistently, or firewall counters do not match expectations, the connection table is one of the first places to investigate.

This guide explains how connection tracking works in RouterOS, how to inspect sessions, how NAT decisions are remembered, and how to troubleshoot stale, invalid, or unexpectedly fast-tracked connections. Examples use RouterOS v7 syntax; verify behaviour on the exact RouterOS release and hardware before applying changes in production.

What Is MikroTik Connection Tracking?

Connection tracking (conntrack) monitors packet flows and maintains state for connections passing through the router. RouterOS uses this state to associate packets with an existing flow, apply NAT consistently, and let firewall rules distinguish new traffic from replies and related traffic. For the corresponding RouterOS 7 translation rules and port-forwarding examples, see our MikroTik NAT configuration guide.

A tracked connection is not simply one packet or one TCP socket. It is an entry describing a flow, including source and destination addresses and ports, protocol, connection state, NAT information, counters, and timeout information. UDP and other connectionless protocols are tracked too, using protocol-specific timeouts rather than a TCP handshake.

Connection tracking is enabled by default. NAT depends on it: RouterOS evaluates NAT rules on the first packet of a connection and stores the translation in the connection entry. Later packets in that connection use the remembered mapping. This is why changing a NAT rule does not necessarily change the behaviour of sessions that were already established.

Where Connection Tracking Fits in Packet Flow

For routed traffic, conntrack is part of RouterOS packet processing before the filter and NAT decisions that rely on connection state. The exact packet-flow path depends on whether traffic is destined to the router, forwarded through it, bridged, hardware-offloaded, or handled by FastTrack.

For troubleshooting, distinguish three paths. If you need a broader command-line workflow for isolating RouterOS faults, see MikroTik CLI troubleshooting techniques.

Input: packets whose destination is the router itself, such as SSH, WinBox, or DNS service traffic.
Forward: packets routed through the router between networks, such as LAN clients accessing the internet or inbound port-forwarded traffic.
Output: packets generated by the router itself, such as NTP, DNS lookups, or monitoring traffic.

Connection state is evaluated in firewall processing, while destination NAT can change the destination before a forwarded packet reaches its final filtering decision. When debugging, inspect the relevant chain and interface direction rather than assuming every packet traverses the same rules.

MikroTik Connection States Explained

new

The first packet observed for a connection is classified as new. For TCP, this commonly corresponds to the initial SYN packet. For UDP, it is the first packet in the tracked flow. A new connection is not automatically malicious; it simply has no established state entry yet.

established

Packets belonging to a connection that has already exchanged traffic in both directions are generally classified as established. This is the state commonly allowed for ongoing sessions and reply traffic.

A packet is related when it is associated with an existing connection but is not part of the original flow. Certain ICMP error messages and connection-helper-assisted protocols can produce related traffic. Allowing related traffic is important for correct error handling and some application protocols.

invalid

invalid means RouterOS cannot associate the packet with a valid tracked connection. Possible causes include asymmetric routing, malformed or out-of-window packets, inconsistent paths through multiple routers, or packets arriving after state has expired. Do not assume every invalid packet is an attack; identify its source and direction before deciding how to handle it.

untracked

untracked traffic has been deliberately excluded from connection tracking, typically through a RAW table notrack rule. Since it has no conntrack state, normal stateful NAT and connection-state firewall logic cannot be relied upon for it.

How to Inspect Active Connections

Start by checking whether connection tracking is enabled and viewing the table:

/ip firewall connection tracking print
/ip firewall connection print

Filter the table to narrow down a suspected client or protocol:

/ip firewall connection print where src-address~"192.168.88.10"
/ip firewall connection print where protocol=tcp
/ip firewall connection print where dst-port=443
/ip firewall connection print where connection-state=established

Use the fields displayed by your RouterOS version to inspect original and reply tuples, protocol, TCP state, timeout, packet and byte counters, connection mark, and source or destination NAT flags. A connection with increasing counters is actively carrying traffic; a connection with no recent activity may simply be idle until its timeout expires.

To watch new entries appear while reproducing a problem, use the connection table in WinBox or repeat a filtered CLI inspection. Avoid repeatedly dumping a very large table on a busy router: narrow the filter first and consider the CPU and management impact.

How Connection Tracking Affects NAT

RouterOS NAT rules are evaluated for the first packet of a connection. The selected translation is stored in conntrack and applied to subsequent packets in that flow. This has two important consequences:

After changing a NAT rule, existing sessions can continue using the old translation.
Testing a rule change with an already-open browser, SSH session, or application flow may produce a misleading result. Test with a genuinely new connection.

Example: source NAT for a LAN

/ip firewall nat add chain=srcnat out-interface-list=WAN action=masquerade comment="LAN internet access"

Masquerade is commonly used when the WAN address can change, such as a dynamic ISP connection. If the public address is static, an explicit src-nat rule with to-addresses may be more appropriate. Select the method that matches the WAN design; do not add duplicate broad NAT rules without checking rule order.

Example: destination NAT for port forwarding

/ip firewall nat add chain=dstnat in-interface-list=WAN protocol=tcp dst-port=8443 action=dst-nat to-addresses=192.168.88.20 to-ports=443 comment="HTTPS service"

A corresponding forward-chain rule must permit the intended traffic, and the internal host must have a valid return path. Restrict the source address where possible, expose only the required service, and avoid forwarding management interfaces directly to the internet.

When to clear connection entries

If you change NAT behaviour and need to test immediately, remove only the relevant connection entries after considering the impact. Removing a connection entry interrupts that session; it does not fix an incorrect NAT or firewall rule. Clearing the entire table can disconnect many users and applications, so reserve it for controlled maintenance or a justified recovery action.

Building Stateful Firewall Rules

A typical stateful firewall accepts established and related traffic, drops invalid traffic, and then applies explicit policy to new connections. Adapt interface lists, addresses, and service ports to your network:

/ip firewall filter add chain=input connection-state=established,related action=accept comment="Allow established and related"
/ip firewall filter add chain=input connection-state=invalid action=drop comment="Drop invalid"
/ip firewall filter add chain=input in-interface-list=LAN action=accept comment="Allow router access from LAN"
/ip firewall filter add chain=input in-interface-list=WAN action=drop comment="Drop unsolicited WAN access"

/ip firewall filter add chain=forward connection-state=established,related action=accept comment="Allow established and related"
/ip firewall filter add chain=forward connection-state=invalid action=drop comment="Drop invalid"
/ip firewall filter add chain=forward connection-state=new in-interface-list=LAN out-interface-list=WAN action=accept comment="Allow LAN to WAN"

Rule order matters. Place state-handling rules deliberately, then permit only the new connections your policy requires. For a production router, preserve required VPN, management, inter-VLAN, and port-forwarding rules. Review the complete firewall before inserting a broad drop rule, and use Safe Mode or out-of-band access when changing remote firewall policy.

FastTrack and Connection Tracking

FastTrack can accelerate eligible established connections by bypassing parts of the normal firewall and processing path. It still relies on connection tracking, but not every packet of a FastTracked connection traverses every normal processing facility.

This matters when using queues, traffic accounting, IPsec, policy routing, packet marks, or features that expect to inspect every packet. If a connection behaves differently when FastTrack is enabled, temporarily disable or narrow FastTrack during a controlled test and compare the result.

/ip firewall filter add chain=forward action=fasttrack-connection connection-state=established,related comment="FastTrack established and related"
/ip firewall filter add chain=forward action=accept connection-state=established,related comment="Accept established and related"

These are illustrative rules, not a complete firewall. Keep FastTrack ahead of the established/related accept rule when using the standard pattern, and account for exclusions required by your routing, queueing, VPN, and accounting design.

Connection Timeouts, Capacity, and Stale Sessions

Conntrack entries consume memory. The router maintains them until traffic refreshes the entry or the relevant timeout expires. RouterOS exposes protocol-specific timeout settings; defaults can vary by release and should be checked on the device rather than copied from an unrelated configuration.

Inspect current settings and table statistics:

/ip firewall connection tracking print
/ip firewall connection print count-only

Symptoms of conntrack pressure can include a rapidly growing table, memory pressure, failed new sessions, or log messages indicating that the connection table is full. High connection counts can be normal on busy NAT gateways, so compare the count with the router’s memory, CPU, traffic profile, and configured limits.

Do not reduce timeouts indiscriminately to make the table smaller. Short timeouts can break legitimate idle TCP, UDP, VPN, or application sessions. Increase capacity only when the hardware and memory budget support it, and investigate unusual connection churn or scans before changing limits.

A Practical MikroTik Connection Tracking Troubleshooting Workflow

1. Confirm the symptom and traffic path

Identify the client, destination, protocol, port, direction, and whether the flow is input or forward traffic. Test from a single client and record the exact time.

2. Check the connection entry

Filter /ip firewall connection print by the client address, destination, or port. Confirm whether the flow appears, which state it has, whether NAT flags are present, and whether counters increase.

3. Check NAT rule order and matching

Inspect /ip firewall nat print stats and the relevant rule counters. Confirm that the first packet matches the intended rule, that interface lists are correct, and that a more general rule is not matching first. Test with a new session after any change.

4. Check filter rules and counters

Inspect /ip firewall filter print stats. Verify the packet reaches the expected chain and that the allow rule precedes a drop rule. For inbound port forwarding, confirm both destination NAT and the forward-chain permission.

5. Check routing symmetry and return traffic

Ensure replies return through a path that can see the same connection state. Multi-WAN, policy routing, ECMP, VRRP failover, and upstream NAT can create asymmetric paths. A router that sees only one direction may classify packets as invalid or fail to maintain the expected NAT mapping.

6. Isolate FastTrack and helpers

Temporarily test without FastTrack if queues, marks, VPNs, or accounting are involved. Review connection helpers only when the affected protocol needs them; unnecessary helpers expand inspection and can complicate troubleshooting.

7. Remove only the affected session if necessary

Once the configuration is correct, selectively remove the relevant stale connection entry and retest. Avoid flushing all connections as a routine diagnostic step.

Advanced Diagnostics and Best Practices

RAW table and notrack

The RAW table runs before connection tracking and can be used to drop unwanted traffic early or exclude selected traffic from tracking. For example, a carefully scoped notrack rule can reduce tracking overhead for traffic that does not need NAT or stateful filtering. Do not apply notrack to ordinary client internet traffic that relies on NAT or connection-state rules.

/ip firewall raw print

Logging and packet capture

Use temporary, narrowly matched logging to identify which rule sees a packet. Packet Sniffer or Torch can help confirm ingress and egress traffic, but a capture on one interface does not prove that the reply follows the expected route. Remove temporary verbose logging after testing to avoid unnecessary CPU and log load.

Operational checklist

Keep RouterOS and RouterBOARD firmware maintained under a tested change process.
Export and back up the configuration before firewall or NAT changes.
Use interface lists and address lists to keep policies readable.
Keep established/related handling consistent across input and forward chains.
Drop invalid traffic only after considering asymmetric routing and special designs.
Use FastTrack only when its bypass behaviour is compatible with queues, marks, VPNs, and accounting.
Monitor connection counts, memory, CPU, and firewall counters during peak traffic.
Document intentional notrack rules, helpers, NAT exceptions, and multi-WAN routing behaviour.

Frequently Asked Questions

Does MikroTik NAT work without connection tracking?

No. RouterOS NAT relies on connection tracking to remember the translation selected for a connection. Disabling connection tracking disables NAT functionality that depends on it.

Why does a NAT rule change not affect an existing session?

NAT is selected on the first packet and stored in the connection entry. Existing sessions can keep the previous mapping until they expire or are deliberately removed. Test using a new connection.

Should I drop every invalid connection?

Dropping invalid traffic is a common firewall practice, but first investigate asymmetric routing, multi-WAN paths, and other designs that may cause legitimate packets to arrive without matching state.

Does FastTrack disable connection tracking?

No. FastTrack works with connection tracking and accelerates eligible flows by bypassing parts of normal packet processing. This can affect features that expect to inspect every packet.

How often should I clear the connection table?

Routine flushing is not recommended. Conntrack is designed to age out entries using protocol timeouts. Remove specific entries only when troubleshooting or when a deliberate change requires terminating those sessions.

Conclusion

Connection tracking is central to MikroTik NAT and stateful firewall behaviour. A disciplined troubleshooting process starts with the connection entry, follows the packet through NAT and filter rules, verifies the return route, and accounts for FastTrack and timeout behaviour. Inspect narrowly, change one variable at a time, and avoid clearing the whole table unless the operational impact is understood.

Check our list of MikroTik guides