While @Sob’s analysis & advice is the most useful one (if you knew that setting arp=proxy-arp on the LAN interface was necessary, you would have included that into the “relevant part” of the configuration to post, wouldn’t you?), there is another catch with L2TP/IPsec - to allow multiple Windows or Android clients to connect from behind the same public IP address, you need a complicated workaround.
On the other hand, if you don’t insist on keeping the default settings on Windows side or on keeping the LAN subnet, you can make it work without the arp=proxy-arp setting - by default, Windows add a route via the tunnel to a destination subnet that matches to the traditional (A, B, C) class of the address assigned by the server. If it is 192.168.x.y, the route will be to 192.168.x.0/24, so if the LAN subnet is 192.168.x.0/24 too, you need the arp=proxy-arp because from the point of view of the hosts in the LAN, 192.168.x.y is in the same subnet so they try to send data to it directly rather than via gateway. But if you reduce the LAN subnet to 192.168.x.0/25 and give the L2TP clients addresses from 192.168.x.128/25, the LAN hosts will look for a gateway when sending to 192.168.x.128/25, but Windows will still add a route to the whole 192.168.x.0/24.
If a /25 subnet is too small for your LAN, you can use 172.x.y.z (16<=x<=31). In this case, the Windows will add a route to the whole 172.x.0.0/12, so you can have much more addresses in the LAN (even organized into multiple subnets) and still not use arp=proxy-arp.
And if you use non-default settings, you can link a list of routes to the Window’s miniport using powershell, rather than let them add the single class-based route. Windows also support getting a route list via DHCPINFORM message and Option 249, but RouterOS only supports this method for IKEv2, not for L2TP/IPsec.