Hello,
I found this old thread, encoutering the same issue.
But not just once. Multiple times, and a an increasing frequency lately![:evil:]( "Evil or Very Mad")
The issue is exactly as described by the author of the thread : randomly, a client OpenVPN computer trigger the issue with its newly connected tunnel. When pinging the remote OVPN server, It works for only a few seconds, then start lossing all packed permanently or for some prolonged periods of time, with very few periods when a few packed go through.
What's especially problematic is that when the issue arises, the OpenVPN's server side is impacted, for all users (currently connected or later) and must be restarted each time.
I have the feeling the occurence of this particular issue seems to increase with newer releases of OpenVPN, especially since r2.6.x / OpenSSL 3.x / TAPv9 9.2x driver.
Configuration is very straighforward : TAP mode. The issue arises in UDP or TCP, whatever the port. A port NAT rule map the port to the OVPN server. They can be physical server (most of my user case, Windows Server 2016 to 2022) or Hyper-V virtual instances on a basic vSwitch connected to a NIC.
No compression enabled, default parameters.
I don't have a big cohort enough of computers triggering this issue to draw any conclusions, but the user computers are all are quite aged :
- A Lenovo Yoga 730-13iwl with a Core i5-8265u. Was used with Windows 10 Pro then 11 Pro (still in use w/ 24H2), with multiple OVPN Releases. Has always triggered the issue.
- An Asus P1410, Core i3-8130u, Windows 10 Pro 22H2
- A HP Zbook 15 G2 , Core i7-4810HQ, W10 Pro 22H2
Can't remind having a AMD's CPU-based computer triggering the issue so far, but I have very few in use.
Seems to me OpenVPN (or OpenSSL 3.x / TAPv9.x driver) for Windows seems broken, under circumstancies.
At this point, I'm wondering if code optimization / SIMD / AES-SHA hardware acceleration might be broken with older Core Gen CPU.
I'm planning to replace some of the Windows OpenVPN server's instances with appliances running PfSense CE for firewalling and OpenVPN service, hoping it will at least prevent the nasty issue occuring server-side process and impacting the whole service every time.
I found this old thread, encoutering the same issue.
But not just once. Multiple times, and a an increasing frequency lately
The issue is exactly as described by the author of the thread : randomly, a client OpenVPN computer trigger the issue with its newly connected tunnel. When pinging the remote OVPN server, It works for only a few seconds, then start lossing all packed permanently or for some prolonged periods of time, with very few periods when a few packed go through.
What's especially problematic is that when the issue arises, the OpenVPN's server side is impacted, for all users (currently connected or later) and must be restarted each time.
I have the feeling the occurence of this particular issue seems to increase with newer releases of OpenVPN, especially since r2.6.x / OpenSSL 3.x / TAPv9 9.2x driver.
Configuration is very straighforward : TAP mode. The issue arises in UDP or TCP, whatever the port. A port NAT rule map the port to the OVPN server. They can be physical server (most of my user case, Windows Server 2016 to 2022) or Hyper-V virtual instances on a basic vSwitch connected to a NIC.
No compression enabled, default parameters.
I don't have a big cohort enough of computers triggering this issue to draw any conclusions, but the user computers are all are quite aged :
- A Lenovo Yoga 730-13iwl with a Core i5-8265u. Was used with Windows 10 Pro then 11 Pro (still in use w/ 24H2), with multiple OVPN Releases. Has always triggered the issue.
- An Asus P1410, Core i3-8130u, Windows 10 Pro 22H2
- A HP Zbook 15 G2 , Core i7-4810HQ, W10 Pro 22H2
Can't remind having a AMD's CPU-based computer triggering the issue so far, but I have very few in use.
Seems to me OpenVPN (or OpenSSL 3.x / TAPv9.x driver) for Windows seems broken, under circumstancies.
At this point, I'm wondering if code optimization / SIMD / AES-SHA hardware acceleration might be broken with older Core Gen CPU.
I'm planning to replace some of the Windows OpenVPN server's instances with appliances running PfSense CE for firewalling and OpenVPN service, hoping it will at least prevent the nasty issue occuring server-side process and impacting the whole service every time.
Statistics: Posted by Felger — Fri Jan 24, 2025 9:49 pm