Firewall

Settings for IPv4/IPv6 blocking, firewall rule creation, and output blocking.

IPv4

firewall.ipv4.enabled Optional

Env: FIREWALL_IPV4_ENABLED · Default: true

Enable IPv4 address blocking. When enabled, the bouncer creates IPv4 firewall rules and manages the IPv4 address list.

firewall.ipv4.address_list Optional

Env: FIREWALL_IPV4_ADDRESS_LIST · Default: crowdsec-banned

Name of the IPv4 address list in MikroTik where banned IPs are stored.

IPv6

firewall.ipv6.enabled Optional

Env: FIREWALL_IPV6_ENABLED · Default: true

Enable IPv6 address blocking. When enabled, the bouncer creates IPv6 firewall rules and manages the IPv6 address list.

firewall.ipv6.address_list Optional

Env: FIREWALL_IPV6_ADDRESS_LIST · Default: crowdsec6-banned

Name of the IPv6 address list in MikroTik.

Filter Rules

firewall.filter.enabled Optional

Env: FIREWALL_FILTER_ENABLED · Default: true

Create rules in /ip/firewall/filter (and /ipv6/firewall/filter if IPv6 enabled). Filter rules are the standard RouterOS firewall rules processed after connection tracking.

firewall.filter.chains Optional

Env: FIREWALL_FILTER_CHAINS · Default: ["input"]

Which chains to create filter rules in. Common values:

• input — blocks traffic destined to the router itself
• forward — blocks traffic passing through the router

firewall:
  filter:
    chains: ["input", "forward"]

For the environment variable form, comma-separated entries may be written as input,forward or input, forward; surrounding whitespace is trimmed before values are sent to RouterOS.

Raw Rules

firewall.raw.enabled Optional

Env: FIREWALL_RAW_ENABLED · Default: true

Create rules in /ip/firewall/raw (and /ipv6/firewall/raw if IPv6 enabled). Raw rules are processed before connection tracking, providing earlier packet filtering with less CPU usage.

Best practice

Enable both filter and raw rules for defense-in-depth. Raw rules block traffic earlier in the packet processing pipeline.

firewall.raw.chains Optional

Env: FIREWALL_RAW_CHAINS · Default: ["prerouting"]

Which chains to create raw rules in. Typically prerouting.

Like filter chains, comma-separated environment values tolerate surrounding whitespace around each chain name.

Rule Behavior

firewall.deny_action Optional

Env: FIREWALL_DENY_ACTION · Default: drop

Action for firewall rules:

• drop — silently drops packets (recommended)
• reject — sends a rejection response to the sender

firewall.rule_placement Optional

Env: FIREWALL_RULE_PLACEMENT · Default: top

Where to place new firewall rule blocks. Placement is evaluated per RouterOS firewall menu (filter or raw) and protocol (ip or ipv6).

| Strategy | Extra fields | Fallback | Retry behavior | Use case | | ---------------- | -------------------------------------------------------- | ------------------ | --------------------------------------------------------------- | -------------------------------------------------------- | | top | None | No | Yes, tries lower positions if RouterOS refuses the first target | Highest priority while tolerating dynamic/built-in rules | | bottom | None | No | No | Append after existing rules | | position | Required position | Not applicable | Yes, retries lower positions when the target cannot be used | Place at a RouterOS print position | | before_comment | comment, optional comment_match, optional fallback | Yes, default top | Fallback only | Place before a known user rule | | after_comment | comment, optional comment_match, optional fallback | Yes, default top | Fallback only | Place after a known user rule |

Note

The bouncer places related rules as a block so whitelist, counting, and deny/reject rules keep their internal order.

Simple string values remain fully supported and are recommended for simple deployments:

firewall:
  rule_placement: "top"
# or:
# rule_placement: "bottom"

Structured placement accepts these fields:

