Hello,
Cloud you please tell me how to setup L2TP tunnel (server and client) on custom port?
The problem is poor of performance (hap lite) and lack of public ip on both sides.
Encryption is NOT required, I am just escaping from ISP's NAT.
Could you please help?

The intention is not really clear from your post. For L2TP in particular, you cannot change source nor destination port using configration of L2TP itself; you can change the source port using a src-nat rule, but you cannot change the destination port of outgoing traffic unless you use a hairpin tunnel to force the traffic through the firewall twice on the same router.

If the intention is "UDP hole punching", i.e. creation of a tunnel directly between two routers none of which has a public IP address, the best option is IPsec in IKEv2 mode where you can specify the destination port (and you still have to use src-nat and dst-nat rules to take care about the rest). But before starting to configure that completely, check that both ISPs do preserve the source port when doing src-nat, as many don't.

(for the record, v7 can change destination in output chain, no clever loops required)

If neither party has a publicly accessible wanip, then you either have to a
a. rent a server (AWS or oracle)
b. pay a third party vpn provider
c. use free zerotier (which is through a third party but built-in to MT)

(for the record, v7 can change destination in output chain, no clever loops required)

Could you please provide example? If I am thinking correctly:
- server, rewrite incomming packets port from X/udp to 1701/udp
- client, rewrite outgoing packets from 1701/udp to X/udp
??

a. rent a server (AWS or oracle)

Yes I have it now, with CHR installed with public, static IP.

(for the record, v7 can change destination in output chain, no clever loops required)

what do u want to say, that we can change l2tp port?

Not exactly change, but you can cheat using NAT (on client):
Client will be connecting to x.x.x.x:1701, but it will go to x.x.x.x:12345. And on server side it's just regular dstnat.

@sob,

interesting, i was doing that with chain=srcnat, and it does work well.
By using your one, it's not allowing me to establish the tunnel.

It depends on what you're trying to change. As the names suggest, srcnat = source port, dstnat = destination port. So yours is changing client's port, as seen by server. Mine is allowing client to connect to server that's listening on non-standard port. And if needed, you can have both.

Yes I have it now, with CHR installed with public, static IP.

If you have one, why do you need to change port?

And if you do, which port do you want to change - the one at server side (CHR) or the one at client side (your hAP lite)?

If you have one, why do you need to change port?

And if you do, which port do you want to change - the one at server side (CHR) or the one at client side (your hAP lite)?

... because ISP where client is installed blocks 1701/udp. If I will change port on client I must change it on server too. So the answer is: both.

OK. So for 7.x, as @Sob has stated, you can use dst-nat for outgoing traffic of the router itself; for 6.x, you need to set up an IPIP tunnel between two own addresses of the client router, route the own traffic of the client router towards the CHR through one end of that IPIP tunnel, use a dst-nat rule to change the port as the connection emerges from the other end of that IPIP tunnel, and route it via the WAN. The src-nat rule changing the source port may be applied at any stage (first or second).

At the server side, you need to dst-nat the port back to 1701 as you cannot change on which port the L2TP server listens.

But if you use ROS 7, you can as well use Wireguard where you can configure the ports freely at both peers (there are no static roles of client (initiator) and server (responder)).

If you want to stay with ROS 6, you can use IKEv2 where you can also specify the destination port at the initiator side; src-nat rule at initiator and dst-nat rule at responder are still necessary. This is not possible with IKE(v1) because the port you specify is used only during the initial phase of session setup, and then it switches over to port 4500 if NAT is detected and there is no way except dst-nat to change the 4500 to another port.

Even if you use IKEv2 or Wireguard, you can still choose to only use them to encrypt the L2TP transport packets. The advantage of L2TP is that you can use MLPPP to avoid fragmentation at IP level - it silently splits large payload packets into multiple transport ones. This is useful to avoid problems related to broken PMTUD, but the problem of double packet rate remains the same like with the normal fragmentation at IP layer.