We have about 20 sites connected via IPSEC. After upgrading the NGFW, we have unstable IPSEC connection. Before that, IPSEC worked fine.
That means, sometimes IPSEC works, sometimes it wont even work for a few days on some sites. Its completely random and hard to trouble shoot.
We have a different Mikrotik hardware (RB2011UiAS-2HnD, hAP ac, hAP ac lite), different versions (6.49.2 and 6.49.7), different internet providers and types of connection (pppoe, static ip, dhcp client). Problem appears everywhere and we cant pin point the issue...

Temporary workaround we found out if you if you disable Peer in IPsec menu and reenable. Sometimes you just have to disable and reenable once. Sometimes you have to repeat this process a few times. Sometimes, this doesnt even work and after afew hours it just works if you disable peer again.

We have seen that if Mikrotik is initiator, IPSEC is alot more stable. But that is not always the case. IPSEC works too if mikrotik is a responder.

Once IPSEC doesnt work, Mikrotik act strange. You can see alot of established responders peers under Active Peers. Example in a photo https://imgur.com/a/g7NdNys and log get spammed failed to pre process ph2 packet.

Sometimes both SA (from Mikrotik and NGFW) get wipe from Installed SAs. After you run ping tool to the NGFW local network, they came back. Not sure if this is related or not.

NGFW support told us "Mikrotik does not have same selectors (local 0.0.0.0/0 remote 0.0.0.0/0) as NGFW. And that is why VPN does not come up when initiated by NGFW. As the NGFW RBVPN selectors are hardcoded, you need to change the selectors in Mikrotik." In our case, IPSEC didnt worked if we set this in Policies.

No help so far from Forcepoint nor Mikrotik support so we are asking you community if you can help us solve this.

This traffic selector ("local 0.0.0.0/0 remote 0.0.0.0/0") is typically used for VTI, but does not make much sense for the classic policy-based IPsec. And Mikrotik does not support VTI.

This traffic selector ("local 0.0.0.0/0 remote 0.0.0.0/0") is typically used for VTI, but does not make much sense for the classic policy-based IPsec. And Mikrotik does not support VTI.

We setup a test mikrotik and tried to configure with selectors source 0.0.0.0/0 destination 0.0.0.0/0. VPN connection established but you cannot access anything from mikrotik side(lan or internet). As soon as you disable VPN connection, internet and lan access works. Im guessing that it has to do something with routing (dst address 0.0.0.0/0 - gateway (WAN IP GW).

Is there a way to force mikrotik to work only as initiator?

Of course when you have source 0.0.0.0/0 destination 0.0.0.0/0 then all your traffic will match and it will make normal communication impossible.
To fix that, you would at least need to add some higher priority selectors that again exempt networks from that (with action=none instead of action=encrypt).

Still, it is becoming more and more of a pain that MikroTik does not support VTI!
Other manufacturers have moved away from the standards that MikroTik still supports (direct IPSEC tunnel with specified selectors, or using a GRE tunnel on top of an IPSEC transport and having a route table to specify the traffic to use the tunnel).

I know, VTI does not really add something functionally, but it is what "the others" have chosen, and not supporting it excludes MikroTik from interworking more and more each day.
I had to setup a Linux VM to do a VTI tunnel from our company to Microsoft Azure, and it was really TRIVIAL to setup and get going.
I really do not understand why MikroTik did not yet add that config capability of Linux.

(on the other hand, when it is added it will probably be added to v7, which is unusable due to lack of BFD)

Of course when you have source 0.0.0.0/0 destination 0.0.0.0/0 then all your traffic will match and it will make normal communication impossible.
To fix that, you would at least need to add some higher priority selectors that again exempt networks from that (with action=none instead of action=encrypt).

Thanks for reply. I tried that, but had no luck working. Can you show me with an example?

MikroTik nor Forcepoint support was helpful here. We found a workaround. We went from IKEv1 to IKEv2 and ipsec connection is a lot more stable. On some routers we also set a scheduled job that MikroTik ping a server at Forcepoint site every 10 minutes. With this, we achieved that MikroTik is initiator most of the time. Can't say we solved the problem but situation is ALOT better.

Ipsec is notorious for these problems, and some manufacturers have worked around them better than others.
Usually when you have "DPD" (Dead Peer Detection) active it will be more stable, but some manufacturers get it goofed up even with that.
E.g. we have an IPsec tunnel with Microsoft Azure which normally is up all the time, but this week the internet on site was down for a couple of minutes and this tunnel went down never to recover until I disabled it for 15 minutes and re-enabled it.
That (and its resolution) is something I have not seen with MikroTik equipment (talking to eachother and to Linux systems) for ages, but Microsoft apparently is still able to do it. It was quite a common problem across the board 20 years ago.

Yeah, tell me about it! V6 is a f-n nightmare with these notorious problems. Sometimes DPD was the only reason for a dropped connection, everything worked out when it was removed

I have been using IPsec on e.g. Cisco routers for more than 20 years, and I can assure you it was just as bad on Cisco back then.
It is just a flaw in the protocol, for which each manufacturer invents workarounds.
And even admins do. (like setting up regular pings and recovery action scripts, that include "disable it for 15 minutes and re-enable")

Yeah, been there done that!

Regarding MT and Ros v6, we also had problems with lingering SAs that refused to renew themselves or became stuck after a tunnel failure. As I recall it, on some of the more troublesome sites, we resorted to pinging instead of using DPD with a restart script that cleared the related SAs and restarted the unresponsive tunnels accordinaly.