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.

In case anyone tries to do this with a pair of Mikrotik HEX running the default Firewall configuration, be warned that you need an aditional rule, or else it won't work.

For the Mikrotik client you need two lines (make sure to move them at the very beginning of the "NAT" tab in the Firewall window) : For the Mikrotik server you need, at first, this line: But it won't work until you add an additional line in the Server (and move it to the very beginning of the "Filter Rules" tab in the Firewall window): Regards.

EDIT: I have modified this post on August 1st, 2023. Mainly to combat those scummy ISPs that also look for the source port and block connections with UDP 1701 source port!

i can't make it work the server is output.
client is input

happy to export the config if anyone interested

the server is output
client is input

Can you rephrase these?

In addition to posting the configurations of both the client and the server, describe or draw what you want to achieve. The original topic was dealing with making a RouterOS L2TP server listen on some other port than 1701 (which only requires a single dst-nat rule) and with making a RouterOS L2TP client connect to an L2TP server listening at some other port than 1701 (which was complicated with ROS 6 but became as easy as a single dst-nat rule with ROS 7, as @Sob has pointed out in his post). Is your "doesn't work" related to the same scenario?

@sindy brate,

maybe i got that wrong, but this is my theory and set up:

the topology is very simple:

R1 as VPN server and R2 as VPN client

The nat of R1 looks like that:
/ip firewall nat
add chain=output dst-address=x.x.x.x protocol=udp dst-port=1701 action=dst-nat to-ports=12345


and on R2
/ip firewall nat
add chain=input dst-address=x.x.x.x protocol=udp src-port=12345 action=src-nat to-ports=1701

/interface l2tp-client
add connect-to=x.x.y.y:12345 name=l2tp password=password user=user


does it make sance , or i got totaly wrong?

I have changed my post to reflect an ugly reality (there really are more scummy ISPs out there than you think!)

It's currently working very well on four Mikrotiks I've configured. Some of the ISPs are semi-scummy, and don't completely block connections on UDP port 1701, but severely throttle the speed to the point it's almost unusable.

Changing the source and destination ports to avoid 1701 solves both the blocking problem and the throttling problem!

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.

Thanks sindy , clear!

Hi everyone,

I was wondering if it would be worthwhile to restrict the server rules a bit more, in order to avoid clashing with other innocent apps that could use the 12345 port (or whatever port we've chosen to use instead of 1701)

Do you think this configuration in the Server would be better?
I believe those lines would restrict the changing of port 12345 only when coming from our L2TP client. And innocent apps will survive using the same port. Is that correct??

You can do that but it would only make sense if you wanted another application to listen for incoming connections at port 12345. There are multiple cases how to let an "innocent application" listen on a port on WAN:

• you manually set up a dst-nat rule (clearly not your case here)
• the application uses UPnP to create a dst-nat rule dynamically
• you configure that weird way of src-nat that opens the port for anyone in the internet if an application initiates a connection from that port to any single address in the internet (so instead of using UPnP, the application just sends a packet from the port it wants to listen at to any address routed via WAN)

If you use only the "normal" src-nat rules, an incoming packet is matched by both the source and destination addresses and ports, so only packets that arrive to port 12345 and do not match any existing connection will create a new connection towards port 1701.
If you use UPnP or the "weird NAT", you have to have a look where the dynamically created dst-nat rules are positioned in the dstnat chain, as your selective rule must be placed before (above) them in the dstnat chain in order to work.

"Weird NAT" is that a technical term?
Do you mean the new endpoint NAT function?

Do you mean the new endpoint NAT function?

Exactly. It's just that the official name is so meaningless that I cannot remember it.

"FULLY" explained here --> https://help.mikrotik.com/docs/display/ ... pendentNAT

Fully = The normal 'high quality' documentation by MT especially for new functionality.