| Field | Default | Applies to | Description | | --------------- | ------- | --------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | strategy | top | All modes | One of top, bottom, position, before_comment, or after_comment | | position | | position | Required zero-based RouterOS print position. Negative values are invalid. | | comment | | before_comment, after_comment | RouterOS rule comment used as the anchor. Required for comment strategies. | | comment_match | exact | before_comment, after_comment | exact uses a case-sensitive full-string match. contains uses a case-sensitive literal substring match. This is not a regex. | | fallback | top | before_comment, after_comment | top or bottom when the anchor is missing or cannot be used. Ignored for position. | | filter | | Structured config only | Override the global placement for /ip firewall filter and /ipv6 firewall filter, including optional output-blocking rules configured via block_output.enabled. | | raw | | Structured config only | Override the global placement for /ip firewall raw and /ipv6 firewall raw. |

The same structured object can be used under firewall.ipv4.rule_placement and firewall.ipv6.rule_placement for YAML-only protocol overrides. These overrides inherit unspecified fields from the global placement and can contain protocol-local filter and raw overrides.

Place filter rules after an existing user rule while keeping raw rules at the top:

firewall:
  rule_placement:
    strategy: "top"
    filter:
      strategy: "after_comment"
      comment: "drop invalid"
      comment_match: "contains"
      fallback: "top"
    raw:
      strategy: "top"

Place rules at a numeric RouterOS position:

firewall:
  rule_placement:
    strategy: "position"
    position: 2

position is required for strategy: "position" and uses zero-based RouterOS print numbering. If the configured position is greater than the number of existing non-bouncer rules, the block is appended at the bottom. fallback is ignored for strategy: "position".

For example, if RouterOS shows existing non-bouncer rules at positions 0, 1, 2, and 3, then position: 2 inserts the managed block before the rule currently shown as 2. The bouncer excludes its own @cs-routeros-bouncer rules before calculating the target position, so restarts are stable.

If both global placement and filter or raw overrides are configured, the table-specific override wins for that table and inherits any fields it does not set from the global placement.

firewall:
  rule_placement:
    strategy: "before_comment"
    comment: "my rule"
    filter:
      strategy: "top"

In this example, filter uses strategy: "top". raw inherits the global strategy: "before_comment" and comment: "my rule".

Protocol-specific overrides are evaluated after global table overrides. The full precedence order is global placement, global filter/raw, protocol placement, then protocol filter/raw.

firewall:
  rule_placement:
    strategy: "top"
  ipv4:
    rule_placement:
      strategy: "before_comment"
      comment: "IPv4 production anchor"
      fallback: "bottom"
  ipv6:
    rule_placement:
      strategy: "bottom"
      filter:
        strategy: "after_comment"
        comment: "IPv6 filter anchor"
      raw:
        strategy: "position"
        position: 4

In this example, IPv4 rules are placed before the IPv4 anchor. IPv6 rules inherit bottom, IPv6 filter rules are placed after IPv6 filter anchor, and IPv6 raw rules use zero-based position 4.

Additional environment variables for structured global placement:

• FIREWALL_RULE_PLACEMENT - legacy/simple global strategy (top, bottom, position, before_comment, or after_comment)
• FIREWALL_RULE_PLACEMENT_STRATEGY - object-form global strategy; takes precedence over FIREWALL_RULE_PLACEMENT when both are set
• FIREWALL_RULE_PLACEMENT_COMMENT - anchor comment for comment strategies
• FIREWALL_RULE_PLACEMENT_COMMENT_MATCH - exact or contains
• FIREWALL_RULE_PLACEMENT_POSITION - required zero-based numeric position for position
• FIREWALL_RULE_PLACEMENT_FALLBACK - top or bottom for comment strategies

FIREWALL_RULE_PLACEMENT="after_comment"
FIREWALL_RULE_PLACEMENT_COMMENT="drop invalid"
FIREWALL_RULE_PLACEMENT_COMMENT_MATCH="contains"
FIREWALL_RULE_PLACEMENT_FALLBACK="top"

