maybe i got that wrong
You have reverted the logic. The client actively initiates the connection by sending a request packet to the server which passively listens and responds if a request arrives. As the NAT rules are only consulted for the initial packet of each connection, and the subsequent packets of a connection are treated the same (or reverse, for response packets) way like the initial one, to make the server listen on a non-standard port "externally", you need a dst-nat rule on the server in prerouting (same for ROS 6 and ROS 7).
On the client, for L2TP in particular you cannot configure a port of the server in
/interface l2tp-client. Therefore, you need to change the port later, using the firewall. Since you cannot dst-nat outgoing packets, or src-nat incoming ones, in ROS 6, the trick with a hairpin tunnel is necessary there to achieve this; in ROS 7, a possibility to dst-nat outgoing packets has been added to chain output (together with a possibility to src-nat incoming ones in chain input - that's not relevant for the OP's scenario but may be useful elsewhere).
If the OP's ISP blocks UDP port 1701 in either direction (people sometimes do weird things, see @Filament's remark), you also need a src-nat rule on client side because by the L2TP standard, both the client and the server use UDP 1701 as the local port. But L2TP server is tolerant and it accepts client requests coming from any port and responds to that port, so you do not need a mirror rule in server's input chain to "undo" the src-nat done at client side.