Why This Matters

A solid firewall config can take hours to build — but minutes to lose.

Whether it’s:

• A reboot gone wrong
• A bad rule blocking your access
• An upgrade that resets the config
• Or simply forgetting what each rule does…

You need a system to keep your firewall alive, readable, and resilient.

1. Regular Backups and Exports

Difference Between Backup and Export:

How to Backup:

/system backup save name=firewall_config

You’ll get a file like firewall_config.backup in Files — download it to your PC!

How to Export Firewall Only:

/export file=firewall_export

You’ll get firewall_export.rsc.
You can edit, version in Git, or apply on other routers.

2. Use Comments Everywhere

Every rule, every address list, every NAT line — must have a comment.

Example:

/ip firewall filter
add chain=input src-address-list=TRUSTED_IPS action=accept comment="Allow remote Winbox"
/ip firewall nat
add chain=dstnat dst-port=443 action=dst-nat to-addresses=192.168.88.100 comment="HTTPS to NAS"

It’s not optional — future you will thank you.

3. Group Rules Logically

Use grouping by chain and purpose, for example:

• Section 1: Input chain
• Section 2: Forward chain (LAN access)
• Section 3: Forward chain (guest/VPN)
• Section 4: NAT rules
• Section 5: Special protections (DoS, brute-force)
• Section 6: Logging and drops

You can even add empty comment rules as section headers:

/ip firewall filter
add comment="=== INPUT CHAIN START ==="

4. Monitor With Logging (But Not Too Much)

Logging is great — until it crashes your CPU.

Tips:

• Only log important drops, like SSH brute-force or port scans
• Use log-prefix= to easily grep or filter
• Use log limits to reduce spam:

add chain=input src-address-list=SSH_BRUTE action=drop log=yes log-prefix="SSH_BRUTE " log-disabled=no

5. Lock Yourself Out? Here’s the Rescue Plan

If you apply a bad rule and lose access — do one of the following:

Option 1: MAC Winbox

• Connect directly via Winbox using MAC address
• It bypasses IP settings
• Only works in L2

Option 2: Netinstall Reset

• Use MikroTik’s Netinstall to reflash router
• You’ll need physical access and boot from Netinstall server

6. Pro Tips From the Field

Use Address Lists for everything — even internal networks
Document every rule in a .md or .rsc file
Export rules monthly and save in Git or cloud
Use scheduled scripts to check config or notify you
Disable unused services in /ip service

Final Summary

You’ve now built a fully functional, professional-grade MikroTik firewall with:

• Clear input/forward logic
• Dynamic protection against attacks
• NAT and Hairpin NAT
• Scalable address lists
• Clean, well-commented rules
• Backups, logging, and recovery plans

Сообщение Firewall Logging, Backups & Best Practices появились сначала на Boxvirt - Proxmox & OPNsense Infrastructure Guides.

What is NAT?

NAT (Network Address Translation) lets multiple devices on your internal network (usually private IPs like 192.168.x.x) share a single public IP to communicate with the internet.

MikroTik uses source NAT (src-nat) with masquerade by default to make this happen.

Basic Outbound NAT — Internet Access for LAN

Let’s make sure devices in your LAN can access the internet.

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

This tells MikroTik:
“All packets leaving the WAN interface should have their source IP replaced with the router’s public IP.”

What About Incoming Connections?

Suppose you want to host something like:

• A website on your NAS
• An Immich gallery on your home server
• A game server on your PC

You’ll need to port-forward incoming traffic from your public IP to the correct internal IP.

Step-by-Step: Create a Destination NAT (Port Forward)

Let’s say your NAS is at 192.168.88.100 and you want to expose HTTPS (TCP port 443):

/ip firewall nat
add chain=dstnat dst-address=YOUR_PUBLIC_IP protocol=tcp dst-port=443 \
    action=dst-nat to-addresses=192.168.88.100 to-ports=443 comment="Forward HTTPS to NAS"

If you have a dynamic IP, you can use interface lists instead:

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

What Is Hairpin NAT?

Imagine this:

