First, switching firewall completely off is a very bad idea. The filth from the net is incredibly fast to squat in.
Second, do you realize that the order of rules in the firewall matters, as the rules in each chain are evaluated from the first (topmost) one towards the last (bottommost) one until first match, i.e. if you have e.g.
chain=forward action=accept protocol=udp dst-port=500,1701,4500
no packet will ever reach the accept rule because it will match the drop one first?
Third, the IPsec configuration generated dynamically if use-ipsec is set to yes or required is created using the default profile, default proposal, and default policy template. The parameters of the default profile and proposal may not be compatible with the settings expected by your L2TP/IPsec client, and if there is any other IPsec configuration already present, it may be in conflict with the dynamically created one. That's why I was asking what actually doesn't work.
So the first check is that the dynamic IPsec configuration has indeed been created, and that there is no other IPsec configuration interfering with it:
/ip ipsec profile print
/ip ipsec proposal print
/ip ipsec peer print
/ip ipsec identity print
/ip ipsec policy print
If everything is right here - a single profile (default), a single proposal (default), a single peer (dynamically created), a single identity (dynamically created and linked to the only peer), a single policy template, the next step will be to activate logging of IPsec, make a client connection attempt, and read the log to find out what the issue is.
Feel free to ask for details of any step which is not clear to you.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.