DMZ on MikroTik: Isolating Web Servers from Your Office Network

You set up a web server inside the office network. A week later someone scanned it from outside and found a hole connecting it to the accounting server on the same subnet. Sound familiar? DMZ on MikroTik fixes this exactly the way it should have been from day one: the server is visible from the internet, but it physically cannot reach your LAN.

Here’s the practical part. No 4000-word introduction. One VLAN, three firewall chains, port forwarding, and scan protection. An hour of work, if your hands aren’t shaking.

1. The diagnosis: why a web server on a shared network is a ticking bomb

You set up a site or an app on a server inside the office. Everything works, everyone’s happy. Then the server gets compromised, through a CMS vulnerability, a leaky plugin, anything from outside. And if that server sits on the same subnet as the accounting department’s workstations, the attacker doesn’t just get one hacked site, they get access to the entire internal network. DMZ on MikroTik is a way to move a public-facing service into a separate segment, where breaking into the server doesn’t turn into breaking into the company.

What you’ll end up with: an isolated VLAN for web servers, forwarding for 80/443 (and any other ports) from outside, firewall rules that physically block traffic from DMZ to LAN, and basic protection against automated port scanning.

Time required: 40-60 minutes if MikroTik is already configured and you have Winbox or SSH access. If you’re starting from scratch, add 20 minutes for basic bridge configuration.

What you need before starting:

• MikroTik with RouterOS v7 (v6 works too, but the VLAN syntax is slightly different)
• At least 2 free Ethernet ports or one port set up as a VLAN trunk
• A public IP or port forwarding through your ISP
• Understanding of your current topology: where LAN is, where WAN is, what’s already in the firewall

The focus of this article, DMZ on MikroTik, is exactly that: not “how DMZ works” in theory, but a concrete working configuration you can copy and adapt.

What this article covers

• Why skipping a DMZ eventually leads to a breach in your LAN
• Step-by-step setup: VLAN, dst-nat, firewall filter
• Verifying the isolation actually works
• Common mistakes and how to fix them
• Alternative approaches, for when you don’t need a DMZ at all
• Maintenance: monitoring, config backup, rule persistence

2. Why this breaks down without a DMZ

Here’s what actually happens in production when a web server sits on the same subnet as the office:

• One subnet, one trust level. The firewall at the router level doesn’t distinguish “this is a server facing the internet” from “this is the accountant’s laptop.” Both are on 192.168.1.0/24, both trusted by default.
• Scanners find the service within minutes. Shodan and masscan constantly index open 80/443 ports across the entire internet. Your server will be found not because someone is specifically targeting you, but because bots scan the whole IPv4 range.
• A vulnerability in the application is not “if” but “when.” WordPress, Joomla, custom PHP, doesn’t matter what’s running. Sooner or later a hole shows up that gets someone a shell on the server.
• A shell on a server in a shared LAN is a shell in your network. An attacker on the server can ping internal hosts, scan SMB, reach terminal servers. Nothing stops routing inside the VLAN.
• Backups and databases live nearby. If the file server and web server are on the same subnet, compromising one gives access to the other at L2.
• The logs confirm this constantly. Open /log on any MikroTik with a public IP and you’ll see hundreds of connection attempts to SSH and web ports per day. That’s background noise, not an anomaly.

And your queries say the database hung when the server on the shared network got hit with a shell injection through a contact form.

3. The recipe: building a DMZ on MikroTik step by step

The scheme is simple: a bridge with VLAN filtering, a separate VLAN for DMZ, dst-nat to a public IP, and a firewall filter with three key rules.

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#ffffff',
    'primaryTextColor': '#1e293b',
    'primaryBorderColor': '#94a3b8',
    'lineColor': '#64748b',
    'fontSize': '15px',
    'fontFamily': 'ui-sans-serif, system-ui, sans-serif'
  },
  'flowchart': {'curve': 'linear', 'nodeSpacing': 50, 'rankSpacing': 50}
}}%%
flowchart TD
    A["Internet WAN"] --> B["MikroTik"]
    B --> C["VLAN 10 Office LAN"]
    B --> D["VLAN 20 DMZ web server"]
    D --> E["Internet via NAT"]
    D -.-> C
    style A fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style B fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style C fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d
    style D fill:#f8fafc,stroke:#f97316,stroke-width:2px,color:#c2410c
    style E fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d

The dotted arrow from D to C is what should be blocked. The whole article exists for that one arrow.

System requirements

Port table

Preparation

Check your current configuration before changing anything:

/interface bridge print
/interface vlan print
/ip firewall filter print
/ip firewall nat print

Result: you’ll see the list of existing bridges, VLANs, and rules. If a bridge already exists with LAN on it, we’ll add a VLAN on top of it without breaking what’s there.