• Your DNS (e.g., Unbound or Pi-hole) resolves nas.yourdomain.com to your public IP
• You’re inside your home network
• You open https://nas.yourdomain.com

Now your request leaves the LAN → goes to the router’s public IP → hits the port forward… and fails

That’s because by default, MikroTik doesn’t know how to reflect this back to LAN — it’s confused because the destination is “external,” but the source is internal.

That’s where Hairpin NAT comes in.

How to Enable Hairpin NAT

You’ll need two extra rules to make it work:

1. Accept Internal Reflection in Firewall

/ip firewall filter
add chain=forward src-address=192.168.88.0/24 dst-address=192.168.88.100 action=accept \
    comment="Allow hairpin access to NAS"

Adjust IPs accordingly.

2. Add NAT Reflection Rule

This rule rewrites the source address so the internal server sees it as coming from the router:

/ip firewall nat
add chain=srcnat src-address=192.168.88.0/24 dst-address=192.168.88.100 \
    out-interface=bridge action=masquerade comment="Hairpin NAT"

Replace bridge with your LAN bridge or interface if different.

Now you can access https://yourdomain.com inside your LAN, and it will hit the internal server without issues.

Troubleshooting Tips

• Make sure your port forward is above the general masquerade rule in NAT
• Check that your firewall forward chain allows the internal access
• If using VLANs, match the correct interfaces/subnets in Hairpin NAT rule
• Test from a real client, not the router itself

Full Example: HTTPS to NAS With Hairpin

# Port forward
/ip firewall nat
add chain=dstnat in-interface-list=WAN protocol=tcp dst-port=443 \
    action=dst-nat to-addresses=192.168.88.100 to-ports=443 comment="HTTPS to NAS"

# Hairpin NAT
/ip firewall nat
add chain=srcnat src-address=192.168.88.0/24 dst-address=192.168.88.100 \
    out-interface=bridge action=masquerade comment="Hairpin NAT"

# Allow forward
/ip firewall filter
add chain=forward src-address=192.168.88.0/24 dst-address=192.168.88.100 action=accept

Summary

You understand what NAT and port forwarding are
You can expose internal services to the public safely
You added Hairpin NAT to make them accessible locally
You troubleshooted common issues like DNS and interfaces

Сообщение Understanding NAT & Hairpin NAT in MikroTik появились сначала на Boxvirt - Proxmox & OPNsense Infrastructure Guides.

Why MikroTik Routers Get Targeted

If your router has a public IP — it will be scanned.
Thousands of bots around the world constantly:

• Look for open Winbox, SSH, Telnet, or API ports
• Try brute-force logins
• Launch SYN floods and DoS attacks
• Abuse open DNS for reflection attacks

Even a home router gets hit dozens of times a day.

So let’s build rules that:

• Drop malicious traffic
• Rate-limit brute-force attempts
• Detect scanners
• Log suspicious activity

Step 1: Detect and Drop Port Scanners

MikroTik has a neat feature to detect port scanning automatically.

Add this rule near the top of your input chain:

bashКопироватьРедактировать/ip firewall filter
add chain=input protocol=tcp psd=21,3s,3,1 action=add-src-to-address-list \
    address-list=PORT_SCANNERS address-list-timeout=1d comment="Detect TCP port scan"

Explanation:

• Detects if 21 different TCP ports are probed in 3 seconds
• Adds the source IP to PORT_SCANNERS list
• Keeps it blocked for 1 day

Now, block those scanners:

bashКопироватьРедактировать/ip firewall filter
add chain=input src-address-list=PORT_SCANNERS action=drop comment="Drop port scanners"

Step 2: Drop Bogon and Reserved IPs on WAN

Bots often spoof invalid IPs — like private ranges or loopback — that should never appear on WAN.

Block them at the input chain (and forward, if needed):

bashКопироватьРедактировать/ip firewall filter
add chain=input src-address=0.0.0.0/8 action=drop comment="Drop bogus src IP"
add chain=input src-address=127.0.0.0/8 action=drop comment="Drop loopback"
add chain=input src-address=10.0.0.0/8 action=drop comment="Drop private src"
add chain=input src-address=169.254.0.0/16 action=drop comment="Drop link-local"
add chain=input src-address=192.168.0.0/16 action=drop comment="Drop private src"

