Packet Flow in RouterOS

Packet Flow in RouterOS

Understanding packet flow is essential for configuring advanced firewall setups, traffic prioritization, and routing policies in MikroTik RouterOS. This document explains how packets are processed through the router, covering routed packets, bridged packets, firewall chains, and hardware offloading.

Overview

RouterOS packet processing involves multiple facilities that packets traverse in a specific order. Understanding this flow helps when configuring firewall rules, NAT, traffic shaping, and other network features. The packet flow diagram is divided into three main parts: the overall diagram, detailed bridging/routing/MPLS flow, and the chain processing diagram showing which facilities are applied at each stage.

When a packet arrives at the router, it goes through several decision points: first determining if it’s destined for the router itself (local delivery), needs to be routed to another network (forward), or needs to be bridged (same broadcast domain). Each of these paths involves different processing chains and firewall rules.

Firewall Chains

RouterOS uses five default chains that allow filtering packets at various points in the processing pipeline:

Chain	Table	Purpose
PREROUTING	raw, mangle, nat	Applies to packets as they arrive on the interface
INPUT	mangle, filter	Applies to packets just before delivery to local processes
OUTPUT	raw, mangle, nat, filter	Applies to packets generated by the router
FORWARD	mangle, filter	Applies to packets routed through the router
POSTROUTING	mangle, nat	Applies to packets as they leave the interface

Chain Processing Order

The complete processing order for a routed packet follows this sequence:

1. Packet arrives at physical in-interface
2. Goes through logical in-interface (for tunneled packets)
3. Prerouting processing (RAW → Connection Tracking → Mangle → DNAT)
4. Routing decision (determines if packet is local or forwarded)
5. Input or Forward processing depending on destination
6. Postrouting processing (Mangle → SNAT → Queues)
7. Exits through physical out-interface

Viewing Current Chain Processing

You can verify packet flow using the packet flow diagram in RouterOS:

/packet-flow print

Flow of Routed Packet

Forward Path

The forward path processes packets that are being routed through the router to another network. This is the most common scenario for firewall rule configuration.

The packet goes through these stages:

1. Prerouting: Hotspot check → RAW prerouting → Connection tracking → Mangle prerouting → DNAT
2. Routing Decision: Router looks up destination in routing table
3. Forward: TTL check → Mangle forward → Filter forward → Accounting
4. Postrouting: Mangle postrouting → SNAT → Hotspot undo → Queue tree → Simple queues
5. IPsec: Policy check and processing

Forward Path Firewall Configuration

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

Input Path

The input path processes packets destined for the router itself, such as management access, DHCP requests, or services running on the router.

Processing stages:

1. Prerouting: Hotspot check → RAW prerouting → Connection tracking → Mangle prerouting → DNAT
2. Routing Decision: Router determines packet is local
3. Input: Mangle input → Filter input → Queue tree → Simple queues
4. IPsec: Policy check and processing

Input Path Firewall Configuration

/ip firewall filter
add chain=input action=accept connection-state=established,related comment="Allow established"
add chain=input action=accept protocol=icmp comment="Allow ICMP"
add chain=input action=accept in-interface=LAN comment="Allow LAN access"
add chain=input action=drop comment="Drop all other input"

Output Path

The output path handles packets originated by the router itself, such as ping responses, routing updates, or traffic generated by router services.

Processing stages:

1. Local Process: Router generates the packet
2. Routing Decision: Route lookup for the packet
3. Output: Bridge decision → Connection tracking → Mangle output → Filter output → Routing adjustment
4. Postrouting: Mangle postrouting → SNAT → Hotspot undo → Queue tree → Simple queues
5. IPsec: Policy check and processing

Flow of Bridged Packet

Bridging connects devices on the same network without routing. Packets forwarded through a bridge follow a different processing path than routed packets.

Bridge Forward

Bridge forward occurs when a packet enters one bridge port and exits through another:

1. Bridge NAT dst-nat (MAC destination, priority can be changed)
2. Check use-ip-firewall option
3. Bridge host table lookup (flood if unknown destination)
4. Bridge filter forward chain
5. Check use-ip-firewall option
6. Bridge NAT src-nat (MAC source, priority can be changed)
7. Check use-ip-firewall option

Basic Bridge Configuration

/interface bridge
add name=bridge1
/interface bridge port
add bridge=bridge1 interface=ether1
add bridge=bridge1 interface=ether2

Bridge Input

Bridge input processes packets destined for the bridge interface itself (to reach services on the bridge):

1. Bridge NAT dst-nat
2. Check use-ip-firewall option
3. Bridge host table lookup (MAC matching bridge address goes to input)
4. Bridge filter input chain

Bridge Output

Bridge output handles packets exiting through bridge ports:

