Routing Issue: Traffic to Garage Network Goes Out via PPPoE Instead of Local Interface

RouterOS Version: 7.20.2
Main Router Name: Greven
Goal:
Send traffic from the management VLAN (vlan10::MGMT) to a Grafana server (192.168.20.252) located behind another MikroTik router in the garage, connected via ether3-garage.
The main router should source-NAT the traffic and keep it isolated from the garage network.


Network Topology

[Greven Router]
  ether3-garage: 192.168.30.253
     |
     |  (Garage link)
     |
[Garage Router]
  ether3-garage: 192.168.30.1
  LANs behind: 
     192.168.20.0/24
     192.168.8.0/24
     192.168.88.0/24

Goal:
→ Traffic from VLAN10 (MGMT) → 192.168.20.252 should route via ether3-garage, not PPPoE-out1 (WAN).


Current Configuration (Greven)

Routes

 #  DST-ADDRESS      GATEWAY       ROUTING-TABLE  DISTANCE
 1  192.168.8.0/24   192.168.30.1  main           1
 2  192.168.20.0/24  192.168.30.1  main           1
    192.168.30.0/24  ether3-garage main           0
 3  192.168.88.0/24  192.168.30.1  main           1

NAT

/ip firewall nat
 0 chain=srcnat action=masquerade out-interface=ether3-garage
 1 chain=srcnat action=masquerade out-interface=wireguard_barssel
 2 chain=srcnat action=masquerade out-interface=pppoe-out1

ARP Table

/ip arp print where interface=ether3-garage
192.168.30.1 reachable


Observed Problem

When checking the route:

/ip route check 192.168.20.252

→ Output:

status: ok
interface: pppoe-out1
nexthop: 192.168.20.252

Even though the static route exists (gateway 192.168.30.1),
the router still selects the WAN interface (pppoe-out1) to reach 192.168.20.252.


What Has Been Tried

  • Verified ARP for 192.168.30.1 → reachable :white_check_mark:

  • Deleted/rebuilt ARP cache

  • Set static ARP entry for 192.168.30.1

  • Verified local subnet route (192.168.30.0/24 via ether3-garage)

  • Added check-gateway=ping

  • Attempted to set immediate-gw=192.168.30.1%ether3-garage (fails syntax in ROS v7)

Despite all of that, /ip route check still reports pppoe-out1 instead of ether3-garage.


Question

Why does RouterOS v7 still route packets to 192.168.20.252 via the default PPPoE route,
even though there is a valid static route to 192.168.20.0/24 via 192.168.30.1 (ether3-garage)
and a reachable ARP entry for that next-hop?

Is there a change in how RouterOS v7 handles next-hop reachability / immediate-gw resolution between local subnets that are connected via another MikroTik router?


Goal Summary

:white_check_mark: Keep NAT between Greven → Garage
:white_check_mark: Route 192.168.20.0/24 traffic over ether3-garage
:cross_mark: Do not send it via PPPoE-out1
:white_check_mark: Prevent Garage users from reaching Greven’s internal networks


Would you like me to add a short “export compact” example to this summary (so the forum can reproduce your setup)? It usually helps a lot.

Can you post the output of

/ip route print proplist=dst-address,gateway,immediate-gw,distance,scope,target-scope,routing-table

?

Otherwise, people on the forum usually prefer seeing a censored configuration export first.

Hello,

here is the output:

Flags: D - DYNAMIC; I - INACTIVE; A - ACTIVE; c - CONNECT; s - STATIC; v - VPN
Columns: DST-ADDRESS, GATEWAY, IMMEDIATE-GW, DISTANCE, SCOPE, TARGET-SCOPE, ROUTING-TABLE

DST-ADDRESS GATEWAY IMMEDIATE-GW DISTANCE SCOPE TARGET-SCOPE ROUTING-TABLE

DAv 0.0.0.0/0 pppoe-out1 pppoe-out1 1 30 10 main
DAc 10.255.255.0/30 wireguard_barssel wireguard_barssel 0 10 5 main
DAc xxxxxxxxxxx/32 pppoe-out1 pppoe-out1 0 10 5 main
DAc 192.168.0.0/24 vlan10::MGMT vlan10::MGMT 0 10 5 main
0 As 192.168.1.0/24 wireguard_barssel wireguard_barssel 1 30 10 main
1 Is 192.168.8.0/24 192.168.30.1 1 10 5 main
2 Is 192.168.20.0/24 192.168.30.1 1 10 5 main
DAc 192.168.30.0/24 ether3-garage ether3-garage 0 10 5 main
3 As 192.168.88.0/24 192.168.30.1 192.168.30.1%ether3-garage 1 30 10 main
DAc 192.168.120.0/24 vlan20::PARENT vlan20::PARENT 0 10 5 main
DAc 192.168.130.0/24 vlan30::GUEST vlan30::GUEST 0 10 5 main
DAc 192.168.140.0/24 vlan40::SMART vlan40::SMART 0 10 5 main
DAc 192.168.150.0/24 vlan50::TABLET vlan50::TABLET 0 10 5 main
DAc 192.168.160.0/24 vlan60::CHILD vlan60::CHILD 0 10 5 main
DAc 192.168.170.0/24 vlan70::ALEXA vlan70::ALEXA 0 10 5 main
DAc 192.168.178.0/24 ether1-WAN ether1-WAN 0 10 5 main

These two routes that you manually added:

1 Is 192.168.8.0/24 192.168.30.1 1 10 5 main
2 Is 192.168.20.0/24 192.168.30.1 1 10 5 main

are currently inactive, due to the target-scope value of 5. If you want the two routes to become active, and properly point to 192.168.30.1 as the gateway, you'll need to increase their target-scope value to at least 10. And if you do that, also set their scope to be higher than 10. You can set scope to 30 which is the default value for static routes. As you can see, the other working manually added static route:

3 As 192.168.88.0/24 192.168.30.1 192.168.30.1%ether3-garage 1 30 10 main

has the proper value 10 for target-scope.

If you want a route to participate in the next-hop selection, its scope value must be less than or equal the value of target-scope of the referring route. The route:

DAc 192.168.30.0/24 ether3-garage ether3-garage 0 10 5 main

has scope=10 (which is the default value for connected routes). If you want to use 192.168.30.1 as gateway for another route, and want ether3-garage to be used as the next-hop, then that other route must specify at least target-scope=10 not target-scope=5 like you did.

To recapitulate: the fix is to edit the two routes, and change to target-scope=10 (or higher). You don't have to manually increase scope because scope will automatically be set to at least target-scope + 1 , but it's still preferable to set scope=30, the default value for static routes.

Here is some literature: IP Routing - RouterOS - MikroTik Documentation.

Only as a side note, whenever you seem like having an issue with routes a (simpler):
/ip route print
will be enough to see which routes are active (As) and which are inactive (Is), etc..

It won't be enough (like the command CGGXANNX suggested) to show all the details, but enough to understand if the issue is related to the active or inactive (or unreachable, etc.) status of one or more routes.

Thx a lot, that worked!

I missed the change in V7, but in the Dokumentation is everything explained.

Looks like the issue came down to next-hop resolution in the main routing table. Adjusting the connected route and scope values usually fixes it. Glad you figured it out.