Hi,
I’ve tried to find info and just can’t.
As I understood in v7 is updated kernel.
As kernel was the problem in previous versions, my question is :
Does OpenVPN working properly on v7 both TCP and UDP ?
Thank you in advance
Kernel has nothing to do with UDP OpenVPN. Official OpenVPN used to work even with kernels way older than RouterOS v6 has. The problem was that MikroTik reimplemented OpenVPN themselves and didn’t include UDP at first. They added it only later and released it with RouterOS v7. I didn’t test it myself, but I’ve seen some complaints in release thread. It’s probably best to test it yourself and see if it works for you.
Hello,
OpenVPN UDP works like a charm on 7.1.1, I didn’t check the TCP.
Seems like its either TCP or UDP but not both.
Correct But why you wanna use TCP? TCP Is too damn slow in my country maybe you dont have this problem but just saying.
When udp is in use, the connection drops about once an hour with following errors on server side
recvd P_DATA packet, dropping
Clients are Linux/Android - no matter
Correct. I never used an OVPN connection for that long before and after I did the same happened to me. What HW did you use? Was it a Virtual like CHR or x86 or an actual MT device?
I Can’t Pass this part on MT to MT OVPN. No matter how I set my certificate and CRL. I even set the same NTP but doesn’t matter.
LOG OPVN---->: : disconnected
I had issues with 7.1 and 7.1.1 and several of the rc’s since the OpenVPN UDP was made available, issue I find is that it will work and then it’ll stop passing traffic after a undetermined time, could be a two days, - could be an hour or two. it affects both Android, Linux and Windows clients in my case.
TCP is stable but slow, I think Mikrotik have some bugs to work out, probably why we havent seen a new 7.2rc yet 
Kind Regards,
Jim.
could you ever connect MT to MT?
It was CHR ROS 7.2rc1. Now I downgraded to 7.1.1 due to high cpu utilization by “management” process.
Hello everyone.
It is so, as I have been able to determine the error of 100% CPU “management” process, it persists in 7.3 beta.
Both with Open VPN udp and tcp.
This error only occurs when the OpenVPN server is activated and some connections are established.
Too bad we can’t test the new TLS 1.2 in depth.
Hopefully this post will be observed by Mikrotik and they will solve this problem.
I will be pending.
Greetings,
FM,
Hi, did you found a workaround for this?
I upgraded to 7.3rc1 today to see if this is fixed. I’ll post the results after my tests.
Regards.
Hi,
I do see a similar problem using OVPN UDP for a PTP connection between a Mikrotik hap ac3 and an hap ac2 running both on RouterOS 7.4. Occasionally the connection drops and while the client (hap ac2) still thinks it’s connected, the server (hap ac3) does not and I see the server log being polluted with the following log messages:
connection established from XXX.XXX.XXX.XXX, port: XXXXX to XXX.XXX.XXX.XXX
recvd P_DATA packet, dropping
Usually, disabling and enabling the OVPN client works, but is not very convenient.
Chris
Check the recent beta release.
http://forum.mikrotik.com/t/v7-5beta-testing-is-released/159724/1
*) ovpn - fixed encryption key renewal process which caused periodic session disconnects;
*) ovpn - improved system stability when hardware acceleration is used on ARM64 devices;
*) ovpn - moved disconnected user logging message from “debug” to “info” topic;
For the packet drop, check the Time on both sides of your tunnel. Furthermore, you should enable debugging with the OVPN client and see what is being dropped it might be a simple MTU issue.
@own3r1138
Thanks for your reply. I’ll look into this.
Chris
UPDATE: I enabled debug logging on both client and server and while the client shows nothing suspicious (client thinks it’s still connected) I see the following on the server with debug logging enabled:
recvd P_DATA packet, dropping
<XXX.XXX.XXX.XXX>: disconnected <bad packet received>
connection established from XXX.XXX.XXX.XXX, port: XXXXX to XXX.XXX.XXX.XXX
sent P_CONTROL_HARD_RESET_SERVER_V2 kid=0 sid=9fe13697d12f8793 pid=0 DATA len=0
rcvd P_DATA kid=0 sid=a363e1b6d1f748c DATA len=136
Further, MTU was already reduced before to 1300, because some services were not functioning. Any input is highly welcome and I look forward to v7.5. On a sidenote: it seems to be that my problems were introduced with v7.4, but that’s only a guess.
Chris
meanwhile wireguard is working fine fine fine
client shows nothing suspicious
You should use the OVPN legacy client v 2.5.7 Also, You should use “verb” in your config file with a value greater than 5. In recent versions verb option is shown as an unused option I don’t know why.
That was a great hint. I wasn’t aware of wireguard, but it seemed promising and I just set it up and replaced OpenVPN. Works flawlessly and is significantly faster than OpenVPN. Thanks!
Thanks again for your help, highly appreciated. I switched to wireguard now and don’t have any more resources for testing. Can you (for future reference) specify, what you mean by legacy client (Is there a second “hidden” client available on RouterOS?).