Environment variables configure the global placement only. Use YAML when you need different filter, raw, IPv4, or IPv6 placement strategies.

firewall.comment_prefix Optional

Env: FIREWALL_COMMENT_PREFIX · Default: crowdsec-bouncer

Prefix for comments on all bouncer-managed resources in MikroTik. Used to identify and manage rules.

Example comments generated:

crowdsec-bouncer:filter-input-input-v4 @cs-routeros-bouncer
crowdsec-bouncer:raw-prerouting-input-v4 @cs-routeros-bouncer
crowdsec-bouncer:filter-input-input-v6 @cs-routeros-bouncer

Rule Logging

firewall.log Optional

Env: FIREWALL_LOG · Default: false

Enable RouterOS logging on firewall rules. When enabled, matched packets are logged in the RouterOS system log.

firewall.log_prefix Optional

Env: FIREWALL_LOG_PREFIX · Default: crowdsec-bouncer

Prefix for RouterOS log entries when logging is enabled. Helps identify bouncer-related log entries in the router log.

firewall:
  log: true
  log_prefix: "crowdsec-bouncer"

Input Interface Filtering

Restrict input (filter) and prerouting (raw) rules to specific interfaces. By default, rules apply to all interfaces.

Default behavior

When both interface and interface_list are empty (the default), firewall rules match traffic arriving on every interface. This blocks banned IPs regardless of whether the traffic comes from WAN, LAN, or any other interface.

Use this setting to limit blocking to the WAN interface only, so that banned IPs on the LAN side can still reach the router (e.g., for management or internal services).

firewall.block_input.interface Optional

Env: FIREWALL_BLOCK_INPUT_INTERFACE · Default: — (all interfaces)

Restrict input/raw rules to a single interface.

firewall:
  block_input:
    interface: "ether1"

firewall.block_input.interface_list Optional

Env: FIREWALL_BLOCK_INPUT_INTERFACE_LIST · Default: — (all interfaces)

Restrict input/raw rules to an interface list. Alternative to specifying a single interface.

firewall:
  block_input:
    interface_list: "WAN"

Note

If both interface and interface_list are set, both are applied to the rule (RouterOS evaluates them as AND).

Output Blocking

Block outbound traffic to banned IPs. Disabled by default.

firewall.block_output.enabled Optional

Env: FIREWALL_BLOCK_OUTPUT · Default: false

Enable blocking of outgoing traffic to banned IPs. This prevents your network from establishing connections to known malicious IPs.

firewall.block_output.interface Optional

Env: FIREWALL_BLOCK_OUTPUT_INTERFACE · Default: —

WAN interface for output rules. Required if block_output.enabled is true (unless interface_list is set).

firewall:
  block_output:
    enabled: true
    interface: "ether1"

firewall.block_output.interface_list Optional

Env: FIREWALL_BLOCK_OUTPUT_INTERFACE_LIST · Default: —

WAN interface list for output rules. Alternative to specifying a single interface.

firewall:
  block_output:
    enabled: true
    interface_list: "WAN"

Note

If both interface and interface_list are set, interface takes precedence.

---

Rule Customization

Advanced options for customizing how firewall rules are created and what traffic they match.

Each option below shows the bouncer YAML configuration and the equivalent RouterOS command that the bouncer generates. The RouterOS commands are shown to help you understand exactly what rules are created on the router.

firewall.reject_with Optional

Env: FIREWALL_REJECT_WITH · Default: —

Customize the ICMP response type when deny_action is reject. Only valid when deny_action: "reject".

| Value | Description | | --------------------------- | ------------------------------------------------- | | icmp-network-unreachable | Network is unreachable | | icmp-host-unreachable | Host is unreachable | | icmp-port-unreachable | Port is unreachable | | icmp-protocol-unreachable | Protocol is unreachable | | icmp-network-prohibited | Network administratively prohibited | | icmp-host-prohibited | Host administratively prohibited | | icmp-admin-prohibited | Communication administratively prohibited | | tcp-reset | Send TCP RST (recommended for TCP-heavy services) |