Step 3: Basic DoS Protection (SYN Flood, Ping Flood)

MikroTik supports connection limits and rate matching.

Limit TCP SYN connections per IP:

/ip firewall filter
add chain=input protocol=tcp tcp-flags=syn connection-limit=30,32 \
    action=add-src-to-address-list address-list=SYN_FLOODERS \
    address-list-timeout=1d comment="SYN flood detect"
add chain=input src-address-list=SYN_FLOODERS action=drop comment="Drop SYN flooders"

Limit ICMP (Ping) Floods:

/ip firewall filter
add chain=input protocol=icmp limit=5,10 action=accept comment="Allow limited ping"
add chain=input protocol=icmp action=drop comment="Drop excessive ping"

Step 4: Brute Force Protection — SSH, Winbox, etc.

We’ll use connection rate limits to detect brute force:

SSH Brute-Force Detection:

/ip firewall filter
add chain=input protocol=tcp dst-port=22 src-address-list=!TRUSTED_IPS \
    connection-state=new src-address-list=!SSH_WHITELIST \
    action=add-src-to-address-list address-list=SSH_BRUTE address-list-timeout=1d \
    comment="SSH brute force detector"

add chain=input src-address-list=SSH_BRUTE action=drop comment="Drop SSH brute IPs"

You can repeat this for Winbox (port 8291), Telnet, or other services.

Step 5: Log Suspicious Behavior (Optional but Useful)

You can log any drop or suspicious action:

/ip firewall filter
add chain=input src-address-list=SSH_BRUTE action=drop log=yes log-prefix="SSH BRUTE: "

Just remember: log carefully. If you’re under a flood, logging every packet can overload your router.

Tip: Use Connection Limits for Other Abuse Scenarios

If you suspect spamming, malware, or excessive usage — you can add connection limits per IP or per subnet.

Example:

/ip firewall filter
add chain=forward protocol=tcp dst-port=25 src-address-list=LAN_SUBNETS \
    connection-limit=10,32 action=drop comment="Limit SMTP spam"

Example: Full Protection Ruleset Snippet

# Port scan detection
add chain=input protocol=tcp psd=21,3s,3,1 action=add-src-to-address-list \
    address-list=PORT_SCANNERS address-list-timeout=1d comment="Port scan detect"
add chain=input src-address-list=PORT_SCANNERS action=drop

# Brute force protection
add chain=input protocol=tcp dst-port=22 connection-state=new \
    src-address-list=!TRUSTED_IPS action=add-src-to-address-list \
    address-list=SSH_BRUTE address-list-timeout=1d comment="SSH brute detect"
add chain=input src-address-list=SSH_BRUTE action=drop

# SYN flood
add chain=input protocol=tcp tcp-flags=syn connection-limit=30,32 \
    action=add-src-to-address-list address-list=SYN_FLOODERS address-list-timeout=1d
add chain=input src-address-list=SYN_FLOODERS action=drop

# ICMP rate limit
add chain=input protocol=icmp limit=5,10 action=accept
add chain=input protocol=icmp action=drop

# Bogon drop
add chain=input src-address=0.0.0.0/8 action=drop
add chain=input src-address=10.0.0.0/8 action=drop
add chain=input src-address=127.0.0.0/8 action=drop

Summary

You’ve implemented rules against port scanners, brute force, SYN floods, and ping floods
You block reserved and spoofed IPs
You rate-limit ICMP and connection abuse
You log and block offenders dynamically
You’re now very hard to scan or attack

Сообщение Firewall Protection Against Attacks появились сначала на Boxvirt - Proxmox & OPNsense Infrastructure Guides.

In MikroTik’s firewall, the forward chain handles traffic that passes through the router — not destined to it.

Examples:

• Your laptop accessing google.com
• A guest phone trying to stream Netflix
• A surveillance camera sending footage to the cloud
• A VPN client accessing a NAS in your LAN

If it goes through the router from one interface to another — it hits the forward chain.

Default MikroTik Behavior

By default, MikroTik allows everything in forward chain. That means:

