l2tp client: configure source port

RouterOS General
1

Hi, the problem I’m facing has lot of explanations and discussions on this forum like http://forum.mikrotik.com/t/multiple-road-warrior-l2tp-ipsec-clients-behind-nat-solved/118206/1 and http://forum.mikrotik.com/t/l2tp-ipsec-client-behind-nat/115845/1 - all about multiple L2TP/IPSec clients behind shared NAT. As far as I understand, the issue can be solved if such l2tp clients will use different source ports (random). According to the first link -

Some client implementations are aware of this and use random ports. RouterOS server implementation is not strict in this and accepts connections from such clients, so this is a solution of the problem for these implementations

so it can be a solution for Mikrotik client as well. Is my understanding correct?

But t seems this functionality is not implemented in RouterOS l2tp client - there is no possibility to change the source port. If this can be a solution, how it’s possible to ask Mikrotik to implement this feature (randomizing l2tp client’s source port)?

In the meanwhile, any ideas how it can be implemented (srcport:1701 → srcport:other before ESP encapsulation) on client side in other ways?

Thank you.

2

Hi,

“Some client implementations are aware of this and use random ports. RouterOS server implementation is not strict in this and accepts connections from such clients, so this is a solution of the problem for these implementations” – so it can be a solution for Mikrotik client as well.

I created the lab and can confirm - when clients are using different source port, everything works. My lab is the following:

  • my home laptop with two clients: (a) VM RouterOS v7 and (b) xl2tpd+strongswan
  • my LAN is behind NAT, so both clients are behind the same public IP
  • server (CHR under RouterOS v7) located somewhere in public cloud
  • VM RoS calls server from udp/1701, xl2tpd calls server from udp/1702. In this configuration it works, as soon as I reconfigure xl2tpd to use udp/1701 as a source, life ends (which is expected).

But t seems this functionality is not implemented in RouterOS l2tp client - there is no possibility to change the source port. If this can be a solution, how it’s possible to ask Mikrotik to implement this feature (randomizing l2tp client’s source port)?

Randomizing is not a case. To work around this problem, we need to specify the port in the policy, so it’s just required to do the very simple thing - add ability to specify source port for l2tp client session. That’s all and this many-years-standing issue will gone.

Anyone here from Mikrotik? :slight_smile: Is this absolutely impossible?

Thank you.

3

You can do source nat on the output chain normally.
Unfortunately not sure if it works when it is about to be ipsec encrypted.
If works the 2nd Mikrotik could source nat its port 1701 to maybe 1702

4

Hi,

2nd mikrotik do not work - it’s about “roadwarriors”, my network has tens of those guys and few of them (different ones because they’re really moving) regularly face this problem.

And, unfortunately, output chain do not support src-nat:

[admin@MI2] /ip/firewall/nat> add chain=output action=src-nat src-port=1701 to-ports=1702 protocol=udp out-interface=ether1
failure: srcnat action must be in srcnat/input chains

Thank you.

5

Yes, that is known. The first article you mention shows you how to work around that.

I agree it should be solved, best by having a checkmark “use random high-numbered source port instead of 1701” so you would not have to manage the allocation of different source port numbers.

But anyway, L2TP/IPsec is on the way out. Systems like Android (and I think also IOS) no longer support it “because it is insecure”.
(no idea what that exactly is based on, and if that is one of those “studies” that come up with totally unrealistic scenarios and minor effects)

So we need to move to IKEv2 where these issues are no longer present. Unfortunately because RouterOS still does not support VTI or another way of having all IPsec traffic on a separate virtual interface, that usually means quite some rework in the config.
And you usually need to keep supporting L2TP/IPsec alongside, at least for some time. So double work.

6

So we need to move to IKEv2 where these issues are no longer present

The issue is that I’m moving from IKEv1 to IKEv2 to solve this issue too :slight_smile: At first (at the moment of launch, as usual, there was no time :slight_smile: ) I used “use_ipsec=yes” and what is wrong with this configuration - IKEv1, PSK and the issue with multiple clients behind the shared NAT.

Then I did a shift to the manual configuration of L2TP over IPSec (IKEv2, certificate authN) and, for some reasons, was thinking the issue will be automagically fixed with IKE2 (don’t even remember where I read about this). But no, the issue is still there. As far as I understand, it is unrelated to IKE version, since it comes from port-less ESP.

