IP ADDRESS UNREACHABLE

Good Day,

I will appreciate any urgent help as this is my first time posting on the forum.

Explanation of the issue i have.

I have Three Different Mikrotik devices connected to each other in different locations, Router 1 is the HQ, Router 2 is a Regional Head Office and Router 3 is the Branch.

Router 1 IP ADDRESS
S 192.168.90.1/30 LAN communicating with a central server at the HQ
S 172.168.172.5/30 FIBER OPTICS LINK to the Regional Head Office

Router 1 IP Route
AS dst-add=0.0.0.0/0 gateway=172.168.172.6 (reachable)
AS dst-add=192.168.90.148/30 (reachable)

Router 2 IP ADDRESS
S 103.200.xx.xx/28 WAN PUBLIC IP address connecting to an ISP
S 172.168.172.6/30 FIBER OPTICS LINK to the HQ
S 10.10.1.1/24 PPTP VPN link to the Branch

Router 2 IP Route
AS dst-add=0.0.0.0/0 gateway=103.200.xx.xx (reachable)
AS dst-add=192.168.90.0/30 gateway=172.168.172.5 (reachable)
AS dst-add=192.168.90.148/30 gateway=10.10.1.253 (reachable)

Router 3 IP ADDRESS
D 10.10.1.253/24 PPTP VPN LINK to the Regional Head
D 10.210.xx.xx LTE1 dial in from mobile ISP
S 192.168.90.149/30 Branch LAN

Router 3 IP Route
DAS dst-add=0.0.0.0/0 gateway=LTE1 (reachable)
AS dst-add=10.10.1.0/24 gateway=10.10.1.1 (reachable)
AS dst-add=192.168.90.0/30 gateway=10.10.1.1 (reachable)

NOW to the LINK test…
Please help pay attention to the details below…

PING test from Router 1 to Router 2 is OKAY
PING test (192.168.90.1) from Router 2 to Router 1 is OKAY
PING test (192.168.90.149) from Router 2 to Router 3 is OKAY
PING test from Router 3 to Router 2 is OKAY

PING test (192.168.90.1) from Router 3 to Router 1 is OKAY

PING test (192.168.90.149) from Router 1 to Router 3 in NOT OKAY

I have took my time for days to trace route now i think i need more professional advice.

“urgent” and “first post ever” do not fit together well as the first posts ever appear on the forum with such a huge delay that they are rarely at the first page.

Other than that, its seems that there is a firewall/NAT issue. But without seeing the configurations of all three routers, I cannot suggest anything more precise.

Why is the branch LAN the same as the HQ LAN?? Can you use different nomenclature to avoid confusion?

The /30 is important. Humans may be confused, computers are not:
192.168.90.1: 1100 0000.1010 0000.0101 1010.0000 0001
/30: 1111 1111.1111 1111.1111 1111.1111 1100

192.168.90.149: 1100 0000.1010 0000.0101 1010.1001 0101
/30: 1111 1111.1111 1111.1111 1111.1111 1100

Router 1 IP ADDRESS
S 192.168.90.1/30 LAN communicating with a central server at the HQ
S 172.168.172.5/30 FIBER OPTICS LINK to the Regional Head Office

Router 1 IP Route
AS dst-add=0.0.0.0/0 gateway=172.168.172.6 (reachable)
AS dst-add=192.168.90.148/30 (reachable)

I’m a confused human. How can static 192.168.90.148/30 be reachable with a static IP address 192.168.90.1/30 ?
My confusion, or Typo, or RouterOS dropping the CIDR extension as last resort ???

As the route lists have been edited in some way, not just copy-pasted from the ROS output, I’ve concluded that the dynamically added routes to connected subnets have been intentionally omitted from the OP. Hence I assume that the route with dst-address=192.168.90.148/30 at Router 1 has some gateway (not shown), and the whole route with dst-address=192.168.90.0/30 has not been shown at all.

As pinging between a pair of addresses in these two “similar” subnets works in one direction, i.e. the request from A to B reaches B and the response from B to A reaches A, routing must either be completely correct (it may not be symmetric, though) or there must be a src-nat somewhere in A to B direction. And even if routing works and no src-nat is involved, firewall rules may block the request from B to A.


No way. If none of the configured routes matches the destination address of the packet, the packet is dropped (but a default route matches all).

The only “last resort” handling applies with routing marks - if no route with the required routing-mark value matches a packet, routing table main is used to route the packet by default, unless this is explicitly prohibited using an /ip route rule row with action=lookup-only-in-table. But that’s far away from the topic.