• LAN can access WAN
• Devices in different subnets can talk to each other
• IoT devices can ping your servers
• Anyone on your guest Wi-Fi can scan your home PCs

Sounds bad? It is.

We’re going to change that.

Our Goal

• Allow LAN to go to the internet
• Block internet from accessing LAN (unsolicited)
• Segment guests, IoT, and sensitive networks
• Only allow specific cross-subnet traffic
• Detect and log suspicious or brute-force attempts
• Rate-limit scans and flooding

Step 1: Allow Established and Related Connections

We always start here:

/ip firewall filter
add chain=forward connection-state=established,related action=accept comment="Allow related & established"

This permits returning traffic like replies to web requests.

Step 2: Drop Invalid Connections

Packets without context or connection tracking often indicate garbage, malware, or errors:

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

Step 3: Allow LAN and VPN to Internet

We’ll assume you already have LAN_SUBNETS and VPN_SUBNETS address lists. You allow these to go out:

/ip firewall filter
add chain=forward src-address-list=LAN_SUBNETS out-interface-list=WAN action=accept comment="LAN to internet"
/ip firewall filter
add chain=forward src-address-list=VPN_SUBNETS out-interface-list=WAN action=accept comment="VPN to internet"

Optional: Instead of out-interface-list=WAN, you can use dst-address-type=!local or other advanced filtering.

Step 4: Block Inter-Subnet Traffic (Optional)

If you don’t want your guest network to access your private network, drop or restrict it.

Example:

/ip firewall filter
add chain=forward src-address=192.168.20.0/24 dst-address=192.168.88.0/24 action=drop comment="Block Guest to LAN"

You can also use interface lists or VLANs here.

Step 5: Log and Drop Everything Else

At the bottom of the chain, drop all other forward attempts. Optionally log them:

/ip firewall filter
add chain=forward log=yes log-prefix="Dropped FORWARD: " action=drop

Or just quietly drop:

/ip firewall filter
add chain=forward action=drop comment="Drop all else"

Pro Tip: If you’re running services that should be reachable (e.g., port forwards), you’ll create exceptions before this drop rule.

Optional: Allow Specific Internal Flows

For example, if a VPN client needs to reach a NAS in your LAN:

/ip firewall filter
add chain=forward src-address=10.10.10.0/24 dst-address=192.168.88.100 protocol=tcp dst-port=445 action=accept comment="VPN to NAS (SMB)"

Or allow ICMP (ping) between LAN and VPN:

/ip firewall filter
add chain=forward src-address-list=VPN_SUBNETS dst-address-list=LAN_SUBNETS protocol=icmp action=accept comment="VPN ping LAN"

Forward Chain Example (Clean & Secure)

/ip firewall filter
add chain=forward connection-state=established,related action=accept comment="Allow known connections"
add chain=forward connection-state=invalid action=drop comment="Drop invalid"

add chain=forward src-address-list=LAN_SUBNETS out-interface-list=WAN action=accept comment="LAN internet"
add chain=forward src-address-list=VPN_SUBNETS out-interface-list=WAN action=accept comment="VPN internet"

add chain=forward src-address=192.168.20.0/24 dst-address=192.168.88.0/24 action=drop comment="Guest to LAN — blocked"

add chain=forward action=drop comment="Drop everything else"

Summary

You’ve secured the forward chain
You allowed legitimate traffic to pass
Blocked inter-subnet traffic where needed
Dropped unknown or invalid connections
Laid the groundwork for firewall segmentation

Сообщение Forward Chain Firewall Rules: Controlling LAN, Guests, and the Internet появились сначала на Boxvirt - Proxmox & OPNsense Infrastructure Guides.

The input chain governs access to your router itself — the Winbox interface, SSH terminal, web admin panel (WebFig), DNS, and more. If this chain is open, you’re essentially leaving your MikroTik naked on the internet.

And bots will try to log in. Constantly.

Even if they fail, just the traffic volume can cause performance issues, log flooding, and trigger ISP abuse reports.

So, our goal is clear: Block everything by default, then allow only trusted IPs to access administrative services.

