ICMP redirect host message away from site-to-site IPSEC tunnel. Linux-based hosts routing is messed up

RouterOS General
1

Hello, i have 2 offices. One of them is behind the provider’s router/NAT.

Office1——Mikrotik1 (bridge)——-Prov.Router.NAT——INTERNET—–Mikrotik2—–Office2

Mikrotik1 is the initiator of the IPSEC tunnel. From my windows i can ping across the tunnel the office2. Mikrotik1 has its IPv4 in the same subnet of Office1 and is in bridge mode (transparent firewall). Bun my Linux machines in Office1 cannot reach the Office2. I found that they receive and process the ICMP redirect messages from Mikrotik1, who says that if you want to go to Office2, you go via Provider’s Router, not Mikrotik1. So, all linux-based machines poison their routing tables and loose connectivity because the IPSEC tunnel’s gateway is Mikrotik1, not Prov.Router. In Office1 i can only have one subnet.

How to disable this specific ICMP redirect message for this kind of IPSEC traffic? Is it possible without disabling ICMP redirects completely?

2

You can turn off redirects under /ip settings.

But I don't understand why the Mikrotik would redirect them unless it has no route to Mikrotik2.
You can add a black hole route (or something better) for this case.

Do they have static routes or similar to make them go via Mikrotik1 in the first place?

3

Yes, for now i have disabled the icmp redirects completely. (I had to reboot the Mikrotik1 in order to make this disable effective).

The idea is that not all hosts, but some of hosts in Office1 have static routes for Office2 via Mikrotik1. On Mikrotik1 there are no specific routes for Office2, only IPSEC configuration. This works for Windows hosts because windows does not care about the redirects. But linux hosts take them seriously, so why this post. Thanks.

4

It is quite a common problem with site-to-site tunnels as they intercept the routing in a very strange way.

It is first completely processed by the routing, and then at the last moment it is matched with the IPsec policies and it is decided not to route it but put it in the tunnel. Apparently redirect messages already have been sent before that.

It is one of the many reasons why I prefer to use a tunnel interface on top of a transport IPsec policy, e.g. GRE/IPsec, IPIP/IPsec or L2TP/IPsec.

5

I seem to have learned something new, cool.

Not sure if the following would work, but maybe you could create a new bridge on the router and add to that bridge an IP in the office2 range (with a /24 or whatever mask)
So mikrotik1 will attempt to send the packet towards the bridge, which then get hijacked by the ipsec policy.

6

Maybe it is like this.

I noticed that Linux host gets first ping reply from office2, then it gets redirect from Mikrotik1, and then it gets ping timeouts from default gateway.