Hello,

A week ago all my ipsec VPNs stopped working, I tried to reboot, change psk, change cert, use a backup... but still not working.

In the logs the only thing related to ipsec its:

"initiate new phase 1 (Identity Protection): local ip[port]<=>remote ip[port]"
"the packet is retransmitted by remote ip[port]"
"phase1 negotiation failed due to time up local ip[port]<=>remote ip[port]"

Its crazy because I changed nothing, any ideas?

Thanks.

Sounds like your ISP has changed some settings. Since you mention "all", can you provide the details of the one with the simplest topology?

I have two scenarios:

First scenario: 1 mikrotik behind an ISP router with the dmz pointing to the mikrotik giving me the logs I mentioned above.

Second scenario: On my main mikrotik I have configured a server with L2TP over IPSEC in which the clients connect either using MAPs or by software and in this case the log I get is “remote ip parsing packet failed, possible cause: wrong password” but as I said everything is the same as when it was working, no password changed.

"First scenario" mentions a single peer; what is the other peer in this scenario, another Mikrotik or a VPN client on a computer or phone?

"Second scenario" mentions a "main mikrotik" and multiple remote clients - does MAP mean a Mikrotik mAP?

Or did I get you wrong and there is one site according to "second scenario" and many sites according to "first scenario" connect to it?

In any case, there may be an issue with tracked connections on various firewalls along the path - after restart of one of them somewhere in the middle of the path, the source port (or even address) of an incoming packet to a peer may be different than before the restart, which the connection tracking on the receiving peer cannot handle properly as the IPsec packets sent by that peer itself keep updating the old pinhole.

In such case, you have to use /ip firewall connection print detail with some conditions and /tool sniffer with some conditions to identify the issue, and typically removal of the old tracked connections resolves the situation.

So choose two particular Mikrotiks and we can debug the issue on them.

In the first scenario I have multiple mikrotiks connected to "the main one (also a mikrotik)" via ipsec from different public ips and ISP providers also.

In the second one I have a L2TP server configured on the mikrotik and the clients uses map (mikrotik map) or software vpns

OK, so let's concentrate on a single session in the first scenario, choose one of the "outer" Mikrotiks and let's debug the current state. Show me the configuration exports of both of them, with public addresses and any kind of other sensitive information filtered out.

We managed to patch it setting the pfs group to none in the proposal but still looking why we are losing that packages, seems to be something related with ISP

Second scenario problem not solved yet

It happened to me too some time ago, the problem was that the ISP was under DDoS attack and had set the most sensitive filters.