Step-by-Step Strategy

1. Allow established and related connections
2. Allow access from trusted IPs / LAN
3. Block new WAN connections
4. Log attempts from unknown sources (optional)
5. Disable unused services like FTP, Telnet
6. Secure access with strong passwords and timeouts

Step 1: Allow Safe Traffic

First, as discussed in earlier sections, allow already-established connections and those related to them (like ICMP replies):

/ip firewall filter
add chain=input connection-state=established,related action=accept comment="Allow established & related"

This ensures existing connections, like your current Winbox session, won’t get cut off.

Step 2: Allow Access from Trusted Sources

Here, we’ll permit only specific IPs and subnets — defined earlier in our TRUSTED_IPS and LAN_SUBNETS address lists.

/ip firewall filter
add chain=input src-address-list=TRUSTED_IPS action=accept comment="Allow admin access from trusted IPs"
/ip firewall filter
add chain=input src-address-list=LAN_SUBNETS action=accept comment="Allow access from LAN"

You can also target specific ports:

add chain=input src-address-list=TRUSTED_IPS protocol=tcp dst-port=8291,22 action=accept comment="Allow Winbox & SSH"

Step 3: Drop Everything Else

Now it’s time to block everything not explicitly allowed. And we’ll do this carefully, placing this rule after all previous accepts:

/ip firewall filter
add chain=input connection-state=new action=drop comment="Drop all new inbound connections"

This rule will reject any new connection attempt to the router itself — unless it came from a trusted address.

Step 4: Optional Logging (for Curiosity or Forensics)

Want to see who’s knocking on your WAN interface? You can log their attempts like this:

/ip firewall filter
add chain=input connection-state=new log=yes log-prefix="Blocked INPUT: " action=drop

But be careful — under attack, logs can grow rapidly. Use it temporarily or with rate limits.

Step 5: Disable Unused MikroTik Services

By default, RouterOS enables things like:

• Telnet (TCP 23)
• FTP (TCP 21)
• WebFig (TCP 80, 443)
• Winbox (TCP 8291)
• SSH (TCP 22)
• API ports (8728, 8729)

If you’re not using a service — disable it:

/ip service disable telnet
/ip service disable ftp
/ip service disable www
/ip service disable www-ssl

You can also restrict services to certain interfaces or address lists:

/ip service set winbox address=192.168.88.0/24

Step 6: Secure Credentials and Access Settings

Even with firewall rules, don’t forget:

• Use strong passwords for all user accounts
• Don’t use the default admin user — disable or rename it
• Set System → Users → Group → Policies carefully
• Set Winbox inactivity timeouts under Tools → Settings

Summary

You’ve locked down direct access to the router
Only trusted IPs or LAN can manage the router
Everything else is blocked or logged
You’ve disabled services you don’t use
Your firewall input chain is clean, simple, and secure

Сообщение Protecting Router Access: Lock Down the Input Chain Like a Pro появились сначала на Boxvirt - Proxmox & OPNsense Infrastructure Guides.

Let’s face it — if you’ve ever tried managing a firewall with individual IP rules, you know it gets messy fast. One rule for your laptop, another for your phone, a separate one for your work VPN, and maybe one more for your buddy’s IP that you forgot to label properly. Before you know it, your rule set looks like a crime scene.

Address Lists fix that.

They let you group IPs into logical categories and reference them in your rules. Once you start using them, you’ll wonder how you ever lived without them.

What Is an Address List?

In MikroTik, an address list is simply a named group of IP addresses or subnets. You can reference them in:

• Firewall filter rules
• NAT rules
• Mangle rules
• And even scripts

Instead of writing 5 different rules for 5 IPs — you can write one rule and maintain the list separately. This keeps your rules clean, readable, and easy to update.

Why Use Address Lists?

Here’s what you get when you build your rules around address lists:

Benefit	Why it matters
Clarity	You’ll immediately know what the rule is protecting
Simplicity	Fewer firewall rules overall
Scalability	Easily add/remove IPs without editing rule logic
Automation	Use scripts or dynamic rules to update lists
Security	Group risky IPs together for blocking or limiting

