I have a network as shown (I hope it is understandable). I can’t understand why there is this problem:
ping from PC1 (192.168.22.10) to hmi (192.168.131.50) does not respond.
While pinging from PC1 to NVR (192.168.131.11) works.
Ping between PC3 (192.168.20.10) and hmi (192.168.131.50) also works.
If I open a terminal from Routerboard 1 and I ping to hmi it works and responds.
If I run a traceroute from PC1 it stops at Routerboard 4
Where am I wrong?
Thanks
You’ve given no configurations, but with such a large number of elements, the first thing I’d do would be to run /tool sniffer quick ip-address=192.168.22.10 ip-protocol=icmp, ping the hmi from PC1 and look how far the icmp request and icmp response get. There may be some policy routing on RouterBoard #4 which prevents responses towards PC1 to take a correct route.
Thanks for your answer,
I ran the tests, routing is fine for me.
Also because if you ping a device (for example NVR) always on the 192.168.131.xxx network it responds.
The strange thing that I can’t understand if pinging occurs between PC1 and
another device of the 192.168.131.xxx network which is not a PC or an HMI then responds.
For example:
from PC1 ping 192.168.131.11 reply OK
from PC1 ping 192.168.131.50 no reply
I have checked with wireshark installed on PC1 and the PING arrives but
the PC does not respond as seen by the capture, this if I’m not mistaken means that the routing is right.
Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Code: 0
Checksum: 0xb701 [correct]
[Checksum Status: Good]
Identifier (BE): 9133 (0x23ad)
Identifier (LE): 44323 (0xad23)
Sequence number (BE): 1 (0x0001)
Sequence number (LE): 256 (0x0100)
[No response seen]
[Expert Info (Warning/Sequence): No response seen to ICMP request]
[No response seen to ICMP request]
[Severity level: Warning]
[Group: Sequence]
Timestamp from icmp data: Apr 18, 2020 11:25:20.861962000 ora legale Europa occidentale
[Timestamp from icmp data (relative): 0.256700000 seconds]
Data (48 bytes)
I don’t understand from what you wrote where you actually took the capture (sniff), as the packet printout doesn’t show the address, so it is impossible to say whether it the request is captured as being sent by the PC or captured when received at the RouterBoard 4.
The reason why I’ve recommended to run the sniffer, with the parameters I gave, at RouterBoard4 while pinging the hmi from PC1, is that it would show you through which interface the ping request from the PC has arrived, through which one it has left towards the hmi (and whether it has at all), whether the hmi has responded and through which interface the response has left (if it has left at all).
The routing must be correct in both directions on every element. Since you say that traceroute to hmi’s address ends at RouterBoard 4, correct routes to the hmi’s address from the PC1 all the way to RouterBoard4 exist, and so do the routes from RouterBoard 4 to PC1’s address. So there may be a wrong or missing route on the hmi itself, or the firewall on RouterBoard 4 may block the request or response, or maybe a wrong network mask is set on the RouterBoard 4’s interface to which the hmi is connected.
This is the result of the sniffer
Ping from 192.168.20.10 to 192.168.131.50
INT... TIME NUM DI SRC-MAC DST-MAC VLAN SRC-ADDRESS
ether1 39.791 1 <- 6C:3B:6B:A6:49:DB 64:D1:54:2F:0F:E7 192.168.20.10
bri... 39.791 2 -> 64:D1:54:2F:0F:E8 00:0C:26:0E:1A:40 192.168.20.10
ether2 39.791 3 -> 64:D1:54:2F:0F:E8 00:0C:26:0E:1A:40 192.168.20.10
ether2 39.791 4 <- 00:0C:26:0E:1A:40 64:D1:54:2F:0F:E8 192.168.131.50
bri... 39.791 5 <- 00:0C:26:0E:1A:40 64:D1:54:2F:0F:E8 192.168.131.50
ether1 39.791 6 -> 64:D1:54:2F:0F:E7 6C:3B:6B:A6:49:DB 192.168.131.50
Ping from 192.168.22.10 to 192.168.131.50
INT... TIME NUM DI SRC-MAC DST-MAC VLAN SRC-ADDRESS
ether1 9.965 1 <- 6C:3B:6B:A6:49:DB 64:D1:54:2F:0F:E7 192.168.22.10
bri... 9.965 2 -> 64:D1:54:2F:0F:E8 00:0C:26:0E:1A:40 192.168.22.10
ether2 9.965 3 -> 64:D1:54:2F:0F:E8 00:0C:26:0E:1A:40 192.168.22.10
The comparison of the two sniffs clearly shows that the hmi itself either ignores the ping from PC 1, or doesn’t know how to route the response. You can see the request to go towards it through ether2, but nothing from the hmi comes back.
Is the Gateway of the hmi correct ?
sure, seen, what I still don’t understand is why from PC3 it works well!
I inserted a raspberry with address into the 192.168.131.0 network
192,168,131,108.
By pinging from PC1 to him he replies, then I connect from PC1 to the raspberry with putty and I ping the raspberry to PC1 and he does NOT answer.
I connect another laptop and DHCP is assigned 192.168.22.127, I try to ping from the raspberry to the laptop and it does NOT answer, in this case the traceroute stops at Mikrotik 5 (192.168.22.1)
From the raspberry I ping the mikrotik 192.168.22.1 and it answers
well even if from the raspberry I ping towards 192.168.22.30 it replies (which is a connected NVR where there is PC1)
I tried to disable the W10 firewall of PC1 and then the ping from raspberry to PC1 responds.
The very strange thing is that PC1 with W10 firewall active moves it instead of PC3 works and responds to ping even with firewall w10 active.
My conclusion is that SSTP between RB4 and RB5 is not seen by the operating system as a LAN and therefore the firewall intervenes.
I really don’t know what else to think.
Yes the Gateway HMI is correct 192.168.131.254 address bridge lan MK
Then because if I run a Traceroute from the Routerboard 5 → 192.168.131.50 it ends positively with the dest.
While if I run from PC1 with w10 does a tracert → 192.168.131.50 stop at Routerboard 4?
The only firewall which can prevent the hmi from responding the incoming ping from the PC is a firewall on the hmi itself. If the response was visible on ether2&bridge but not on ether1 of RouterBoard 4, it would be the firewall on RouterBoard 4.
Windows firewall in default settings for “private” networks only responds to ping from LAN, which means the local subnet of the interface to which the ping request arrives. However, there is no way how the hmi could see 192.168.20.0/24 as part of its LAN subnet while not seeing 192.168.22.0/24 as a part of it too, because the longest common mask for 192.168.20.0/24 and 192.168.131.0/24 is /16, so anything 192.168.x.y fits.
In any case, the issue lays within the hmi itself, there is no point searching anywhere else in your network until you can see the response for PC1 on ether2 of RouterBoard 4. You haven’t stated what kind of device the hmi actually is, so no suggestions can be given.
Nothing, I can’t understand, the HMI doesn’t have Firewall, I give up 
Thanks for everything anyway