Bouncer configuration:

firewall:
  deny_action: "reject"
  reject_with: "icmp-admin-prohibited"

Equivalent RouterOS commands generated by the bouncer:

# Without reject_with (default reject behavior):
/ip/firewall/filter add chain=input action=reject src-address-list=crowdsec-banned comment="crowdsec-bouncer:filter-input-input-v4 @cs-routeros-bouncer"

# With reject_with="icmp-admin-prohibited":
/ip/firewall/filter add chain=input action=reject reject-with=icmp-admin-prohibited src-address-list=crowdsec-banned comment="crowdsec-bouncer:filter-input-input-v4 @cs-routeros-bouncer"

# With reject_with="tcp-reset":
/ip/firewall/filter add chain=input action=reject reject-with=tcp-reset src-address-list=crowdsec-banned comment="crowdsec-bouncer:filter-input-input-v4 @cs-routeros-bouncer"

Tip

Use tcp-reset if you mainly want to reject TCP connections (SSH brute-force, web scanners). Use icmp-admin-prohibited for a generic “access denied” response that works with any protocol.

---

firewall.filter.connection_state Optional

Env: FIREWALL_FILTER_CONNECTION_STATE · Default: — (matches all)

Add a connection-state matcher to filter rules. This restricts rule matching to specific connection states, allowing established/related connections to pass through even if the source IP is banned.

Comma-separated values are normalized before RouterOS use, so new, invalid is treated as new,invalid.

| State | Description | | ------------- | ---------------------------------------------------------- | | new | A new connection (first packet of a flow) | | established | Part of an already established connection | | related | Related to an existing connection (e.g., FTP data channel) | | invalid | Cannot be identified or does not have any known state | | untracked | Packet is untracked (bypassing connection tracking) |

Caution

This option only applies to filter rules. RAW rules do not support connection-state matching because raw operates before connection tracking.

Bouncer configuration — block only new connections:

firewall:
  filter:
    enabled: true
    chains: ["input"]
    connection_state: "new"

Equivalent RouterOS commands:

# Without connection_state (default — blocks ALL packets from banned IPs):
/ip/firewall/filter add chain=input action=drop src-address-list=crowdsec-banned comment="crowdsec-bouncer:filter-input-input-v4 @cs-routeros-bouncer"

# With connection_state="new" (only blocks NEW connections, existing ones can finish):
/ip/firewall/filter add chain=input action=drop connection-state=new src-address-list=crowdsec-banned comment="crowdsec-bouncer:filter-input-input-v4 @cs-routeros-bouncer"

# With connection_state="new,invalid" (blocks new and invalid packets):
/ip/firewall/filter add chain=input action=drop connection-state=new,invalid src-address-list=crowdsec-banned comment="crowdsec-bouncer:filter-input-input-v4 @cs-routeros-bouncer"

Use case

Setting connection_state: "new" is useful if you want to block new connections from banned IPs but allow already-established connections (e.g., ongoing downloads) to finish gracefully. This prevents abruptly cutting off legitimate sessions that were started before the IP was banned.

---

firewall.filter.log_prefix / firewall.raw.log_prefix / firewall.block_output.log_prefix Optional

Env: FIREWALL_FILTER_LOG_PREFIX / FIREWALL_RAW_LOG_PREFIX / FIREWALL_BLOCK_OUTPUT_LOG_PREFIX

Override the global log_prefix for specific rule types. This allows differentiating log entries from filter, raw, and output rules when parsing RouterOS logs.

Resolution order: per-type prefix → global firewall.log_prefix.

| Rule type | Config key | Env var | | ------------------ | ---------------------------------- | ---------------------------------- | | Filter input rules | firewall.filter.log_prefix | FIREWALL_FILTER_LOG_PREFIX | | Raw input rules | firewall.raw.log_prefix | FIREWALL_RAW_LOG_PREFIX | | Output rules | firewall.block_output.log_prefix | FIREWALL_BLOCK_OUTPUT_LOG_PREFIX |