The Essential Lists You Should Create

Here’s a professional starter kit of address lists you can (and should) build:

You’ll use these lists throughout your firewall — from access control to detection.

How to Add IPs to Address Lists

Here are real-world examples of building useful address lists.

Add your main LAN subnet:

/ip firewall address-list add list=LAN_SUBNETS address=192.168.88.0/24 comment="Main LAN"

Add your work IP for remote access:

/ip firewall address-list add list=TRUSTED_IPS address=203.0.113.5 comment="Work VPN Admin"

Add a known attacker to blocklist:

/ip firewall address-list add list=BLOCKED_IPS address=185.23.88.44 comment="SSH Brute Force"

How to Use Lists in Firewall Rules

Let’s say you want to allow only your LAN to access the router. You could write:

/ip firewall filter add chain=input src-address=192.168.88.0/24 action=accept

But that’s hardcoded. What if you have more than one subnet?

Instead, write:

/ip firewall filter add chain=input src-address-list=LAN_SUBNETS action=accept comment="Allow LAN access"

Now if you add another subnet to LAN_SUBNETS, the rule automatically applies — no editing needed.

Bonus: Temporary Blocks with Timeout

You can even add entries to a list that expire automatically — great for banning bots or brute-force IPs for a limited time:

/ip firewall address-list add list=BLOCKED_IPS address=192.0.2.66 timeout=1d comment="Temp ban"

The IP will be automatically removed from the list after one day.

Dynamic Updates & Detection

Once you’ve built address lists, you can:

• Dynamically add IPs to lists based on behavior (via firewall rules or scripting)
• Use Netwatch or scripts to pull blocklists from external sources
• Trigger alerts when new IPs are added

It’s flexible, it’s powerful — and it scales with your network.

Example — A Well-Structured List Setup

/ip firewall address-list
add list=LAN_SUBNETS address=192.168.88.0/24 comment="Main LAN"
add list=LAN_SUBNETS address=192.168.50.0/24 comment="Server Subnet"

add list=TRUSTED_IPS address=203.0.113.5 comment="Work VPN Admin"
add list=TRUSTED_IPS address=192.0.2.77 comment="My Laptop"

add list=BLOCKED_IPS address=185.22.11.19 comment="Repeated Scanner"

Advanced Use Cases

• Firewall detection logic: If someone hits a protected port → auto-add to BLOCKED_IPS
• Geographic filtering: Create lists for country-specific IP ranges
• Scheduled lockdowns: Block/allow lists based on time (via script or scheduler)
• External threat feeds: Import addresses from abuse.ch, spamhaus, etc.

Recap

You now understand what address lists are
You know how to build and use them effectively
You’re ready to write cleaner, more flexible rules
You’ve added tools for blocking, detecting, and managing access like a pro

Сообщение Address Lists for Humans (and Hackers) MikroTik появились сначала на Boxvirt - Proxmox & OPNsense Infrastructure Guides.

Let’s be honest — most MikroTik routers out there are running with some half-baked default config and leftover rules that nobody fully understands. We’re not going to build on a mystery box.
We’re going to start clean, understand everything, and configure the firewall like a professional from day one.

Step 1: Wipe Out the Default Config (Optional but Recommended)

When you first unbox and boot a MikroTik router, it usually comes with a default setup — which may include:

• DHCP server
• NAT masquerade rule
• Basic firewall rules (sometimes)
• Bridge interfaces
• Winbox open to all

The problem?

You don’t know what it’s doing — and that’s a security risk.
If you’re serious about building your own firewall rules from scratch, it’s better to clear the default config and start fresh.

Warning:

Resetting your router will remove all current config — including access. Be sure you’re physically connected or know what you’re doing.

How to Reset the Config (Without Default Rules):

From Winbox or Terminal, run:

/system reset-configuration no-defaults=yes skip-backup=yes

This will reboot the router and leave it with a bare system — no IPs, no NAT, no DHCP, no firewall.
You’ll need to connect via MAC address in Winbox afterward to start configuring.

Step 2: Reconnect via MAC Address (Winbox Only)

After reset, the router won’t have an IP address — so you can’t reach it by IP.

