I could reach my RouterOS box from other VLANs, but not from the VLAN whose own gateway IP I was trying to use. Remote gateway addresses answered SSH. The local one on the same segment did not. That is backwards from how you expect routing to feel, and it wasted a weekend of careful tests.

This is what I checked, what did not fix it, and how I stopped fighting it without leaving the network in a bad state. It rhymes with an earlier story, the management VLAN routing mystery, except here I pinned more of the odd behavior on the router side (input chain never saw the traffic) instead of the laptop.

The problem

From a client on VLAN 10 (for example 10.0.10.x):

• SSH to the router on another VLAN’s address (e.g. 10.0.99.1, 10.0.20.1) → works
• SSH to 10.0.10.1 (the gateway on that VLAN) → fails with “no route to host”
• Traffic to the local gateway IP did not hit the firewall input chain (I confirmed with debug logging)
• The router could still ping the client from that interface; L2 looked fine
• The routing table showed normal connected routes for each /24

So it was not “the router is down” and it was not a generic VLAN mis-tag on the wire. Something in the path treated “me talking to my own subnet’s router address” differently than “me talking to a different subnet’s router address.”

Hardware context: RouterOS 7.20.x (stable) on an RB4011iGS+ (ARM). Bridge VLAN filtering in play, VLAN interfaces on the bridge, separate bridge VLAN table entries per VLAN (per MikroTik’s own docs for this style of setup).

What I tried first

Strict address state with api_modify

I refactored router-vlans.yml to enforce IP addresses with api_modify so drift could not linger. During testing the network broke hard enough that I rolled back. Useful experiment; not the root cause of this symptom.

Splitting combined VLAN entries

I had read enough forum threads about combined vlan-ids= entries that I split one big entry into one row per VLAN, matching MikroTik’s examples. Same outcome: no fix for local gateway reachability, and another rollback when things got worse mid-change.

Config sanity pass

Everything I expected to matter looked correct:

• Bridge port frame-types: admit-all
• Bridge ingress-filtering: yes
• VLAN interfaces: all on bridge-lan, not parked on slave ports by mistake
• Subnets: /24 everywhere that should be /24
• Firewall rules: present; the weird part was traffic never arriving for the failing case
• Bridge VLAN table: separate entries per VLAN after the split test

So I was not staring at a single obvious typo. I was staring at behavior that skipped input processing for the local-gateway case.

What the routing table showed

A typical connected route looked like:

dst-address=10.0.10.0/24
gateway=vlan10-clients
local-address=10.0.10.1%vlan10-clients

That says “this network is directly connected,” which is true. It does not explain why packets destined for the router’s own address on that interface failed to show up on input the way I expected.

My working hypothesis (still not proven to lab standards): with bridge VLAN filtering plus VLAN interfaces, RouterOS may handle “client → same-interface gateway IP” on a different internal path than “client → other subnet’s gateway,” including cases where the packet does not traverse the usual input chain the way forum examples assume. There are forum posts in the same neighborhood; none matched this exact pattern cleanly enough to call it solved by one checkbox.

What I did instead of a root-cause fix

I stopped trying to win on 10.0.10.1 from VLAN 10 for management.

Workaround: use a remote gateway IP for SSH and Winbox from any VLAN. Example pattern:

• From VLAN 10: manage via 10.0.99.1 or 10.0.20.1
• From VLAN 20: use 10.0.99.1 or 10.0.10.1
• From VLAN 99: use 10.0.10.1 or 10.0.20.1

Because cross-VLAN addresses already worked, this stayed boring and reliable. Not elegant. Functional.

I also wrote a recovery runbook for VLAN experiments (routeros-vlan-recovery style notes): remote VLAN IP first, physical port on the box, disabling VLAN filtering in an emergency, serial if needed. If you change bridge VLAN filtering without a backout path, you earn the outage you get.

Quick “unstick the bridge” reminder if you truly lock yourself out and can still reach CLI:

/interface bridge set bridge-lan vlan-filtering=no

(Only do that with intent; it changes your security model.)

Lessons

• Bridge VLAN filtering is powerful and also where “the docs say X” meets “my packet took a shortcut I did not expect.”
• Have recovery steps before you rewrite VLAN tables, not after.
• A workaround you can trust beats a perfect theory that needs a maintenance window and a packet walk you do not have time to finish.

If I revisit it

• Forum post with exports and a tight repro
• Packet sniffer on the router to see where the local-gateway flow dies
• Try another RouterOS minor on the RB4011 in a lab window

Sources

• MikroTik — Bridge VLAN table
• MikroTik — Layer 2 misconfiguration
• Forum threads on VLANs, gateways, and bridge setups (various; none were a drop-in match for this exact symptom)

---

Disclosure: This article contains affiliate links. If you purchase through these links, I may earn a commission at no extra cost to you.