Community discussions

MikroTik App
 
th0massin0
Member Candidate
Member Candidate
Topic Author
Posts: 156
Joined: Sun May 11, 2014 4:16 am
Location: Poland

L2TP on custom port or other tunnel type

Sun Nov 06, 2022 11:59 am

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?
 
sindy
Forum Guru
Forum Guru
Posts: 9902
Joined: Mon Dec 04, 2017 9:19 pm

Re: L2TP on custom port or other tunnel type

Sun Nov 06, 2022 1:38 pm

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.
 
Sob
Forum Guru
Forum Guru
Posts: 9049
Joined: Mon Apr 20, 2009 9:11 pm

Re: L2TP on custom port or other tunnel type

Sun Nov 06, 2022 6:52 pm

(for the record, v7 can change destination in output chain, no clever loops required)
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 14471
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: L2TP on custom port or other tunnel type

Sun Nov 06, 2022 7:58 pm

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)
 
th0massin0
Member Candidate
Member Candidate
Topic Author
Posts: 156
Joined: Sun May 11, 2014 4:16 am
Location: Poland

Re: L2TP on custom port or other tunnel type

Sun Nov 06, 2022 9:48 pm

(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.
 
User avatar
nichky
Forum Guru
Forum Guru
Posts: 1121
Joined: Tue Jun 23, 2015 2:35 pm

Re: L2TP on custom port or other tunnel type

Mon Nov 07, 2022 1:39 am

(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?
 
Sob
Forum Guru
Forum Guru
Posts: 9049
Joined: Mon Apr 20, 2009 9:11 pm

Re: L2TP on custom port or other tunnel type

Mon Nov 07, 2022 4:22 am

Not exactly change, but you can cheat using NAT (on client):
/ip firewall nat
add chain=output dst-address=x.x.x.x protocol=udp dst-port=1701 action=dst-nat to-ports=12345
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.
 
User avatar
nichky
Forum Guru
Forum Guru
Posts: 1121
Joined: Tue Jun 23, 2015 2:35 pm

Re: L2TP on custom port or other tunnel type

Mon Nov 07, 2022 6:28 am

@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.
 
Sob
Forum Guru
Forum Guru
Posts: 9049
Joined: Mon Apr 20, 2009 9:11 pm

Re: L2TP on custom port or other tunnel type

Mon Nov 07, 2022 7:52 am

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.
 
sindy
Forum Guru
Forum Guru
Posts: 9902
Joined: Mon Dec 04, 2017 9:19 pm

Re: L2TP on custom port or other tunnel type

Mon Nov 07, 2022 9:54 am

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)?
 
th0massin0
Member Candidate
Member Candidate
Topic Author
Posts: 156
Joined: Sun May 11, 2014 4:16 am
Location: Poland

Re: L2TP on custom port or other tunnel type

Mon Nov 07, 2022 11:05 am

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.
 
sindy
Forum Guru
Forum Guru
Posts: 9902
Joined: Mon Dec 04, 2017 9:19 pm

Re: L2TP on custom port or other tunnel type

Mon Nov 07, 2022 11:30 am

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.

Who is online

Users browsing this forum: Bing [Bot] and 13 guests