The LAN bridge has an IP of 192.168.11.49/23.
I can ping (IP) anything on the 192.168.11.0 range, but nothing on the 192.168.10.0 range. I can ping 192.168.10.0 addresses if I use ARP ping.
Any idea what I’m doing wrong?
The LAN bridge has an IP of 192.168.11.49/23.
I can ping (IP) anything on the 192.168.11.0 range, but nothing on the 192.168.10.0 range. I can ping 192.168.10.0 addresses if I use ARP ping.
Any idea what I’m doing wrong?
Check the subnet mask on the hosts’ configurations.
If the host thinks it’s a 255.255.255.0 netmask, then it will only ping “the other half” of the supernet is through its default gateway.
I had a look and the host is using a /23 mask.
BTW, I can ping from the 192.168.11.x and 192.168.10.x addresses to the Mikrotik. Just not from Mikrotik to the 192.168.10.x network.
In that case, check firewall / nat rules
Also, if the IP on lan-bridge changed from /24 to /23 - make sure the network is also updated correctly.
Do you have it bridged / switched? Or routed?
The network is showing as 192.168.10.0 which I believe is correct.
I’m not an expert on RouterOS, but I think it’s in bridged mode.
If you’re using LAN bridge, then make sure the supernet IP is configured on the bridge interface, and make sure that you don’t have any filter (forward chain) or NAT rules which match based on the physical interfaces (ether1, etc).
When bridging, IP addresses and rules should always go on the bridge interface.
Thanks for your help so far ZeroByte. See attached, two screenshots of the IP addresses, filter and NAT rules. Do they look correct?
I would change the srcnat a little bit.
Remove the src and dst address criteria, and just have out-interface=Eth1 - Crs Interconnect
The input filter for DNS is a good idea. I would change it a tad though - instead of src-address=!192.168.10.0/23, use in-interface=Eth1 - Crs Interconnect
Notice the trend? If you use IPs, that works, but especially with a udp service like DNS, it leaves the door open for spoofing. In all cases, if you change IP addressing then you have more places to go fix the rules. The policy is essentially based on interface anyway, right? If it comes in this interface, it’s from the Internet and we should be suspicious… If it comes from here, then it’s from my own network, so I’ll trust it… etc.
Something just occurred to me though - if you have two hosts, e.g. 192.168.10.22 and 192.168.11.22 - if they want to communicate with each other, they should be able to do so without the Mikrotik getting involved at all. If they can’t see each other, then either one or both of them has the wrong subnet mask configured. (it should be 255.255.254.0)
When two hosts are in the same IP network, their communication is all direct host-to-host via their MAC addresses, and not via the router. Of course, if host1 is on ether3 and host2 is on ether5 - and these two ports are bridged by a software bridge (/interface bridge) on the Mikrotik, then there MIGHT be some Layer2 firewall rules that could block this - check the bridge firewall tab. Also make sure you don’t have split horizon defined on the ports of the bridge.
However, if they’re both plugged into a switch and they can’t talk - then it’s 99.9999999999999% likely that the hosts are to blame.