Community discussions

MikroTik App
 
anserk
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 51
Joined: Wed Mar 02, 2022 5:08 pm

ICMP redirects with routing rules

Thu Oct 06, 2022 12:32 am

I found out MikroTik is not sending ICMP redirects when using a routing rule, pointing to a table with just the default route. Example configuration:
/ip route
add distance=1 dst-address=0.0.0.0/0 gateway=10.1.1.10 pref-src="" routing-table=wireless scope=30 suppress-hw-offload=no target-scope=10
/routing rule
add action=lookup-only-in-table src-address=10.1.1.24/32 table=wireless
With the above configuration all traffic from 10.1.1.24 is routed through the "wireless" table, which has just one route. All outbound packets from the host go to the main router, then go out the same VLAN interface and go to 10.1.1.10 router. ICMP redirects are not being sent. The returning traffic is routed by 10.1.1.10 directly back to 10.1.1.24, since they are on the same subnet. This breaks the connectivity due to firewall rule dropping invalid state. It's understandable as the main router never sees returning traffic. A workaround was to put a rule allowing all traffic going in and out that same VLAN interface. That's not ideal for several reasons, one being that this traffic is not being fasttracked as it's not considered "established".

When adding a static route to a specific destination IP, then ICMP redirects are being sent out. Is this behaviour expected?

I'm asking this mainly for academic purposes. Most client devices do not accept ICMP redirects by default anyway.

Are there any suggestions for the best firewall configuration in this scenario to limit the overhead? I need to bypass as many things as possible. This is what I have so far:
add action=accept chain=forward in-interface=vlan101 out-interface=vlan101
I'm not sure if adding a raw rule to mark these packets as untracked would help in any way.
 
Sob
Forum Guru
Forum Guru
Posts: 9119
Joined: Mon Apr 20, 2009 9:11 pm

Re: ICMP redirects with routing rules

Thu Oct 06, 2022 12:59 am

As the router sees it, there's only single route, no local subnet for target 10.1.1.10, so no reason to send any redirects. If you don't want to copy routes to local subnets in different routing tables (which could be problematic), you can add another routing rule before this one, to look up any local destination in main routing table and then it should work correctly.
 
anserk
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 51
Joined: Wed Mar 02, 2022 5:08 pm

Re: ICMP redirects with routing rules

Fri Oct 07, 2022 2:13 am

That makes sense, thanks for the tips. Here is the weird part: it works for one host/IP but not the others. I used the routing rules approach for local subnets, steering to the main table. The rules are identical for two given source IPs, works for one but not the other. Seems like a bug.
 
Sob
Forum Guru
Forum Guru
Posts: 9119
Joined: Mon Apr 20, 2009 9:11 pm

Re: ICMP redirects with routing rules

Fri Oct 07, 2022 2:20 am

Try to post what you have. The rule I had in mind would have only single condition, dst-address=10.1.1.0/24 (or whatever different size of subnet you may have), nothing about source address.
 
anserk
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 51
Joined: Wed Mar 02, 2022 5:08 pm

Re: ICMP redirects with routing rules

Sat Oct 08, 2022 1:31 am

I get your point about the rule to local subnet being for any source. It didn't make any difference having one rule without a source or multiple rules for each source like below.

This is what I have:
/ip route
add distance=1 dst-address=0.0.0.0/0 gateway=10.1.1.10 pref-src="" routing-table=wireless scope=30 suppress-hw-offload=no target-scope=10
/routing rule
add action=lookup disabled=no dst-address=10.1.0.0/22 src-address=10.1.1.200/32 table=main
add action=lookup disabled=no dst-address=10.11.12.0/24 src-address=10.1.1.200/32 table=main
add action=lookup-only-in-table disabled=no dst-address=143.x.x.x/32 src-address=10.1.1.200/32 table=vpn
add action=lookup-only-in-table disabled=no src-address=10.1.1.200/32 table=wireless
add action=lookup disabled=no dst-address=10.1.1.0/24 src-address=10.1.1.20/32 table=main
add action=lookup-only-in-table disabled=no src-address=10.1.1.20/32 table=wireless
Redirect were sent every time for .1.200 but not for .1.20. I played with it more, and it appears it works occasionally. I was running sniffer and fiddling with the rules, and sometimes all of a sudden the redirects showed up. Then I would ping another IP, and redirects wouldn't be sent out. I would ping the previous IP, and it worked again. I'm testing with a smartphone as client at .1.20, and when I unlock it, I see a bunch of redirects for some HTTPS IPs (phone is probably checking in with some services). But when I ping, say, 8.8.8.8 in a controlled manner, there are no redirects.

It is very consistent with .1.200, for every ICMP echo request I get an ICMP redirect immediately.

On both occasions it works (when it works) even without the local subnet rule.

I appreciate your help, but see no point in wasting more your time on this. Unless you see a glaring error in my configuration. I have no practical use for this. Initially I thought it would be nice to control things centrally on the router, but ICMP redirects are not accepted by any client I know unless manually reconfiguring it, which defeats the purpose. If I have to touch the clients, I will just reconfigure default gateway or add static routes. I'm still curious why it doesn't work consistently, but my curiosity is getting fatigued.
 
Sob
Forum Guru
Forum Guru
Posts: 9119
Joined: Mon Apr 20, 2009 9:11 pm

Re: ICMP redirects with routing rules

Sat Oct 08, 2022 2:48 am

Actually, what I wrote initially is not well put / inaccurate / misleading. The idea behind redirects is:

- there's main gateway 10.0.1.1(?) (used by client)
- there's another gateway 10.0.1.10
- main router has route to target (e.g. 8.8.8.8) via second router
- client sends something to 8.8.8.8
- main router responds with redirect, which is like saying "hey, 8.8.8.8 is reachable via 10.0.1.10, it's in same subnet as yours, I'm going to send it there, so next time you can sent it there yourself (it will be faster and I won't have to be bothered; win-win)"

I'm not sure about details, how exactly is this evaluated, how routing rules are linked to routes, if they need to match exactly. But it makes sense to use subnet (the one shared by client and both routers) exactly as is. Maybe it's not strictly required, but it's the safest bet. If you have 10.1.0.0/22, then use that and not only some subset. And you can have only one common rule at the beginning (order matters, because first matching rule is used):
/routing rule
add action=lookup dst-address=10.1.0.0/22 table=main
There shouldn't be any reason (in most cases) why anything destined to address that's part of this subnet should be sent anywhere else, i.e. if you say that this destination should be looked up only in main routing table, it shouldn't break anything, because it's what you always want.

Who is online

Users browsing this forum: Bing [Bot], Cloudtechiq [Bot], Kuitz, patrikg, xristostsilis and 74 guests