Hello,

sometimes it happens that the VPN tunnel interrupts.
Then I get this error message: Then the RB tries to reconnect to the server (Linux OVPN server, not a other RB). Sometimes it takes more than one retry and while reconnecting the CPU goes up to 100%.

I use on my RB two outgoing and one incoming OVPN connections.
Sometimes it needs ten or twenty retries that one lost OVPN connection is avalable again.

It is strange that the CPU goes up to 100% while reconnecting.

Is this a bug in 6.41?

Thanks.

Any known bug?

100% CPU while (re)connecting.

Single core routerboard? Wich model? Depending upon your settings, the SSL key part can get quite heavy.

Yes, single core - RB750.

I am running two OVPN clients and one OVPN server on it.

Sometimes, the reconnect takes few seconds, sometimes it takes 30 minutes.

This is weird. The connection does use a lot of CPU power - but it takes about 10 seconds. Could be packet loss? Maybe sporadic packet loss, on one of the links?

No, there is no packet loss.
I think because of the the high cpu power the timeout will be reached before the connection is esablished.
I use for all three OVPN configs certificates with 4096 bit.

No, there is no packet loss.
I think because of the the high cpu power the timeout will be reached before the connection is esablished.
I use for all three OVPN configs certificates with 4096 bit.

It is possible. 4096 will give the CPU a lot of work. Can you try with 2048?

With 2048 bits it should be no problem, but it also works with 4096 bits sometimes to establish the tunnel, so I think it is only a timeout problem of RB.
If Mikrotik would give the ssl command more cpu time an set a higher timeout it could be solved.

I have other RB2011 with 2048 bit certificates and there is no problem but the RB2011 has more cpu power and more memory than the RB750.

Maybe Mikrotik can change the software to solve this issue!?

I think it would be cheaper for MT and faster for you to get faster RB. Multiple tunnels and large keys are, I think, not the targeted domain for 750.

With 2048 bits it should be no problem, but it also works with 4096 bits sometimes to establish the tunnel, so I think it is only a timeout problem of RB.
If Mikrotik would give the ssl command more cpu time an set a higher timeout it could be solved.

I have other RB2011 with 2048 bit certificates and there is no problem but the RB2011 has more cpu power and more memory than the RB750.

Maybe Mikrotik can change the software to solve this issue!?

There is only so much you can do without a faster CPU. Crypto is a really intensive task - even to the x86 beasts we are used to. Either use a smaller key, or get a faster RB. If You don't need wireless, the RB750Gr3 (hEX) is quite good - and cheap too.

Thanks but why does it work sometimes immediately to establish the connection.
@Mikrotik: Maybe it would be possible to fix this in software for slower devices?

Thanks but why does it work sometimes immediately to establish the connection.

My guess: you are running close to the limit. When the firewall, network, whatever, uses a little more CPU, there isn't processing power enough left to do the crypto in time.

Sure, they could increase the timeout. But this would only push the problem, not solve it. Get a more powerful device, and solve it once and for all.

Yes, I will upgrade to a more powerful device.

But a user-defined timeout also would be fine.
In my case there are some seconds missing because after several tries it works. If the device never would be able to establish a connection it would be clear.
But the problem only occurs with the two outgoing connections, the incoming OVPN connection always established at first try.

Does this fix the problem?