Please bear with me, I am a novice with that.
I am segmenting my network into several smaller networks. For that I have created several bridges, configured the switches, assigned the ports to the bridges, created DHCP servers on that interfaces, assigned IP pools, created networks, placed machines in those different networks, obtained proper IPs etc.
All those devices connect to the internet and can see devices in their own network but a device in Network 192.168.44.0/24 cannot ping a device in 192.168.66.0/24 and vice versa.
I’ve disabled all firewall rules in IP > firewall, checked that there are no filters in Bridge Filters but I still cannot ping devices in other networks.
Furthermore I get strange results when tracing the routes. My machine is 192.168.44.44, has a gateway 192.168.44.1 in a /24 network.
When I trace a device in another network (192.168.66.254)
tracert 192.168.66.254
Tracing route to 192.168.66.254 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 192.168.44.1
2 192.168.44.1 reports: Destination host unreachable.
Trace complete.Now when I trace the gateway of this remote network, I get:
tracert 192.168.66.1
Tracing route to 192.168.66.1 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 192.168.66.1
Trace complete.So from my machine 192.168.44.44, when I try to reach 66.254 it routes through 44.1, but when I try to reach the remote gateway directly it looks like it is directly connected to it (but this 66.1 is not a gateway of my 44.44 machine)
Since I am lacking experience with that I don’t see where this is possibly failing.
Is there some ARP setting wrong or do I explicitly need to NAT between those local networks?
There is only one router. My hardware is a Mikrotik RB3011UiAS, everything is managed on this device and here are the routes:
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADS 0.0.0.0/0 192.168.1.1 1
1 ADC 192.168.1.0/24 192.168.1.2 ether1 0
2 ADC 192.168.44.0/24 192.168.44.1 TrustedDevices 0
3 ADC 192.168.55.0/24 192.168.55.1 MediaZone 0
4 ADC 192.168.66.0/24 192.168.66.1 Smarthome 0
5 ADC 192.168.88.0/24 192.168.88.1 bridge 0
The routes in question should be TrustedDevices and Smarthome.
I briefly managed to get a connection to the device by allowing NAT between those bridges but AFAIK this does not really solve the real problem, does it? Shouldn’t the solution be way before NAT on the router? Presumebly ARP?
Either 192.168.66.254 is not on the Smarthome network, or the default gateway for the device is wrong.
Can you also provide a export for /ip arp, and /ip dhcp-server
It’s quite normal that you’ll be able to access 66.1 because it’s the same physical device. The only reason why you won’t be able to access 66.254 is because either the router can’t see the device (which IP ARP will show us), or it received the wrong network configuration from DHCP (what ip dhcp-server will show us)
Here is my arp list, if I do an export it is empty due to everything is dynamic here
Flags: X - disabled, I - invalid, H - DHCP, D - dynamic, P - published, C - complete
# ADDRESS MAC-ADDRESS INTERFACE
0 DC 192.168.1.1 9C:80:DF:A0:8A:DD ether1
1 DC 192.168.44.44 30:85:A9:9D:5C:DB TrustedDevices
2 DC 192.168.44.2 00:11:32:2D:E4:1D TrustedDevices
3 D 192.168.1.225 ether1
4 DC 192.168.66.253 B8:27:EB:10:00:FB Smarthome
5 DC 192.168.66.254 B8:AC:6F:52:BB:36 Smarthome
AFAIK the device in question should be in the proper network because I see the lease and from the 66.254 point of view its network config looks proper too
You say that they are all connected to the same RB3011 right? Did you post your entire export for /ip arp? You assign 66.1 as a default gateway via DHCP, but 66.1 aren’t assigned to the RB3011 according to your ARP table? Is the ip assigned to the bridge and active? I know, stupid question.
If that’s not the case, you’ll need to look at the 66.254 device specifically. Can you ping/trace the 66.253 device (again, from what I’ve read and understood, you can)? What if you trace from the 66.254 device to 44.44 (i.e. the other way around). Thing is that if this was a end device that wasn’t configured correctly, you would have gotten a timeout error, not a host unreachable, which is pretty much telling you that your RB3011 don’t know how to get to the 66.x network - hence why I’m asking, are you sure the 66.1 address is assigned and active?
From a layer II point, everything looks fine. I’m fairly sure the issue is on the 66.254 device itself. Does it not perhaps have a IP assigned (old legacy from before you started splitting things) in the 44.x network?
Everything is connected to the same router.
However with your hints I was able to solve the problem: My machines I was testing with are Windows machines. What I was totally not aware of is the fact that Windows allows ICMP only from Local Subnet in its firewall configuration. I was using a notebook that I plugged from my 192.168.44.0/24 network into the smarthome network 192.168.66.0/24. Since they were now on different networks ICMPs were filtered. Painfully obvious.
After I brought back my other devices in the 66.0 network I could ping them from my 44.0 net too. So indeed communication between bridges should indeed work out of the box.
Thank you for your hint about what should actually be working and what not which pushed me in the right direction.
That would have been my next thought yes - but I was for some reason thinking we’re talking about android devices or something. Yes, windows by default does not allow UDP based traceroutes to work outside of the local lan, ICMP does though (at least my windows boxes does).
