Hello all.

this is my current network setup:

10.140.28.10/26 LAN__MT_1__AP 10.140.28.129/26 ---( LINK )---10.140.28.130/26 __MT_2__LAN 10.140.28.65 / 27

The problem is that remote MT_2 (10.140.28.65) cannot reach 10.140.28.10 IP !!!
MT_1 routes: 10.140.28.64/27 nexthop is 10.140.28.130
MT_2 routes: 10.140.28.0/26 nexthop is 10.140.28.129

Am i missing something here?
Yesterday I have reset configuration on MT_2 and reconfigure from scrath. It worked for about 2-3 hours and then it stoppped reaching 10.140.28.10 again.

Both are upgraded to version 6.29
Thank you

that's odd.. can you post an export of each router? Have you checked firewall filter/nat?

- No firewall rules.
- MT_2 AP interface can reach MT_1 LAN
- MT_2 LAN interface can NOT reach MT_1 LAN

After some troubleshooting I find out what may cause the issue:

1) devices attached to MT1_LAN & MT2_LAN can communicate between them without any issue.

2) The problem is only isolated to the MT_2: ping with source interface the LAN timeouts.
The ICMP packet does not reach MT_1 AP interface, is the problem is located to MT2 routerboard; it doesnt forward correctly the packets


tools > traceroute > use DNS ==> DNS request obey to "source interface" choise or not?

Are you sure netmasks are consistent on all devices?

if hosts are windows machines check windows firewall, be sure is disabled, also any firewall or network protection on anti-virus software o another security suite

I'm curious, is that PTP link setup? Why the /26??

You could isolate if the problem is in that link, connect both MTs directly on an unused ethernet and set the Link IPs there, if suddenly everything works the some system in the link is to blame...

- Netmask mistake was the first suspect but I have triple checked and seem correct.
- Devices are windows, but those windows hosts do NOT have any problem.
The problem is MT_2 related: it cannot ping the other side when selecting the LAN interface as source

/26 was selected because it is an interface in AP mode with an omni antenna.
Various devices can connect on it using DHCP. DHCP_Pool does not include .130 IP in the range.

I have also checked if any other device accidentally is using .130 IP: none is.
I used a static ARP for .130 device; no improvements.

I think I have to sniff some traffic and check what is going on.

Are you marking routes? I'd say the "problem" is on MT1 not MT2...

No.
I am doing a src-nat to allow MT -LAN to access internet.
The problem remains even if I disable the rule

Later tonight I will upload a full network diagram; maybe I am missing something

- Netmask mistake was the first suspect but I have triple checked and seem correct.
- Devices are windows, but those windows hosts do NOT have any problem.
The problem is MT_2 related: it cannot ping the other side when selecting the LAN interface as source

/26 was selected because it is an interface in AP mode with an omni antenna.
Various devices can connect on it using DHCP. DHCP_Pool does not include .130 IP in the range.

I have also checked if any other device accidentally is using .130 IP: none is.
I used a static ARP for .130 device; no improvements.

I think I have to sniff some traffic and check what is going on.

Are you selecting the LAN interface as the interface where the packets should be sent, or selecting the IP address of the LAN interface as the source address of the ping packets?
(they're different things)

The "Interface" option on the General tab of the ping tool is used to force the packets to leave the Mikrotik via a specific Interface. (It's deceptive if you're used to Cisco's src interface in extended ping). If you're setting LAN interface here, then this is why it's failing.

What you want is to go into the Advanced tab and set the Src Address field to 10.140.28.65.

Not sure this is what you're doing, but I get that impression based on the way you're wording your posts.

Yes, I am used to Cisco interface
I was using LAN interface, probably this is the problem