Not really a dramatic problem I would say, more a not-so-optimal situation.
Your server 192.168.0.11 has its default gateway set to the Mikrotik 192.168.0.1 right ?
So basically you ping, the gateway is looking for the destination and sees it actually on the same interface where the ICMP came from ? It known from its routing table that the 192.168.0.70 is sitting behind a device 192.168.0.5.
So I think the Mikrotik actually transmits ICMP redirect back to your originating host.
Redirects are used when a router believes a packet is being routed sub optimally and it would like to inform the sending host that it should forward subsequent packets to that same destination through a different gateway. So it is trying to tell your PC on 192.168.0.11 to DIRECTLY use the 192.168.0.5 router if it wants to reach 192.168.0.70.
A good example why ICMP is quite important. If you would be filtering ICMP on the host for example, traffic WOULD arrive eventually but NOT optimal. That’s all.
As you can see, traffic does arrive on the 192.168.0.70 but if the sending host 192.168.0.11 is not configured with an extra route/static route you need to cross the network 2x
Thank you for the diagram. Are all of these ip addresses for real, or just example ones you’re providing us with? The x.x.0.5 router should be routing a different ip scheme behind it like 192.168.88.0. Otherwise, you will need to manually (I think) maintain an optimal route table. Change you network to where host 192.168.0.70 becomes 192.168.88.70.
No, this is perfectly OK. As you can see on the top, the main LAN is 192.168.0.0/28 (NOT /24) with the Mikrotik being 192.168.0.1 so the subnet 192.168.0.68/30 sitting “behind” the router 192.168.0.5 is not overlapping in any way.
If ICMP does its work I don’t think anything should be done.
Your server 192.168.0.11 receives the ICMP messages from the Mikrotik and must act accordinly. It could alter its routing-cache and install a route to destination 192.168.0.68/30 with next-hop 192.168.0.5 (this is dynamic and probably not permanent)
Done!
Offcourse you can add a static route on the host for the 192.168.0.68/30 network via 192.168.0.5
Can you check on the host what it did with the ICMP redirect suggestion ? Do trace-route after such a ping ? Does your trace-route still contains 192.168.0.1 in the path ?
It is Windows ? Linux ?
Eg for certain Windows versions : A host route learned by means of an ICMP Redirect will be added to the route table for 10 minutes, after which time it is removed and must be relearned through another ICMP Redirect.
But your host might be configured to ignore these as they might be a potential security issue to redirect traffic away from the correct path…
You will have to experiment a bit, as it looks like the ICMP redirect are not accepted/processed by the Linux host.
As you can read, perhaps you need to disable secure_redirects or something.
I think in the trace-route finally the 192.168.0.1 should be visible anymore. But remember this is dynamic. If this is a PERMANENT setup, I suggest you add a STATIC route on the hosts that require it and document it!
The Server 192.168.0.11 is able to reach/connect Host 192.168.0.70 without any issues. But my concern is what changes shall i make to make the routing proper as this is just the scenario in the LAB. But don’t wan’t these things to happen when configured for the clients.
Difficult question to answer in your name. What you see is just ICMP doing it’s job and telling your (lab) client there is better, more direct way to 192.168.0.70 but it appears the client is ignoring this. Packets will arrive, but you are traversing the LAN segment 2x so sub-optimal.
So these “clients” in the real network, what are they ? Windows machines ? Are there Linux or MAC computers too ? Other appliances with proprietary OS’ses ?
Option 1 : Leave it like it is and monitor interface statistics to make sure you don’t start getting saturation ? If you have lots of data moving (eg. backups) the fact you need 2x to cross the LAN-segment is indeed far from optimal. You can then investigate for the different OS what needs to be done so the clients would accept this “redirect” message and install a better route automagically. This are eg. certain registry-keys or kernel-parameters to make sure the client accepts & complies to redirect-messages offered to it.
Option 2 : Force a static-route onto all clients for the subnet behind 192.168.0.5 (and perhaps other subnets further down that pipe). Different OS will require different ways to add a (persistant) static route.
Sorry for the delayed response, was out of office. In real network, the server 192.168.0.11 is a Radius Server (Linux Machine) and 192.168.0.70 is a client which gets authenticated by the radius server.