Step 1. Create the VLAN for DMZ

Go to the bridge that already faces LAN and add a VLAN interface on top of it with a new ID.

/interface vlan add name=vlan20-dmz vlan-id=20 interface=bridge-lan

Result: a virtual interface vlan20-dmz now exists. No IP, no rules yet, just an L2 segment inside the bridge.

Step 2. Enable VLAN filtering on the bridge

Without this step, VLAN tags just roam across the whole network with no isolation. This is where filtering is what actually separates traffic by port.

/interface bridge set bridge-lan vlan-filtering=yes
/interface bridge vlan add bridge=bridge-lan vlan-ids=20 tagged=bridge-lan untagged=ether3
/interface bridge vlan add bridge=bridge-lan vlan-ids=10 tagged=bridge-lan untagged=ether2

Result: ether2 (the port to the office switches) delivers VLAN 10 untagged, ether3 (the port to the server in DMZ) delivers VLAN 20 untagged. The server and office machines never see the tags, for them it’s just a separate physical network.

Step 3. Assign an IP address to the DMZ segment

/ip address add address=192.168.20.1/24 interface=vlan20-dmz

Result: MikroTik now has a gateway address of 192.168.20.1 for the DMZ network. The server will get 192.168.20.10 (for example) with gateway 192.168.20.1.

Step 4. Set up dst-nat for inbound traffic

Public IP on the WAN interface, and inside, a web server at 192.168.20.10. Forward 80 and 443:

/ip firewall nat add chain=dstnat protocol=tcp dst-port=80 in-interface=ether1-wan action=dst-nat to-addresses=192.168.20.10 to-ports=80 comment="DMZ HTTP"
/ip firewall nat add chain=dstnat protocol=tcp dst-port=443 in-interface=ether1-wan action=dst-nat to-addresses=192.168.20.10 to-ports=443 comment="DMZ HTTPS"

Result: a request to the public IP on :80 and :443 goes to the server in DMZ. Verify this in the next step.

Step 5. Firewall filter: the core of the whole isolation

This is the heart of DMZ on MikroTik. Three rules that define who goes where:

/ip firewall filter add chain=forward connection-state=established,related action=accept comment="Allow established"
/ip firewall filter add chain=forward connection-state=invalid action=drop comment="Drop invalid"
/ip firewall filter add chain=forward in-interface=ether1-wan out-interface=vlan20-dmz protocol=tcp dst-port=80,443 action=accept comment="WAN to DMZ web"
/ip firewall filter add chain=forward in-interface=vlan20-dmz out-interface=bridge-lan action=drop comment="Block DMZ to LAN"
/ip firewall filter add chain=forward in-interface=vlan20-dmz out-interface=ether1-wan action=accept comment="Allow DMZ to internet"
/ip firewall filter add chain=forward action=drop comment="Default deny"

Rule order matters here. Established/related and invalid go first, that’s the baseline of any sane firewall. Next, allow WAN→DMZ only on 80/443. Then explicitly block DMZ→LAN. Then allow DMZ→internet, so the server can install updates and send mail. At the end, a default deny that catches anything not matched by the explicit rules.

Result: the server in DMZ is reachable from outside on 80/443, can reach the internet, but sees absolutely nothing on the office LAN: no ping, no SMB, no RDP.

Step 6. Protection against scanning

Scanners hammer port after port from one IP or range. Rate-limit new connections:

/ip firewall filter add chain=forward protocol=tcp dst-port=80,443 connection-state=new in-interface=ether1-wan dst-address=192.168.20.10 action=jump jump-target=port-scan-check comment="Check port scan"

/ip firewall filter add chain=port-scan-check protocol=tcp connection-limit=20,32 action=add-src-to-address-list address-list=scanners address-list-timeout=1h comment="Mark scanners"
/ip firewall filter add chain=port-scan-check src-address-list=scanners action=drop comment="Drop scanners"
/ip firewall filter add chain=port-scan-check action=accept comment="Accept rest"

Result: if a single IP opens more than 20 concurrent connections, it lands in the scanners address-list and gets dropped for an hour. A regular site visitor won’t trigger this, a mass scanner will.

4. Verification: is the isolation actually working

A config being written doesn’t mean it works as intended. Check it from three angles.

From the server in DMZ, try to reach the LAN (should fail):

ping 192.168.10.5

Result should be 100% packet loss. If the ping goes through, the “Block DMZ to LAN” rule isn’t working or is in the wrong position.

From outside, check that the web server is reachable:

curl -I https://your-domain.com

Result: HTTP 200 or a redirect. If it times out, check dst-nat and the WAN→DMZ rule.

