Context:
When the “use-ipsec” option is enabled on an L2TP Client interface, the configuration and dynamic IPSec peer policy are added to encapsulate the L2TP connection in the IPSec tunnel. This works correctly, the problem appears when disabling an L2TP Client interface, the dynamic IPsec configurations associated with this interface are not deleted in any of the IPsec tables where they were created, therefore a continuous error appears in the LOG indicating a failure in the negotiation phase 1.
Each time the disable/enable process is repeated, new entries are created in the IPsec tables associated with the L2TP Client interface to which the action is applied.
You can see in the image, several entries associated with the same L2TP Client interface, but only one (of each one) is active, the rest of the entries remain because they were not eliminated when the l2tp interface was disabled.
I’d start by upgrading from 6.47 to 6.47.10. If still the same, it’s worth opening a ticket at Mikrotik support. And until they solve it, create static copies of the dynamically created IPsec configuration rows (you’ll have to use different names for the named ones) and then uncheck use-ipsec=yes on the /interface l2tp-client row.
I tried this version and others, and the problem persists. Valid your solution, thank you. I also think that “use-ipsec” should be dynamic in both directions create/remove. I will definitely open a support ticket.
I’ve just tried it on a CHR running 6.47.9, it works normally - once I disable the /interface l2tp-client, the dynamically created IPsec configuration items disappear as they should.
You may try to export (not backup) the configuration into a file, download the file to the PC, netinstall the machine with the same version it was running during the export, and then re-create the configuration from the export by copy-pasting it line by line.
Or start by doing only /system reset-configuration keep-users=yes instead of the netinstall step.
It seems that something broke down in the actual configuration hidden below the “visible” one, and the configuration reset might be sufficient to clean this up. Not guaranteed, though, so then the same with an actual netinstall would be the next thing to do.