Hello,
After updating from 6.41.4 to 6.42.5 the traffic does not go through the tunnel (tunnel is established, but the traffic does not go).
After downgrade to 6.41.4 everything works fine again.

What changes in 6.42. led to this?

Only support might know the particular changes in detail, and even that is not sure if they were unintentional. There seems to be some mess in policy ordering, and I had issues where one peer has decided to use plain ESP while the other one was encapsulating it into UDP.

So to start from somewhere, post here the output of /ip ipsec remote-peers print detail, /ip ipsec policy print and /ip ipsec installed-sa print from both ends (if both are Mikrotik ones), after systematically replacing each occurrence of each public address by a distinctive pattern like pub.lic.ip.1, pub.lic.ip.2 (so that the relationship remains visible) and removing the auth-key and enc-key items from the installed-sa output.

I found a bug in the 6.42.x version:
6.42 generate policy with incorrect Dst.Address: instead of 0.0.0.0/0 (in 6.41) i see public ip of remote router (in 6.42)

Mikrotik, please fix this bug ASAP!

Mikrotik cannot fix a bug if they don't get enough information about it. So generate the supout.rif file and send it to support@mikrotik.com. I am running several IPsec tunnels using various 6.42.x versions and things like this do not happen, so it is not a generic issue to happen to everyone.

I'd suggest you to follow the instructions in my automatic signature, as there may be something in your configuration which results in what you describe.

Plus add the output of /ip ipsec remote-peers print, /ip ipsec policy print, /ip ipsec installed-sa print, of course after applying the systematic public IP address substitutions also on these data before posting them.

>>I am running several IPsec tunnels using various 6.42.x versions and things like this do not happen

You also use 0.0.0.0/0 in Src.Address (and Generate Policy on other side)?

I don't. If you have tested that this is the unambiguous cause (i.e., if you use something else than 0.0.0.0/0, the generated policy is correct), then state this clearly when sending the information to support.

BTW, use of two policies, one with 0.0.0.0/1 and another one with 128.0.0.0/1, could be a workaround until Mikrotik fixes the 0.0.0.0/0 issue.

6.42.7 also have this issue!

6.43.2 also have this issue!

6.43.4 also have this issue!

Mikrotik cannot fix a bug if they don't get enough information about it. So generate the supout.rif file and send it to support@mikrotik.com.

Have you done this?

This behavior can be easily reproduced in the test lab.

This behavior can be easily reproduced in the test lab.

The key here is to send the e-mail to support with a clear description of the problem, have you done at least that? Because posting it at the forum is not the way to inform Mikrotik about the problem, they don't read every single post at the forum, while they do read every single e-mail which arrives to support@mikrotik.com.

Sending supout.rif makes it easier (and sometimes at all possible) to analyse for guys at support because they have all the necessary information in one place; what they actually need is the complete configuration including the dynamic elements which are not part of the export (because e.g. a dynamically assigned address may collide with a manually configured one) plus the information about the routerboard model, routeros version, and the actually running version of the firmware. So if your case description is clear enough, the supout.rif may not be actually necessary, but the formal process the support guys have to follow makes them ask for it because the alternative ways of putting the information together cost them more time. So I've found it easier to change the passwords and addresses (or, better, set up an environment with no public addresses) and generate the supout.rif than to argue with them why it is not necessary.

But again, the key is to describe the case clearly enough using the right information channel.

This behavior can be easily reproduced in the test lab.

Have you written to them so that they can try to reproduce the problem?

Since you are so hesitant to contact support, can you explain your setup and logic behind your policy configuration here? I can not think of a single case where responder should generate a dynamic policy with dst-address=0.0.0.0/0. Later versions (6.42+) has a security measure that disallows this to not allow an initiator to possibly disrupt network on responder.

can you explain your setup and logic behind your policy configuration here? I can not think of a single case where responder should generate a dynamic policy with dst-address=0.0.0.0/0.
We have a large number of subnets, and instead of creating a separate policy for each subnet, we create one policy for 0.0.0.0/0

Later versions (6.42+) has a security measure that disallows this to not allow an initiator to possibly disrupt network on responder.
My configuration worked fine for 7 years, and only 6.42 disrupt my network.

why didn't you write about these fundamental changes in 6.42 changelog??

I do confirm. Has the same problem with IPSec...

Any workaround?

apparently ipsec has many problems, one of my clients updated the router and lost the connection ipsec and NAT, just at this time I have a problem with another ipsec, it worked 1 week, then it stopped working, so far no one has been able to give with the solution. The Ipsec is established without problems, the two mikrotik routers see the LANs but the hosts can not ping each other and there is no lack of the NAT rule. what a big problem.

Woes without technical details are pointless; what helps is analysis. Networking environment is a dynamic one with all those automatic updates which sometimes happen without letting the user know if the OS vendor deems them "critical", so a conclusion that a Mikrotik is the reason of the problem if you haven't upgraded it (i.e. in the case where it worked for a week and then stopped) is a premature one without a hop-by-hop analysis of the traffic. I don't say it cannot be a Mikrotik issue; I just say that there is a good chance that it isn't and that it can thus be resolved, and that if it is a Mikrotik issue, it needs to be reported in a way allowing the R&D to fix it.

So I'd recommend to use /tool sniffer or /tool torch to check whether the ICMP packets do arrive to the Mikrotik from the host on one site, arrive encrypted via WAN to the other site, and leave the LAN interface towards the target host on the other site, and if they do, do the same for the responses. I'd also check whether the /ip ipsec installed-sa print shows any packets to be transported at all. All this allows to find out which of the devices drops the packets and is the basis for finding out why.

If you want, you can post the configuration exports of both devices following the hint in my automatic signature.