hello
i have that use for l2tp/ipsec server . when all my client discconect and then go back i have error pahse 1 negottion failed to send error
but my client connect seperatlly is ok and connect
how can i limited connected to my router ?
how can i use all cpu core for l2tp/ipsec ?


thanksd

How can I limited ipsec established to mikrotik ?
When my 500 user connect mikrotik cpu full but when all user connect cpu
Usage is 3% I want limited ipsec established for example I want else connect 30 ipsec established in 1 min
Can anyone help me ?

So if I summarize:

• if 500 clients are up and running, the CPU load is 3 %
• if a single client tries to connect while the others are running, there is no problem
• if 500 clients are trying to connect at the same time, the CPU goes to 100 % and most clients cannot connect

Is that correct?

If so, what is the reason that all the clients attempt to connect at the same time? A recovery from a network outage or some natural event, like the beginning of business hours?

What you can do to protect the CPU from overload is to limit the number of connection requests that reach the IPsec stack per unit of time by accepting only up to N new connections to UDP port 500 per unit of time using the limit matcher in /ip firewall filter. As there is no way to instruct the clients to wait for a certain amount of time, so there is no point in queueing the received requests and releasing them from the queue with a given rate (which is technically possible) because the clients may give up after some tens of seconds. Routers typically never give up; end devices (PCs and phones) typically do, so the connections from this kind of devices will fail anyway, except that for a different reason (connection timeout instead of negotiation failure).

If we talk about routers as clients, there is one more point - the timeout of a UDP connection is 3 minutes by default. So if the connection avalanche is caused by a recovery from network outage, and the outage was shorter than 3 minutes, the new connection attempts may hit already open pinholes and thus bypass the limitation rules. Hence it is helpful that port 500 was used only during connection establishment, because there is no way to distinguish a re-connection attempt from a DPD packet. So even if the clients (initiators) are running on public IPs, a forced use of NAT traversal mechanism at server side is helpful - the connections will migrate to port 4500 and only new connection attempts will arrive to port 500.

To get more detailed suggestions, you have to convince me that your application case is worth it. If the clients are PCs and/or phones, going into more detail would be just a waste of time as the outcome would be unsatisfactory anyway.

Thanks a lot my friend
You explained my problem exactly
All my clients is mikrotik router board that connect to main office with l2tp/ipsec .
When my internet connection in main office fails all clients disconnected and after soled my problem all try to reconnect
I tested with ccr router and give same problem
Do you have a suggestion for this problem?

All my clients is mikrotik router board that connect to main office with l2tp/ipsec.

Great, so the pre-requisite that the clients never give up is met.

I tested with ccr router and give same problem

That's no surprise. The amount of data processing needed to establish a connection is high, and several steps are necessary. As a too large delay of any of these steps is fatal for the connection attempt as a whole, and as the chances that none of the steps fails for a particular connection are close to zero, none of the attempts ever succeeds and the load remains high forever.

Do you have a suggestion for this problem?

Sure, I have already described the suggestion above. You have to moderate the flow of the initial packets to UDP port 500 to the IPsec stack in the firewall using the using the limitmatcher in /ip firewall filter. This will reduce the number of connection attempts to even start. As dropping the initial packets from the others is a much less CPU intensive task, this dropping will not prevent the connections whose initial packets were allowed to get in from completion; once they get completed, the CPU load will decrease and a batch of subsequent connection attempts can be enabled.

So replace the single rule
action=accept chain=input protocol=udp dst-port=500,1701,4500
in /ip firewall filter by the following three ones:
action=accept chain=input dst-port=500 limit=5/10s,0 protocol=udp
action=drop chain=input dst-port=500 protocol=udp
action=accept chain=input protocol=udp dst-port=1701,4500
and that should do the trick.

If the rule to be replaced looks different in your firewall, or if you don't use a stateful firewall, post the output of /ip firewall filter export.

5 attempts in 10s should be at the safe side; if it helps, you may be able to allow more. 5 attempts in 10s means slightly more than 15 minutes for all 500 clients to recover.

If some of the clients connect from public addresses, the server configuration needs to be modified, otherwise connections from those clients would ruin the idea.

thanks a lot
i change config and test it and feed back for you