1. Bridge host table lookup
2. Bridge filter output chain
3. Bridge NAT src-nat
4. Check use-ip-firewall option

Forward With IP Firewall Enabled

When use-ip-firewall=yes is enabled on the bridge, bridged packets also go through routing chains:

/interface bridge set bridge1 use-ip-firewall=yes

This enables IP-level filtering on bridged traffic but increases CPU usage.

Enabling use-ip-firewall on bridges significantly increases CPU load since packets must go through both bridge and routing processing.

Flow of Hardware Offloaded Packet

Most MikroTik devices have dedicated switching hardware (switch chip) that can handle bridging without CPU involvement. This is called Bridge Hardware Offloading.

Switch Forward

When hardware offloading is enabled and packets move between switch ports:

1. Switch checks if in-interface is hardware offloaded
2. Switch host table lookup (forward to destination port or flood)
3. Packets never reach the CPU

Enable Hardware Offloading

/interface bridge
add name=bridge1 hw=yes
/interface bridge port
add bridge=bridge1 interface=ether1 hw=yes
add bridge=bridge1 interface=ether2 hw=yes

Switch to CPU

When hardware-offloaded packets need CPU processing:

1. Switch checks hardware offloading status
2. Switch host table lookup
3. Packet forwarded to switch-cpu port for software processing

This occurs when:

• Destination MAC matches the bridge interface (local delivery)
• Packet is flooded (broadcast, multicast, unknown unicast)
• Special processing required (DHCP, IGMP snooping)

Hardware Offloading Requirements

Hardware offloading requires:

• No bridge firewall, filter, or NAT rules
• use-ip-firewall disabled
• No mesh or metarouter interfaces
• Bridge VLAN filtering and DHCP snooping disabled (RouterOS 7.1 and earlier)

Viewing Offload Status

/interface bridge port print

Look for the hw column showing yes for hardware-offloaded ports.

FastPath and FastTrack

FastPath and FastTrack are performance optimization features that bypass normal packet processing.

FastPath

FastPath skips most CPU processing by handling packets directly in the network driver. It’s automatic when conditions are met:

/interface print stats-detail

FastPath is active when:

• No firewall rules configured
• No simple queues or queue trees with parent=global
• No connection tracking needed
• No IPsec policies
• No VRF configuration

FastTrack

FastTrack combines FastPath with connection tracking. It marks connections for accelerated processing:

/ip firewall filter
add chain=forward action=fasttrack-connection connection-state=established,related
add chain=forward action=accept connection-state=established,related

FastTrack packets bypass firewall, connection tracking, queues, and IPsec. Ensure you understand the security implications before enabling.

FastTrack requirements:

• Only TCP and UDP connections
• Must use main routing table
• No VRF configuration
• No active packet sniffing

Practical Examples

Example 1: Basic Firewall for Routed Traffic

This configuration secures a simple router with LAN behind it:

/ip firewall filter
# Input chain - protect the router
add chain=input action=accept connection-state=established,related
add chain=input action=accept protocol=icmp
add chain=input action=accept in-interface=LAN
add chain=input action=drop

# Forward chain - protect LAN devices
add chain=forward action=accept connection-state=established,related
add chain=forward action=accept connection-state=related in-interface=LAN out-interface=WAN
add chain=forward action=drop connection-state=invalid
add chain=forward action=drop in-interface=WAN out-interface=LAN

Example 2: Bridge with VLAN Filtering

/interface bridge
add name=bridge1 vlan-filtering=yes

/interface bridge vlan
add bridge=bridge1 tagged=bridge1 vlan-ids=10,20

/interface bridge port
add bridge=bridge1 interface=ether1 vlan-mode=secure
add bridge=bridge1 interface=ether2 vlan-mode=secure
add bridge=bridge1 interface=ether3 vlan-mode=secure

Example 3: Performance Tuning with FastTrack

For high-performance networks, use FastTrack for established connections:

/ip firewall filter
add chain=forward action=fasttrack-connection connection-state=established,related
add chain=forward action=accept connection-state=established,related
add chain=forward action=accept connection-state=related in-interface=LAN
add chain=forward action=drop connection-state=invalid

Troubleshooting Packet Flow

Check Which Chain a Packet Traverses

Use packet flow monitoring:

/tool packet-flow print

View Connection Tracking Entries

/ip firewall connection print

Monitor FastPath Statistics

/interface print stats-detail

Look for packets passing through FastPath vs slow path in the statistics.

Debug with Firewall Logs

/ip firewall filter
add chain=forward action=log log-prefix="forward-drop: " connection-state=invalid

/log print

Related Topics

• Firewall - Firewall filter, NAT, and raw rules
• Bridging and Switching - Bridge configuration and VLAN filtering
• Queues - Traffic shaping and QoS
• IPsec - VPN tunnel processing