Bouncer configuration:

firewall:
  log: true
  log_prefix: "crowdsec" # global default
  filter:
    log_prefix: "cs-filter" # overrides global for filter rules
  raw:
    log_prefix: "cs-raw" # overrides global for raw rules
  block_output:
    log_prefix: "cs-output" # overrides global for output rules

Equivalent RouterOS commands:

# Filter rules use "cs-filter" prefix:
/ip/firewall/filter add chain=input action=drop src-address-list=crowdsec-banned log=yes log-prefix="cs-filter" comment="crowdsec-bouncer:filter-input-input-v4 @cs-routeros-bouncer"

# Raw rules use "cs-raw" prefix:
/ip/firewall/raw add chain=prerouting action=drop src-address-list=crowdsec-banned log=yes log-prefix="cs-raw" comment="crowdsec-bouncer:raw-prerouting-input-v4 @cs-routeros-bouncer"

# Output rules use "cs-output" prefix:
/ip/firewall/filter add chain=output action=drop dst-address-list=crowdsec-banned out-interface=ether1 log=yes log-prefix="cs-output" comment="crowdsec-bouncer:filter-output-output-v4 @cs-routeros-bouncer"

RouterOS log output example

jan/15 14:30:01 firewall,info cs-filter input: in:ether1 out:(unknown 0), src-mac 00:11:22:33:44:55, proto TCP (SYN), 185.220.101.1:45678->192.168.1.1:22, len 60
jan/15 14:30:01 firewall,info cs-raw prerouting: in:ether1 out:(unknown 0), src-mac 00:11:22:33:44:55, proto TCP (SYN), 185.220.101.1:45679->192.168.1.1:443, len 60
jan/15 14:30:02 firewall,info cs-output output: in:(unknown 0) out:ether1, proto TCP, 192.168.1.100:54321->185.220.101.1:80, len 60

Use case

Per-type log prefixes are essential for log parsing tools (e.g., syslog parsers, fail2ban, or SIEM systems) that need to distinguish between inbound blocked traffic (filter/raw) and outbound blocked traffic (output).

---

firewall.block_input.whitelist Optional

Env: FIREWALL_BLOCK_INPUT_WHITELIST · Default: —

Name of a RouterOS address-list containing trusted IPs that should bypass CrowdSec blocking. When set, the bouncer creates an accept rule before the drop/reject rule for each chain, allowing traffic from the whitelisted sources to pass through even if they are in the CrowdSec ban list.

This works with both filter and raw rules. The address-list must be created and managed separately on the router.

Step 1 — Create the whitelist on your router:

# Add trusted IPs to the whitelist address-list (manage this yourself):
/ip/firewall/address-list add list=crowdsec-whitelist address=10.0.0.1 comment="monitoring server"
/ip/firewall/address-list add list=crowdsec-whitelist address=192.168.1.0/24 comment="LAN subnet"

Step 2 — Configure the bouncer:

firewall:
  block_input:
    whitelist: "crowdsec-whitelist"

Equivalent RouterOS commands generated by the bouncer:

# For each chain, the bouncer creates TWO rules — accept BEFORE drop:

# 1) Accept rule for whitelisted IPs (placed first):
/ip/firewall/filter add chain=input action=accept src-address-list=crowdsec-whitelist comment="crowdsec-bouncer:filter-input-whitelist-v4 @cs-routeros-bouncer"
# 2) Drop rule for banned IPs (placed after accept):
/ip/firewall/filter add chain=input action=drop src-address-list=crowdsec-banned comment="crowdsec-bouncer:filter-input-input-v4 @cs-routeros-bouncer"