On MikroTik itself, check the rule counters, are they incrementing on real traffic:

/ip firewall filter print stats

Result: the packet counter on “Block DMZ to LAN” should stay at zero under normal conditions. If it’s growing, someone is actually trying to break out of DMZ into LAN, and that’s worth investigating, not ignoring.

Check the logs for scan attempts:

/log print where topics~"firewall"
/ip firewall address-list print where list=scanners

5. Common problems: what breaks and how to fix it

It’s not as bad as you think. It’s actually worse, but every issue here is fixed with a single command.

/interface bridge port print

If you still have physical access to the device after losing network access, connect via the console port directly, bypassing the bridge. That’s the only reliable path when a self-inflicted rule has cut off network access.

About SSH and Winbox separately

/ip firewall filter add chain=input protocol=tcp dst-port=8291,22 src-address=!192.168.10.0/24 action=drop comment="Restrict management"

6. Alternatives

A DMZ on MikroTik via VLAN isn’t the only option, and not always the most convenient one.

• A separate physical switch for DMZ. Simpler conceptually, more expensive in hardware. Makes sense if you already have a spare switch and don’t want to spend router ports.
• A reverse proxy in front of the server (Nginx or Traefik) on a separate machine in DMZ. Adds another layer, useful if you have multiple servers and need a single entry point.
• Cloudflare Tunnel or similar. The server doesn’t open any ports outward at all, everything goes through an outbound connection to the cloud. Convenient for small projects, but adds a dependency on a third party.
• Virtualization with a separate hypervisor for DMZ. If the server is already virtual, move it to a separate physical host, not just a separate VLAN.

VLAN on MikroTik is chosen as the main scenario here because it doesn’t require extra hardware and works on equipment that’s already sitting in most offices.

7. Maintenance

Setting it up isn’t the same as forgetting about it. A DMZ without monitoring is just a nice diagram on paper.

• Monitor firewall counters. A script that checks hourly whether the packet count on “Block DMZ to LAN” is growing.
• Back up the configuration before any change. One forgotten export, and you’ll be rebuilding everything from memory at 3 AM.
• Persist rules via export and import on recovery. The config should load from a file, not from memory.
• Update RouterOS on a schedule, not after a breach. It only takes one overlooked vulnerability in an old firmware to compromise the whole perimeter.
• Regularly check the scanners address-list. If it’s been empty for weeks, either you have no traffic, or the rule stopped working.

/system backup save name=router-backup-$(:tostr [/system clock get date])
/export file=router-config-backup

Security checklist

• UFW / firewall filter: all rules explicit, default deny at the end
• Management access (SSH, Winbox) fully closed from outside
• SSH hardening on the server itself in DMZ: keys instead of passwords, fail2ban at the Linux host level (not on MikroTik, that’s the server’s job, not the router’s)
• Separate database user on the server with minimal privileges
• Router configuration backups and server data backups kept separate
• IP-based restrictions on administrative interfaces

Backup strategy

Restoring the config:

/system backup load name=router-backup-2026-07-20

Updating RouterOS

Before updating, check the changelog on the official MikroTik Download page, firewall behavior sometimes changes between minor versions.

/system backup save name=pre-update-backup
/system package update check-for-updates
/system package update install

If something breaks after the update, roll back using the same backup file saved before the update.

8. FAQ

Why isn’t the DMZ working after setup?

Most often it’s the firewall rule order. RouterOS processes rules top to bottom and stops at the first match. If accept established/related is too broad or default deny isn’t last, isolation won’t work as intended. Check the order with /ip firewall filter print.

How do I verify the DMZ is set up correctly?

A ping from the server in DMZ to any host on LAN should consistently time out. At the same time, curl from outside to the public IP should get a response from the web server. If both conditions hold, isolation is configured correctly.

What if the server in DMZ can’t update packages?

Check the DMZ→internet rule, it needs to be above default deny in the forward chain. Also confirm DNS resolves from the server, otherwise updates fail even with the firewall open.

How is a DMZ different from plain port forwarding?

Plain port forwarding (dst-nat) by itself doesn’t isolate the server from the rest of the network, it just redirects traffic. DMZ adds firewall rules on top that physically prevent the server from initiating connections toward the LAN. Port forwarding without DMZ is an open door into the main house, DMZ is a separate wing with its own single entrance.

9. What’s next

You set up the VLAN, configured dst-nat, and closed off DMZ→LAN with three lines of firewall filter. Now a breach of the web server through an application vulnerability stays a problem of that one server, not a ticket into the entire office network.

From here it’s about monitoring and regular updates. A config doesn’t rot by itself, but it doesn’t watch itself either. If something’s off after setup, drop a comment and we’ll sort it out.