Hi,
we have found strange? behaviour of Mikrotik handling UDP packets. We have Mikrotik with L2TP VPN connected to VPN server. There are more servers behind VPN server, processing data. Behind Mikrotik there is device, which sends UDP packets through VPN to server. Server sends back to device UDP packets with some kind of data confirmation. We have found, that in case when VPN disconnects, UDP packets from device destined to server are correctly masqueraded and sent through WAN. This is normal behaviour. BUT as soon as VPN connects again, UDP packets from device start to flow to server through VPN again, but with SENDER IP incorrectly set to WAN IP of Mikrotik because they are also masqueraded. So Mikrotik is able to recognize situation when it is necessary to start masquerading, but is not able to stop masquerading when VPN is up again and packets start to go by another way.
Solution of this problem is to delete UDP connection in the list of connections in Firewall window. We have also lowered UDP timeout in Connection Tracking from 10 sec to 1 sec and it seems to be solved for now.

But I would like to know whether is this an error in RouterOS or is this normal behavior?

I have found the same 'issue'. It doesn't just affect VPN connections, it also affects Multi-WAN setups. If a connection fails over to the secondary WAN link, then recovers to the primary, it will have the wrong IP.

As you've discovered, you have to clear the connections. The best way to automate this is with some kind of script.

This isn't a RouterOS error as such, but I believe other routers automate the connection clearing processes, where as RouterOS does not. It's a shame.

You can clear all the UDP connections in a script with the following:

Setup your masq rules separately, one for each out-interface? Then only NAT new connections? that way 'invalid' connections will die off on their own and start new ones?

Setup your masq rules separately, one for each out-interface? Then only NAT new connections? that way 'invalid' connections will die off on their own and start new ones?

But UDP connections don't 'die' as such?