# Same pattern for raw rules:
/ip/firewall/raw add chain=prerouting action=accept src-address-list=crowdsec-whitelist comment="crowdsec-bouncer:raw-prerouting-whitelist-v4 @cs-routeros-bouncer"
/ip/firewall/raw add chain=prerouting action=drop src-address-list=crowdsec-banned comment="crowdsec-bouncer:raw-prerouting-input-v4 @cs-routeros-bouncer"

# And for IPv6 (if enabled):
/ipv6/firewall/filter add chain=input action=accept src-address-list=crowdsec-whitelist comment="crowdsec-bouncer:filter-input-whitelist-v6 @cs-routeros-bouncer"
/ipv6/firewall/filter add chain=input action=drop src-address-list=crowdsec6-banned comment="crowdsec-bouncer:filter-input-input-v6 @cs-routeros-bouncer"

Use case

The whitelist is useful when you have trusted monitoring systems, security scanners, or internal services whose IPs might end up in CrowdSec ban lists (e.g., a vulnerability scanner that triggers brute-force detection). Instead of modifying CrowdSec itself, you can whitelist them at the firewall level.

Interaction with connection_state

When connection_state is configured, it also applies to the whitelist accept rule. This means the accept rule will only match packets in the specified connection states. For most use cases, this is fine because the bouncer-managed drop/reject rule uses the same connection_state filter. If you have additional firewall rules below the bouncer-managed rules, whitelisted IPs in other connection states may still be evaluated by them.

---

firewall.block_output.passthrough_v4 / passthrough_v6 Optional

Env: FIREWALL_BLOCK_OUTPUT_PASSTHROUGH_V4 / FIREWALL_BLOCK_OUTPUT_PASSTHROUGH_V6 · Default: —

Allow a specific local client IP to bypass output blocking. Uses src-address negation (!IP) on the output drop/reject rule, so packets from this source address are not blocked even when going to a banned destination.

Bouncer configuration:

firewall:
  block_output:
    enabled: true
    interface: "ether1"
    passthrough_v4: "192.168.1.100"
    passthrough_v6: "fd00::100"

Equivalent RouterOS commands:

# Without passthrough (default — blocks ALL local clients from reaching banned IPs):
/ip/firewall/filter add chain=output action=drop dst-address-list=crowdsec-banned out-interface=ether1 comment="crowdsec-bouncer:filter-output-output-v4 @cs-routeros-bouncer"

# With passthrough_v4="192.168.1.100" (all clients blocked EXCEPT 192.168.1.100):
/ip/firewall/filter add chain=output action=drop dst-address-list=crowdsec-banned out-interface=ether1 src-address=!192.168.1.100 comment="crowdsec-bouncer:filter-output-output-v4 @cs-routeros-bouncer"

# With passthrough_v6="fd00::100":
/ipv6/firewall/filter add chain=output action=drop dst-address-list=crowdsec6-banned out-interface=ether1 src-address=!fd00::100 comment="crowdsec-bouncer:filter-output-output-v6 @cs-routeros-bouncer"

Use case

Use this when you have a security scanner or honeypot (e.g., 192.168.1.100) that needs to communicate with known malicious IPs for research purposes, while still blocking outbound access for all other local clients.

---

firewall.block_output.passthrough_v4_list / passthrough_v6_list Optional

Env: FIREWALL_BLOCK_OUTPUT_PASSTHROUGH_V4_LIST / FIREWALL_BLOCK_OUTPUT_PASSTHROUGH_V6_LIST · Default: —

Same as passthrough but using an address-list instead of a single IP. Uses src-address-list negation (!list) on the output rule. This is more flexible when multiple clients need to bypass output blocking.

Note

When both a single IP and an address-list are configured for the same protocol, the address-list takes precedence and the single IP is ignored.

Step 1 — Create the passthrough list on your router:

# Add clients that should bypass output blocking:
/ip/firewall/address-list add list=trusted-clients-v4 address=192.168.1.100 comment="security scanner"
/ip/firewall/address-list add list=trusted-clients-v4 address=192.168.1.200 comment="honeypot server"