Open Winbox, click on Neighbors, and connect using the MAC address.

This is a unique MikroTik feature — no DHCP needed. Once you’re back in, you can start configuring IP addresses manually.

Step 3: Add a Basic Management IP (for Access)

Let’s assign a static IP to the LAN interface so you can work more comfortably.

/ip address add address=192.168.88.1/24 interface=ether2

Replace ether2 with your LAN port. Now set your PC IP to something like 192.168.88.10 and reconnect via this IP in Winbox or browser (WebFig).

Step 4: View Existing Firewall Rules (If Any)

If you chose not to reset your router, or you’re working with an existing config, take a moment to see what rules are already in place:

/ip firewall filter print

You’ll see a list of rules — each with a number, chain, action, and optional comments.

Delete everything you don’t fully understand or want to replace.

To remove all firewall filter rules:

/ip firewall filter remove [find]

Step 5: Save a Clean Backup (Optional but Smart)

Now that we’ve wiped the junk and set a minimal base IP, let’s save this clean state so you can revert back easily.

From Terminal:

/system backup save name=clean_base_config

Or in Winbox → Files → Backup → Save.

Download the backup to your PC, just in case.

What You Have Now

Clean MikroTik config
Static IP for local access
Empty firewall — ready to build securely
No random services exposed
Full control

You’re now in charge of every packet that enters or leaves your router.

Сообщение Initial Setup: Clean the Slate and Prepare for Real Protection появились сначала на Boxvirt - Proxmox & OPNsense Infrastructure Guides.

In MikroTik, you build your firewall rules manually, from scratch. This gives you incredible power — and just as much responsibility.

Let’s break down what actually happens to a packet as it passes through the router.

The Three Chains: input, forward, output

MikroTik’s firewall is built on three main chains, each with a very specific job.

1. Input chain — protects the router itself

This chain handles packets destined for the router. For example:

• You’re logging in via Winbox or SSH
• You’re pinging the router
• You’re accessing WebFig or the DNS server on the router

Pro Tip: If you don’t protect the input chain, your MikroTik is exposed to the world.

2. Forward chain — controls traffic passing through the router

This is where you manage LAN WAN traffic, VPN clients, and even guest networks. If a packet goes through the router (from one interface to another), it hits the forward chain.

Examples:

• A computer on LAN opens a website
• A mobile device connects to VPN and accesses the internet
• A camera on VLAN 20 streams video to a remote server

3. Output chain — traffic from the router

This is not often used in most setups, but still important. It’s for traffic the router itself initiates:

• DNS queries (if using MikroTik as DNS client)
• NTP sync
• RouterOS package updates

We’ll mostly focus on input and forward, but it’s good to know this chain exists.

What Determines Which Chain Gets Hit?

Let’s say a packet arrives from the internet:

• If it’s meant for your public IP (e.g., someone scanning port 8291) → input
• If it’s meant for a device on your LAN → forward
• If it’s coming from the router itself → output

Every packet hits only one of these chains.

Connection States: new, established, related, invalid

This is one of the most important things to understand if you want to write smart firewall rules.

When MikroTik receives a packet, it checks its connection tracking table and assigns it a state:

State	Meaning
new	The first packet of a connection (like a TCP SYN or first UDP packet)
established	Part of an already approved connection (like reply packets)
related	Connection triggered by another one (e.g., FTP data channel, ICMP error)
invalid	Corrupted, expired, or unknown connection — usually garbage

Best Practice:

Always allow established and related connections. Drop invalid. Then handle new traffic with real rules.

/ip firewall filter
add chain=input connection-state=established,related action=accept
add chain=input connection-state=invalid action=drop

You’ll repeat the same for forward chain too.

What Happens First? Firewall Rule Processing Order

MikroTik firewall goes down the list top to bottom, and stops at the first matching rule.

That means rule order matters. If your first rule says «accept everything,» nothing else will be checked. If a later rule says «drop all,» but the earlier one accepted the traffic — too late.

Tip: Always put specific accept rules before broad drop rules.

Example order:

1. accept established, related
2. allow DNS from LAN
3. allow VPN traffic
4. drop invalid
5. drop everything from WAN

