You can see that different users can either have some split policies sent through the router, or send the whole traffic, which is tricky in the client side.
I’m planning to use this setting for teleworkers that have a small mikrotik router configured straight away. In those the configuration would be similar to:
It is working locally, i.e. the router at the “client” side of the ipsec tunnel will give the error I posted, but
it is not working for clients of the given router. For them (example is a linux machine):
$ ping -s 1 -c 1 -s 1410 -M do 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1410(1438) bytes of data.
1418 bytes from 1.1.1.1: icmp_seq=1 ttl=56 time=206 ms
--- 1.1.1.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 206.688/206.688/206.688/0.000 ms
$ ping -s 1 -c 1 -s 1411 -M do 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1411(1439) bytes of data.
--- 1.1.1.1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
This example has a 1438 MTU, the MTU changes depending on how the connection is done to the main router.
It is also working for clients of the router that have the split-include=192.168.88.0/24,192.168.89.0/24,192.168.90.0/24 configuration.
It is not working for clients of the router that have the split-include=0.0.0.0/0 configuration. The router does not send the fragmentation needed packet.
At least this is what I’m seeing, both with stable (6.45.6) and testing (6.46beta44) configuration in the clients and server. I have fully deactivated the firewall of the client to ensure that I was not blocking the icmp packet.
Check what the router really sends or not directly on router, add logging rule in output for icmp and destination address of client, and you’ll see.
I’d expect the opposite for split-include configs, i.e. that 0.0.0.0/0 would work, but selected subnets would not. Because if the router sends icmp packet from wrong address not covered by policy, tunnel won’t take it. But there’s no wrong address with 0.0.0.0/0.
This is what I did, using /tool sniffer and some logging, and I have seen.
Well, my laptop is sending a icmp echo from 192.168.21.251 to (say) 1.1.1.1. This is masqueraded at the router to 192.168.90.253 → 1.1.1.1, and then it falls into the policy, so it is encrypted, but it is too big. The error is not visible anywhere. My hypothesis is that the policy “eats” the error before nat can set the source address back to 192.168.21.1, as the policy is 192.168.90.253 → 0.0.0.0/0.
When the split-include configs are used everything works. My hypothesis is that the return packet being outside of the split-include (192.168.21.N) it is correctly returned, and what I see in linux:
From 192.168.90.253 icmp_seq=1 Frag needed and DF set (mtu = 1438)
Reinforces the hypothesis, as it is sourced from the natted network, the same subject to the policy (harmless in this case)
This would point to a bug in Routeros (or even the underlying linux machinery), I think errors during ipsec encapsulation should not be subject to ipsec policies.
And I can’t find a workaround because there is no firewall action to reject-with-fragmentation-needed that I could use before nat+ipsec traps the packet…
Can’t it be your srcnat rules touching something they should not? Because unless I’m lost in what’s connected where, if the icmp response should go to 192.168.21.251, then 192.168.90.253 as source doesn’t look right.
Well, I don’t choose the source of an ICMP error packet generated by the kernel/network machinery. I’m sending traffic and masquerading it, it is the masqueraded packet that generates the error.
I just have a “masquerade” rule for all traffic to WAN
This error packet is NOT going to WAN, 192.168.21.0 is LAN.
I think the bug or misbehaviour is that the error packet inherits the source address or the original packet instead of using the routing machinery to select the right source, which would be 192.168.21.1. Let’s see if anyone from Mikrotik that knows the guts can confirm or I should send a standard bug report and wait forever.