Step 2 — Configure the bouncer:

firewall:
  block_output:
    enabled: true
    interface: "ether1"
    passthrough_v4_list: "trusted-clients-v4"
    passthrough_v6_list: "trusted-clients-v6"

Equivalent RouterOS commands:

# With passthrough_v4_list="trusted-clients-v4" (all clients blocked EXCEPT those in the list):
/ip/firewall/filter add chain=output action=drop dst-address-list=crowdsec-banned out-interface=ether1 src-address-list=!trusted-clients-v4 comment="crowdsec-bouncer:filter-output-output-v4 @cs-routeros-bouncer"

# With passthrough_v6_list="trusted-clients-v6":
/ipv6/firewall/filter add chain=output action=drop dst-address-list=crowdsec6-banned out-interface=ether1 src-address-list=!trusted-clients-v6 comment="crowdsec-bouncer:filter-output-output-v6 @cs-routeros-bouncer"

---

Complete Example

Here is a full configuration combining multiple rule customization options:

firewall:
  deny_action: "reject"
  reject_with: "tcp-reset"
  log: true
  log_prefix: "crowdsec"
  rule_placement: "top"
  filter:
    enabled: true
    chains: ["input", "forward"]
    connection_state: "new"
    log_prefix: "cs-filter"
  raw:
    enabled: true
    chains: ["prerouting"]
    log_prefix: "cs-raw"
  block_input:
    interface: "ether1"
    whitelist: "crowdsec-whitelist"
  block_output:
    enabled: true
    interface: "ether1"
    log_prefix: "cs-output"
    passthrough_v4_list: "trusted-clients-v4"

Full RouterOS rules generated (IPv4)

# Filter — input chain (whitelist + reject with connection-state):
/ip/firewall/filter add chain=input action=accept src-address-list=crowdsec-whitelist in-interface=ether1 connection-state=new log=yes log-prefix="cs-filter" comment="crowdsec-bouncer:filter-input-whitelist-v4 @cs-routeros-bouncer"
/ip/firewall/filter add chain=input action=reject reject-with=tcp-reset src-address-list=crowdsec-banned in-interface=ether1 connection-state=new log=yes log-prefix="cs-filter" comment="crowdsec-bouncer:filter-input-input-v4 @cs-routeros-bouncer"

# Filter — forward chain (same pattern):
/ip/firewall/filter add chain=forward action=accept src-address-list=crowdsec-whitelist in-interface=ether1 connection-state=new log=yes log-prefix="cs-filter" comment="crowdsec-bouncer:filter-forward-whitelist-v4 @cs-routeros-bouncer"
/ip/firewall/filter add chain=forward action=reject reject-with=tcp-reset src-address-list=crowdsec-banned in-interface=ether1 connection-state=new log=yes log-prefix="cs-filter" comment="crowdsec-bouncer:filter-forward-input-v4 @cs-routeros-bouncer"

# Raw — prerouting chain (no connection-state, no reject-with):
/ip/firewall/raw add chain=prerouting action=accept src-address-list=crowdsec-whitelist in-interface=ether1 log=yes log-prefix="cs-raw" comment="crowdsec-bouncer:raw-prerouting-whitelist-v4 @cs-routeros-bouncer"
/ip/firewall/raw add chain=prerouting action=drop src-address-list=crowdsec-banned in-interface=ether1 log=yes log-prefix="cs-raw" comment="crowdsec-bouncer:raw-prerouting-input-v4 @cs-routeros-bouncer"

# Filter — output chain (with passthrough list):
/ip/firewall/filter add chain=output action=reject reject-with=tcp-reset dst-address-list=crowdsec-banned out-interface=ether1 src-address-list=!trusted-clients-v4 log=yes log-prefix="cs-output" comment="crowdsec-bouncer:filter-output-output-v4 @cs-routeros-bouncer"