Thought Experiment: Which Chain?

Let’s play a quick round to see how well you understand the chains. Which chain handles these?

1. You connect to MikroTik via Winbox from the internet → input
2. Your laptop browses Google via NAT → forward
3. MikroTik checks for a RouterOS update → output
4. Remote VPN client accesses NAS on your LAN → forward
5. You ping MikroTik from LAN → input

Logging — Know What’s Hitting the Firewall

Logging helps understand what rules are matching (and what isn’t).

You can log a rule like this:

/ip firewall filter
add chain=input action=drop log=yes log-prefix="DROP-WAN: "

Log prefix helps quickly identify in logs. Use it sparingly — too much logging can crash your router under attack.

Summary of Key Concepts

• MikroTik has 3 firewall chains — input, forward, output
• Every packet hits only one chain
• You should protect input to lock down the router
• Use connection states to simplify rule logic
• Rule order matters — first match wins
• Keep logs clean and informative

Сообщение How MikroTik Firewall Works (and Why You Need to Understand It) появились сначала на Boxvirt - Proxmox & OPNsense Infrastructure Guides.

Want to connect to your home network from anywhere? Or route all your MikroTik traffic through a VPS with a static IP? Then WireGuard is your best friend. Here’s how I personally set it up — step-by-step, no fluff, no jargon.

Why WireGuard?

WireGuard is a modern VPN protocol. It’s fast, lightweight, and refreshingly simple — no certificates, no massive config files. Just a few keys, IPs, and you’re good to go. If you’re on RouterOS 7+, you’re ready.

What You’ll Need

• A MikroTik router running RouterOS 7.1+
• Access to Winbox or the terminal
• A basic idea of who’s the server and who’s the client
• A few minutes (and maybe a coffee )

Step 1: Create the WireGuard Interface

1. Open Winbox → Interfaces → WireGuard
2. Click the + and name your interface something like wg0
3. Choose a port, like 13231
4. Generate a keypair using the terminal:

/interface wireguard key print

Save both Private and Public keys somewhere safe.

Step 2: Add the Peer (the other side)

1. Go to WireGuard → Peers
2. Add a new peer:
   • Public Key from the other side (your client or VPS)
   • Allowed Address: e.g., 192.168.100.2/32
   • Endpoint: optional if you’re not the client
   • Persistent Keepalive: 25s if the peer is behind NAT

Step 3: Assign an IP Address to wg0

Go to IP → Addresses, click +:

• Address: 192.168.100.1/24
• Interface: wg0

That’s the MikroTik’s IP inside the VPN tunnel. Your client might be 192.168.100.2.

Step 4: Add a Route (If Needed)

If you’re connecting two networks (site-to-site), you’ll need to add a static route:

/ip route add dst-address=192.168.200.0/24 gateway=192.168.100.2

Step 5: Add Firewall Rules

Let’s make sure traffic is allowed:

/ip firewall filter add chain=input protocol=udp dst-port=13231 action=accept
/ip firewall filter add chain=forward src-address=192.168.100.0/24 action=accept

Optional: lock down your WAN completely (for extra paranoia):

/ip firewall filter add chain=input in-interface=ether1 connection-state=new action=drop

Step 6: Client Configuration (Linux Example)

[Interface]
PrivateKey = <your-client-private-key>
Address = 192.168.100.2/24

[Peer]
PublicKey = <mikrotik-public-key>
Endpoint = your.domain.com:13231
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

It’s the same on Windows — just paste it into the WireGuard GUI.

Step 7: Test It

• Ping 192.168.100.1 from the client
• In Winbox, check Interface → WireGuard — you should see traffic
• Still not working? Read below

Common Issues (and Fixes)

Summary

So far, you’ve:

• Set up a working WireGuard VPN on MikroTik
• Secured communication between two points
• Opened the door to advanced use cases — static IP via VPS, remote access, multi-site routing

Сообщение How to Set Up WireGuard VPN on MikroTik — Real-World Guide (2025) появились сначала на Boxvirt - Proxmox & OPNsense Infrastructure Guides.