best by having a checkmark “use random high-numbered source port instead of 1701” so you would not have to manage the allocation of different source port numbers.

Having random port adds complexity to the implementation. It’s ok when using “use_ipsec=yes” in l2tp client configuration but it’s unclear how to specify port in ipsec policy when doing manual configuration (see above pros and cons).

From my point of view, this change (ability to specify source port) is very simple, since client ports do not have any other dependencies inside the ROS. This is just a client port, which do not need to be referred by other parts of configuration except when “use_ipsec=yes” used and this is the only situation when this port need to be referred by another service.

But anyway, L2TP/IPsec is on the way out. Systems like Android (and I think also IOS) no longer support it “because it is insecure”.
(no idea what that exactly is based on, and if that is one of those “studies” that come up with totally unrealistic scenarios and minor effects)

Among all other approaches, L2TPoIPSec is the most simple in terms of massive scale (server do not require specific configuration per client - both in L2TP and IPSec parts). Also, I like IPSec itself for (a) UDP and (b) compatibility with everything. Having VTI is, of course, could be be a great addition but even without VTI it’s the most compatible encryption framework.

And, not being security engineer, I don’t share the opinion about “insecurity”, because there are two layers of authN - PPP username/password and, which is more important, IPSec certificate- or even PSK-based authN with PFS and TFC padding (latter - if supported :wink: ).

The first article you mention shows you how to work around that

To be frank, it’s not a “solution” - it looks like very complex system of crutches and supports because no other ways are available :slight_smile:

Thanks.

7

Solved on client side. According to https://help.mikrotik.com/docs/display/ROS/Packet+Flow+in+RouterOS#PacketFlowinRouterOS-Output two rules on client are required which do the job:

[admin@MI2] /ip/firewall> export
/ip firewall mangle
add action=mark-packet chain=output new-packet-mark=lo2tp protocol=udp src-port=1701
/ip firewall nat
add action=src-nat chain=srcnat packet-mark=lo2tp protocol=udp to-ports=17003

where first rule catch locally originated packets from udp/1701 and mark them and second rule catch marked packets and rewrite to another client port (17003). Respectively, ipsec policy need to be described in the following way:

/ip ipsec policy
add dst-port=1701 level=unique peer=remote_peer proposal=l2tp protocol=udp src-port=17003

and voila, it works.

8

Hello, the version of routers that I have is RouterOS 7.8, when entering these rules
"[admin@MI2] /ip/firewall> export
/ip firewall mangle
add action=mark-packet chain=output new-packet-mark=lo2tp protocol=udp src-port=1701
/ip firewall nat
add action=src-nat chain=srcnat packet-mark=lo2tp protocol=udp to-ports=17003 "if I do them but the latter does not do it, it gives an error
" /ip ipsec policy
add dst-port=1701 level=unique peer=remote_peer proposal=l2tp protocol=udp src-port=17003 “the error it gives is input does not match any value of peer”.
Why is he doing it?
Thank you

9

Do you have a peer called “remote_peer”?

10

I don’t know how can I know?
What should I verify?
I used the script as I saw it because I thought it was the solution

" /ip ipsec policy
add dst-port=1701 level=unique peer=remote_peer proposal=l2tp protocol=udp src-port=17003 "

the error is this does not match any value of peer

11

Check your configuration.

Command should be:
/ip ipsec peer print
to list all existing peers.

BTW, I have no idea how l2tp/ipsec works or should be configured, I am only trying to explain to you the reason why that error comes out, the line attempts to add something to a peer, and this peer is not found.

12

He does just cut/paste commands into his config without understanding the context, that is why it does not work.

13

Hello, here is what is listed.

Flags: X - disabled; D - dynamic; R - responder
0 DR name=“l2tp-in-server” passive=yes profile=default exchange-mode=main send-initial-contact=yes

Does the problem behind nat have a solution?

14

No idea what it will do, but in your case the command line should be:

/ip ipsec policy
add dst-port=1701 level=unique peer=> l2tp-in-server > proposal=l2tp protocol=udp src-port=17003

Cannot say if double quotes will be needed or not.

15

No, that is wrong. An interface is not the same thing as a peer.
It is complicated.