I'm tired of RouterOS behaving differently than any other router on the market. ICMP error replies should be sent from the same interface that received the ICMP request. Without this tracerouting to something which passes through RouterOS-equipment and is multihomed is useless.

I'm just asking RouterOS to behave like any other router on the market. It can't be that hard. Since RouterOS is Linux underneath the feature should already be available if Mikrotik didn't delete that code from the kernel.

http://linuxinsight.com/proc_sys_net_ip ... faddr.html

"This is the behaviour many network administrators will expect from a router. And it can make debugging complicated network layouts much easier" . Yes..

Either make it default so it actually behaves like a normal router or just add a checkbox under /ip settings.

Please..

Bringing up this again for input because I still don't get why it's not implemented.

Using the "devel"-login and setting,

# echo 1 > /proc/sys/net/ipv4/icmp_errors_use_inbound_ifaddr

shows that it works and there's no kernel issue from custom MT code or anything to make it work. Please give a respond to why this is not implemented in for example under ip->settings.

Official excuse is that this is only user forum and MikroTik employees don't necessarily read every topic here. If you want to be sure that they see it, you need to write to support.

# echo 1 > /proc/sys/net/ipv4/icmp_errors_use_inbound_ifaddr

+1 to make this an configurable option!

This is a good example of why the "MikroTik employees don't necessarily read every topic here. If you want to be sure that they see it, you need to write to support" argument is bogus.

I submitted a pointer to this topic in Jan 2023 as SUP-103754, in Mar 2023 it was replied with "Thank you very much for pointing it out. We will see what we can do.", and in May 2023 it was closed with resolution Done.

But NOTHING HAS CHANGED. Still no setting, still the same behavior.

Strange, when I run traceroutes, I see the expect path in the replies. Am I missing something here?

Unless you modified pref-src incorrectly via route filters (for BGP full tables) or manually for static routes/double/triple WAN.

I always make sure routes learnt via interface A has pref-src matching the IP of that interface A. Same for interface B. Never seen this problem.

It ignores pref-src. The pref-src has been correctly set but an incorrect one is used. This is sort of consistent with the fact that mangle and route-marking of such packets is also not possible. They are apparently generated via a different mechanism than "output".

It is a config with multiple route tables. Traffic comes in via a tunnel, which is in the routing rules config, and the route back has a pref-src, but still the ICMP reply is made from the public internet address instead of from the tunnel address or another address local to the overlay network.
And that is to be expected without this setting. As explained above it can be fixed by adding this line to sysctl.conf:

net.ipv4.icmp_errors_use_inbound_ifaddr = 1

Pelchi are you saying external ICMP incoming could potentially go back out the wrong router even if we mark the incoming traffic.

No.

Pelchi are you saying external ICMP incoming could potentially go back out the wrong router even if we mark the incoming traffic.

If we are using static routes and not BGP, then we SHOULD mark incoming traffic to make sure it egresses via the same interface. So I don't see any problems here at all.

It is not about incoming and routed ICMP traffic, it is about the ICMP traffic generated by the router as a result of it!
Traffic enters the router, TTL decrements to zero or destination is unreachable or firewall rejects the traffic, an ICMP is sent back, but that is traffic originated by the router which does not pass the "output" chain (at least any route marking done there does not affect it) and it also does not follow the usual rules for source address selection.
That could be changed by setting that parameter.

It ignores pref-src. The pref-src has been correctly set but an incorrect one is used. This is sort of consistent with the fact that mangle and route-marking of such packets is also not possible. They are apparently generated via a different mechanism than "output".

Never thought about this, but I've never see PMTUD in the firewall...guessing it happens in kernel?

I've seen pref-src= act different on V6 vs V7, at least with VRRP ... so I'm not sure it always applied, in all case at least. Mangle can fix VRRP, but not if something doesn't go through firewall...

Seems like net.ipv4.icmp_errors_use_inbound_ifaddr should be a setting, like rp-filter / other kernel things in /ip/settings... While it could default to 0, to not break something that expect whatever was going on before. But yeah what the "primary interface" be on RouterOS, seems indeterministic (which is what icmp_errors_use_inbound_ifaddr=0 means)...

Indeed. I think it is not very likely that some real world scenario would break when this parameter is hardwired to "1" (especially as the "primary interface" is not well defined), but it could be made an extra parameter under /ip/settings to avoid any risk.

A factor preventing a solution via marking is that a packet can have only a single packet mark, and I already use that for priority.
It looks like in v7 they are planning to allow multiple packet marks (e.g. in 4 "packet mark groups"), and that is possible in the Linux kernel, but the implementation was not finished.
Also, in my case the problem would be solved by allowing "packet priority" as a queue selector in queue trees, as an alternative to "packet mark".
It would likely be more efficient as well. At the moment I do a sequence of setting packet priority from DSCP high bits, then 8 packet marks depending on packet priority in mangle, then a selection of 8 queues in a queue tree based on packet mark. But it would be easier to select the queue based on packet priority, that would also leave the packet mark available for tricks around multiple gateways (I now use routing mark for that).