__group__ ticket summary component version milestone type owner status created _changetime _description _reporter Active Tickets 1416 BSOD on Windows 10 with OpenVPN 2.5.x Generic / unclassified OpenVPN 2.5.1 (Community Ed) Bug / Defect reopened 2021-06-30T06:44:07Z 2022-12-07T18:00:04Z "In OpenVPN 2.5.3 (but also reproducible in OpenVPN 2.5.1) we experienced this BSOD on Windows 10 when connection to server is attempted. This has been reported by ProtonVPN users. I attach sample of OpenVPN connection being used, and minidump. " kaplun Active Tickets 543 Packets are sent in wrong order via TCP breaking HMAC verificytion Networking OpenVPN 2.3.6 (Community Ed) Bug / Defect new 2015-04-11T13:16:11Z 2023-01-01T09:53:37Z "When negotiating the connection, the client sends packets in this order: 15, 17, 16, 17, 18 Without tls_auth the server just warns with ""ACK 17 is a replay: [18]"" but else it goes unnoticed, but with tls_auth it will lead to: ""Authenticate/Decrypt packet error: packet HMAC authentication failed"" Detailed client logs can be found here: http://pastebin.com/6xJqBANk This happens under high latency SAT Link with tls_auth and TCP More details, including configs can be found here: http://pastebin.com/7m7vkKnN This bug exists at least since 2.0.9 Currently what I think happens is, that after getting two ACKS in a row, he jumps over packet 16 and sends 17 early. Then he recalculates the next packet and ends up with 16 and is back in order again. Since the ACK of 17 is comeing late, 17 is being sent twice even. Partial log: {{{ Apr 11 12:14:24 client openvpn[10121]: TCPv4_CLIENT WRITE [114] to [AF_INET]xxx.xxx.xxx.xxx:yyyy: P_CONTROL_V1 kid=0 [ ] pid=15 DATA len=100 Apr 11 12:14:24 client openvpn[10121]: ACK reliable_can_send active=4 current=0 : [16] 14 15 12 13 Apr 11 12:14:24 client openvpn[10121]: ACK output sequence broken: [16] 14 15 12 13 ... Apr 11 12:14:25 client openvpn[10121]: TCPv4_CLIENT READ [22] from [AF_INET]xxx.xxx.xxx.xxx:yyyy: P_ACK_V1 kid=0 [ 12 ] ... Apr 11 12:14:25 client openvpn[10121]: ACK reliable_can_send active=3 current=1 : [16] 14 15 13 Apr 11 12:14:25 client openvpn[10121]: ACK reliable_send ID 13 (size=104 to=4) ... Apr 11 12:14:25 client openvpn[10121]: TCPv4_CLIENT READ [22] from [AF_INET]xxx.xxx.xxx.xxx:yyyy: P_ACK_V1 kid=0 [ 13 ] Apr 11 12:14:25 client openvpn[10121]: ACK received for pid 13, deleting from send buffer Apr 11 12:14:25 client openvpn[10121]: BIO read tls_read_ciphertext 100 bytes Apr 11 12:14:25 client openvpn[10121]: ACK mark active outgoing ID 16 Apr 11 12:14:25 client openvpn[10121]: BIO read tls_read_ciphertext 100 bytes Apr 11 12:14:25 client openvpn[10121]: ACK mark active outgoing ID 17 Apr 11 12:14:25 client openvpn[10121]: ACK output sequence broken: [18] 14 15 16 17 Apr 11 12:14:25 client openvpn[10121]: ACK reliable_send_timeout 0 [18] 14 15 16 17 ... Apr 11 12:14:25 client openvpn[10121]: TCPv4_CLIENT WRITE [114] to [AF_INET]xxx.xxx.xxx.xxx:yyyy: P_CONTROL_V1 kid=0 [ ] pid=17 DATA len=100 Apr 11 12:14:25 client openvpn[10121]: ACK reliable_can_send active=4 current=2 : [18] 14 15 16 17 Apr 11 12:14:25 client openvpn[10121]: ACK reliable_send ID 16 (size=104 to=3) ... Apr 11 12:14:25 client openvpn[10121]: TCPv4_CLIENT WRITE [114] to [AF_INET]xxx.xxx.xxx.xxx:yyyy: P_CONTROL_V1 kid=0 [ ] pid=16 DATA len=100 Apr 11 12:14:25 client openvpn[10121]: ACK reliable_can_send active=4 current=1 : [18] 14 15 16 17 Apr 11 12:14:25 client openvpn[10121]: ACK reliable_send ID 17 (size=104 to=4) ... Apr 11 12:14:25 client openvpn[10121]: TCPv4_CLIENT WRITE [114] to [AF_INET]xxx.xxx.xxx.xxx:yyyy: P_CONTROL_V1 kid=0 [ ] pid=17 DATA len=100 Apr 11 12:14:25 client openvpn[10121]: ACK reliable_can_send active=4 current=0 : [18] 14 15 16 17 Apr 11 12:14:25 client openvpn[10121]: ACK output sequence broken: [18] 14 15 16 17 ... Apr 11 12:14:25 client openvpn[10121]: TCPv4_CLIENT READ [22] from [AF_INET]xxx.xxx.xxx.xxx:yyyy: P_ACK_V1 kid=0 [ 14 ] ... Apr 11 12:14:25 client openvpn[10121]: TCPv4_CLIENT WRITE [114] to [AF_INET]xxx.xxx.xxx.xxx:yyyy: P_CONTROL_V1 kid=0 [ ] pid=18 DATA len=100 ... Apr 11 12:14:26 client openvpn[10121]: TCPv4_CLIENT READ [22] from [AF_INET]xxx.xxx.xxx.xxx:yyyy: P_ACK_V1 kid=0 [ 15 ] ... Apr 11 12:14:26 client openvpn[10121]: TCPv4_CLIENT WRITE [114] to [AF_INET]xxx.xxx.xxx.xxx:yyyy: P_CONTROL_V1 kid=0 [ ] pid=19 DATA len=100 ... Apr 11 12:14:26 client openvpn[10121]: TCPv4_CLIENT READ [22] from [AF_INET]xxx.xxx.xxx.xxx:yyyy: P_ACK_V1 kid=0 [ 17 ] Apr 11 12:14:26 client openvpn[10121]: ACK received for pid 17, deleting from send buffer Apr 11 12:14:26 client openvpn[10121]: ACK reliable_can_send active=3 current=0 : [20] 18 19 16 Apr 11 12:14:26 client openvpn[10121]: ACK output sequence broken: [20] 18 19 16 Apr 11 12:14:26 client openvpn[10121]: ACK reliable_send_timeout 2 [20] 18 19 16 }}} " cyslider Active Tickets 687 SIGTERM (soft) lost if followed by a SIGUSR1/SIGHUP restart during the exit-notify wait Generic / unclassified OpenVPN git master branch (Community Ed) Bug / Defect new 2016-06-05T18:57:28Z 2016-07-14T20:26:12Z "When '''--explicit-exit-notify n''' is used, a ''soft'' SIGTERM triggers exit-notify repeated n times in 1 second intervals, before the signal is really set. During this wait a SIGUSR1 or SIGHUP restart causes the SIGTERM lost. The connection just restarts. Seen on Linux and Windows. To reproduce, connect to the management interface and send {{{ signal SIGTERM signal SIGUSR1 }}} The second command maybe SIGHUP instead, and should be issued before the exit notify triggered by the SIGTERM is completed (using n=2 or larger helps). {{{ Sun Jun 5 14:42:52 2016 us=482865 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:7500 Sun Jun 5 14:42:53 2016 us=905629 MANAGEMENT: CMD 'signal SIGTERM' Sun Jun 5 14:42:53 2016 us=905710 SIGTERM received, sending exit notification to peer Sun Jun 5 14:42:54 2016 us=511249 MANAGEMENT: CMD 'signal SIGUSR1' Sun Jun 5 14:42:54 2016 us=511490 TCP/UDP: Closing socket Sun Jun 5 14:42:54 2016 us=511533 SIGUSR1[hard,] received, process restarting Sun Jun 5 14:42:54 2016 us=511559 Restart pause, 5 second(s) Sun Jun 5 14:42:59 2016 us=527109 Re-using SSL/TLS context Sun Jun 5 14:42:59 2016 us=527230 Control Channel MTU parms [ L:1557 D:1184 EF:66 EB:0 ET:0 EL:3 ] .. .. Sun Jun 5 14:43:04 2016 us=110261 Initialization Sequence Completed }}} Except for the explicit-exit-notify, the client is a vanilla tls-client: {{{ client dev tun ping 30 ping-restart 120 remote test-server 1194 resolv-retry infinite nobind persist-tun persist-key user nobody group nobody ca test-ca.crt cert test-client.crt key keys/test-client.key ns-cert-type server tls-auth keys/test-ta.key 1 cipher AES-256-CBC explicit-exit-notify 2 management localhost 7500 nice 3 verb 4 }}}" Selva Nair Active Tickets 712 connection issue with PKCS#11 support Generic / unclassified OpenVPN 2.3.11 (Community Ed) Bug / Defect reopened 2016-07-20T10:05:11Z 2016-09-22T13:40:15Z "For the Arch Linux OpenVPN package [0] I enabled PKCS#11 support recently [1]. The new package has issues connecting to servers that worked before. The issue has been reported in downstream bug tracker [2]. Note the affected connections do not use PKCS#11 at all, support has just been enabled in the package. [0] https://www.archlinux.org/packages/?name=openvpn [1] https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/openvpn&id=d45bef7c0674e760f30cca45db1fad65c9568b1e [2] https://bugs.archlinux.org/task/50090" eworm Active Tickets 744 Automatic restarting the VPN connection fails, if smartcard authentication is used Generic / unclassified OpenVPN 2.3.12 (Community Ed) Bug / Defect new 2016-09-29T19:15:41Z 2016-11-09T22:02:29Z "When OpenVPN is configured with client SSL certificates on smartcards, only the initial smartcard authentication works. After some time the server gets an ""inactivity timeout"" and forces the client to reconnect: {{{ Thu Sep 29 18:09:44 2016 voigtmail/6.7.8.9:60430 [myusername] Inactivity timeout (--ping-restart), restarting Thu Sep 29 18:53:58 2016 5.6.7.8:60430 TLS: Initial packet from [AF_INET]5.6.7.8:60430, sid=b23ecb44 b7950179 }}} With the management interface, the user enters the correct PIN for the smartcard again: {{{ >HOLD:Waiting for hold release hold release SUCCESS: hold release succeeded >PASSWORD:Need 'PIV_II (PIV Card Holder pin) token' password password 'PIV_II (PIV Card Holder pin) token' 123456 SUCCESS: 'PIV_II (PIV Card Holder pin) token' password entered, but not yet verified >HOLD:Waiting for hold release }}} But the OpenVPN client is unable to get the smartcard certificate a second time. The OpenVPN client log: {{{ Thu Sep 29 20:49:11 2016 MANAGEMENT: CMD 'hold release' Thu Sep 29 20:49:11 2016 Socket Buffers: R=[212992->212992] S=[212992->212992] Thu Sep 29 20:49:11 2016 UDPv4 link local: [undef] Thu Sep 29 20:49:11 2016 UDPv4 link remote: [AF_INET]100.1.2.3:1194 Thu Sep 29 20:49:11 2016 TLS: Initial packet from [AF_INET]176.28.8.208:1194, sid=fe884eab 3d62abcb Thu Sep 29 20:49:11 2016 CRL CHECK OK: CN=My CA Thu Sep 29 20:49:11 2016 VERIFY OK: depth=1, CN=My CA Thu Sep 29 20:49:11 2016 Validating certificate key usage Thu Sep 29 20:49:11 2016 ++ Certificate has key usage 00a0, expects 00a0 Thu Sep 29 20:49:11 2016 VERIFY KU OK Thu Sep 29 20:49:11 2016 Validating certificate extended key usage Thu Sep 29 20:49:11 2016 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication Thu Sep 29 20:49:11 2016 VERIFY EKU OK Thu Sep 29 20:49:11 2016 CRL CHECK OK: CN=www.my-domain.com Thu Sep 29 20:49:11 2016 VERIFY OK: depth=0, CN=www.my-domain.com Thu Sep 29 20:49:17 2016 MANAGEMENT: CMD 'password [...]' Thu Sep 29 20:49:17 2016 PKCS#11: Cannot perform signature 5:'CKR_GENERAL_ERROR' Thu Sep 29 20:49:17 2016 OpenSSL: error:14099006:SSL routines:ssl3_send_client_verify:EVP lib Thu Sep 29 20:49:17 2016 TLS_ERROR: BIO read tls_read_plaintext error Thu Sep 29 20:49:17 2016 TLS Error: TLS object -> incoming plaintext read error Thu Sep 29 20:49:17 2016 TLS Error: TLS handshake failed Thu Sep 29 20:49:17 2016 SIGUSR1[soft,tls-error] received, process restarting }}} The first error ""PKCS#11: Cannot perform signature 5:'CKR_GENERAL_ERROR'"" was already discussed in the OpenSC mailing list, unfortunately without results: http://opensc.1086184.n5.nabble.com/C-Login-returns-CKR-GENERAL-ERROR-SCardBeginTransaction-failed-0x8010001d-td15288.html The OpenVPN server shows this in the logs: {{{ Thu Sep 29 18:54:58 2016 5.6.7.8:60430 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Thu Sep 29 18:54:58 2016 5.6.7.8:60430 TLS Error: TLS handshake failed Thu Sep 29 18:54:58 2016 5.6.7.8:60430 SIGUSR1[soft,tls-error] received, client-instance restarting Thu Sep 29 20:47:11 2016 5.6.7.8:56393 TLS: Initial packet from [AF_INET]5.6.7.8:56393, sid=39e1ac75 5fb99acd Thu Sep 29 20:47:51 2016 5.6.7.8:43099 TLS: Initial packet from [AF_INET]5.6.7.8:43099, sid=38c31726 86110326 Thu Sep 29 20:48:11 2016 5.6.7.8:56393 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Thu Sep 29 20:48:11 2016 5.6.7.8:56393 TLS Error: TLS handshake failed Thu Sep 29 20:48:11 2016 5.6.7.8:56393 SIGUSR1[soft,tls-error] received, client-instance restarting Thu Sep 29 20:48:51 2016 5.6.7.8:43099 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Thu Sep 29 20:48:51 2016 5.6.7.8:43099 TLS Error: TLS handshake failed Thu Sep 29 20:48:51 2016 5.6.7.8:43099 SIGUSR1[soft,tls-error] received, client-instance restarting Thu Sep 29 20:49:11 2016 5.6.7.8:38836 TLS: Initial packet from [AF_INET]5.6.7.8:38836, sid=246bffc5 ed13edad Thu Sep 29 20:50:11 2016 5.6.7.8:38836 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Thu Sep 29 20:50:11 2016 5.6.7.8:38836 TLS Error: TLS handshake failed Thu Sep 29 20:50:11 2016 5.6.7.8:38836 SIGUSR1[soft,tls-error] received, client-instance restarting }}} The failure can be resolved with restarting the OpenVPN client. Of course, also the smartcard certificates can be replaced with software certificates. My setup: * OpenVPN 2.3.12 * OpenVPN Server: Ubuntu 14.04, IP 100.1.2.3 (changed) * OpenVPN Client: openSUSE Tumbleweed 20160926, IP 5.6.7.8 (changed) * OpenSC 0.16 * PKCS11 Helper 1.11 * Authentication with 2048 Bit EasyRSA certificates (both client and server; server: software certificate; client: certificate on the Yubikey 4) * Smartcard: Yubikey 4 in PIV mode" Bjoern Voigt Active Tickets 837 "HKCU\Software\OpenVPN-GUI is deleted if ""version"" key is missing" Windows GUI OpenVPN 2.4.0 (Community Ed) Bug / Defect new 2017-02-01T16:08:32Z 2017-02-20T14:40:59Z "I upgraded from version 2.3.13 to 2.4 and wondered about the new defaults for user specific configuration files and such. My former system wide defaults where not used anymore. So after debugging this with Process Monitor and recognizing that HKCU seems to be queried only, I cleaned the HKCU part and imported my HLKM settings there. The new ""version"" key introduced with #252 was missing in that case, because it was new and I cleaned the former settings to get rid of maybe wrong ones, and on every restart of the GUI the app deleted the whole HKCU\Software\OpenVPN-GUI. The only error message on gets is that there's no configurations found because of the used default values in such case. This looks like a somewhat unexpected behaviour to me. If you think that a missing version key is so important to delete whatever is in place currently, I would expect a detailed error message telling me so. Without such message I could only wonder about the missing settings until I noticed that behaviour in Process Monitor again. I would like to suggest considering not deleting at all. If you find a missing version key, simply add one and whatever keys are needed for the particular version and live with everything else. You can't forbid the user to add any kind of garbage at any time anyway." tschoening Active Tickets 838 Don't ignore HKEY_LOCAL_MACHINE\SOFTWARE\OpenVPN-GUI. Windows GUI OpenVPN 2.4.0 (Community Ed) Bug / Defect new 2017-02-01T16:36:38Z 2017-02-20T13:55:26Z "I upgraded from version 2.3.13 to 2.4 and wondered about the new defaults for user specific configuration files and such. My former system wide defaults where not used anymore, so I used Process Monitor to see what happens... It seems that the former HKLM-settings are completely ignored now? Is there any reason for that or something like a migration guide documenting that? I already manually adopted the former HKLM settings to be able to work without any admin permissions for all users of a system and that worked perfectly well. The only thing I needed to do was to copy my config_dir and log_dir to HKCU, with exactly the same values as before, but I couldn't find where this is documented. Additionally, reading from HKLM as a fallback always made sense to me for environments in which multiple users user the GUI and shoudl all store their logs and configs in the same dir structure. This can easily be done by using %APPDATA% int he registry: > ""config_dir""=""%APPDATA%\\OpenVPN\\config"" > ""log_dir""=""%APPDATA%\\OpenVPN\\log"" So, I suggest to either write some migration guide or keep reading from HKLM as a fallback. This is in reference to #837: https://community.openvpn.net/openvpn/ticket/837" tschoening Active Tickets 839 Inconsistencies about OpenVPNServiceInteractive Windows GUI OpenVPN 2.4.0 (Community Ed) Bug / Defect new 2017-02-01T17:16:29Z 2017-02-20T18:39:02Z "If OpenVPNServiceInteractive is not started, the GUI provides an error message telling a user so, even though the service is not needed in some cases at all. If e.g. a user doesn't use connections which push additional routes, the GUI warns about the not running service, but it is able to successfully create the connection and that connection works. If the user tries to start a connection which in theory pushes additional routes, establishing that connections seems to fail ultimately. The problem is that, it worked in former version of OpenVPN: Without this service you logged that you can't add routes because of ERROR_ACCESS_DENIED, but simply continued successfully and called e.g. an up-script in which I could create a needed route manually. Those connections are not working anymore without running the interactive service, I needed to downgrade to 2.3.14 and the connections workes as expected again. If OpenVPNServiceInteractive is running instead, I'm forced to add my current user to a special group before I'm able to use any connection, even those which has been successfully started without the service running before and even though in former versions without such service I was allowed to start my user defined connections as well without any admin privileges or special group membership. That doesn't make sense to me. While I appreciate your affords regarding the interactive service for adding routes and such for the default user, because it surely makes life easier for those, I don't see why it's a good thing to break with the former working behaviour if the service is not available for some reason. Just log your error message like you have done before and keep going. I would even reconsider the warning message about the not running service, because in default installations it will be running and if things don't work people will notice error messages in the log and such. Your current behaviour is making life worse for people like me, which stop your service for some reason: I don't want your service to add arbitrary routes pushed by an arbitrary OpenVPN server to my local network. I have some up/down-Scripts managing routes of connections manually by purpose, because of overlapping networks and various other problems. In such cases I simply benefit of OpenVPN not being able to apply pushed routes automatically, have a place to document which routes make problems to me and which do I need. Those scripts are using ""runas"" and simply work. I know this is not for the general user, but your former behaviour worked very well for me and that and the new service are perfectly compatible as I see it. You just need to make sure that in case of a not running service your behaviour is the same as before, especially just continue to establish a connection like you did in former versions. The average user won't stop that service, but if I do to get the old behaviour back, I think this should work. Thanks! P.S.: The attached screenshot is one connection which pushes routes and did work without the service and without admin privileges before. The bottom error message didn't occur, but instead the up-script was executed." tschoening Active Tickets 841 Tap-windows fails with Error = 0xe0000246 - tap-windows OpenVPN 2.4.0 (Community Ed) Bug / Defect new 2017-02-07T15:55:48Z 2017-02-07T15:55:48Z "Hi all! I' like to report problem with adding tap interface at Windows 10 Home x64 PC (1607 v. 10.0.14393 build 14393.693 , sys model UX305UAB). System has 2 months and it is the first, preinstalled OS. No Kasperski or VMware instlled. I was using: * openvpn 2.4 instalation pack: https://swupdate.openvpn.org/community/releases/openvpn-install-2.4.0-I602.exe * later tap-windows separate installer: https://swupdate.openvpn.org/community/releases/tap-windows-9.21.2.exe The effect is that: * Tap-windows instalator during installation shows error with adding tap interface. * tap-windows installation files are in place, * driver is loaded into DriverStore * Device Manager sees new interface under Netwok Cards but it is ""Unknown Device"" * There is no Registry Entry for the interface under {{{ HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318} }}} * Updating legacy driver with Device Manager shows immediate error that i can't be dane at this time * setapapi.dev.log shows error (log added at the end of the message): {{{ !!! Failed to install device instance 'ROOT\NET\0000'. Error = 0xe0000246 }}} What I've tried already: * instructions under https://community.openvpn.net/openvpn/wiki/ManagingWindowsTAPDrivers#Debugginginstallationproblems (BTW one of the links doesn't work: https://forums.openvpn.net/post35811.html#p35811) * deleting user temp files, * clearing driver in DataStore with pnputils.exe -d * disabling Avast antyvirus, * installing in Safe mode, * Activating Administrator account and installing using this account, * Stoping Windows Update service Checked hemry's problem with the same error: * Ticket [ticket:592] https://community.openvpn.net/openvpn/ticket/592 * https://forums.openvpn.net/viewtopic.php?t=22888 Microsoft manual at https://technet.microsoft.com/en-us/library/cc756336(v=ws.10).aspx sais: {{{ 3758096966 (0xE0000246) Device Installer Not Ready Cause A class installer or a co-installer for a device cannot run because a component on which it depends did not run. Solution If you have not modified the device driver package yourself, contact the manufacturer of the device or the driver package to obtain an updated driver package. If you customized the device driver package for your deployment, see the Windows Driver Kit at http://go.microsoft.com/fwlink/?LinkId=59546 on the Microsoft Web site. }}} And now trying for a few day's with no result. I'm out of ideas where to go next. Please help. My setupapi.dev.log: {{{ >>> [Device Install (UpdateDriverForPlugAndPlayDevices) - tap0901] >>> Section start 2017/02/05 10:07:32.948 cmd: ""D:\Program files\TAP-adapter\bin\tapinstall.exe"" install ""D:\Program files\TAP-adapter\driver\OemVista.inf"" tap0901 ndv: INF path: D:\Program files\TAP-adapter\driver\OemVista.inf ndv: Install flags: 0x00000001 ndv: {Update Device Driver - ROOT\NET\0000} ndv: Search options: 0x00000080 ndv: Searching single INF 'D:\Program files\TAP-adapter\driver\OemVista.inf' dvi: {Build Driver List} 10:07:32.964 dvi: Searching for hardware ID(s): dvi: tap0901 sig: {_VERIFY_FILE_SIGNATURE} 10:07:32.964 sig: Key = oemvista.inf sig: FilePath = d:\program files\tap-adapter\driver\oemvista.inf sig: Catalog = d:\program files\tap-adapter\driver\tap0901.cat ! sig: Verifying file against specific (valid) catalog failed! (0x800b0109) sig: {_VERIFY_FILE_SIGNATURE exit(0x800b0109)} 10:07:33.011 sig: {_VERIFY_FILE_SIGNATURE} 10:07:33.026 sig: Key = oemvista.inf sig: FilePath = d:\program files\tap-adapter\driver\oemvista.inf sig: Catalog = d:\program files\tap-adapter\driver\tap0901.cat sig: Success: File is signed in Authenticode(tm) catalog. sig: {_VERIFY_FILE_SIGNATURE exit(0xe0000241)} 10:07:33.042 dvi: Created Driver Node: dvi: HardwareID - tap0901 dvi: InfName - d:\program files\tap-adapter\driver\oemvista.inf dvi: DevDesc - TAP-Windows Adapter V9 dvi: Section - tap0901.ndi dvi: Rank - 0x00ff0000 dvi: Signer Score - Authenticode dvi: DrvDate - 04/21/2016 dvi: Version - 9.0.0.21 dvi: {Build Driver List - exit(0x00000000)} 10:07:33.058 dvi: {DIF_SELECTBESTCOMPATDRV} 10:07:33.058 dvi: Default installer: Enter 10:07:33.058 dvi: {Select Best Driver} dvi: Class GUID of device changed to: {4d36e972-e325-11ce-bfc1-08002be10318}. dvi: Selected: dvi: Description - [TAP-Windows Adapter V9] dvi: InfFile - [d:\program files\tap-adapter\driver\oemvista.inf] dvi: Section - [tap0901.ndi] dvi: {Select Best Driver - exit(0x00000000)} dvi: Default installer: Exit dvi: {DIF_SELECTBESTCOMPATDRV - exit(0x00000000)} 10:07:33.058 ndv: Forcing driver install: ndv: Inf Name - oemvista.inf ndv: Driver Date - 04/21/2016 ndv: Driver Version - 9.0.0.21 sto: {Setup Import Driver Package: d:\program files\tap-adapter\driver\oemvista.inf} 10:07:33.058 inf: Provider: TAP-Windows Provider V9 inf: Class GUID: {4d36e972-e325-11ce-bfc1-08002be10318} inf: Driver Version: 04/21/2016,9.00.00.21 inf: Catalog File: tap0901.cat sto: {Copy Driver Package: d:\program files\tap-adapter\driver\oemvista.inf} 10:07:33.073 sto: Driver Package = d:\program files\tap-adapter\driver\oemvista.inf sto: Flags = 0x00000007 sto: Destination = C:\Users\ADMINI~1\AppData\Local\Temp\{4b12c8c7-09d1-ea44-9aeb-aee7ed3d2ba9} sto: Copying driver package files to 'C:\Users\ADMINI~1\AppData\Local\Temp\{4b12c8c7-09d1-ea44-9aeb-aee7ed3d2ba9}'. flq: Copying 'd:\program files\tap-adapter\driver\oemvista.inf' to 'C:\Users\ADMINI~1\AppData\Local\Temp\{4b12c8c7-09d1-ea44-9aeb-aee7ed3d2ba9}\oemvista.inf'. flq: Copying 'd:\program files\tap-adapter\driver\tap0901.cat' to 'C:\Users\ADMINI~1\AppData\Local\Temp\{4b12c8c7-09d1-ea44-9aeb-aee7ed3d2ba9}\tap0901.cat'. flq: Copying 'd:\program files\tap-adapter\driver\tap0901.sys' to 'C:\Users\ADMINI~1\AppData\Local\Temp\{4b12c8c7-09d1-ea44-9aeb-aee7ed3d2ba9}\tap0901.sys'. sto: {Copy Driver Package: exit(0x00000000)} 10:07:33.105 pol: {Driver package policy check} 10:07:33.120 pol: {Driver package policy check - exit(0x00000000)} 10:07:33.120 sto: {Stage Driver Package: C:\Users\ADMINI~1\AppData\Local\Temp\{4b12c8c7-09d1-ea44-9aeb-aee7ed3d2ba9}\oemvista.inf} 10:07:33.120 inf: {Query Configurability: C:\Users\ADMINI~1\AppData\Local\Temp\{4b12c8c7-09d1-ea44-9aeb-aee7ed3d2ba9}\oemvista.inf} 10:07:33.120 inf: Driver package 'oemvista.inf' is configurable. inf: {Query Configurability: exit(0x00000000)} 10:07:33.120 flq: Copying 'C:\Users\ADMINI~1\AppData\Local\Temp\{4b12c8c7-09d1-ea44-9aeb-aee7ed3d2ba9}\oemvista.inf' to 'C:\WINDOWS\System32\DriverStore\Temp\{6a06f428-c305-1948-ac2a-e837b4dec385}\oemvista.inf'. flq: Copying 'C:\Users\ADMINI~1\AppData\Local\Temp\{4b12c8c7-09d1-ea44-9aeb-aee7ed3d2ba9}\tap0901.cat' to 'C:\WINDOWS\System32\DriverStore\Temp\{6a06f428-c305-1948-ac2a-e837b4dec385}\tap0901.cat'. flq: Copying 'C:\Users\ADMINI~1\AppData\Local\Temp\{4b12c8c7-09d1-ea44-9aeb-aee7ed3d2ba9}\tap0901.sys' to 'C:\WINDOWS\System32\DriverStore\Temp\{6a06f428-c305-1948-ac2a-e837b4dec385}\tap0901.sys'. sto: {DRIVERSTORE IMPORT VALIDATE} 10:07:33.167 sig: {_VERIFY_FILE_SIGNATURE} 10:07:33.183 sig: Key = oemvista.inf sig: FilePath = C:\WINDOWS\System32\DriverStore\Temp\{6a06f428-c305-1948-ac2a-e837b4dec385}\oemvista.inf sig: Catalog = C:\WINDOWS\System32\DriverStore\Temp\{6a06f428-c305-1948-ac2a-e837b4dec385}\tap0901.cat ! sig: Verifying file against specific (valid) catalog failed! (0x800b0109) sig: {_VERIFY_FILE_SIGNATURE exit(0x800b0109)} 10:07:33.214 sig: {_VERIFY_FILE_SIGNATURE} 10:07:33.214 sig: Key = oemvista.inf sig: FilePath = C:\WINDOWS\System32\DriverStore\Temp\{6a06f428-c305-1948-ac2a-e837b4dec385}\oemvista.inf sig: Catalog = C:\WINDOWS\System32\DriverStore\Temp\{6a06f428-c305-1948-ac2a-e837b4dec385}\tap0901.cat sig: Success: File is signed in Authenticode(tm) catalog. sig: {_VERIFY_FILE_SIGNATURE exit(0xe0000241)} 10:07:33.245 sto: {DRIVERSTORE IMPORT VALIDATE: exit(0x00000000)} 10:07:33.245 sig: Signer Score = 0x0F000000 sig: Signer Name = OpenVPN Technologies, Inc. sto: {DRIVERSTORE IMPORT BEGIN} 10:07:33.245 sto: {DRIVERSTORE IMPORT BEGIN: exit(0x00000000)} 10:07:33.245 cpy: {Copy Directory: C:\WINDOWS\System32\DriverStore\Temp\{6a06f428-c305-1948-ac2a-e837b4dec385}} 10:07:33.245 cpy: Target Path = C:\WINDOWS\System32\DriverStore\FileRepository\oemvista.inf_amd64_a572b7f20c402d28 cpy: {Copy Directory: exit(0x00000000)} 10:07:33.261 idb: {Register Driver Package: C:\WINDOWS\System32\DriverStore\FileRepository\oemvista.inf_amd64_a572b7f20c402d28\oemvista.inf} 10:07:33.261 idb: Created driver package object 'oemvista.inf_amd64_a572b7f20c402d28' in DRIVERS database node. idb: Created driver INF file object 'oem8.inf' in DRIVERS database node. idb: Registered driver package 'oemvista.inf_amd64_a572b7f20c402d28' with 'oem8.inf'. idb: {Register Driver Package: exit(0x00000000)} 10:07:33.261 idb: {Publish Driver Package: C:\WINDOWS\System32\DriverStore\FileRepository\oemvista.inf_amd64_a572b7f20c402d28\oemvista.inf} 10:07:33.261 idb: Activating driver package 'oemvista.inf_amd64_a572b7f20c402d28'. cpy: Published 'oemvista.inf_amd64_a572b7f20c402d28\oemvista.inf' to 'oem8.inf'. idb: Indexed 3 device IDs for 'oemvista.inf_amd64_a572b7f20c402d28'. sto: Flushed driver database node 'DRIVERS'. Time = 0 ms sto: Flushed driver database node 'SYSTEM'. Time = 0 ms idb: {Publish Driver Package: exit(0x00000000)} 10:07:33.277 sto: {DRIVERSTORE IMPORT END} 10:07:33.292 dvi: Flushed all driver package files to disk. Time = 0 ms sig: Installed catalog 'tap0901.cat' as 'oem8.cat'. sto: {DRIVERSTORE IMPORT END: exit(0x00000000)} 10:07:33.308 sto: {Stage Driver Package: exit(0x00000000)} 10:07:33.308 sto: {Setup Import Driver Package - exit (0x00000000)} 10:07:33.323 dvi: Searching for hardware ID(s): dvi: tap0901 dvi: Class GUID of device changed to: {4d36e972-e325-11ce-bfc1-08002be10318}. ump: Installation will be processed asynchronously !!! ndv: Device install failed for device. ndv: Installing NULL driver. ump: Installation will be processed asynchronously ndv: {Update Device Driver - exit(e0000246)} !!! ndv: Failed to install device instance 'ROOT\NET\0000'. Error = 0xe0000246 <<< Section end 2017/02/05 10:07:33.323 <<< [Exit status: FAILURE(0xe0000246)] }}} " przemyslaw.przytula Active Tickets 843 "Incorrect warning message when dropping packets because of ""Recursive routing detected""" Generic / unclassified OpenVPN 2.4.0 (Community Ed) Bug / Defect new 2017-02-14T13:06:33Z 2018-04-04T16:10:58Z "When recursive routing is detected a packet is dropped and the following error message is printed: {{{drop tun packet to [AF_INET]212.83.177.138:443}}} Here port 443 is not actually read from the packet, it is simply assumed that the destination port of the packet is the same as the one of the VPN server, but that this is not necessarily the case as I verified with tcpdump. A possible explanation of how this is possible is here: https://forums.openvpn.net/viewtopic.php?f=4&p=67980#p67980 By the way, if this gets fixed, it would be nice to have as much info as possible on the packet in the error message." archimede.pitagorico Active Tickets 855 openvpn should check that there's a working TAP before even attempting to create a tunnel Generic / unclassified OpenVPN 2.3.9 (Community Ed) Bug / Defect new 2017-03-10T21:58:22Z 2017-03-13T08:36:41Z "Hi there We've been having problems with running openvpn as a service. Under some still unknown circumstances (I suspect Cisco Anyconnect is involved), a working openvpn Windows install will suddenly find itself with a disabled TAP interface. What seems to happen is openvpn negotiates the tunnel successfully, and at the last moment starts interacting with the TAP interface - and fails. It then goes into a retry infinite loop (not sure if that's openvpn or the service manager we're using, but I *want* openvpn to auto-retry - except in this situation!). The problem is the valid client is looping and this causes a large load on the server - due to the vast range of scripts we call on ""--up"". This nails the server - which nails all other happy clients So my point is that I don't see why openvpn needs to let this happen. Couldn't openvpn be re-coded to check that there's a working TAP interface before even attempting to negotiate? ie if the TAP is disabled, then openvpn should just exit - it's never going to work - so why bother trying. I don't care if that leads to a load problem on the client - I just want to get the load off the server :-) Thanks Jason " jhaar Active Tickets 856 "Missing port in ""status 2"" management in ""Real Address"" field (under ipv6 config)" IPv6 OpenVPN 2.4.0 (Community Ed) Bug / Defect new 2017-03-15T14:21:52Z 2017-03-15T14:21:52Z "If i request 'status 2' in management interface within a both ipv4/ipv6 server, the port in ""Real Address"" field is missing. {{{ HEADER,CLIENT_LIST,Common Name,Real Address,Virtual Address,Virtual IPv6 Address,Bytes Received,Bytes Sent,Connected Since,Connected Since (time_t),Username,Client ID,Peer ID CLIENT_LIST,mycommonname,81.201.180.117,10.6.0.3,fde6:7a:7d20:1::1001,668169,1731037,Fri Mar 10 11:38:04 2017,1489145884,UNDEF,39,0 }}} The same version of OpenVPN 2.4.0, on the same machine, with a config ipv4 only, dump the ""ipv4address:port"" in ""Real Address"" field (like any previous OpenVPN version). For this reason for me it's a ""Bug / Defect"". In the function ""mroute_addr_print_ex"" in \src\openvpn\mroute.c the flag MR_WITH_PORT is not even contemplated in MR_ADDR_IPV6 case switch. Port is also missing in ipv6 section of ""struct mroute_addr"" in \src\openvpn\mroute.h The recommended format is [ipv6]:port, the same format used by ip6tables in dnat ipv6 port forwarding. " Clodo Active Tickets 857 Connection attempt from Windows client causes server computer network lockup for SSH connections. Generic / unclassified OpenVPN 2.3.4 (Community Ed) Bug / Defect new 2017-03-22T05:08:48Z 2017-03-22T23:36:57Z "Hello, I will attach configuration files. There may be some misconfiguration on my part, however, while attempting to connect to the server from Windows the virtual machine the server is running on fails to service open SSH connections and does not open new ones. Running `ping` in the background keeps the connection usable, as well as attempting to connect via secure shell (though the connections do not appear to complete). This may affect other protocols." R0b0t1 Active Tickets 878 Route: Waiting for TUN/TAP interface to come up... Generic / unclassified OpenVPN 2.4.0 (Community Ed) Bug / Defect new 2017-04-28T08:51:08Z 2017-12-01T13:51:19Z "My user is getting the dreaded ""Waiting for TUN/TAP interface to come up..."" message. What can he do? {{{ Fri Apr 28 08:34:53 2017 OpenVPN 2.4.1 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Mar 22 2017 Fri Apr 28 08:34:53 2017 Windows version 6.1 (Windows 7) 64bit Fri Apr 28 08:34:53 2017 library versions: OpenSSL 1.0.2k 26 Jan 2017, LZO 2.09 Enter Management Password: Fri Apr 28 08:34:53 2017 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340 Fri Apr 28 08:34:53 2017 Need hold release from management interface, waiting... Fri Apr 28 08:34:54 2017 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340 Fri Apr 28 08:34:54 2017 MANAGEMENT: CMD 'state on' Fri Apr 28 08:34:54 2017 MANAGEMENT: CMD 'log all on' Fri Apr 28 08:34:54 2017 MANAGEMENT: CMD 'echo all on' Fri Apr 28 08:34:54 2017 MANAGEMENT: CMD 'hold off' Fri Apr 28 08:34:54 2017 MANAGEMENT: CMD 'hold release' Fri Apr 28 08:34:55 2017 MANAGEMENT: CMD 'username ""Auth"" ""martmuel""' Fri Apr 28 08:34:55 2017 MANAGEMENT: CMD 'password [...]' Fri Apr 28 08:34:55 2017 WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead. Fri Apr 28 08:34:55 2017 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication Fri Apr 28 08:34:55 2017 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication Fri Apr 28 08:34:55 2017 MANAGEMENT: >STATE:1493361295,RESOLVE,,,,,, Fri Apr 28 08:34:55 2017 TCP/UDP: Preserving recently used remote address: [AF_INET]193.175.73.200:1194 Fri Apr 28 08:34:55 2017 Socket Buffers: R=[8192->8192] S=[8192->8192] Fri Apr 28 08:34:55 2017 UDP link local: (not bound) Fri Apr 28 08:34:55 2017 UDP link remote: [AF_INET]193.175.73.200:1194 Fri Apr 28 08:34:55 2017 MANAGEMENT: >STATE:1493361295,WAIT,,,,,, Fri Apr 28 08:34:55 2017 MANAGEMENT: >STATE:1493361295,AUTH,,,,,, Fri Apr 28 08:34:55 2017 TLS: Initial packet from [AF_INET]193.175.73.200:1194, sid=d14a10e8 fbef2ede Fri Apr 28 08:34:55 2017 VERIFY OK: depth=1, C=DE, ST=Berlin, L=Berlin, O=Charite-VPN, OU=GB-IT, CN=Charite-VPN CA, name=EasyRSA, emailAddress=vpn@charite.de Fri Apr 28 08:34:55 2017 VERIFY OK: nsCertType=SERVER Fri Apr 28 08:34:55 2017 Validating certificate extended key usage Fri Apr 28 08:34:55 2017 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication Fri Apr 28 08:34:55 2017 VERIFY EKU OK Fri Apr 28 08:34:55 2017 VERIFY X509NAME OK: C=DE, ST=Berlin, L=Berlin, O=Charite-VPN, OU=GB-IT, CN=openvpn.charite.de, emailAddress=vpn@charite.de Fri Apr 28 08:34:55 2017 VERIFY OK: depth=0, C=DE, ST=Berlin, L=Berlin, O=Charite-VPN, OU=GB-IT, CN=openvpn.charite.de, emailAddress=vpn@charite.de Fri Apr 28 08:34:55 2017 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA Fri Apr 28 08:34:55 2017 [openvpn.charite.de] Peer Connection Initiated with [AF_INET]193.175.73.200:1194 Fri Apr 28 08:34:56 2017 MANAGEMENT: >STATE:1493361296,GET_CONFIG,,,,,, Fri Apr 28 08:34:56 2017 SENT CONTROL [openvpn.charite.de]: 'PUSH_REQUEST' (status=1) Fri Apr 28 08:34:56 2017 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 141.42.1.1,dhcp-option DOMAIN charite.de,register-dns,block-outside-dns,sndbuf 393216,rcvbuf 393216,route-gateway 172.29.0.1,topology subnet,ping 10,ping-restart 30,redirect-gateway def1,ifconfig 172.29.5.78 255.255.192.0,peer-id 6,cipher AES-256-GCM' Fri Apr 28 08:34:56 2017 OPTIONS IMPORT: timers and/or timeouts modified Fri Apr 28 08:34:56 2017 OPTIONS IMPORT: --sndbuf/--rcvbuf options modified Fri Apr 28 08:34:56 2017 Socket Buffers: R=[8192->393216] S=[8192->393216] Fri Apr 28 08:34:56 2017 OPTIONS IMPORT: --ifconfig/up options modified Fri Apr 28 08:34:56 2017 OPTIONS IMPORT: route options modified Fri Apr 28 08:34:56 2017 OPTIONS IMPORT: route-related options modified Fri Apr 28 08:34:56 2017 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified Fri Apr 28 08:34:56 2017 OPTIONS IMPORT: peer-id set Fri Apr 28 08:34:56 2017 OPTIONS IMPORT: adjusting link_mtu to 1625 Fri Apr 28 08:34:56 2017 OPTIONS IMPORT: data channel crypto options modified Fri Apr 28 08:34:56 2017 Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key Fri Apr 28 08:34:56 2017 Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key Fri Apr 28 08:34:56 2017 interactive service msg_channel=0 Fri Apr 28 08:34:56 2017 ROUTE_GATEWAY 10.31.32.1/255.255.240.0 I=12 HWADDR=24:77:03:6c:d7:28 Fri Apr 28 08:34:56 2017 open_tun Fri Apr 28 08:34:56 2017 TAP-WIN32 device [LAN-Verbindung 2] opened: \\.\Global\{995E69E0-5281-4004-8833-3F3E4AFF6335}.tap Fri Apr 28 08:34:56 2017 TAP-Windows Driver Version 9.21 Fri Apr 28 08:34:56 2017 Set TAP-Windows TUN subnet mode network/local/netmask = 172.29.0.0/172.29.5.78/255.255.192.0 [SUCCEEDED] Fri Apr 28 08:34:56 2017 Notified TAP-Windows driver to set a DHCP IP/netmask of 172.29.5.78/255.255.192.0 on interface {995E69E0-5281-4004-8833-3F3E4AFF6335} [DHCP-serv: 172.29.63.254, lease-time: 31536000] Fri Apr 28 08:34:56 2017 Successful ARP Flush on interface [16] {995E69E0-5281-4004-8833-3F3E4AFF6335} Fri Apr 28 08:34:56 2017 do_ifconfig, tt->did_ifconfig_ipv6_setup=0 Fri Apr 28 08:34:56 2017 MANAGEMENT: >STATE:1493361296,ASSIGN_IP,,172.29.5.78,,,, Fri Apr 28 08:34:56 2017 Block_DNS: WFP engine opened Fri Apr 28 08:34:56 2017 Block_DNS: Using existing sublayer Fri Apr 28 08:34:56 2017 Block_DNS: Added permit filters for exe_path Fri Apr 28 08:34:56 2017 Block_DNS: Added block filters for all interfaces Fri Apr 28 08:34:56 2017 Block_DNS: Added permit filters for TAP interface Fri Apr 28 08:35:01 2017 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down Fri Apr 28 08:35:01 2017 Route: Waiting for TUN/TAP interface to come up... Fri Apr 28 08:35:07 2017 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down Fri Apr 28 08:35:07 2017 Route: Waiting for TUN/TAP interface to come up... Fri Apr 28 08:35:08 2017 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down Fri Apr 28 08:35:08 2017 Route: Waiting for TUN/TAP interface to come up... Fri Apr 28 08:35:09 2017 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down Fri Apr 28 08:35:09 2017 Route: Waiting for TUN/TAP interface to come up... Fri Apr 28 08:35:10 2017 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down Fri Apr 28 08:35:10 2017 Route: Waiting for TUN/TAP interface to come up... Fri Apr 28 08:35:11 2017 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down Fri Apr 28 08:35:11 2017 Route: Waiting for TUN/TAP interface to come up... Fri Apr 28 08:35:12 2017 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down Fri Apr 28 08:35:12 2017 Route: Waiting for TUN/TAP interface to come up... Fri Apr 28 08:35:13 2017 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down Fri Apr 28 08:35:13 2017 Route: Waiting for TUN/TAP interface to come up... Fri Apr 28 08:35:14 2017 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down Fri Apr 28 08:35:14 2017 Route: Waiting for TUN/TAP interface to come up... Fri Apr 28 08:35:15 2017 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down Fri Apr 28 08:35:15 2017 Route: Waiting for TUN/TAP interface to come up... Fri Apr 28 08:35:16 2017 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down Fri Apr 28 08:35:16 2017 Route: Waiting for TUN/TAP interface to come up... Fri Apr 28 08:35:17 2017 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down Fri Apr 28 08:35:17 2017 Route: Waiting for TUN/TAP interface to come up... Fri Apr 28 08:35:18 2017 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down Fri Apr 28 08:35:18 2017 Route: Waiting for TUN/TAP interface to come up... Fri Apr 28 08:35:19 2017 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down Fri Apr 28 08:35:19 2017 Route: Waiting for TUN/TAP interface to come up... Fri Apr 28 08:35:20 2017 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down Fri Apr 28 08:35:20 2017 Route: Waiting for TUN/TAP interface to come up... Fri Apr 28 08:35:21 2017 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down Fri Apr 28 08:35:21 2017 Route: Waiting for TUN/TAP interface to come up... Fri Apr 28 08:35:22 2017 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down Fri Apr 28 08:35:22 2017 Route: Waiting for TUN/TAP interface to come up... Fri Apr 28 08:35:23 2017 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down Fri Apr 28 08:35:23 2017 Route: Waiting for TUN/TAP interface to come up... Fri Apr 28 08:35:24 2017 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down Fri Apr 28 08:35:24 2017 Route: Waiting for TUN/TAP interface to come up... Fri Apr 28 08:35:25 2017 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down Fri Apr 28 08:35:25 2017 Route: Waiting for TUN/TAP interface to come up... Fri Apr 28 08:35:26 2017 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down Fri Apr 28 08:35:26 2017 Route: Waiting for TUN/TAP interface to come up... Fri Apr 28 08:35:27 2017 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down Fri Apr 28 08:35:27 2017 Route: Waiting for TUN/TAP interface to come up... Fri Apr 28 08:35:28 2017 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down Fri Apr 28 08:35:28 2017 Route: Waiting for TUN/TAP interface to come up... Fri Apr 28 08:35:29 2017 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down Fri Apr 28 08:35:29 2017 Route: Waiting for TUN/TAP interface to come up... Fri Apr 28 08:35:30 2017 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down Fri Apr 28 08:35:30 2017 Route: Waiting for TUN/TAP interface to come up... Fri Apr 28 08:35:31 2017 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down Fri Apr 28 08:35:31 2017 C:\Windows\system32\route.exe ADD 193.175.73.200 MASK 255.255.255.255 10.31.32.1 Fri Apr 28 08:35:31 2017 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=25 and dwForwardType=4 Fri Apr 28 08:35:31 2017 Route addition via IPAPI succeeded [adaptive] Fri Apr 28 08:35:31 2017 C:\Windows\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 172.29.0.1 Fri Apr 28 08:35:31 2017 Warning: route gateway is not reachable on any active network adapters: 172.29.0.1 Fri Apr 28 08:35:31 2017 Route addition via IPAPI failed [adaptive] Fri Apr 28 08:35:31 2017 Route addition fallback to route.exe Fri Apr 28 08:35:31 2017 env_block: add PATH=C:\Windows\System32;C:\Windows;C:\Windows\System32\Wbem Fri Apr 28 08:35:31 2017 C:\Windows\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 172.29.0.1 Fri Apr 28 08:35:31 2017 Warning: route gateway is not reachable on any active network adapters: 172.29.0.1 Fri Apr 28 08:35:31 2017 Route addition via IPAPI failed [adaptive] Fri Apr 28 08:35:31 2017 Route addition fallback to route.exe Fri Apr 28 08:35:31 2017 env_block: add PATH=C:\Windows\System32;C:\Windows;C:\Windows\System32\Wbem SYSTEM ROUTING TABLE 0.0.0.0 0.0.0.0 10.31.32.1 p=0 i=12 t=4 pr=3 a=125 h=0 m=25/0/0/0/0 0.0.0.0 128.0.0.0 172.29.0.1 p=0 i=12 t=4 pr=3 a=0 h=0 m=26/0/0/0/0 10.31.32.0 255.255.240.0 10.31.46.139 p=0 i=12 t=3 pr=3 a=125 h=0 m=281/0/0/0/0 10.31.46.139 255.255.255.255 10.31.46.139 p=0 i=12 t=3 pr=3 a=125 h=0 m=281/0/0/0/0 10.31.47.255 255.255.255.255 10.31.46.139 p=0 i=12 t=3 pr=3 a=125 h=0 m=281/0/0/0/0 127.0.0.0 255.0.0.0 127.0.0.1 p=0 i=1 t=3 pr=3 a=289 h=0 m=306/0/0/0/0 127.0.0.1 255.255.255.255 127.0.0.1 p=0 i=1 t=3 pr=3 a=289 h=0 m=306/0/0/0/0 127.255.255.255 255.255.255.255 127.0.0.1 p=0 i=1 t=3 pr=3 a=289 h=0 m=306/0/0/0/0 128.0.0.0 128.0.0.0 172.29.0.1 p=0 i=12 t=4 pr=3 a=0 h=0 m=26/0/0/0/0 169.254.0.0 255.255.0.0 169.254.202.100 p=0 i=16 t=3 pr=3 a=268 h=0 m=276/0/0/0/0 169.254.202.100 255.255.255.255 169.254.202.100 p=0 i=16 t=3 pr=3 a=268 h=0 m=276/0/0/0/0 169.254.255.255 255.255.255.255 169.254.202.100 p=0 i=16 t=3 pr=3 a=268 h=0 m=276/0/0/0/0 193.175.73.200 255.255.255.255 10.31.32.1 p=0 i=12 t=4 pr=3 a=0 h=0 m=25/0/0/0/0 224.0.0.0 240.0.0.0 127.0.0.1 p=0 i=1 t=3 pr=3 a=289 h=0 m=306/0/0/0/0 224.0.0.0 240.0.0.0 169.254.202.100 p=0 i=16 t=3 pr=3 a=278 h=0 m=276/0/0/0/0 224.0.0.0 240.0.0.0 10.31.46.139 p=0 i=12 t=3 pr=3 a=265 h=0 m=281/0/0/0/0 255.255.255.255 255.255.255.255 127.0.0.1 p=0 i=1 t=3 pr=3 a=289 h=0 m=306/0/0/0/0 255.255.255.255 255.255.255.255 169.254.202.100 p=0 i=16 t=3 pr=3 a=278 h=0 m=276/0/0/0/0 255.255.255.255 255.255.255.255 10.31.46.139 p=0 i=12 t=3 pr=3 a=265 h=0 m=281/0/0/0/0 SYSTEM ADAPTER LIST Microsoft Virtual WiFi Miniport Adapter Index = 17 GUID = {344EA4AB-8B50-458B-8C0F-1DA94FAF8E73} IP = 0.0.0.0/0.0.0.0 MAC = 24:77:03:6c:d7:29 GATEWAY = 0.0.0.0/255.255.255.255 DHCP SERV = DHCP LEASE OBTAINED = Fri Apr 28 08:35:31 2017 DHCP LEASE EXPIRES = Fri Apr 28 08:35:31 2017 DNS SERV = TAP-Windows Adapter V9 Index = 16 GUID = {995E69E0-5281-4004-8833-3F3E4AFF6335} IP = 169.254.202.100/255.255.0.0 MAC = 00:ff:99:5e:69:e0 GATEWAY = 0.0.0.0/255.255.255.255 DHCP SERV = 0.0.0.0/255.255.255.255 DHCP LEASE OBTAINED = Fri Apr 28 08:35:31 2017 DHCP LEASE EXPIRES = Fri Apr 28 08:35:31 2017 DNS SERV = Dell Wireless 5550 HSPA+ Mini-Card Network Adapter Index = 15 GUID = {9DB2AE8B-33FF-46BF-90AD-659DEA580C34} IP = 0.0.0.0/0.0.0.0 MAC = 02:80:37:ec:02:00 GATEWAY = 0.0.0.0/255.255.255.255 DNS SERV = Bluetooth-Ger\E4t (PAN) Index = 13 GUID = {552C8E14-C0E5-4A81-ABF2-E9308727AF86} IP = 0.0.0.0/0.0.0.0 MAC = 7c:e9:d3:bf:b0:69 GATEWAY = 0.0.0.0/255.255.255.255 DHCP SERV = DHCP LEASE OBTAINED = Fri Apr 28 08:35:31 2017 DHCP LEASE EXPIRES = Fri Apr 28 08:35:31 2017 DNS SERV = Intel(R) Centrino(R) Ultimate-N 6300 AGN Index = 12 GUID = {2DE9D370-DE13-45CB-9E10-E435B50037BD} IP = 10.31.46.139/255.255.240.0 MAC = 24:77:03:6c:d7:28 GATEWAY = 10.31.32.1/255.255.255.255 DHCP SERV = 10.31.32.2/255.255.255.255 DHCP LEASE OBTAINED = Fri Apr 28 08:33:26 2017 DHCP LEASE EXPIRES = Fri Apr 28 09:03:26 2017 DNS SERV = 141.42.206.150/255.255.255.255 193.175.73.150/255.255.255.255 Intel(R) 82579LM Gigabit Network Connection Index = 11 GUID = {06008A5F-658A-4CA5-8429-4718B163BC8B} IP = 0.0.0.0/0.0.0.0 MAC = d4:be:d9:2a:69:28 GATEWAY = 10.39.16.1/255.255.255.255 DHCP SERV = DHCP LEASE OBTAINED = Fri Apr 28 08:35:31 2017 DHCP LEASE EXPIRES = Fri Apr 28 08:35:31 2017 PRI WINS = 10.39.212.66/255.255.255.255 SEC WINS = 10.43.120.59/255.255.255.255 DNS SERV = Fri Apr 28 08:35:31 2017 Initialization Sequence Completed With Errors ( see http://openvpn.net/faq.html#dhcpclientserv ) Fri Apr 28 08:35:31 2017 MANAGEMENT: >STATE:1493361331,CONNECTED,ERROR,172.29.5.78,193.175.73.200,1194,, Fri Apr 28 08:35:31 2017 Start ipconfig commands for register-dns... Fri Apr 28 08:35:31 2017 C:\Windows\system32\ipconfig.exe /flushdns Fri Apr 28 08:35:31 2017 C:\Windows\system32\ipconfig.exe /registerdns Fri Apr 28 08:35:37 2017 End ipconfig commands for register-dns... Fri Apr 28 08:35:38 2017 SIGTERM received, sending exit notification to peer Fri Apr 28 08:35:39 2017 C:\Windows\system32\route.exe DELETE 193.175.73.200 MASK 255.255.255.255 10.31.32.1 Fri Apr 28 08:35:39 2017 Route deletion via IPAPI succeeded [adaptive] Fri Apr 28 08:35:39 2017 C:\Windows\system32\route.exe DELETE 0.0.0.0 MASK 128.0.0.0 172.29.0.1 Fri Apr 28 08:35:39 2017 Warning: route gateway is not reachable on any active network adapters: 172.29.0.1 Fri Apr 28 08:35:39 2017 Route deletion via IPAPI failed [adaptive] Fri Apr 28 08:35:39 2017 Route deletion fallback to route.exe Fri Apr 28 08:35:39 2017 env_block: add PATH=C:\Windows\System32;C:\Windows;C:\Windows\System32\Wbem Fri Apr 28 08:35:39 2017 C:\Windows\system32\route.exe DELETE 128.0.0.0 MASK 128.0.0.0 172.29.0.1 Fri Apr 28 08:35:39 2017 Warning: route gateway is not reachable on any active network adapters: 172.29.0.1 Fri Apr 28 08:35:39 2017 Route deletion via IPAPI failed [adaptive] Fri Apr 28 08:35:39 2017 Route deletion fallback to route.exe Fri Apr 28 08:35:39 2017 env_block: add PATH=C:\Windows\System32;C:\Windows;C:\Windows\System32\Wbem Fri Apr 28 08:35:39 2017 Closing TUN/TAP interface Fri Apr 28 08:35:39 2017 TAP: DHCP address released Fri Apr 28 08:35:39 2017 SIGTERM[soft,exit-with-notification] received, process exiting Fri Apr 28 08:35:39 2017 MANAGEMENT: >STATE:1493361339,EXITING,exit-with-notification,,,,, }}} " hildeb Active Tickets 881 OpenVPN v2.4 breaks --status formatting of client IP:port on FreeBSD Networking OpenVPN 2.4.0 (Community Ed) Bug / Defect new 2017-04-30T21:56:09Z 2017-05-01T07:39:08Z "Received report on #openvpn that the format of --status files where different from v2.3.12 to v2.4.x In v2.3.12, you can see: Test-Client,x.x.x.x:53176,5220,5420,Sun Apr 30 17:27:07 2017 While in v2.4.0 Test-Client,x.x.x.x,5220,5420,Sun Apr 30 17:27:07 2017 I did a `git bisect` to locate this issue, and it stopped at this commit: {{{ $ git bisect bad 8832c6c4cf7d1425684dd8e56984e407fe3e2aac is the first bad commit commit 8832c6c4cf7d1425684dd8e56984e407fe3e2aac Author: Arne Schwabe Date: Mon Nov 25 13:31:18 2013 +0100 Implement listing on IPv4/IPv6 dual socket on all platform With this patch OpenVPN will listen on Ipv4 as well as IPv6 when an IPv6 socket is used. Using bind ipv6only will disable this behavior Acked-by: Gert Doering Message-Id: <1385382680-5912-7-git-send-email-arne@rfc2549.org> URL: http://article.gmane.org/gmane.network.openvpn.devel/8052 Signed-off-by: Gert Doering }}} The complete git bisect log: {{{ $ git bisect log git bisect start # good: [8990b218fa9db71714ac42b0095c594e19861320] Preparing release of v2.3.12 git bisect good 8990b218fa9db71714ac42b0095c594e19861320 # bad: [9e0963c11aa439deb382d7d6bc40b6ade999401c] New approach to handle peer-id related changes to link-mtu. git bisect bad 9e0963c11aa439deb382d7d6bc40b6ade999401c # good: [6abd293e5c04467a17e6ed4cf01c708cef0ac046] Preparing for v2.3_beta1 git bisect good 6abd293e5c04467a17e6ed4cf01c708cef0ac046 # bad: [3173787a0beea7c335b1aaedcd2ca5303b17bc22] Fix compiler warning for unused result of write() git bisect bad 3173787a0beea7c335b1aaedcd2ca5303b17bc22 # good: [8476edbb1748e11de0e4fda8989c9e470285926b] Only print script warnings when a script is used. Remove stray mention of script-security system. git bisect good 8476edbb1748e11de0e4fda8989c9e470285926b # good: [076fd3e46bbbe6261317d58cc2442f8eccc927ce] Change the type of all ports in openvpn to const char* and let getaddrinfo resolve the port together with the hostname. git bisect good 076fd3e46bbbe6261317d58cc2442f8eccc927ce # bad: [925b8a463b78620c1f856a0224396ac7d53e6295] Support non-ASCII characters in Windows tmp path git bisect bad 925b8a463b78620c1f856a0224396ac7d53e6295 # good: [282788a835f6c9dfb85e8f9a3bd45f5841271b06] Fix assertion when SIGUSR1 is received while getaddrinfo is successful git bisect good 282788a835f6c9dfb85e8f9a3bd45f5841271b06 # good: [aa162d44edae8530391775b55e7b4f149548537e] When resolving fails print the error message from socket layer git bisect good aa162d44edae8530391775b55e7b4f149548537e # good: [68793f40e1d04409264d21dd24453d959828a306] Move ASSERT so external-key with OpenSSL works again git bisect good 68793f40e1d04409264d21dd24453d959828a306 # bad: [451de0a8d61a8a2c4a049837374a728090b4e4d6] Fix IPv6_V6ONLY logic. git bisect bad 451de0a8d61a8a2c4a049837374a728090b4e4d6 # bad: [8832c6c4cf7d1425684dd8e56984e407fe3e2aac] Implement listing on IPv4/IPv6 dual socket on all platform git bisect bad 8832c6c4cf7d1425684dd8e56984e407fe3e2aac # first bad commit: [8832c6c4cf7d1425684dd8e56984e407fe3e2aac] Implement listing on IPv4/IPv6 dual socket on all platform }}} " David Sommerseth Active Tickets 885 Pressing reconnect fails to reconnect with auth failure Generic / unclassified OpenVPN 2.4.0 (Community Ed) Bug / Defect new 2017-05-08T07:32:49Z 2017-05-08T15:27:36Z "In the gui, when I am already connected, I open up the status and press reconnect, then it does not reconnect, instead gives auth failed and a prompt comes up asking for password, which should have been previously saved. May 08 01:25:08 2017 TCP/UDP: Preserving recently used remote address: [AF_INET]172.98.67.4:1198 Mon May 08 01:25:08 2017 UDP link local: (not bound) Mon May 08 01:25:08 2017 UDP link remote: [AF_INET]172.98.67.4:1198 Mon May 08 01:25:08 2017 [4e6f0e412dafba4add2d6178916260a5] Peer Connection Initiated with [AF_INET]172.98.67.4:1198 Mon May 08 01:25:09 2017 Preserving previous TUN/TAP instance: pia virtual Mon May 08 01:25:09 2017 NOTE: Pulled options changed on restart, will need to close and reopen TUN/TAP device. Mon May 08 01:25:10 2017 open_tun Mon May 08 01:25:10 2017 TAP-WIN32 device [pia virtual] opened: \\.\Global\{4E56AD95-0ECF-412C-9467-C01FDA916F99}.tap Mon May 08 01:25:10 2017 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.30.10.6/255.255.255.252 on interface {4E56AD95-0ECF-412C-9467-C01FDA916F99} [DHCP-serv: 10.30.10.5, lease-time: 31536000] Mon May 08 01:25:10 2017 Successful ARP Flush on interface [14] {4E56AD95-0ECF-412C-9467-C01FDA916F99} Mon May 08 01:25:10 2017 do_ifconfig, tt->did_ifconfig_ipv6_setup=0 Mon May 08 01:25:22 2017 Initialization Sequence Completed Mon May 08 01:27:38 2017 SIGHUP[hard,] received, process restarting Mon May 08 01:27:38 2017 OpenVPN 2.4.1 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Mar 22 2017 Mon May 08 01:27:38 2017 Windows version 6.1 (Windows 7) 64bit Mon May 08 01:27:38 2017 library versions: OpenSSL 1.0.2k 26 Jan 2017, LZO 2.09 Mon May 08 01:27:43 2017 TCP/UDP: Preserving recently used remote address: [AF_INET]172.98.67.4:1198 Mon May 08 01:27:43 2017 UDP link local: (not bound) Mon May 08 01:27:43 2017 UDP link remote: [AF_INET]172.98.67.4:1198 Mon May 08 01:27:44 2017 [4e6f0e412dafba4add2d6178916260a5] Peer Connection Initiated with [AF_INET]172.98.67.4:1198 Mon May 08 01:27:45 2017 AUTH: Received control message: AUTH_FAILED Mon May 08 01:27:45 2017 SIGUSR1[soft,auth-failure] received, process restarting" illumilore Active Tickets 895 Connection not restored after network change Generic / unclassified OpenVPN 2.4.2 (Community Ed) Bug / Defect new 2017-05-26T10:38:37Z 2017-05-26T10:38:37Z "openvpn detects ""connection reset"" after wifi network changed, but it adds direct route to the server with non-existent default gateway (one from previously connected network). Stripped log attached. Real remote IP replaced with 111.222.333.444" mbg033 Active Tickets 910 "Browsers' domain name resolution is not done through VPN if GUI wasn't started with ""Run as adminitstator""" Windows GUI OpenVPN 2.4.3 (Community Ed) Bug / Defect new 2017-07-02T01:46:25Z 2017-07-19T20:42:02Z "I became aware of this problem when I connect a VPN server in some other country from China, since it is known that our country will hijack certain domain name resolution (for whatever reasons). Say I connect a VPN server in the UK, I can then watch programmes on bbc.co.uk, yet I still can't access google or any site with names containing ""vpn"" (e.g. openvpn.net) with Firefox or Edge. (However, if I do domain name resolution with nslookup, it appears that the resolution is done through the VPN.) This does not happen if I started the GUI with ""Run as administrator"", or running openvpn with cmd/ps started with that. (While if cmd/ps is not started with that, openvpn cannot complete initializing the connection at all, which is pretty much expected). The only difference in the log is the following additional line shown when the GUI is NOT started with ""Run as administrator"": Flag 'def1' added to --redirect-gateway (iservice is in use) I am using Windows 10 RS2 and openvpn-install-2.4.3-I601.exe." tom.ty89 Active Tickets 914 user flag does not kill root Management OpenVPN 2.4.3 (Community Ed) Bug / Defect new 2017-07-12T07:07:16Z 2017-09-06T23:34:37Z "I'm using 2.4.3 on CentOS 7, with the openvpn-server systemd unit. My config contains user nobody; group nobody. Yet, after initialization, running ps -ef | grep openvpn returns two processes, one owned by nobody and a second owned by root. Unless I'm misunderstanding the user/group flags, the root process should be killed when the nobody threads are created. Output is here: nobody 686 1 0 01:42 ? 00:00:00 /usr/sbin/openvpn --status /run/openvpn-server/status-server.log --status-version 2 --suppress-timestamps --config server.conf root 690 686 0 01:42 ? 00:00:00 /usr/sbin/openvpn --status /run/openvpn-server/status-server.log --status-version 2 --suppress-timestamps --config server.conf" scottb Active Tickets 926 Invalid tun MTU if link-mtu is in use Generic / unclassified OpenVPN 2.4.3 (Community Ed) Bug / Defect new 2017-08-15T11:36:50Z 2017-08-28T12:57:35Z "When trying to use link-mtu option instead of mssfix on both client and server sides it leads to MTU problems because tun adapter mtu is higher than should be. I use dual tcp+udp openvpn server but it doesn't matter, let's consider udp (default) one. You can see configs and client log in attachment. On server side udp log I can see: {{{ WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1298) Control Channel MTU parms [ L:1420 D:1172 EF:78 EB:0 ET:0 EL:3 ] }}} and corresponding MTU value for udp tun0 adapter: {{{ 6: tun0: mtu 1298 qdisc pfifo_fast state UNKNOWN group default qlen 100 link/none inet 172.16.16.1/24 brd 172.16.16.255 scope global tun0 valid_lft forever preferred_lft forever 7: tun1: mtu 1296 qdisc pfifo_fast state UNKNOWN group default qlen 100 link/none inet 172.16.16.1/24 brd 172.16.16.255 scope global tun1 valid_lft forever preferred_lft forever }}} While on client side tun adapter mtu is different with server (1295 vs 1298, which is also weird for me) one and different from the value shown in log: {{{ OPTIONS IMPORT: WARNING: peer-id set, but link-mtu fixed by config - reducing tun-mtu to 1295, expect MTU problems /sbin/ip link set dev tun0 up mtu 1367 }}} tun0 adapter has corresponding value: {{{ 5: tun0: mtu 1367 qdisc pfifo_fast state UNKNOWN group default qlen 100 link/none inet 172.16.16.2/24 brd 172.16.16.255 scope global tun0 valid_lft forever preferred_lft forever }}} After this I cannot reach some sites (like beta.speedtest.net) because of MTU problems. When I manually changed (after connection via: `ip link set dev tun0 mtu 1295`) tun0 MTU to the one have seen in log MTU issue fixed and I can reach the site. I imagine that openvpn should set tun adapter mtu to the one shown in log WARNING message (if it has rights - I've not drop privileges because of dual tcp/udp config). Also can you please tell me why client and server tun-mtu value differs (1295 on client, 1298 on server) while openvpn version (2.4.3) and OS type (Ubuntu Xenial) are the same?" vmspike Active Tickets 929 remember password is nonfunctional Generic / unclassified OpenVPN 2.2.2 (Community Ed) Bug / Defect new 2017-08-26T08:10:24Z 2017-08-26T08:10:24Z When the remember password box is checked, the password is never remembered after internet loss. illumilore Active Tickets 937 "Socket option ""IPV6_V6ONLY=0"" not allowed on DragonFlyBSD and OpenBSD" IPv6 OpenVPN 2.4.3 (Community Ed) Bug / Defect new 2017-09-22T16:02:30Z 2017-09-23T02:21:23Z "Dear OpenVPN developers, I have just set up an OpenVPN (v2.4.3) server on my VPS with DragonFlyBSD (v4.8.0) as the operating system, and my VPS has (static) IPv4 & IPv6 configured. It works quiet well except for the dual IPv4 & IPv6 listening. If I set `proto udp`, OpenVPN could **only** bind to **UDP6** on the DragonFlyBSD (prefer IPv6), and showed these warning messages: {{{ Could not determine IPv4/IPv6 protocol. Using AF_INET6 Socket Buffers: R=[42080->42080] S=[9216->9216] setsockopt(IPV6_V6ONLY=0) Setting IPV6_V6ONLY=0 failed: Operation not supported (errno=45) UDPv6 link local (bound): [AF_INET6][undef]:8080 UDPv6 link remote: [AF_UNSPEC] }}} So this issue is due to that `IPV6_V6ONLY=0` is //not allowed/supported// on DragonFlyBSD, which is also described in its man page [[http://mdoc.su/d/ip6|ip6(4)]]. In addition, OpenBSD also explains in its man page [[https://man.openbsd.org/ip6#IPV6_V6ONLY|ip6(4)]] that `IPV6_V6ONLY` is a //read-only// option, and //IPv6 sockets are always IPv6-only//, for security considerations. Therefore, it should be a better/best practice to open two sockets, one for IPv4, and the other for IPv6 only? In this way, OpenVPN daul-stack server will work more consistently across different platforms. And the [[https://community.openvpn.net/openvpn/wiki/PlatformNotes|platform notes]] about IPv6 on *BSD can be updated/removed. Best regards, Aly" liweitianux Active Tickets 950 Long-running VPN session stops decrypting data Crypto OpenVPN 2.4.4 (Community Ed) Bug / Defect new 2017-10-22T00:14:53Z 2017-10-26T04:35:07Z "I have an OpenVPN connection between my phone and my server. Periodically, the VPN stops sending data, even though the connection seems to be open still. Restarting the client restores data flow. I turned up logging on the server to try to see what is happening, but I cannot determine a root cause. I've attached the full log. The first ""Error"" I see is at Sat Oct 21 16:37:27 2017 us=180526, and I know things aren't working by the time I see AEAD errors, starting at Sat Oct 21 17:13:13 2017 us=359274. Because this is an error that seems to occur randomly after lots of time, it is hard to get more detail than this. The first error is this: Sat Oct 21 16:37:27 2017 us=180526 TLS State Error: No TLS state for client [AF_INET]192.168.1.1:59790, opcode=9 Sat Oct 21 16:37:27 2017 us=180648 GET INST BY REAL: 192.168.1.1:59790 [failed] Eventually I see this for every packet sent from client to server, and the server drops the data: Sat Oct 21 17:13:13 2017 us=359274 phone/192.168.1.1:59790 AEAD Decrypt error: cipher final failed I am running OpenVPN 2.4.4 on my server, and OpenVPN for Android on my client. I think this is different than [https://community.openvpn.net/openvpn/ticket/847 issue 847]." jdanders Active Tickets 951 learn-address script should have dev env variable defined for delete too Generic / unclassified OpenVPN 2.4.0 (Community Ed) Bug / Defect new 2017-10-31T01:12:10Z 2017-10-31T08:59:31Z "Hello, The learn-address script has the dev environment variable defined when called for add or update, which is useful for adding routes. It however does not have it when called for delete, that's really a problem because one then doesn't know which route to remove, notably when several instances of openvpn run on the system system (e.g. to listen both on udp and tcp). Samuel" sthibault Active Tickets 952 """comp-lzo no"" and ""compress"" options not compatible" Configuration OpenVPN 2.4.4 (Community Ed) Bug / Defect new 2017-10-31T18:18:09Z 2018-05-18T18:14:22Z "Hello, I am trying to upgrade our OpenVPN servers from v2.3 to v2.4. Almost everything is done, with the exception of compression. Environment: - OpenVPN v2.4.4 on server side - A mix of OpenVPN 2.3 on the client side, but v2.4.4 behaves the same. Objective: Upgrade servers from v2.3 to v2.4, maintaining backward compatibility with v2.3 clients and allow v2.4 clients to connect. As I have mentioned above, the issue is with compression. Currently, we have: - Servers v2.3: comp-lzo no - Clients: comp-lzo yes As comp-lzo is a deprecated flag, I was trying to use the compress one to replace it. According to the docs: If the algorithm parameter is empty, compression will be turned off, but the packet framing for compression will still be enabled, allowing a different setting to be pushed later. This is mostly true, but communications between the v2.4 server and v2.3 client will not happen with these settings: - Server: compress - Client: comp-lzo no After a few debugging, OpenVPN initializes the compression setting with: - compress option, with no arguments: - comp.alg=1 - comp.flags=4 - comp-lzo no option: - comp.alg=1 - comp.flags=0 The COMP_F_SWAP flag in compress option, will swap one byte, which apparently make the protocol incompatible. Now, if we take a look at other settings: - compress lzo option: - comp.alg=2 - comp.flags=0 - comp-lzo yes option: - comp.alg=2 - comp.flags=0 The source code, however, intentionally defines compress (without options) like that: options->comp.alg = COMP_ALG_STUB; options->comp.flags = COMP_F_SWAP; Bottom line, the issue is that, although there is a way to render lzo compression compatible with v2.3/v2.4 clients, when it is activated, there is no apparently solution for when compression packet framing only is enabled. IMO, it makes sense to have ""compress lzo""/""comp-lzo yes"" and ""compress""/""comp-lzo no"" to be compatible among them. Unless that COMP_F_SWAP really needs to be there. Or am I missing something? Thank you for your help, Rui " ruisantos Active Tickets 953 Dual-Stack Server with tls-auth has errors when IPv6 clients connect IPv6 OpenVPN 2.4.3 (Community Ed) Bug / Defect new 2017-10-31T19:45:59Z 2018-09-26T08:57:02Z "I have configured a server with dual-stack support (proto udp6). When clients (OpenVPN connect on iOS) connect via IPv6 they get a timeout on the client side and the server logs bad packet IDs and packet authentication failures. The error goes away when I configure the server to be IPv6 only by using a ""local "" configuration line." gpf Active Tickets 956 Management Interface does not query for PKCS#11 token password in daemon mode Management OpenVPN 2.4.4 (Community Ed) Bug / Defect new 2017-11-03T16:42:11Z 2022-11-20T21:22:36Z "When running with a pkcs hardware that requires a PIN code to unlock, Openvpn management interface fails to prompt for PIN Code and instead prompts only for Token Insertion. Example config file: {{{ client remote myserver dev tun persist-tun persist-key verb 3 ca ca.crt keepalive 10 60 cipher AES-256-CBC comp-lzo nobind pkcs11-providers /usr/local/lib/libeTPkcs11.dylib pkcs11-cert-private 1 pkcs11-id 'SafeNet\x2C\x20Inc\x2E/eToken/0256f233/ACE\x20eToken/XXXXXX' pkcs11-pin-cache 3600 management 127.0.0.1 8888 management-hold management-query-passwords }}} when run with command ""openvpn --config config.ovpn"" connecting to the management port yields the following dialog: {{{ >INFO:OpenVPN Management Interface Version 1 -- type 'help' for more info >HOLD:Waiting for hold release:0 hold release SUCCESS: hold release succeeded >PASSWORD:Need 'ACE eToken token' password password 'ACE eToken token' MyPINCode SUCCESS: 'ACE eToken token' password entered, but not yet verified ... }}} and completes connection successfully but when run with command ""openvpn --daemon --config config.ovpn"", management dialog is: {{{ >INFO:OpenVPN Management Interface Version 1 -- type 'help' for more info >HOLD:Waiting for hold release:0 hold release SUCCESS: hold release succeeded >NEED-OK:Need 'token-insertion-request' confirmation MSG:Please insert ACE eToken token needok 'token-insertion-request' ok SUCCESS: 'token-insertion-request' needok-confirmation entered, but not yet verified >NEED-OK:Need 'token-insertion-request' confirmation MSG:Please insert ACE eToken token ... }}} The daemon loops on needok since it can't read the token successfully without the PIN Code." rluta Active Tickets 961 [MacOS] OpenVPN fails to use crypto token when run daemonized Generic / unclassified OpenVPN 2.4.4 (Community Ed) Bug / Defect new 2017-11-29T11:03:04Z 2022-12-21T17:22:10Z "Hi, I’m willing to deploy OpenVPN, authentified with hardware crypto tokens, on MacOS X clients, with Tunnelblick GUI. Unfortunately, it fails, as discussed on [https://groups.google.com/forum/#!topic/tunnelblick-discuss/f_Rp_2nV-x8]. I investigated a bit, and found out that the problem occurs only when OpenVPN is run daemonized. I could dig the issue up to a call, by the PKCS#11 library, to the SCardEstablishContext PC/SC function, which returns SCARD_E_NO_SERVICE (“The Smart card resource manager is not running.”) when OpenVPN is run daemonized, and SCARD_S_SUCCESS when it’s not daemonized. It seems to me that the problem should be related to the way OpenVPN daemonizes itself. I know little about MacOS (I’m more a Linux guy), but I’d be happy to help investigate this issue. I have no idea whether this issue is MacOS-specific. I run my tests with MacOS Sierra 10.12.6." z80a Active Tickets 962 /etc/openvpn does not support symlinks anymore Generic / unclassified Bug / Defect new 2017-11-29T22:26:21Z 2021-12-17T22:43:43Z "/etc/openvpn does not support symlinks anymore. not sure if this in intentional as it used to. i could not find anything in the change logs referring to symlinks." waf Active Tickets 964 connection fails when VirtualBox is installed Generic / unclassified Bug / Defect new 2017-12-07T07:36:53Z 2017-12-07T07:36:53Z "openvpn 2.5 from master (july 2017 build) installed on Windows also Virtualbox is installed virtualbox creates several ethernet adapters openvpn connection fails log {{{ Fri Dec 01 19:26:21 2017 TAP-WIN32 device [Ethernet 3] opened: \\.\Global\{11253FCA-72B8-422F-81B3-6D90A7DBD29C}.tap Fri Dec 01 19:26:21 2017 TAP-Windows Driver Version 9.21 Fri Dec 01 19:26:21 2017 Set TAP-Windows TUN subnet mode network/local/netmask = 192.168.78.0/192.168.78.14/255.255.255.0 [SUCCEEDED] Fri Dec 01 19:26:21 2017 Notified TAP-Windows driver to set a DHCP IP/netmask of 192.168.78.14/255.255.255.0 on interface {11253FCA-72B8-422F-81B3-6D90A7DBD29C} [DHCP-serv: 192.168.78.254, lease-time: 31536000] Fri Dec 01 19:26:21 2017 NOTE: FlushIpNetTable failed on interface [67] {11253FCA-72B8-422F-81B3-6D90A7DBD29C} (status=1168) : Ýëåìåíò íå íàéäåí. }}} message in russian means ""element not found"" after Virtualbox was uninstalled, openvpn is not failing anymore " chipitsine Active Tickets 965 openvpn fails on reconnect when server is restarted Generic / unclassified OpenVPN 2.4.4 (Community Ed) Bug / Defect new 2017-12-07T07:40:25Z 2017-12-20T20:44:59Z "the following setup server 2.5 git master, authentication by login/password client either linux or windows (tested both) when client connects, auth token is issued, which is used as a password later after I restart server, client still tries to authenticate with auth token, authentication fails I assume client should retry to authenticate with login/password in such case (if token failed), however it does not happen" chipitsine Active Tickets 972 "openvpn-gui does not show login/password window on ""verb 30""" Generic / unclassified Bug / Defect new 2018-01-01T08:13:13Z 2018-01-01T08:13:13Z "during some investigation, I set ""verb 30"" no login/password window " chipitsine Active Tickets 973 "restart network adapter leads to ""AUTH_FAILED""" Generic / unclassified Bug / Defect new 2018-01-01T08:19:58Z 2018-01-04T12:23:33Z "when some of our users perform powershell command (when openvpn is connected) Get-NetAdapter | Restart-NetAdapter so, openvpn complains with AUTH_FAILED (and saved password is forgotten) do not ask why people do wish to Restart-NetAdapter, I've no idea. however, I beleive that it should not end with AUTH_FAILED the worst is that saved password is forgotten trac#972 is somehow related to this issue. I tried to increase verbosity level " chipitsine Active Tickets 1004 VPN routes stay intact when changed local network but can't reconnect to VPN from that new local network Generic / unclassified Bug / Defect new 2018-01-29T05:23:50Z 2018-02-04T10:55:38Z "VPN routes stay intact when changed local network but can't reconnect to VPN from that new local network. So the situation is the following: # You connect from home network to office VPN network from your laptop. # Then you suspend the laptop, take to the office, resume it from sleep. *Current result:* You can't connect to machines in office network. The pushed route is still set up though VPN client can't to office VPN anymore. Sending HUP signal to openvpn client fixes the problem but probably sending signal after each resume from sleep is not the optimal choice. *Expected result:* Routes are not present after resume. ---- Or how should I change the configuration to suit my needs best (e.g. apply pushed route's metric to be higher?)" teneri Active Tickets 1005 Chain CA fails with 1.2.6 Crypto OpenVPN 2.4.4 (Community Ed) Bug / Defect new 2018-01-29T09:44:29Z 2022-12-22T08:46:09Z "Hi, Since 1.2.6 it seems the chain CA validation is broken. Our infra is a bit particular as we have two differents CA Server: CA1 -> subCA1 -> Sub-subCA1 -> server cert Clients: CA2 -> subCA2 -> Sub-subCA2 -> client cert The server includes CA2 in addition to the CA1 chain in its CA file to validate our clients. The clients include CA1 in addition to the CA2 chain in its CA file as well. All works for windows/linux/OSX/Android clients. But it fails for IOS since 1.2.6 (and maybe 1.2.5), it was working before though. The server log shows that if fails to check the client chain: {{{ VERIFY ERROR: depth=0, error=unable to get local issuer certificate: OU=OpenVPN-Mobile, CN=xxx }}} I tried different combination to include in the client CA but it never manages to get the local issuer. There is a thread here: https://forums.openvpn.net/viewtopic.php?f=36&t=25674 With the help of ordex, we've identified that the problem comes from mbed TLS as the same issue occurs with mbed TLS on linux but not with openssl. Thanks, Ben" benjy Active Tickets 1070 IPv6 packet received by L2 client breaks MAC mapping? Networking OpenVPN 2.4.4 (Community Ed) Bug / Defect new 2018-06-10T11:44:36Z 2018-08-04T08:57:10Z "Topology: [ client ] -- L2/TAP tunnel -- [ server ] -- L2 link -- [ host ] Issue flow: 1. Initially traffic works as intended 2. After a while server sends an IPv6 multicast to client (packet No. 26773) 3. After this packet, all traffic designated for server is no longer routed via the tunnel. Basically, any packet written in the TAP interface at the client side with the server MAC as the destination, it's spewed back out in the TAP interface by the OpenVPN. It is not sent over the tunnel. However, any packets with a destination different than server's MAC is routed correctly. So client can still communicate with host, but not with server. The packet capture was taken on client's TAP interface. In the packet capture, client is 172.16.10.5, server is 172.16.10.1 and host is 172.16.10.20. If you look closely in the packet capture, you'll notice that after the IPv6 packet No. 26773 (the only IPv6 packet), all ICMP replies (or any traffic) from client to server appear twice, once when going from TAP interface to OpenVPN and once when it is immediately spewed back out by OpenVPN. Basically OpenVPN will throw packets back on the TAP interface if the destination MAC matches the source of a previously received IPv6 packet. Or once an IPv6 packet is received, all traffic targeting the source MAC of that packet won't be send over the tunnel, and instead is spewed back out on the TAP interface. {{{ root@ubuntu:~# openvpn --version OpenVPN 2.4.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 10 2018 library versions: OpenSSL 1.1.0g 2 Nov 2017, LZO 2.08 Originally developed by James Yonan Copyright (C) 2002-2017 OpenVPN Technologies, Inc. Compile time defines: enable_async_push=no enable_comp_stub=no enable_crypto=yes enable_crypto_ofb_cfb=yes enable_debug=yes enable_def_auth=yes enable_dependency_tracking=no enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=needless enable_fragment=yes enable_iproute2=yes enable_libtool_lock=yes enable_lz4=yes enable_lzo=yes enable_maintainer_mode=no enable_management=yes enable_multihome=yes enable_pam_dlopen=no enable_pedantic=no enable_pf=yes enable_pkcs11=yes enable_plugin_auth_pam=yes enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_selinux=no enable_server=yes enable_shared=yes enable_shared_with_static_runtimes=no enable_silent_rules=no enable_small=no enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=yes enable_werror=no enable_win32_dll=yes enable_x509_alt_username=yes with_aix_soname=aix with_crypto_library=openssl with_gnu_ld=yes with_mem_check=no with_sysroot=no root@ubuntu:~# }}}" Chris_DB Active Tickets 1082 Not clear for how long does openVPN caches the resolved IP address of remote host Generic / unclassified OpenVPN 2.4.4 (Community Ed) Bug / Defect new 2018-08-02T07:30:14Z 2020-10-11T16:07:33Z "Currently when running openVPN client in log it says: {{{ Preserving recently used remote address: }}} For how long it will cache it? How to tune it? Maybe best to add some info into man?" teneri Active Tickets 1146 Error in add_block_dns_filters(): FwpEngineOpen: open fwp session failed : In der Endpunktzuordnung sind keine weiteren Endpunkte verfügbar. [status=0x6d9] Networking OpenVPN 2.4.6 (Community Ed) Bug / Defect new 2018-12-10T14:17:15Z 2020-01-06T19:25:10Z "One of my users cannot log-in using opevpn, since the activation of the firewall/DNS blocking is failing (log is attached). Wed Dec 05 20:44:40 2018 OpenVPN 2.4.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 26 2018 Wed Dec 05 20:44:40 2018 Windows version 6.1 (Windows 7) 64bit Wed Dec 05 20:44:40 2018 library versions: OpenSSL 1.1.0h 27 Mar 2018, LZO 2.10 ... Wed Dec 05 20:46:03 2018 Error in add_block_dns_filters(): FwpEngineOpen: open fwp session failed : In der Endpunktzuordnung sind keine weiteren Endpunkte verfügbar. [status=0x6d9] Wed Dec 05 20:46:03 2018 MANAGEMENT: Client disconnected Wed Dec 05 20:46:03 2018 Blocking DNS failed! Wed Dec 05 20:46:03 2018 Exiting due to fatal error I found several mentions of ""Block_DNS: adding block dns filters using service failed: There are no more endpoints available from the endpoint mapper. [status=0x6d9]"" Like here: https://forum.netgate.com/topic/122516/openvpn-blocking-dns-failed-unable-to-connect-to-vpn" hildeb Active Tickets 1215 No PIN prompt for PKCS#11 Generic / unclassified OpenVPN 2.4.7 (Community Ed) Bug / Defect new 2019-09-16T09:15:57Z 2022-01-15T00:16:31Z "I’m trying to use OpenVPN client with my client key stored on a Nitrokey Start (think of it as a smart card) and accessed via PKCS#11. In general it works but entering the PIN is an issue. On Linux (Ubuntu 18.04, SUSE Tumbleweed) as well as on Windows when starting OpenVPN client it waits for the PIN to be provided but doesn’t prompt the user to enter the PIN. Instead I have to open a separate terminal, telnet into the OpenVPN client and enter the PIN (tried on Linux). This is horrible user experience and I don’t think it’s the desired work flow. From what I read OpenVPN expects systemd to provide the PIN through systemd-ask-pass but systemd doesn’t prompt to enter a PIN. My impression is that systemd-ask-pass’s primarily focus is prompting for passwords during boot-time but not during run-time. Therefore I’m wondering if using systemd-ask-pass during run-time is a good idea. Since I face the same issue on Windows (where no systemd is installed, obviously) here the cause must be something else. Looking at solving this issue I’m wondering: a) An option for OpenVPN to enforce password prompt even when systemd exists, wouldn’t that make sense? (I couldn’t find such) In any case this is more a workaround instead of a proper solution. b) What would be the systematic solution to that issue? Since this issue happens on Windows too, I don’t believe pushing this issue down to systemd would be the right approach." jans Active Tickets 1242 Dropped Packages on Windows Server 2012 with routing enabled Networking OpenVPN 2.4.8 (Community Ed) Bug / Defect new 2019-12-09T17:40:34Z 2021-04-01T10:31:23Z "On Windows Server 2012 I have issues with dropped packages, when I have enabled IP routing on the server (IPEnableRouter=1). When I disable the routing, everything is fine and the rtt of each package is low as expected. Then I enable the routing without any other changes in the configs and the rtt of around 30% of packages goes >3000ms (from 40ms). This is also the case if I only ping this OpenVPN server from a vpn client, so there should be no routing to the outside of the tunnel. Now I switched back to version 2.3.18-I001 and the issue is gone. I use the same config for my tests with 2.4.8 and 2.3.18: port 1194 proto udp dev tun comp-lzo route-delay 20 10 ip-win32 netsh" Erikkolo Active Tickets 1252 Unable to reconnect after Windows standby / hibernation Generic / unclassified OpenVPN 2.4.8 (Community Ed) Bug / Defect new 2020-02-12T11:26:07Z 2020-02-19T21:17:46Z "Upgraded from 2.4.6 to 2.4.8 (Windows 10). 2.4.6 was very stable - no configs have been changed etc. After the upgrade to 2.4.8 I notice that when I put by computer with an active connection to standby / hibernation and wake it up later it will not reconnect. When I double click on the icon it says something like: ""The connection to the management interface failed"" (message translated as English is not my native language). Restarting the service sometimes worked but sometimes the service was completly stuck and wouldn't end. I thought this might be an issue with my computer so I installed it on colleges computer with the same behavior. We discussed it and he said that he has the feeling that is only happens when he uses the secure connection (2 profiles - 1. split DNS; 2. full VPN tunneling). I couldn't verify this as i already rolled back for now. Configs: #SPLIT DNS TUN dev tun persist-key cipher AES-256-CBC ncp-ciphers AES-128-GCM:AES-192-GCM:AES-256-GCM auth SHA256 tls-client client resolv-retry infinite remote vpn.company.com 1196 udp verify-x509-name ""vpn.company.com"" name auth-user-pass pkcs12 a-b-p1-UDP4-1196-vpn.company.com.p12 remote-cert-tls server register-dns verb 3 fragment 1400 mssfix 1400 # FULL TUN dev tun persist-tun persist-key cipher AES-256-CBC ncp-ciphers AES-128-GCM:AES-192-GCM:AES-256-GCM auth SHA256 tls-client client resolv-retry infinite remote vpn.company.com 1197 udp verify-x509-name ""vpn.company.com"" name auth-user-pass pkcs12 a-b-p1-UDP4-1196-vpn.company.com.p12 remote-cert-tls server register-dns verb 3 fragment 1400 mssfix 1400 Logfile mentioned in the error mesage: ... 12:19:18 2020 C:\windows\system32\route.exe DELETE XXX.XXX.XXX.XXX MASK 255.255.255.255 192.168.2.1 12:19:18 2020 Warning: route gateway is not reachable on any active network adapters: 192.168.2.1 12:19:18 2020 Route deletion via service failed 12:19:18 2020 C:\windows\system32\route.exe DELETE 0.0.0.0 MASK 128.0.0.0 XX.XX.XX.XX 12:19:18 2020 Route deletion via service succeeded 12:19:18 2020 C:\windows\system32\route.exe DELETE 128.0.0.0 MASK 128.0.0.0 XX.XX.XX.XX 12:19:18 2020 Route deletion via service succeeded 12:19:18 2020 Closing TUN/TAP interface 12:19:31 2020 TAP: DHCP address released 12:19:31 2020 SIGTERM[hard,] received, process exiting 12:19:31 2020 MANAGEMENT: >STATE:1581506371,EXITING,SIGTERM,,,,, " blaupause Active Tickets 1257 capath does not refresh CRL and also disable crl-verify Crypto OpenVPN 2.4.6 (Community Ed) Bug / Defect assigned 2020-03-02T17:53:47Z 2023-11-06T08:44:58Z "Hello, I'm using capath in order to validate certificates issued by multiple CAs. Without crl-verify, it does check CRL correctly (files *.r* inside capath). However, it does not refresh them when they are updated and even after they expire. I need to restart openvpn (which is not ideal) when I update any CRL. I tried to use crl-verify again with: crl-verify /same/path/of/capath/ dir But it does not change the behavior. I also tried a different path, moving all *.r* files into the new directory. crl-verify /different/path/of/capath.crl/ dir However, openvpn simply ignored it (when capath is in use). I did a strace and it stat()s only /same/path/of/capath/*.r* (only once) and never /different/path/of/capath.crl/*.r*. As now capath had no CRL, it accepted a revoked cert. Please, add all CRL inside capath to the ""files to refresh on client connect"" list. I'm actually using 2.4.5. However, nothing in changelog touched that area since then." luizluca Active Tickets 1329 starting a server instance a second time (failing) messes up routing for the first instance Generic / unclassified OpenVPN git master branch (Community Ed) Bug / Defect new 2020-09-18T15:13:03Z 2021-06-16T17:40:18Z "So, I have this server instance {{{ port 51194 proto udp6 dev tun server 10.204.2.0 255.255.255.0 }}} which will on start do this: {{{ Sep 18 17:01:32 gentoo tun-udp-p2mp[27140]: net_iface_mtu_set: mtu 1500 for tun1 Sep 18 17:01:32 gentoo tun-udp-p2mp[27140]: net_iface_up: set tun1 up Sep 18 17:01:32 gentoo tun-udp-p2mp[27140]: net_addr_ptp_v4_add: 10.204.2.1 peer 10.204.2.2 dev tun1 ... Sep 18 17:01:32 gentoo tun-udp-p2mp[27140]: net_route_v4_add: 10.204.2.0/24 via 10.204.2.2 dev [NULL] table 0 metric -1 ... Sep 18 17:01:32 gentoo tun-udp-p2mp[27140]: setsockopt(IPV6_V6ONLY=0) Sep 18 17:01:32 gentoo tun-udp-p2mp[27140]: UDPv6 link local (bound): [AF_INET6][undef]:51194 }}} all good: {{{ $ ip route |grep 10.204.1 10.204.1.0/24 via 10.204.1.2 dev tun0 10.204.1.2 dev tun0 proto kernel scope link src 10.204.1.1 }}} Now, start this instance again (because you messed up your locking in the surrounding scripts, or whatever)... it fails, because it cannot bind: {{{ 2020-09-18 17:09:14 us=113238 net_addr_ptp_v4_add: 10.204.1.1 peer 10.204.1.2 dev tun7 2020-09-18 17:09:14 us=114066 net_route_v4_add: 10.204.1.0/24 via 10.204.1.2 dev [NULL] table 0 metric -1 2020-09-18 17:09:14 us=114278 setsockopt(IPV6_V6ONLY=0) 2020-09-18 17:09:14 us=114338 TCP/UDP: Socket bind failed on local address [AF_INET6][undef]:51194: Address already in use (errno=98) 2020-09-18 17:09:14 us=114376 Exiting due to fatal error 2020-09-18 17:09:14 us=114422 net_route_v4_del: 10.204.1.0/24 via 10.204.1.2 dev [NULL] table 0 metric -1 }}} but now: {{{ # ip route |grep 10.204.1 10.204.1.2 dev tun0 proto kernel scope link src 10.204.1.1 }}} the routes belonging to the *other* instance are gone. Not sure why this happens. I think netlink should tell us ""this route already exists"" and then we should *not* remove it on exit (AFAIR our logic already does ""we only remove routes that we successfully installed"") - but we do not seem to receive this feedback. I have not tested with an ""iproute2"" based openvpn binary, or on other platforms." Gert Döring Active Tickets 1391 Commas in commonName conflict with status_open files like --ifconfig-pool-persist and --status Generic / unclassified OpenVPN git master branch (Community Ed) Bug / Defect new 2021-03-09T08:55:31Z 2021-09-16T12:45:48Z "As the subject already concisely points out, if you have a comma in your commonName, you get entries like these: {{{ # cat /run/openvpn/server-status.log OpenVPN CLIENT LIST Updated,Tue Mar 9 09:41:40 2021 Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since John Doe, Company,1.2.3.4:60900,1399590,4125576,Tue Mar 9 08:17:21 2021 }}} ^- where ""John Doe, Company"" is the commonName, but is spread out over CSV fields 1 and 2. For the `ifconfig-pool-persist` file, this means you could have a commonName with an IP in it, like `CN = John Doe,2.2.2.2` and the persist file could look like this: {{{ # cat /var/spool/openvpn/client-addresses.txt John Doe,2.2.2.2,10.0.0.3 Someone Else,10.0.0.2 }}} As far as I understand, there is no escaping in place and the comma is read as a simple delimiter: https://github.com/OpenVPN/openvpn/blob/v2.4.10/src/openvpn/pool.c#L492-L509 Can we do something about this? The current situation makes CNs with commas troublesome for machine reading of the status files. And it opens up a small possibility for tampering (moving someone else to a different IP, if you can control your CN). Best would probably be to escape the field altogether (percent-encoding the comma and percents, for instance). That would make it backwards incompatible though. Cheers, Walter Doekes OSSO B.V." wdoekes Active Tickets 1437 Documentation for --client-nat is wrong Documentation OpenVPN 2.5.0 (Community Ed) Bug / Defect new 2021-11-08T11:09:24Z 2022-02-04T08:41:39Z "When the man page was converted to rst (commit f500c49c8e0a77ce665b11f6adbea4029cf3b85f) for some reason the documentation for --client-nat was changed and is now wrong. Before: > .B \-\-client\-nat snat|dnat network netmask alias > This pushable client option sets up a stateless one\-to\-one NAT > rule on packet addresses (not ports), and is useful in cases > where routes or ifconfig settings pushed to the client would > create an IP numbering conflict. > > .B network/netmask > (for example 192.168.0.0/255.255.0.0) > defines the local view of a resource from the client perspective, while > .B alias/netmask > (for example 10.64.0.0/255.255.0.0) > defines the remote view from the server perspective. After: > --client-nat args > This pushable client option sets up a stateless one-to-one NAT rule on > packet addresses (not ports), and is useful in cases where routes or > ifconfig settings pushed to the client would create an IP numbering > conflict. > > Examples: > :: > > client-nat snat 192.168.0.0/255.255.0.0 > client-nat dnat 10.64.0.0/255.255.0.0 > > `network/netmask` (for example `192.168.0.0/255.255.0.0`) defines > the local view of a resource from the client perspective, while > `alias/netmask` (for example `10.64.0.0/255.255.0.0`) defines the > remote view from the server perspective. Which is obviously not the same. And the examples just seem to be wrong. Found while looking into https://github.com/OpenVPN/openvpn/pull/86 " flichtenheld Active Tickets 1440 Problem reconnecting when dynamic challenge and password file are used. Generic / unclassified OpenVPN 2.5.4 (Community Ed) Bug / Defect new 2021-11-19T16:23:06Z 2022-12-22T07:31:05Z "I recently set up new VPN servers running OpenVPN CE on Debian (version 2.5.1-3 on server side). Authentication is handled using a service connected to the management socket (management-client-auth is set on the server). Login/password is used to authenticate users, and a dynamic challenge is used to provide MFA. I'm connecting from a Linux Laptop running Debian, running openvpn in a terminal. I tried with Debian's provided version (2.5.1), and newest version available in Openvpn's repository (2.5.4-bullseye0). Login and password are stored in a file referenced by the option ""auth-user-pass client-config.pwd"" When performing initial connection, everything works as expected : - first connection fails with a reason starting with ""AUTH_FAILED,CRV1:"" - a retry is done by the client, prompting the user with the challenge prompt - user enters OTP code - authentication success - session is established So far, so good... Then, if a deconnection occurs (by restarting openvpn service on the server, tried also by disconnecting wi-fi on the laptop), it takes a random time to re-establish connection : - client reconnects and tries to re-send the initial challenge response - auth fails because the user has to go through first authentication step (login/pass), which is expected - new connection is done by providing login/pass automatically (using ""auth-user-pass client-config.pwd""). - connection fails with a reason starting with ""AUTH_FAILED,CRV1:"" - challenge prompt is displayed but.... - ...client starts connecting to the server instantly without letting the user entering OTP code - authentication fails because the answer given to the challenge is an empty string - client retries login/pass, then empty challenge answer, for a random amount of attempts - miraculously, the clients prompts for challenge answer, and lets the user enter the OTP code - authentication success - session is established If I use only ""auth-user-pass"" in client config to enter manually the login/pass, everything works as expected. The issue occurs only when using a file to provide login/pass." N-Mi Active Tickets 1463 Script security warnings - Revisit code and decide WARN or Note ? Generic / unclassified Bug / Defect reopened 2022-04-19T11:49:07Z 2022-05-24T12:06:01Z "OpenVPN 2.5.6 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Mar 16 2022 Config: {{{ script-security 3 up up.sh down down.sh }}} Log (verb 4): {{{ 2022-04-19 12:42:44 us=119164 WARNING: file '/etc/openvpn/tunc_55111u/pki/ta.key' is group or others accessible 2022-04-19 12:42:44 us=119231 WARNING: file '/etc/openvpn/userpass.txt' is group or others accessible 2022-04-19 12:42:44 us=119257 Current Parameter Settings: 2022-04-19 12:42:44 us=119272 config = 'tunc_55111u.conf' 2022-04-19 12:42:44 us=119288 mode = 0 2022-04-19 12:42:44 us=119303 persist_config = DISABLED 2022-04-19 12:42:44 us=119318 persist_mode = 1 2022-04-19 12:42:44 us=119333 show_ciphers = DISABLED 2022-04-19 12:42:44 us=119347 show_digests = DISABLED 2022-04-19 12:42:44 us=119360 show_engines = DISABLED 2022-04-19 12:42:44 us=119377 genkey = DISABLED 2022-04-19 12:42:44 us=119391 genkey_filename = '[UNDEF]' 2022-04-19 12:42:44 us=119405 key_pass_file = '[UNDEF]' 2022-04-19 12:42:44 us=119420 show_tls_ciphers = DISABLED 2022-04-19 12:42:44 us=119437 connect_retry_max = 0 2022-04-19 12:42:44 us=119451 Connection profiles [0]: 2022-04-19 12:42:44 us=119468 proto = tcp-client 2022-04-19 12:42:44 us=119483 local = '[UNDEF]' 2022-04-19 12:42:44 us=119497 local_port = '[UNDEF]' 2022-04-19 12:42:44 us=119512 remote = '10.1.101.226' 2022-04-19 12:42:44 us=119527 remote_port = '55111' 2022-04-19 12:42:44 us=119542 remote_float = DISABLED 2022-04-19 12:42:44 us=119556 bind_defined = DISABLED 2022-04-19 12:42:44 us=119572 bind_local = DISABLED 2022-04-19 12:42:44 us=119586 bind_ipv6_only = DISABLED 2022-04-19 12:42:44 us=119602 connect_retry_seconds = 10 2022-04-19 12:42:44 us=119615 connect_timeout = 20 2022-04-19 12:42:44 us=119631 socks_proxy_server = '[UNDEF]' 2022-04-19 12:42:44 us=119645 socks_proxy_port = '[UNDEF]' 2022-04-19 12:42:44 us=119661 tun_mtu = 1500 2022-04-19 12:42:44 us=119675 tun_mtu_defined = ENABLED 2022-04-19 12:42:44 us=119690 link_mtu = 1500 2022-04-19 12:42:44 us=119703 link_mtu_defined = DISABLED 2022-04-19 12:42:44 us=119720 tun_mtu_extra = 0 2022-04-19 12:42:44 us=119733 tun_mtu_extra_defined = DISABLED 2022-04-19 12:42:44 us=119749 mtu_discover_type = -1 2022-04-19 12:42:44 us=119763 fragment = 0 2022-04-19 12:42:44 us=119779 mssfix = 1450 2022-04-19 12:42:44 us=119793 explicit_exit_notification = 0 2022-04-19 12:42:44 us=119807 tls_auth_file = '/etc/openvpn/tunc_55111u/pki/ta.key' 2022-04-19 12:42:44 us=119823 key_direction = 1 2022-04-19 12:42:44 us=119837 tls_crypt_file = '[UNDEF]' 2022-04-19 12:42:44 us=119851 tls_crypt_v2_file = '[UNDEF]' 2022-04-19 12:42:44 us=119867 Connection profiles END 2022-04-19 12:42:44 us=119880 remote_random = DISABLED 2022-04-19 12:42:44 us=119896 ipchange = '[UNDEF]' 2022-04-19 12:42:44 us=119910 dev = 'tunc55111' 2022-04-19 12:42:44 us=119924 dev_type = '[UNDEF]' 2022-04-19 12:42:44 us=119940 dev_node = '[UNDEF]' 2022-04-19 12:42:44 us=119954 lladdr = '[UNDEF]' 2022-04-19 12:42:44 us=119970 topology = 1 2022-04-19 12:42:44 us=119984 ifconfig_local = '[UNDEF]' 2022-04-19 12:42:44 us=119999 ifconfig_remote_netmask = '[UNDEF]' 2022-04-19 12:42:44 us=120013 ifconfig_noexec = DISABLED 2022-04-19 12:42:44 us=120028 ifconfig_nowarn = DISABLED 2022-04-19 12:42:44 us=120042 ifconfig_ipv6_local = '[UNDEF]' 2022-04-19 12:42:44 us=120058 ifconfig_ipv6_netbits = 0 2022-04-19 12:42:44 us=120072 ifconfig_ipv6_remote = '[UNDEF]' 2022-04-19 12:42:44 us=120087 shaper = 0 2022-04-19 12:42:44 us=120101 mtu_test = 0 2022-04-19 12:42:44 us=120117 mlock = DISABLED 2022-04-19 12:42:44 us=120131 keepalive_ping = 0 2022-04-19 12:42:44 us=120146 keepalive_timeout = 0 2022-04-19 12:42:44 us=120160 inactivity_timeout = 0 2022-04-19 12:42:44 us=120176 inactivity_minimum_bytes = 0 2022-04-19 12:42:44 us=120190 ping_send_timeout = 0 2022-04-19 12:42:44 us=120205 ping_rec_timeout = 0 2022-04-19 12:42:44 us=120220 ping_rec_timeout_action = 0 2022-04-19 12:42:44 us=120235 ping_timer_remote = ENABLED 2022-04-19 12:42:44 us=120249 remap_sigusr1 = 0 2022-04-19 12:42:44 us=120264 persist_tun = DISABLED 2022-04-19 12:42:44 us=120278 persist_local_ip = DISABLED 2022-04-19 12:42:44 us=120293 persist_remote_ip = DISABLED 2022-04-19 12:42:44 us=120307 persist_key = DISABLED 2022-04-19 12:42:44 us=120323 passtos = DISABLED 2022-04-19 12:42:44 us=120337 resolve_retry_seconds = 1000000000 2022-04-19 12:42:44 us=120352 resolve_in_advance = DISABLED 2022-04-19 12:42:44 us=120367 username = '[UNDEF]' 2022-04-19 12:42:44 us=120382 groupname = '[UNDEF]' 2022-04-19 12:42:44 us=120396 chroot_dir = '[UNDEF]' 2022-04-19 12:42:44 us=120411 cd_dir = '[UNDEF]' 2022-04-19 12:42:44 us=120425 writepid = '[UNDEF]' 2022-04-19 12:42:44 us=120441 up_script = 'up.sh' 2022-04-19 12:42:44 us=120455 down_script = 'down.sh' 2022-04-19 12:42:44 us=120470 down_pre = DISABLED 2022-04-19 12:42:44 us=120484 up_restart = DISABLED 2022-04-19 12:42:44 us=120499 up_delay = DISABLED 2022-04-19 12:42:44 us=120513 daemon = DISABLED 2022-04-19 12:42:44 us=120529 inetd = 0 2022-04-19 12:42:44 us=120542 log = DISABLED 2022-04-19 12:42:44 us=120557 suppress_timestamps = DISABLED 2022-04-19 12:42:44 us=120571 machine_readable_output = DISABLED 2022-04-19 12:42:44 us=120586 nice = 0 2022-04-19 12:42:44 us=120600 verbosity = 4 2022-04-19 12:42:44 us=120616 mute = 0 2022-04-19 12:42:44 us=120629 gremlin = 0 2022-04-19 12:42:44 us=120644 status_file = '[UNDEF]' 2022-04-19 12:42:44 us=120658 status_file_version = 1 2022-04-19 12:42:44 us=120674 status_file_update_freq = 60 2022-04-19 12:42:44 us=120688 occ = ENABLED 2022-04-19 12:42:44 us=120704 rcvbuf = 0 2022-04-19 12:42:44 us=120717 sndbuf = 0 2022-04-19 12:42:44 us=120732 mark = 0 2022-04-19 12:42:44 us=120746 sockflags = 0 2022-04-19 12:42:44 us=120761 fast_io = DISABLED 2022-04-19 12:42:44 us=120775 comp.alg = 1 2022-04-19 12:42:44 us=120791 comp.flags = 0 2022-04-19 12:42:44 us=120805 route_script = '[UNDEF]' 2022-04-19 12:42:44 us=120829 route_default_gateway = '[UNDEF]' 2022-04-19 12:42:44 us=120848 route_default_metric = 0 2022-04-19 12:42:44 us=120862 route_noexec = DISABLED 2022-04-19 12:42:44 us=120877 route_delay = 0 2022-04-19 12:42:44 us=120891 route_delay_window = 30 2022-04-19 12:42:44 us=120907 route_delay_defined = DISABLED 2022-04-19 12:42:44 us=120921 route_nopull = DISABLED 2022-04-19 12:42:44 us=120935 route_gateway_via_dhcp = DISABLED 2022-04-19 12:42:44 us=120951 allow_pull_fqdn = DISABLED 2022-04-19 12:42:44 us=120965 Pull filters: 2022-04-19 12:42:44 us=120981 ignore ""route 192.168."" 2022-04-19 12:42:44 us=120995 management_addr = '[UNDEF]' 2022-04-19 12:42:44 us=121011 management_port = '[UNDEF]' 2022-04-19 12:42:44 us=121026 management_user_pass = '[UNDEF]' 2022-04-19 12:42:44 us=121042 management_log_history_cache = 250 2022-04-19 12:42:44 us=121056 management_echo_buffer_size = 100 2022-04-19 12:42:44 us=121070 management_write_peer_info_file = '[UNDEF]' 2022-04-19 12:42:44 us=121087 management_client_user = '[UNDEF]' 2022-04-19 12:42:44 us=121103 management_client_group = '[UNDEF]' 2022-04-19 12:42:44 us=121117 management_flags = 0 2022-04-19 12:42:44 us=121132 shared_secret_file = '[UNDEF]' 2022-04-19 12:42:44 us=121146 key_direction = 1 2022-04-19 12:42:44 us=121164 ciphername = 'AES-256-GCM' 2022-04-19 12:42:44 us=121180 ncp_enabled = ENABLED 2022-04-19 12:42:44 us=121194 ncp_ciphers = 'AES-256-GCM:AES-128-GCM' 2022-04-19 12:42:44 us=121209 authname = 'SHA1' 2022-04-19 12:42:44 us=121225 prng_hash = 'SHA1' 2022-04-19 12:42:44 us=121240 prng_nonce_secret_len = 16 2022-04-19 12:42:44 us=121254 keysize = 0 2022-04-19 12:42:44 us=121270 engine = DISABLED 2022-04-19 12:42:44 us=121284 replay = ENABLED 2022-04-19 12:42:44 us=121298 mute_replay_warnings = DISABLED 2022-04-19 12:42:44 us=121315 replay_window = 64 2022-04-19 12:42:44 us=121329 replay_time = 15 2022-04-19 12:42:44 us=121345 packet_id_file = '[UNDEF]' 2022-04-19 12:42:44 us=121359 test_crypto = DISABLED 2022-04-19 12:42:44 us=121376 tls_server = DISABLED 2022-04-19 12:42:44 us=121391 tls_client = ENABLED 2022-04-19 12:42:44 us=121407 ca_file = '[INLINE]' 2022-04-19 12:42:44 us=121421 ca_path = '[UNDEF]' 2022-04-19 12:42:44 us=121438 dh_file = '[UNDEF]' 2022-04-19 12:42:44 us=121454 cert_file = '[INLINE]' 2022-04-19 12:42:44 us=121469 extra_certs_file = '[UNDEF]' 2022-04-19 12:42:44 us=121485 priv_key_file = '[INLINE]' 2022-04-19 12:42:44 us=121499 pkcs12_file = '[UNDEF]' 2022-04-19 12:42:44 us=121514 cipher_list = '[UNDEF]' 2022-04-19 12:42:44 us=121528 cipher_list_tls13 = '[UNDEF]' 2022-04-19 12:42:44 us=121544 tls_cert_profile = '[UNDEF]' 2022-04-19 12:42:44 us=121558 tls_verify = '[UNDEF]' 2022-04-19 12:42:44 us=121574 tls_export_cert = '[UNDEF]' 2022-04-19 12:42:44 us=121588 verify_x509_type = 2 2022-04-19 12:42:44 us=121604 verify_x509_name = 'v303.tct.secp384r1.s01' 2022-04-19 12:42:44 us=121618 crl_file = '[UNDEF]' 2022-04-19 12:42:44 us=121632 ns_cert_type = 0 2022-04-19 12:42:44 us=121648 remote_cert_ku[i] = 65535 2022-04-19 12:42:44 us=121662 remote_cert_ku[i] = 0 2022-04-19 12:42:44 us=121678 remote_cert_ku[i] = 0 2022-04-19 12:42:44 us=121692 remote_cert_ku[i] = 0 2022-04-19 12:42:44 us=121708 remote_cert_ku[i] = 0 2022-04-19 12:42:44 us=121722 remote_cert_ku[i] = 0 2022-04-19 12:42:44 us=121736 remote_cert_ku[i] = 0 2022-04-19 12:42:44 us=121751 remote_cert_ku[i] = 0 2022-04-19 12:42:44 us=121765 remote_cert_ku[i] = 0 2022-04-19 12:42:44 us=121779 remote_cert_ku[i] = 0 2022-04-19 12:42:44 us=121793 remote_cert_ku[i] = 0 2022-04-19 12:42:44 us=121807 remote_cert_ku[i] = 0 2022-04-19 12:42:44 us=121822 remote_cert_ku[i] = 0 2022-04-19 12:42:44 us=121836 remote_cert_ku[i] = 0 2022-04-19 12:42:44 us=121850 remote_cert_ku[i] = 0 2022-04-19 12:42:44 us=121864 remote_cert_ku[i] = 0 2022-04-19 12:42:44 us=121879 remote_cert_eku = 'TLS Web Server Authentication' 2022-04-19 12:42:44 us=121894 ssl_flags = 3264 2022-04-19 12:42:44 us=121908 tls_timeout = 10 2022-04-19 12:42:44 us=121922 renegotiate_bytes = -1 2022-04-19 12:42:44 us=121936 renegotiate_packets = 0 2022-04-19 12:42:44 us=121951 renegotiate_seconds = 0 2022-04-19 12:42:44 us=121965 handshake_window = 60 2022-04-19 12:42:44 us=121979 transition_window = 3600 2022-04-19 12:42:44 us=121993 single_session = DISABLED 2022-04-19 12:42:44 us=122007 push_peer_info = ENABLED 2022-04-19 12:42:44 us=122021 tls_exit = DISABLED 2022-04-19 12:42:44 us=122035 tls_crypt_v2_metadata = '[UNDEF]' 2022-04-19 12:42:44 us=122049 pkcs11_protected_authentication = DISABLED 2022-04-19 12:42:44 us=122063 pkcs11_protected_authentication = DISABLED 2022-04-19 12:42:44 us=122077 pkcs11_protected_authentication = DISABLED 2022-04-19 12:42:44 us=122093 pkcs11_protected_authentication = DISABLED 2022-04-19 12:42:44 us=122106 pkcs11_protected_authentication = DISABLED 2022-04-19 12:42:44 us=122121 pkcs11_protected_authentication = DISABLED 2022-04-19 12:42:44 us=122135 pkcs11_protected_authentication = DISABLED 2022-04-19 12:42:44 us=122149 pkcs11_protected_authentication = DISABLED 2022-04-19 12:42:44 us=122164 pkcs11_protected_authentication = DISABLED 2022-04-19 12:42:44 us=122178 pkcs11_protected_authentication = DISABLED 2022-04-19 12:42:44 us=122192 pkcs11_protected_authentication = DISABLED 2022-04-19 12:42:44 us=122206 pkcs11_protected_authentication = DISABLED 2022-04-19 12:42:44 us=122221 pkcs11_protected_authentication = DISABLED 2022-04-19 12:42:44 us=122234 pkcs11_protected_authentication = DISABLED 2022-04-19 12:42:44 us=122249 pkcs11_protected_authentication = DISABLED 2022-04-19 12:42:44 us=122263 pkcs11_protected_authentication = DISABLED 2022-04-19 12:42:44 us=122278 pkcs11_private_mode = 00000000 2022-04-19 12:42:44 us=122292 pkcs11_private_mode = 00000000 2022-04-19 12:42:44 us=122306 pkcs11_private_mode = 00000000 2022-04-19 12:42:44 us=122321 pkcs11_private_mode = 00000000 2022-04-19 12:42:44 us=122335 pkcs11_private_mode = 00000000 2022-04-19 12:42:44 us=122349 pkcs11_private_mode = 00000000 2022-04-19 12:42:44 us=122364 pkcs11_private_mode = 00000000 2022-04-19 12:42:44 us=122378 pkcs11_private_mode = 00000000 2022-04-19 12:42:44 us=122392 pkcs11_private_mode = 00000000 2022-04-19 12:42:44 us=122406 pkcs11_private_mode = 00000000 2022-04-19 12:42:44 us=122421 pkcs11_private_mode = 00000000 2022-04-19 12:42:44 us=122435 pkcs11_private_mode = 00000000 2022-04-19 12:42:44 us=122449 pkcs11_private_mode = 00000000 2022-04-19 12:42:44 us=122463 pkcs11_private_mode = 00000000 2022-04-19 12:42:44 us=122477 pkcs11_private_mode = 00000000 2022-04-19 12:42:44 us=122491 pkcs11_private_mode = 00000000 2022-04-19 12:42:44 us=122505 pkcs11_cert_private = DISABLED 2022-04-19 12:42:44 us=122519 pkcs11_cert_private = DISABLED 2022-04-19 12:42:44 us=122533 pkcs11_cert_private = DISABLED 2022-04-19 12:42:44 us=122548 pkcs11_cert_private = DISABLED 2022-04-19 12:42:44 us=122562 pkcs11_cert_private = DISABLED 2022-04-19 12:42:44 us=122575 pkcs11_cert_private = DISABLED 2022-04-19 12:42:44 us=122589 pkcs11_cert_private = DISABLED 2022-04-19 12:42:44 us=122603 pkcs11_cert_private = DISABLED 2022-04-19 12:42:44 us=122618 pkcs11_cert_private = DISABLED 2022-04-19 12:42:44 us=122632 pkcs11_cert_private = DISABLED 2022-04-19 12:42:44 us=122646 pkcs11_cert_private = DISABLED 2022-04-19 12:42:44 us=122660 pkcs11_cert_private = DISABLED 2022-04-19 12:42:44 us=122674 pkcs11_cert_private = DISABLED 2022-04-19 12:42:44 us=122688 pkcs11_cert_private = DISABLED 2022-04-19 12:42:44 us=122702 pkcs11_cert_private = DISABLED 2022-04-19 12:42:44 us=122716 pkcs11_cert_private = DISABLED 2022-04-19 12:42:44 us=122731 pkcs11_pin_cache_period = -1 2022-04-19 12:42:44 us=122745 pkcs11_id = '[UNDEF]' 2022-04-19 12:42:44 us=122759 pkcs11_id_management = DISABLED 2022-04-19 12:42:44 us=122775 server_network = 0.0.0.0 2022-04-19 12:42:44 us=122790 server_netmask = 0.0.0.0 2022-04-19 12:42:44 us=122811 server_network_ipv6 = :: 2022-04-19 12:42:44 us=122825 server_netbits_ipv6 = 0 2022-04-19 12:42:44 us=122840 server_bridge_ip = 0.0.0.0 2022-04-19 12:42:44 us=122855 server_bridge_netmask = 0.0.0.0 2022-04-19 12:42:44 us=122870 server_bridge_pool_start = 0.0.0.0 2022-04-19 12:42:44 us=122886 server_bridge_pool_end = 0.0.0.0 2022-04-19 12:42:44 us=122899 ifconfig_pool_defined = DISABLED 2022-04-19 12:42:44 us=122919 ifconfig_pool_start = 0.0.0.0 2022-04-19 12:42:44 us=122936 ifconfig_pool_end = 0.0.0.0 2022-04-19 12:42:44 us=122952 ifconfig_pool_netmask = 0.0.0.0 2022-04-19 12:42:44 us=122965 ifconfig_pool_persist_filename = '[UNDEF]' 2022-04-19 12:42:44 us=122981 ifconfig_pool_persist_refresh_freq = 600 2022-04-19 12:42:44 us=122994 ifconfig_ipv6_pool_defined = DISABLED 2022-04-19 12:42:44 us=123010 ifconfig_ipv6_pool_base = :: 2022-04-19 12:42:44 us=123025 ifconfig_ipv6_pool_netbits = 0 2022-04-19 12:42:44 us=123039 n_bcast_buf = 256 2022-04-19 12:42:44 us=123053 tcp_queue_limit = 64 2022-04-19 12:42:44 us=123067 real_hash_size = 256 2022-04-19 12:42:44 us=123082 virtual_hash_size = 256 2022-04-19 12:42:44 us=123096 client_connect_script = '[UNDEF]' 2022-04-19 12:42:44 us=123110 learn_address_script = '[UNDEF]' 2022-04-19 12:42:44 us=123124 client_disconnect_script = '[UNDEF]' 2022-04-19 12:42:44 us=123139 client_config_dir = '[UNDEF]' 2022-04-19 12:42:44 us=123153 ccd_exclusive = DISABLED 2022-04-19 12:42:44 us=123167 tmp_dir = '/tmp' 2022-04-19 12:42:44 us=123180 push_ifconfig_defined = DISABLED 2022-04-19 12:42:44 us=123196 push_ifconfig_local = 0.0.0.0 2022-04-19 12:42:44 us=123213 push_ifconfig_remote_netmask = 0.0.0.0 2022-04-19 12:42:44 us=123226 push_ifconfig_ipv6_defined = DISABLED 2022-04-19 12:42:44 us=123242 push_ifconfig_ipv6_local = ::/0 2022-04-19 12:42:44 us=123257 push_ifconfig_ipv6_remote = :: 2022-04-19 12:42:44 us=123270 enable_c2c = DISABLED 2022-04-19 12:42:44 us=123285 duplicate_cn = DISABLED 2022-04-19 12:42:44 us=123299 cf_max = 0 2022-04-19 12:42:44 us=123313 cf_per = 0 2022-04-19 12:42:44 us=123327 max_clients = 1024 2022-04-19 12:42:44 us=123341 max_routes_per_client = 256 2022-04-19 12:42:44 us=123355 auth_user_pass_verify_script = '[UNDEF]' 2022-04-19 12:42:44 us=123369 auth_user_pass_verify_script_via_file = DISABLED 2022-04-19 12:42:44 us=123383 auth_token_generate = DISABLED 2022-04-19 12:42:44 us=123398 auth_token_lifetime = 0 2022-04-19 12:42:44 us=123411 auth_token_secret_file = '[UNDEF]' 2022-04-19 12:42:44 us=123425 port_share_host = '[UNDEF]' 2022-04-19 12:42:44 us=123439 port_share_port = '[UNDEF]' 2022-04-19 12:42:44 us=123453 vlan_tagging = DISABLED 2022-04-19 12:42:44 us=123468 vlan_accept = all 2022-04-19 12:42:44 us=123482 vlan_pvid = 1 2022-04-19 12:42:44 us=123496 client = DISABLED 2022-04-19 12:42:44 us=123510 pull = ENABLED 2022-04-19 12:42:44 us=123524 auth_user_pass_file = '/etc/openvpn/userpass.txt' 2022-04-19 12:42:44 us=123540 OpenVPN 2.5.6 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Mar 16 2022 2022-04-19 12:42:44 us=123562 library versions: OpenSSL 1.1.1f 31 Mar 2020, LZO 2.10 2022-04-19 12:42:44 us=123769 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts 2022-04-19 12:42:44 us=125046 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication 2022-04-19 12:42:44 us=125072 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication 2022-04-19 12:42:44 us=125172 Control Channel MTU parms [ L:1624 D:1182 EF:68 EB:0 ET:0 EL:3 ] 2022-04-19 12:42:44 us=125203 Data Channel MTU parms [ L:1624 D:1450 EF:124 EB:406 ET:0 EL:3 ] 2022-04-19 12:42:44 us=125234 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1552,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,keydir 1,cipher AES-256-GCM,auth [null-digest],keysize 256,tls-auth,key-method 2,tls-client' 2022-04-19 12:42:44 us=125246 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1552,tun-mtu 1500,proto TCPv4_SERVER,comp-lzo,keydir 0,cipher AES-256-GCM,auth [null-digest],keysize 256,tls-auth,key-method 2,tls-server' 2022-04-19 12:42:44 us=125279 TCP/UDP: Preserving recently used remote address: [AF_INET]10.1.101.226:55111 2022-04-19 12:42:44 us=125325 Socket Buffers: R=[131072->131072] S=[16384->16384] 2022-04-19 12:42:44 us=125343 Attempting to establish TCP connection with [AF_INET]10.1.101.226:55111 [nonblock] 2022-04-19 12:42:44 us=126596 TCP connection established with [AF_INET]10.1.101.226:55111 2022-04-19 12:42:44 us=128261 TCP_CLIENT link local: (not bound) 2022-04-19 12:42:44 us=128302 TCP_CLIENT link remote: [AF_INET]10.1.101.226:55111 2022-04-19 12:42:44 us=129751 TLS: Initial packet from [AF_INET]10.1.101.226:55111, sid=8bde60a3 975cfe65 2022-04-19 12:42:44 us=138821 VERIFY OK: depth=1, C=00, ST=tct, L=home, O=tctnet, OU=tctnet-secp384r1, CN=CA tct-secp384r1, emailAddress=me@home.org 2022-04-19 12:42:44 us=141162 VERIFY KU OK 2022-04-19 12:42:44 us=141202 Validating certificate extended key usage 2022-04-19 12:42:44 us=141216 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication 2022-04-19 12:42:44 us=141228 VERIFY EKU OK 2022-04-19 12:42:44 us=141239 VERIFY X509NAME OK: C=00, ST=tct, L=home, O=tctnet, OU=tctnet-secp384r1, CN=v303.tct.secp384r1.s01, emailAddress=me@home.org 2022-04-19 12:42:44 us=141251 VERIFY OK: depth=0, C=00, ST=tct, L=home, O=tctnet, OU=tctnet-secp384r1, CN=v303.tct.secp384r1.s01, emailAddress=me@home.org 2022-04-19 12:42:44 us=160332 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, peer certificate: 384 bit EC, curve secp384r1, signature: ecdsa-with-SHA384 2022-04-19 12:42:44 us=160397 [v303.tct.secp384r1.s01] Peer Connection Initiated with [AF_INET]10.1.101.226:55111 2022-04-19 12:42:44 us=161663 Key [AF_INET]10.1.101.226:55111 [0] not initialized (yet), dropping packet. 2022-04-19 12:42:44 us=205964 PUSH: Received control message: 'PUSH_REPLY,block-ipv6,topology subnet,explicit-exit-notify 3,comp-lzo no,compress,route-gateway 10.55.111.225,topology subnet,route 10.7.39.137,ping 0,ping-restart 0,ping 10,ping-restart 30,ifconfig 10.55.111.254 255.255.255.224,peer-id 0,cipher AES-256-GCM' 2022-04-19 12:42:44 us=206185 OPTIONS IMPORT: timers and/or timeouts modified 2022-04-19 12:42:44 us=206386 OPTIONS IMPORT: --explicit-exit-notify can only be used with --proto udp 2022-04-19 12:42:44 us=206493 OPTIONS IMPORT: compression parms modified 2022-04-19 12:42:44 us=206562 OPTIONS IMPORT: --ifconfig/up options modified 2022-04-19 12:42:44 us=206582 OPTIONS IMPORT: route options modified 2022-04-19 12:42:44 us=206594 OPTIONS IMPORT: route-related options modified 2022-04-19 12:42:44 us=206606 OPTIONS IMPORT: peer-id set 2022-04-19 12:42:44 us=206618 OPTIONS IMPORT: adjusting link_mtu to 1627 2022-04-19 12:42:44 us=206630 OPTIONS IMPORT: data channel crypto options modified 2022-04-19 12:42:44 us=206759 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key 2022-04-19 12:42:44 us=206784 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key 2022-04-19 12:42:44 us=207009 ROUTE_GATEWAY 10.1.101.1/255.255.255.0 IFACE=enp5s0 HWADDR=24:b6:fd:31:bc:ca 2022-04-19 12:42:44 us=207555 TUN/TAP device tunc55111 opened 2022-04-19 12:42:44 us=207609 do_ifconfig, ipv4=1, ipv6=0 2022-04-19 12:42:44 us=207637 /sbin/ip link set dev tunc55111 up mtu 1500 2022-04-19 12:42:44 us=211074 /sbin/ip link set dev tunc55111 up 2022-04-19 12:42:44 us=214581 /sbin/ip addr add dev tunc55111 10.55.111.254/27 2022-04-19 12:42:44 us=220597 up.sh tunc55111 1500 1627 10.55.111.254 255.255.255.224 init ******** * * * UP * * * ******** 2022-04-19 12:42:44 us=221760 /sbin/ip route add 10.7.39.137/32 via 10.55.111.225 2022-04-19 12:42:44 us=223613 Initialization Sequence Completed }}} " tct Active Tickets 1471 State stuck at AUTH after reneg failure and recovery Generic / unclassified OpenVPN 2.5.7 (Community Ed) Bug / Defect new 2022-07-28T03:59:37Z 2023-01-07T21:45:51Z "(client version 2.5.7) After a successful connection, if a subsequent reneg fails, a new TLS session gets established, but the state as reported by management interface never proceeds beyond ""AUTH"". The connection is, however, up and working. For a management client that connects mid-session this is confusing if not impossible to handle without some hackery like parsing log history to check how it got there. Here is a snippet from interaction with the management interface of a client that is initially in state = CONNECTED. reneg-sec is set to 60 for debugging. {{{ state 1658699592,CONNECTED,SUCCESS,10.9.0.4,192.z.x.y,1194,,,26xx:x:x:x::1002 log on >LOG:1658699711,,TLS: soft reset sec=60/60 bytes=2640/-1 pkts=24/0 }}} Just before this point I start a new connection with same common-name which causes the server to drop this session. The next reneg fails and new session starts. {{{ >LOG:1658699771,N,TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) >LOG:1658699771,N,TLS Error: TLS handshake failed >LOG:1658699771,,TLS: move_session: dest=TM_LAME_DUCK src=TM_ACTIVE reinit_src=1 >LOG:1658699786,,MANAGEMENT: >STATE:1658699786,WAIT,,,,,, >STATE:1658699786,WAIT,,,,,, >LOG:1658699786,,MANAGEMENT: >STATE:1658699786,AUTH,,,,,, >STATE:1658699786,AUTH,,,,,, >LOG:1658699786,,TLS: Initial packet from [AF_INET]192.z.x.y:1194, sid=f37f1560 944674f0 >LOG:1658699786,,VERIFY OK: depth=1, C=CA, ST=ON, L=Toronto, O=x, OU=x, CN=x, emailAddress=x@y >LOG:1658699786,,VERIFY OK: nsCertType=SERVER >LOG:1658699786,,VERIFY OK: depth=0, C=CA, ST=ON, L=Toronto, O=x, OU=x, CN=ec-384r1, name=server, emailAddress=x@y >LOG:1658699786,,Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 384 bit EC, curve secp384r1, signature: RSA-SHA256 >LOG:1658699787,,PUSH: Received control message: 'PUSH_REPLY,route 192.x.y.0 255.255.255.0,explicit-exit-notify 1,tun-ipv6,tun-ipv6,route-gateway 10.9.0.1,topology subnet,ping 30,ping-restart 120,ifconfig-ipv6 26x:x:x:x::1002/64 26x:x:x:x::1,ifconfig 10.9.0.4 255.255.255.0,peer-id 0,cipher AES-256-GCM' >LOG:1658699787,,Pushed option removed by filter: 'route 192.168.0.0 255.255.255.0' }}} At this point state = AUTH and it never changes. The client does not seem to treat this as a new connection(as do_up() is already done?). Subsequent renegs succeed as seen below. {{{ >LOG:1658699846,,TLS: soft reset sec=60/60 bytes=0/-1 pkts=0/0 >LOG:1658699846,,VERIFY OK: depth=1, C=CA, ST=ON, L=Toronto, O=x, OU=x, CN=x, emailAddress=x@y >LOG:1658699846,,VERIFY OK: nsCertType=SERVER >LOG:1658699846,,VERIFY OK: depth=0, C=CA, ST=ON, L=Toronto, O=x, OU=x, CN=ec-384r1, name=server, emailAddress=x@y >LOG:1658699846,,Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key >LOG:1658699846,,Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key >LOG:1658699846,,Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 384 bit EC, curve secp384r1, signature: RSA-SHA256 >LOG:1658699907,,TLS: soft reset sec=61/60 bytes=0/-1 pkts=0/0 }}} and on and on. State not changing to CONNECTED looks like a bug to me." Selva Nair Active Tickets 925 Encrypted Backend Management Interface Management OpenVPN 2.3.13 (Community Ed) Feature Wish new 2017-08-08T16:46:20Z 2017-09-15T02:50:00Z "Hi, Your documentation mentions the management interface, at least in the community version, is not secured and thus needs to be run over a unix socket or localhost interface. This is odd for a VPN to not have a secured management interface. Having non-cleartext for management interface by default would be a major security improvement to OpenVPN along with having a U/P for Authentication. Thanks, Tony-Caffe" tony-caffe Active Tickets 978 HMAC authentication failed error message lacking IP address Generic / unclassified OpenVPN 2.4.4 (Community Ed) Feature Wish new 2018-01-11T22:35:00Z 2018-01-11T22:35:00Z "From the log (server side): Jan 11 15:47:42 openvpn udp[585]: Authenticate/Decrypt packet error: packet HMAC authentication failed this makes debugging unnecessary difficult, since it doesn't display a source IP. " hildeb Active Tickets 1485 Saving PIN for OpenVPN client Configuration OpenVPN 2.5.7 (Community Ed) Feature Wish new 2022-11-20T22:31:51Z 2022-11-20T23:09:06Z "OpenVPN supports Smart cards and multi-factor authentication. In the majority of use-cases additional authentication data for Smart cards (PINs) and for multi-factor authentication should be entered interactively. But there are very special use cases, where interactive entry of authentication data is not possible. On of such use-cases is ""Start Before Logon"" (see https://github.com/OpenVPN/openvpn-gui/issues/77). Username and password can be saved via the option ""auth-user-pass"" and a username/password file. Unfortunately there is no such option for saving the PIN for Smart cards. Again in most cases PINs should not be saved. But in the ""Start Before Logon"" use-case OpenVPN can not query the PIN interactively. That's why an option to save PINs is needed, similar to to ""auth-user-pass"". This would is make possible to configure laptops which automatically start an OpenVPN client before client, but only if the Smart card is inserted." Bjoern Voigt Active Tickets 894 (v)s(n)printf hardening Generic / unclassified OpenVPN 2.2.2 (Community Ed) Patch submission new 2017-05-23T19:34:15Z 2019-04-05T12:38:03Z "vsnprintf is a function that can fail. It will always fail for strings that require over 2 gigabytes of buffer space, for the simple reason that this size cannot unambiguously be expressed in its return value; a return value of >= 0 means that that many bytes were written to the buffer, and a negative return value indicates overall failure. Because the largest positive value of a signed int is 2 gigabytes, buffer consumption is limited to that amount. For some format strings, snprintf will also internally allocate (usually small) heap buffers, and will return failure if any of these allocations fail. I believe the FreeBSD internal dtoa() function allocates heap memory, for instance. A memory leak in the main program that can grow so large that vsnprintf cannot allocate its private buffers, will result in failure. In principle, the main program (OpenVPN) can never assume that a call to vsnprintf succeeds, unless it returns a non-negative integer. This is the current openvpn_snprintf in openvpn: {{{ 277 bool 278 openvpn_snprintf(char *str, size_t size, const char *format, ...) 279 { 280 va_list arglist; 281 int len = -1; 282 if (size > 0) 283 { 284 va_start(arglist, format); 285 len = vsnprintf(str, size, format, arglist); 286 va_end(arglist); 287 str[size - 1] = 0; 288 } 289 return (len >= 0 && len < size); 290 } }}} The vsnprintf specifications do not give a clear definition on what the contents of the output buffer may be if the function fails. Hence, if the call to vsnprintf within openvpn_snprintf fails, the space str[0..size-1] may be uninitialized data. Many calls to openvpn_snprintf do not check its return value, so if vsnprintf fails, and the buffer contents is subsequently written to the peer (or to any other channel, like a file), this could constitute a significant data leak. Also overlapping parameters will produce undefined buffer contents. man vsnprintf explicitly says: {{{ Some programs imprudently rely on code such as the following sprintf(buf, ""%s some further text"", buf); to append text to buf. However, the standards explicitly note that the results are undefined if source and destination buffers overlap when calling sprintf(), snprintf(), vsprintf(), and vsnprintf(). Depending on the version of gcc(1) used, and the compiler options employed, calls such as the above will not produce the expected results. }}} These are definitely corner cases, and I'm not aware of an easy to to force vsnprintf failure in openvpn. But the stakes are high (private crypto data and what have you), and other bugs (excessive string generation that is then sprintf'ed, overlapping strings, memory shortage) might lead to a significant security problem this way, so my I'm attaching a patch that ensures that the final contents of the output string is always a valid string that does not contain uninitialized or unrelated data (barring any bugs in the implementation of vsnprintf, which is outside OpenVPN's responsibility or control). Guido" gvranken Active Tickets 1189 regarding unpriv-ip command Generic / unclassified Patch submission reopened 2019-05-30T13:48:48Z 2020-09-01T12:25:31Z "you could add following to your ip wrapper to disallow invoking commands this could be done by using not allowed commands also to iterate through... best regards ip-unpriv.sh #!/bin/sh allowed_cmds=(""route"" ""asdf"") chk=() for((i=0; i<${#allowed_cmds[@]}; i+=1)) do if [ ! ""$( echo $1 | grep ${allowed_cmds[$i]} )"" = """" ] then chk[$i]=1 else chk[$i]=0 fi done for((i=0; i<${#chk[@]}; i+=1)) do if [ ${chk[$i]} = 1 ] then sudo /bin/ip $* fi done" b4sh Active Tickets 949 Forward Error Correction for OpenVPN Generic / unclassified TODO (General task list) new 2017-10-20T17:39:17Z 2022-02-02T12:01:57Z "As discussed in this thread,FEC can improve the connection quality on a lossy link: https://forums.openvpn.net/viewtopic.php?f=10&t=14395 I have implemented the feature and did some test.The algorithm for FEC is Reed-Solomon. = Test Result == environment openvpn client running inside a single core VPS in Tokyo,with 512mb ram openvpn server running inside a single core VPS in Los Angeles,with 128mb ram. The network roundtrip between two machines is about 110~120ms.A simulated packet loss of 10% is introduced at both direction. The parameter for FEC is 20:10,that means sending 10 redundant packets for every 20 original packets.It costs about 1.5 times of bandwidth when compared with original data stream.(A packet loss of 10% is actually very high. For lower packet loss,sure,you can reduce the FEC parameter and use less bandwidth) == SCP TCP single thread copy test OpenVPN without FEC {{{ $ scp 0.test.file 10.222.2.1:~ root@10.222.2.1's password: 0.test.file 0% 3600KB 29.5KB/s 3:25:38 ETA }}} OpenVPN with FEC {{{ $ scp 0.test.file 10.222.2.1:~ root@10.222.2.1's password: 0.test.file 45% 162MB 3.6MB/s 00:55 ETA }}} == ping packet loss test OpenVPN without FEC {{{ $ ping 10.222.2.1 -O PING 10.222.2.1 (10.222.2.1) 56(84) bytes of data. 64 bytes from 10.222.2.1: icmp_seq=1 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=2 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=3 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=4 ttl=64 time=118 ms no answer yet for icmp_seq=5 64 bytes from 10.222.2.1: icmp_seq=6 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=7 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=8 ttl=64 time=118 ms no answer yet for icmp_seq=9 64 bytes from 10.222.2.1: icmp_seq=10 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=11 ttl=64 time=118 ms no answer yet for icmp_seq=12 64 bytes from 10.222.2.1: icmp_seq=13 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=14 ttl=64 time=118 ms no answer yet for icmp_seq=15 64 bytes from 10.222.2.1: icmp_seq=16 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=17 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=18 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=19 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=20 ttl=64 time=118 ms no answer yet for icmp_seq=21 64 bytes from 10.222.2.1: icmp_seq=22 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=23 ttl=64 time=118 ms no answer yet for icmp_seq=24 64 bytes from 10.222.2.1: icmp_seq=25 ttl=64 time=119 ms 64 bytes from 10.222.2.1: icmp_seq=26 ttl=64 time=118 ms no answer yet for icmp_seq=27 64 bytes from 10.222.2.1: icmp_seq=28 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=29 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=30 ttl=64 time=119 ms 64 bytes from 10.222.2.1: icmp_seq=31 ttl=64 time=118 ms no answer yet for icmp_seq=32 64 bytes from 10.222.2.1: icmp_seq=33 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=34 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=35 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=36 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=37 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=38 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=39 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=40 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=41 ttl=64 time=118 ms no answer yet for icmp_seq=42 no answer yet for icmp_seq=43 64 bytes from 10.222.2.1: icmp_seq=44 ttl=64 time=118 ms ^C --- 10.222.2.1 ping statistics --- 44 packets transmitted, 34 received, 22% packet loss, time 43038ms rtt min/avg/max/mdev = 118.289/118.712/119.959/0.530 ms }}} OpenVPN with FEC {{{ $ ping 10.222.2.1 -O PING 10.222.2.1 (10.222.2.1) 56(84) bytes of data. 64 bytes from 10.222.2.1: icmp_seq=1 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=2 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=3 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=4 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=5 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=6 ttl=64 time=129 ms 64 bytes from 10.222.2.1: icmp_seq=7 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=8 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=9 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=10 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=11 ttl=64 time=122 ms 64 bytes from 10.222.2.1: icmp_seq=12 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=13 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=14 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=15 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=16 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=17 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=18 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=19 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=20 ttl=64 time=129 ms 64 bytes from 10.222.2.1: icmp_seq=21 ttl=64 time=120 ms 64 bytes from 10.222.2.1: icmp_seq=22 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=23 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=24 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=25 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=26 ttl=64 time=137 ms 64 bytes from 10.222.2.1: icmp_seq=27 ttl=64 time=120 ms 64 bytes from 10.222.2.1: icmp_seq=28 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=29 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=30 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=31 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=32 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=33 ttl=64 time=120 ms 64 bytes from 10.222.2.1: icmp_seq=34 ttl=64 time=122 ms 64 bytes from 10.222.2.1: icmp_seq=35 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=36 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=37 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=38 ttl=64 time=129 ms 64 bytes from 10.222.2.1: icmp_seq=39 ttl=64 time=120 ms 64 bytes from 10.222.2.1: icmp_seq=40 ttl=64 time=129 ms 64 bytes from 10.222.2.1: icmp_seq=41 ttl=64 time=129 ms ^C --- 10.222.2.1 ping statistics --- 41 packets transmitted, 41 received, 0% packet loss, time 40046ms rtt min/avg/max/mdev = 120.908/122.719/137.724/3.535 ms }}} == summary Looks like it does have improved the connection quality on a lossy link. I hope this feature can be integrated into OpenVPN.I want to know how the developer team think about it. If the feature is acceptable,I can try to make patch. " wangyucn Active Tickets 858 radiusplugin: The server stop responding (std::out_of_range) Generic / unclassified OpenVPN 2.4.0 (Community Ed) Bug / Defect reopened 2017-03-22T14:28:24Z 2023-09-21T15:52:45Z "Hello, I try to use OpenVPN 2.4.0 on CentOS 6.8 i686 (OpenVPN 2.4.0 i686-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Mar 17 2017) And i have this error: {{{ terminate called after throwing an instance of 'std::out_of_range' what(): basic_string::replace }}} '''openvpn server start:''' {{{ Wed Mar 22 14:43:30 2017 us=423214 Current Parameter Settings: Wed Mar 22 14:43:30 2017 us=423267 config = 'server-tun.conf' Wed Mar 22 14:43:30 2017 us=423275 mode = 1 Wed Mar 22 14:43:30 2017 us=423281 persist_config = DISABLED Wed Mar 22 14:43:30 2017 us=423275 mode = 1 Wed Mar 22 14:43:30 2017 us=423281 persist_config = DISABLED Wed Mar 22 14:43:30 2017 us=423286 persist_mode = 1 Wed Mar 22 14:43:30 2017 us=423291 show_ciphers = DISABLED Wed Mar 22 14:43:30 2017 us=423295 show_digests = DISABLED Wed Mar 22 14:43:30 2017 us=423295 show_digests = DISABLED Wed Mar 22 14:43:30 2017 us=423317 show_engines = DISABLED Wed Mar 22 14:43:30 2017 us=423322 genkey = DISABLED Wed Mar 22 14:43:30 2017 us=423327 key_pass_file = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423334 show_tls_ciphers = DISABLED Wed Mar 22 14:43:30 2017 us=423334 show_tls_ciphers = DISABLED Wed Mar 22 14:43:30 2017 us=423339 connect_retry_max = 0 Wed Mar 22 14:43:30 2017 us=423344 Connection profiles [0]: Wed Mar 22 14:43:30 2017 us=423351 proto = tcp-server Wed Mar 22 14:43:30 2017 us=423351 proto = tcp-server Wed Mar 22 14:43:30 2017 us=423356 local = '213.25.35.131' Wed Mar 22 14:43:30 2017 us=423356 local = '213.25.35.131' Wed Mar 22 14:43:30 2017 us=423361 local_port = '443' Wed Mar 22 14:43:30 2017 us=423361 local_port = '443' Wed Mar 22 14:43:30 2017 us=423366 remote = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423371 remote_port = '443' Wed Mar 22 14:43:30 2017 us=423377 remote_float = DISABLED Wed Mar 22 14:43:30 2017 us=423377 remote_float = DISABLED Wed Mar 22 14:43:30 2017 us=423382 bind_defined = DISABLED Wed Mar 22 14:43:30 2017 us=423386 bind_local = ENABLED Wed Mar 22 14:43:30 2017 us=423394 bind_ipv6_only = DISABLED Wed Mar 22 14:43:30 2017 us=423394 bind_ipv6_only = DISABLED Wed Mar 22 14:43:30 2017 us=423399 connect_retry_seconds = 5 Wed Mar 22 14:43:30 2017 us=423399 connect_retry_seconds = 5 Wed Mar 22 14:43:30 2017 us=423404 connect_timeout = 120 Wed Mar 22 14:43:30 2017 us=423404 connect_timeout = 120 Wed Mar 22 14:43:30 2017 us=423409 socks_proxy_server = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423409 socks_proxy_server = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423414 socks_proxy_port = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423414 socks_proxy_port = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423418 tun_mtu = 1500 Wed Mar 22 14:43:30 2017 us=423418 tun_mtu = 1500 Wed Mar 22 14:43:30 2017 us=423423 tun_mtu_defined = ENABLED Wed Mar 22 14:43:30 2017 us=423423 tun_mtu_defined = ENABLED Wed Mar 22 14:43:30 2017 us=423428 link_mtu = 1500 Wed Mar 22 14:43:30 2017 us=423428 link_mtu = 1500 Wed Mar 22 14:43:30 2017 us=423433 link_mtu_defined = DISABLED Wed Mar 22 14:43:30 2017 us=423433 link_mtu_defined = DISABLED Wed Mar 22 14:43:30 2017 us=423438 tun_mtu_extra = 0 Wed Mar 22 14:43:30 2017 us=423442 tun_mtu_extra_defined = DISABLED Wed Mar 22 14:43:30 2017 us=423449 mtu_discover_type = -1 Wed Mar 22 14:43:30 2017 us=423454 fragment = 0 Wed Mar 22 14:43:30 2017 us=423459 mssfix = 1450 Wed Mar 22 14:43:30 2017 us=423465 explicit_exit_notification = 0 Wed Mar 22 14:43:30 2017 us=423470 Connection profiles END Wed Mar 22 14:43:30 2017 us=423476 remote_random = DISABLED Wed Mar 22 14:43:30 2017 us=423476 remote_random = DISABLED Wed Mar 22 14:43:30 2017 us=423481 ipchange = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423486 dev = 'tun' Wed Mar 22 14:43:30 2017 us=423491 dev_type = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423497 dev_node = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423497 dev_node = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423502 lladdr = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423502 lladdr = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423507 topology = 3 Wed Mar 22 14:43:30 2017 us=423512 ifconfig_local = '172.16.120.129' Wed Mar 22 14:43:30 2017 us=423519 ifconfig_remote_netmask = '255.255.255.192' Wed Mar 22 14:43:30 2017 us=423519 ifconfig_remote_netmask = '255.255.255.192' Wed Mar 22 14:43:30 2017 us=423524 ifconfig_noexec = DISABLED Wed Mar 22 14:43:30 2017 us=423528 ifconfig_nowarn = DISABLED Wed Mar 22 14:43:30 2017 us=423528 ifconfig_nowarn = DISABLED Wed Mar 22 14:43:30 2017 us=423533 ifconfig_ipv6_local = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423533 ifconfig_ipv6_local = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423538 ifconfig_ipv6_netbits = 0 Wed Mar 22 14:43:30 2017 us=423544 ifconfig_ipv6_remote = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423550 shaper = 0 Wed Mar 22 14:43:30 2017 us=423550 shaper = 0 Wed Mar 22 14:43:30 2017 us=423555 mtu_test = 0 Wed Mar 22 14:43:30 2017 us=423560 mlock = DISABLED Wed Mar 22 14:43:30 2017 us=423566 keepalive_ping = 10 Wed Mar 22 14:43:30 2017 us=423571 keepalive_timeout = 60 Wed Mar 22 14:43:30 2017 us=423579 inactivity_timeout = 0 Wed Mar 22 14:43:30 2017 us=423579 inactivity_timeout = 0 Wed Mar 22 14:43:30 2017 us=423584 ping_send_timeout = 10 Wed Mar 22 14:43:30 2017 us=423584 ping_send_timeout = 10 Wed Mar 22 14:43:30 2017 us=423589 ping_rec_timeout = 120 Wed Mar 22 14:43:30 2017 us=423589 ping_rec_timeout = 120 Wed Mar 22 14:43:30 2017 us=423593 ping_rec_timeout_action = 2 Wed Mar 22 14:43:30 2017 us=423593 ping_rec_timeout_action = 2 Wed Mar 22 14:43:30 2017 us=423598 ping_timer_remote = ENABLED Wed Mar 22 14:43:30 2017 us=423598 ping_timer_remote = ENABLED Wed Mar 22 14:43:30 2017 us=423602 remap_sigusr1 = 0 Wed Mar 22 14:43:30 2017 us=423602 remap_sigusr1 = 0 Wed Mar 22 14:43:30 2017 us=423607 persist_tun = ENABLED Wed Mar 22 14:43:30 2017 us=423607 persist_tun = ENABLED Wed Mar 22 14:43:30 2017 us=423612 persist_local_ip = DISABLED Wed Mar 22 14:43:30 2017 us=423612 persist_local_ip = DISABLED Wed Mar 22 14:43:30 2017 us=423617 persist_remote_ip = DISABLED Wed Mar 22 14:43:30 2017 us=423617 persist_remote_ip = DISABLED Wed Mar 22 14:43:30 2017 us=423622 persist_key = ENABLED Wed Mar 22 14:43:30 2017 us=423626 passtos = DISABLED Wed Mar 22 14:43:30 2017 us=423633 resolve_retry_seconds = 1000000000 Wed Mar 22 14:43:30 2017 us=423633 resolve_retry_seconds = 1000000000 Wed Mar 22 14:43:30 2017 us=423638 resolve_in_advance = DISABLED Wed Mar 22 14:43:30 2017 us=423644 username = 'openvpn' Wed Mar 22 14:43:30 2017 us=423651 groupname = 'openvpn' Wed Mar 22 14:43:30 2017 us=423656 chroot_dir = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423660 cd_dir = '/etc/openvpn' Wed Mar 22 14:43:30 2017 us=423666 writepid = '/var/run/openvpn/server-tun.pid' Wed Mar 22 14:43:30 2017 us=423679 up_script = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423679 up_script = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423684 down_script = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423689 down_pre = DISABLED Wed Mar 22 14:43:30 2017 us=423693 up_restart = DISABLED Wed Mar 22 14:43:30 2017 us=423703 up_delay = DISABLED Wed Mar 22 14:43:30 2017 us=423710 daemon = ENABLED Wed Mar 22 14:43:30 2017 us=423715 inetd = 0 Wed Mar 22 14:43:30 2017 us=423719 log = ENABLED Wed Mar 22 14:43:30 2017 us=423723 suppress_timestamps = DISABLED Wed Mar 22 14:43:30 2017 us=423727 machine_readable_output = DISABLED Wed Mar 22 14:43:30 2017 us=423731 nice = 0 Wed Mar 22 14:43:30 2017 us=423735 verbosity = 4 Wed Mar 22 14:43:30 2017 us=423739 mute = 0 Wed Mar 22 14:43:30 2017 us=423743 gremlin = 0 Wed Mar 22 14:43:30 2017 us=423747 status_file = '/var/log/openvpn/openvpn-status-tun.log' Wed Mar 22 14:43:30 2017 us=423751 status_file_version = 1 Wed Mar 22 14:43:30 2017 us=423755 status_file_update_freq = 1 Wed Mar 22 14:43:30 2017 us=423759 occ = ENABLED Wed Mar 22 14:43:30 2017 us=423763 rcvbuf = 0 Wed Mar 22 14:43:30 2017 us=423767 sndbuf = 0 Wed Mar 22 14:43:30 2017 us=423771 mark = 0 Wed Mar 22 14:43:30 2017 us=423775 sockflags = 0 Wed Mar 22 14:43:30 2017 us=423779 fast_io = DISABLED Wed Mar 22 14:43:30 2017 us=423783 comp.alg = 2 Wed Mar 22 14:43:30 2017 us=423787 comp.flags = 0 Wed Mar 22 14:43:30 2017 us=423791 route_script = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423795 route_default_gateway = '172.16.120.130' Wed Mar 22 14:43:30 2017 us=423800 route_default_metric = 0 Wed Mar 22 14:43:30 2017 us=423804 route_noexec = DISABLED Wed Mar 22 14:43:30 2017 us=423808 route_delay = 0 Wed Mar 22 14:43:30 2017 us=423812 route_delay_window = 30 Wed Mar 22 14:43:30 2017 us=423816 route_delay_defined = DISABLED Wed Mar 22 14:43:30 2017 us=423820 route_nopull = DISABLED Wed Mar 22 14:43:30 2017 us=423824 route_gateway_via_dhcp = DISABLED Wed Mar 22 14:43:30 2017 us=423828 allow_pull_fqdn = DISABLED Wed Mar 22 14:43:30 2017 us=423832 management_addr = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423836 management_port = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423840 management_user_pass = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423844 management_log_history_cache = 250 Wed Mar 22 14:43:30 2017 us=423849 management_echo_buffer_size = 100 Wed Mar 22 14:43:30 2017 us=423853 management_write_peer_info_file = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423857 management_client_user = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423861 management_client_group = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423865 management_flags = 0 Wed Mar 22 14:43:30 2017 us=423871 plugin[0] /etc/openvpn/plugin/radiusplugin-wo_acc.so '[/etc/openvpn/plugin/radiusplugin-wo_acc.so] [/etc/openvpn/radiusplugin-tun.cnf]' Wed Mar 22 14:43:30 2017 us=423875 shared_secret_file = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423880 key_direction = 1 Wed Mar 22 14:43:30 2017 us=423884 ciphername = 'AES-128-CBC' Wed Mar 22 14:43:30 2017 us=423888 ncp_enabled = ENABLED Wed Mar 22 14:43:30 2017 us=423892 ncp_ciphers = 'AES-128-GCM:AES-128-CBC:AES-256-GCM:AES-256-CBC' Wed Mar 22 14:43:30 2017 us=423897 authname = 'SHA1' Wed Mar 22 14:43:30 2017 us=423901 prng_hash = 'SHA1' Wed Mar 22 14:43:30 2017 us=423905 prng_nonce_secret_len = 16 Wed Mar 22 14:43:30 2017 us=423909 keysize = 16 Wed Mar 22 14:43:30 2017 us=423913 engine = DISABLED Wed Mar 22 14:43:30 2017 us=423917 replay = ENABLED Wed Mar 22 14:43:30 2017 us=423921 mute_replay_warnings = DISABLED Wed Mar 22 14:43:30 2017 us=423925 replay_window = 64 Wed Mar 22 14:43:30 2017 us=423930 replay_time = 15 Wed Mar 22 14:43:30 2017 us=423934 packet_id_file = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423938 use_iv = ENABLED Wed Mar 22 14:43:30 2017 us=423942 test_crypto = DISABLED Wed Mar 22 14:43:30 2017 us=423946 tls_server = ENABLED Wed Mar 22 14:43:30 2017 us=423950 tls_client = DISABLED Wed Mar 22 14:43:30 2017 us=423954 key_method = 2 Wed Mar 22 14:43:30 2017 us=423958 ca_file = '/etc/openvpn/private/cavpn_cert.pem' Wed Mar 22 14:43:30 2017 us=423966 ca_path = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423971 dh_file = '/etc/openvpn/private/dh2048.pem' Wed Mar 22 14:43:30 2017 us=423975 cert_file = '/etc/openvpn/private/server.pem' Wed Mar 22 14:43:30 2017 us=423979 extra_certs_file = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423983 priv_key_file = '/etc/openvpn/private/server.key' Wed Mar 22 14:43:30 2017 us=423988 pkcs12_file = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423992 cipher_list = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423996 tls_verify = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=424000 tls_export_cert = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=424004 verify_x509_type = 0 Wed Mar 22 14:43:30 2017 us=424008 verify_x509_name = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=424012 crl_file = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=424016 ns_cert_type = 0 Wed Mar 22 14:43:30 2017 us=424020 remote_cert_ku[i] = 0 Wed Mar 22 14:43:30 2017 us=424024 remote_cert_ku[i] = 0 Wed Mar 22 14:43:30 2017 us=424028 remote_cert_ku[i] = 0 Wed Mar 22 14:43:30 2017 us=424032 remote_cert_ku[i] = 0 Wed Mar 22 14:43:30 2017 us=424035 remote_cert_ku[i] = 0 Wed Mar 22 14:43:30 2017 us=424039 remote_cert_ku[i] = 0 Wed Mar 22 14:43:30 2017 us=424043 remote_cert_ku[i] = 0 Wed Mar 22 14:43:30 2017 us=424047 remote_cert_ku[i] = 0 Wed Mar 22 14:43:30 2017 us=424051 remote_cert_ku[i] = 0 Wed Mar 22 14:43:30 2017 us=424064 remote_cert_ku[i] = 0 Wed Mar 22 14:43:30 2017 us=424068 remote_cert_ku[i] = 0 Wed Mar 22 14:43:30 2017 us=424072 remote_cert_ku[i] = 0 Wed Mar 22 14:43:30 2017 us=424076 remote_cert_ku[i] = 0 Wed Mar 22 14:43:30 2017 us=424079 remote_cert_ku[i] = 0 Wed Mar 22 14:43:30 2017 us=424083 remote_cert_ku[i] = 0 Wed Mar 22 14:43:30 2017 us=424087 remote_cert_ku[i] = 0 Wed Mar 22 14:43:30 2017 us=424091 remote_cert_eku = 'TLS Web Client Authentication' Wed Mar 22 14:43:30 2017 us=424095 ssl_flags = 132 Wed Mar 22 14:43:30 2017 us=424099 tls_timeout = 10 Wed Mar 22 14:43:30 2017 us=424104 renegotiate_bytes = -1 Wed Mar 22 14:43:30 2017 us=424108 renegotiate_packets = 0 Wed Mar 22 14:43:30 2017 us=424112 renegotiate_seconds = 1800 Wed Mar 22 14:43:30 2017 us=424116 handshake_window = 60 Wed Mar 22 14:43:30 2017 us=424120 transition_window = 3600 Wed Mar 22 14:43:30 2017 us=424124 single_session = DISABLED Wed Mar 22 14:43:30 2017 us=424128 push_peer_info = DISABLED Wed Mar 22 14:43:30 2017 us=424132 tls_exit = DISABLED Wed Mar 22 14:43:30 2017 us=424136 tls_auth_file = '[[INLINE]]' Wed Mar 22 14:43:30 2017 us=424140 tls_crypt_file = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=424146 server_network = 172.16.120.128 Wed Mar 22 14:43:30 2017 us=424150 server_netmask = 255.255.255.192 Wed Mar 22 14:43:30 2017 us=424156 server_network_ipv6 = :: Wed Mar 22 14:43:30 2017 us=424161 server_netbits_ipv6 = 0 Wed Mar 22 14:43:30 2017 us=424166 server_bridge_ip = 0.0.0.0 Wed Mar 22 14:43:30 2017 us=424170 server_bridge_netmask = 0.0.0.0 Wed Mar 22 14:43:30 2017 us=424175 server_bridge_pool_start = 0.0.0.0 Wed Mar 22 14:43:30 2017 us=424180 server_bridge_pool_end = 0.0.0.0 Wed Mar 22 14:43:30 2017 us=424205 push_entry = 'comp-noadapt' Wed Mar 22 14:43:30 2017 us=424209 push_entry = 'reneg-sec 1800' Wed Mar 22 14:43:30 2017 us=424213 push_entry = 'route-gateway 172.16.120.129' Wed Mar 22 14:43:30 2017 us=424217 push_entry = 'topology subnet' Wed Mar 22 14:43:30 2017 us=424221 push_entry = 'ping 10' Wed Mar 22 14:43:30 2017 us=424225 push_entry = 'ping-restart 60' Wed Mar 22 14:43:30 2017 us=424229 ifconfig_pool_defined = ENABLED Wed Mar 22 14:43:30 2017 us=424238 ifconfig_pool_start = 172.16.120.130 Wed Mar 22 14:43:30 2017 us=424244 ifconfig_pool_end = 172.16.120.189 Wed Mar 22 14:43:30 2017 us=424248 ifconfig_pool_netmask = 255.255.255.192 Wed Mar 22 14:43:30 2017 us=424253 ifconfig_pool_persist_filename = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=424257 ifconfig_pool_persist_refresh_freq = 600 Wed Mar 22 14:43:30 2017 us=424261 ifconfig_ipv6_pool_defined = DISABLED Wed Mar 22 14:43:30 2017 us=424266 ifconfig_ipv6_pool_base = :: Wed Mar 22 14:43:30 2017 us=424270 ifconfig_ipv6_pool_netbits = 0 Wed Mar 22 14:43:30 2017 us=424274 n_bcast_buf = 256 Wed Mar 22 14:43:30 2017 us=424278 tcp_queue_limit = 64 Wed Mar 22 14:43:30 2017 us=424282 real_hash_size = 256 Wed Mar 22 14:43:30 2017 us=424286 virtual_hash_size = 256 Wed Mar 22 14:43:30 2017 us=424290 client_connect_script = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=424294 learn_address_script = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=424299 client_disconnect_script = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=424303 client_config_dir = '/etc/openvpn/tun-ccd' Wed Mar 22 14:43:30 2017 us=424307 ccd_exclusive = DISABLED Wed Mar 22 14:43:30 2017 us=423710 daemon = ENABLED Wed Mar 22 14:43:30 2017 us=423715 inetd = 0 Wed Mar 22 14:43:30 2017 us=423719 log = ENABLED Wed Mar 22 14:43:30 2017 us=423723 suppress_timestamps = DISABLED Wed Mar 22 14:43:30 2017 us=423727 machine_readable_output = DISABLED Wed Mar 22 14:43:30 2017 us=423731 nice = 0 Wed Mar 22 14:43:30 2017 us=423735 verbosity = 4 Wed Mar 22 14:43:30 2017 us=423739 mute = 0 Wed Mar 22 14:43:30 2017 us=423743 gremlin = 0 Wed Mar 22 14:43:30 2017 us=423747 status_file = '/var/log/openvpn/openvpn-status-tun.log' Wed Mar 22 14:43:30 2017 us=423751 status_file_version = 1 Wed Mar 22 14:43:30 2017 us=423755 status_file_update_freq = 1 Wed Mar 22 14:43:30 2017 us=423759 occ = ENABLED Wed Mar 22 14:43:30 2017 us=423763 rcvbuf = 0 Wed Mar 22 14:43:30 2017 us=423767 sndbuf = 0 Wed Mar 22 14:43:30 2017 us=423771 mark = 0 Wed Mar 22 14:43:30 2017 us=423775 sockflags = 0 Wed Mar 22 14:43:30 2017 us=423779 fast_io = DISABLED Wed Mar 22 14:43:30 2017 us=423783 comp.alg = 2 Wed Mar 22 14:43:30 2017 us=423787 comp.flags = 0 Wed Mar 22 14:43:30 2017 us=423791 route_script = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423795 route_default_gateway = '172.16.120.130' Wed Mar 22 14:43:30 2017 us=423800 route_default_metric = 0 Wed Mar 22 14:43:30 2017 us=423804 route_noexec = DISABLED Wed Mar 22 14:43:30 2017 us=423808 route_delay = 0 Wed Mar 22 14:43:30 2017 us=423812 route_delay_window = 30 Wed Mar 22 14:43:30 2017 us=423816 route_delay_defined = DISABLED Wed Mar 22 14:43:30 2017 us=423820 route_nopull = DISABLED Wed Mar 22 14:43:30 2017 us=423824 route_gateway_via_dhcp = DISABLED Wed Mar 22 14:43:30 2017 us=423828 allow_pull_fqdn = DISABLED Wed Mar 22 14:43:30 2017 us=423832 management_addr = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423836 management_port = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423840 management_user_pass = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423844 management_log_history_cache = 250 Wed Mar 22 14:43:30 2017 us=423849 management_echo_buffer_size = 100 Wed Mar 22 14:43:30 2017 us=423853 management_write_peer_info_file = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423857 management_client_user = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423861 management_client_group = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423865 management_flags = 0 Wed Mar 22 14:43:30 2017 us=423871 plugin[0] /etc/openvpn/plugin/radiusplugin-wo_acc.so '[/etc/openvpn/plugin/radiusplugin-wo_acc.so] [/etc/openvpn/radiusplugin-tun.cnf]' Wed Mar 22 14:43:30 2017 us=423875 shared_secret_file = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423880 key_direction = 1 Wed Mar 22 14:43:30 2017 us=423884 ciphername = 'AES-128-CBC' Wed Mar 22 14:43:30 2017 us=423888 ncp_enabled = ENABLED Wed Mar 22 14:43:30 2017 us=423892 ncp_ciphers = 'AES-128-GCM:AES-128-CBC:AES-256-GCM:AES-256-CBC' Wed Mar 22 14:43:30 2017 us=423897 authname = 'SHA1' Wed Mar 22 14:43:30 2017 us=423901 prng_hash = 'SHA1' Wed Mar 22 14:43:30 2017 us=423905 prng_nonce_secret_len = 16 Wed Mar 22 14:43:30 2017 us=423909 keysize = 16 Wed Mar 22 14:43:30 2017 us=423913 engine = DISABLED Wed Mar 22 14:43:30 2017 us=423917 replay = ENABLED Wed Mar 22 14:43:30 2017 us=423921 mute_replay_warnings = DISABLED Wed Mar 22 14:43:30 2017 us=423925 replay_window = 64 Wed Mar 22 14:43:30 2017 us=423930 replay_time = 15 Wed Mar 22 14:43:30 2017 us=423934 packet_id_file = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423938 use_iv = ENABLED Wed Mar 22 14:43:30 2017 us=423942 test_crypto = DISABLED Wed Mar 22 14:43:30 2017 us=423946 tls_server = ENABLED Wed Mar 22 14:43:30 2017 us=423950 tls_client = DISABLED Wed Mar 22 14:43:30 2017 us=423954 key_method = 2 Wed Mar 22 14:43:30 2017 us=423958 ca_file = '/etc/openvpn/private/cavpn_cert.pem' Wed Mar 22 14:43:30 2017 us=423966 ca_path = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423971 dh_file = '/etc/openvpn/private/dh2048.pem' Wed Mar 22 14:43:30 2017 us=423975 cert_file = '/etc/openvpn/private/server.pem' Wed Mar 22 14:43:30 2017 us=423979 extra_certs_file = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423983 priv_key_file = '/etc/openvpn/private/server.key' Wed Mar 22 14:43:30 2017 us=423988 pkcs12_file = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423992 cipher_list = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=423996 tls_verify = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=424000 tls_export_cert = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=424004 verify_x509_type = 0 Wed Mar 22 14:43:30 2017 us=424008 verify_x509_name = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=424012 crl_file = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=424016 ns_cert_type = 0 Wed Mar 22 14:43:30 2017 us=424020 remote_cert_ku[i] = 0 Wed Mar 22 14:43:30 2017 us=424024 remote_cert_ku[i] = 0 Wed Mar 22 14:43:30 2017 us=424028 remote_cert_ku[i] = 0 Wed Mar 22 14:43:30 2017 us=424032 remote_cert_ku[i] = 0 Wed Mar 22 14:43:30 2017 us=424035 remote_cert_ku[i] = 0 Wed Mar 22 14:43:30 2017 us=424039 remote_cert_ku[i] = 0 Wed Mar 22 14:43:30 2017 us=424043 remote_cert_ku[i] = 0 Wed Mar 22 14:43:30 2017 us=424047 remote_cert_ku[i] = 0 Wed Mar 22 14:43:30 2017 us=424051 remote_cert_ku[i] = 0 Wed Mar 22 14:43:30 2017 us=424064 remote_cert_ku[i] = 0 Wed Mar 22 14:43:30 2017 us=424068 remote_cert_ku[i] = 0 Wed Mar 22 14:43:30 2017 us=424072 remote_cert_ku[i] = 0 Wed Mar 22 14:43:30 2017 us=424076 remote_cert_ku[i] = 0 Wed Mar 22 14:43:30 2017 us=424079 remote_cert_ku[i] = 0 Wed Mar 22 14:43:30 2017 us=424083 remote_cert_ku[i] = 0 Wed Mar 22 14:43:30 2017 us=424087 remote_cert_ku[i] = 0 Wed Mar 22 14:43:30 2017 us=424091 remote_cert_eku = 'TLS Web Client Authentication' Wed Mar 22 14:43:30 2017 us=424095 ssl_flags = 132 Wed Mar 22 14:43:30 2017 us=424099 tls_timeout = 10 Wed Mar 22 14:43:30 2017 us=424104 renegotiate_bytes = -1 Wed Mar 22 14:43:30 2017 us=424108 renegotiate_packets = 0 Wed Mar 22 14:43:30 2017 us=424112 renegotiate_seconds = 1800 Wed Mar 22 14:43:30 2017 us=424116 handshake_window = 60 Wed Mar 22 14:43:30 2017 us=424120 transition_window = 3600 Wed Mar 22 14:43:30 2017 us=424124 single_session = DISABLED Wed Mar 22 14:43:30 2017 us=424128 push_peer_info = DISABLED Wed Mar 22 14:43:30 2017 us=424132 tls_exit = DISABLED Wed Mar 22 14:43:30 2017 us=424136 tls_auth_file = '[[INLINE]]' Wed Mar 22 14:43:30 2017 us=424140 tls_crypt_file = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=424146 server_network = 172.16.120.128 Wed Mar 22 14:43:30 2017 us=424150 server_netmask = 255.255.255.192 Wed Mar 22 14:43:30 2017 us=424156 server_network_ipv6 = :: Wed Mar 22 14:43:30 2017 us=424161 server_netbits_ipv6 = 0 Wed Mar 22 14:43:30 2017 us=424166 server_bridge_ip = 0.0.0.0 Wed Mar 22 14:43:30 2017 us=424170 server_bridge_netmask = 0.0.0.0 Wed Mar 22 14:43:30 2017 us=424175 server_bridge_pool_start = 0.0.0.0 Wed Mar 22 14:43:30 2017 us=424180 server_bridge_pool_end = 0.0.0.0 Wed Mar 22 14:43:30 2017 us=424205 push_entry = 'comp-noadapt' Wed Mar 22 14:43:30 2017 us=424209 push_entry = 'reneg-sec 1800' Wed Mar 22 14:43:30 2017 us=424213 push_entry = 'route-gateway 172.16.120.129' Wed Mar 22 14:43:30 2017 us=424217 push_entry = 'topology subnet' Wed Mar 22 14:43:30 2017 us=424221 push_entry = 'ping 10' Wed Mar 22 14:43:30 2017 us=424225 push_entry = 'ping-restart 60' Wed Mar 22 14:43:30 2017 us=424229 ifconfig_pool_defined = ENABLED Wed Mar 22 14:43:30 2017 us=424238 ifconfig_pool_start = 172.16.120.130 Wed Mar 22 14:43:30 2017 us=424244 ifconfig_pool_end = 172.16.120.189 Wed Mar 22 14:43:30 2017 us=424248 ifconfig_pool_netmask = 255.255.255.192 Wed Mar 22 14:43:30 2017 us=424253 ifconfig_pool_persist_filename = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=424257 ifconfig_pool_persist_refresh_freq = 600 Wed Mar 22 14:43:30 2017 us=424261 ifconfig_ipv6_pool_defined = DISABLED Wed Mar 22 14:43:30 2017 us=424266 ifconfig_ipv6_pool_base = :: Wed Mar 22 14:43:30 2017 us=424270 ifconfig_ipv6_pool_netbits = 0 Wed Mar 22 14:43:30 2017 us=424274 n_bcast_buf = 256 Wed Mar 22 14:43:30 2017 us=424278 tcp_queue_limit = 64 Wed Mar 22 14:43:30 2017 us=424282 real_hash_size = 256 Wed Mar 22 14:43:30 2017 us=424286 virtual_hash_size = 256 Wed Mar 22 14:43:30 2017 us=424290 client_connect_script = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=424294 learn_address_script = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=424299 client_disconnect_script = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=424303 client_config_dir = '/etc/openvpn/tun-ccd' Wed Mar 22 14:43:30 2017 us=424307 ccd_exclusive = DISABLED Wed Mar 22 14:43:30 2017 us=425161 tmp_dir = '/etc/openvpn/tmp' Wed Mar 22 14:43:30 2017 us=425174 push_ifconfig_defined = DISABLED Wed Mar 22 14:43:30 2017 us=425180 push_ifconfig_local = 0.0.0.0 Wed Mar 22 14:43:30 2017 us=425185 push_ifconfig_remote_netmask = 0.0.0.0 Wed Mar 22 14:43:30 2017 us=425190 push_ifconfig_ipv6_defined = DISABLED Wed Mar 22 14:43:30 2017 us=425195 push_ifconfig_ipv6_local = ::/0 Wed Mar 22 14:43:30 2017 us=425200 push_ifconfig_ipv6_remote = :: Wed Mar 22 14:43:30 2017 us=425204 enable_c2c = ENABLED Wed Mar 22 14:43:30 2017 us=425208 duplicate_cn = DISABLED Wed Mar 22 14:43:30 2017 us=425212 cf_max = 0 Wed Mar 22 14:43:30 2017 us=425217 cf_per = 0 Wed Mar 22 14:43:30 2017 us=425221 max_clients = 60 Wed Mar 22 14:43:30 2017 us=425225 max_routes_per_client = 256 Wed Mar 22 14:43:30 2017 us=425230 auth_user_pass_verify_script = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=425234 auth_user_pass_verify_script_via_file = DISABLED Wed Mar 22 14:43:30 2017 us=425238 auth_token_generate = DISABLED Wed Mar 22 14:43:30 2017 us=425242 auth_token_lifetime = 0 Wed Mar 22 14:43:30 2017 us=425247 port_share_host = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=425251 port_share_port = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=425255 client = DISABLED Wed Mar 22 14:43:30 2017 us=425259 pull = DISABLED Wed Mar 22 14:43:30 2017 us=425263 auth_user_pass_file = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=425269 OpenVPN 2.4.0 i686-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Mar 17 2017 Wed Mar 22 14:43:30 2017 us=425277 library versions: OpenSSL 1.0.1e-fips 11 Feb 2013, LZO 2.03 Wed Mar 22 14:43:30 2017 us=425161 tmp_dir = '/etc/openvpn/tmp' Wed Mar 22 14:43:30 2017 us=425174 push_ifconfig_defined = DISABLED Wed Mar 22 14:43:30 2017 us=425180 push_ifconfig_local = 0.0.0.0 Wed Mar 22 14:43:30 2017 us=425185 push_ifconfig_remote_netmask = 0.0.0.0 Wed Mar 22 14:43:30 2017 us=425190 push_ifconfig_ipv6_defined = DISABLED Wed Mar 22 14:43:30 2017 us=425195 push_ifconfig_ipv6_local = ::/0 Wed Mar 22 14:43:30 2017 us=425200 push_ifconfig_ipv6_remote = :: Wed Mar 22 14:43:30 2017 us=425204 enable_c2c = ENABLED Wed Mar 22 14:43:30 2017 us=425208 duplicate_cn = DISABLED Wed Mar 22 14:43:30 2017 us=425212 cf_max = 0 Wed Mar 22 14:43:30 2017 us=425217 cf_per = 0 Wed Mar 22 14:43:30 2017 us=425221 max_clients = 60 Wed Mar 22 14:43:30 2017 us=425225 max_routes_per_client = 256 Wed Mar 22 14:43:30 2017 us=425230 auth_user_pass_verify_script = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=425234 auth_user_pass_verify_script_via_file = DISABLED Wed Mar 22 14:43:30 2017 us=425238 auth_token_generate = DISABLED Wed Mar 22 14:43:30 2017 us=425242 auth_token_lifetime = 0 Wed Mar 22 14:43:30 2017 us=425247 port_share_host = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=425251 port_share_port = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=425255 client = DISABLED Wed Mar 22 14:43:30 2017 us=425259 pull = DISABLED Wed Mar 22 14:43:30 2017 us=425263 auth_user_pass_file = '[UNDEF]' Wed Mar 22 14:43:30 2017 us=425269 OpenVPN 2.4.0 i686-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Mar 17 2017 Wed Mar 22 14:43:30 2017 us=425277 library versions: OpenSSL 1.0.1e-fips 11 Feb 2013, LZO 2.03 Wed Mar 22 14:43:30 2017 RADIUS-PLUGIN: Configfile name: /etc/openvpn/radiusplugin-tun.cnf. Wed Mar 22 14:43:30 2017 us=426814 PLUGIN_INIT: POST /etc/openvpn/plugin/radiusplugin-wo_acc.so '[/etc/openvpn/plugin/radiusplugin-wo_acc.so] [/etc/openvpn/radiusplugin-tun.cnf]' intercepted=PLUGIN_AUTH_USER_PASS_VERIFY Wed Mar 22 14:43:30 2017 us=448436 Diffie-Hellman initialized with 2048 bit key Wed Mar 22 14:43:30 2017 us=448821 Failed to extract curve from certificate (UNDEF), using secp384r1 instead. Wed Mar 22 14:43:30 2017 us=448852 ECDH curve secp384r1 added Wed Mar 22 14:43:30 2017 us=448976 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication Wed Mar 22 14:43:30 2017 us=448997 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication Wed Mar 22 14:43:30 2017 us=449016 TLS-Auth MTU parms [ L:1624 D:1182 EF:68 EB:0 ET:0 EL:3 ] Wed Mar 22 14:43:30 2017 us=449310 TUN/TAP device tun0 opened Wed Mar 22 14:43:30 2017 us=449336 TUN/TAP TX queue length set to 100 Wed Mar 22 14:43:30 2017 us=449353 do_ifconfig, tt->did_ifconfig_ipv6_setup=0 Wed Mar 22 14:43:30 2017 us=449371 /usr/sbin/ip link set dev tun0 up mtu 1500 Wed Mar 22 14:43:30 2017 us=453412 /usr/sbin/ip addr add dev tun0 172.16.120.129/26 broadcast 172.16.120.191 Wed Mar 22 14:43:30 2017 us=454245 Data Channel MTU parms [ L:1624 D:1450 EF:124 EB:406 ET:0 EL:3 ] Wed Mar 22 14:43:30 2017 us=454429 Could not determine IPv4/IPv6 protocol. Using AF_INET Wed Mar 22 14:43:30 2017 us=454448 Socket Buffers: R=[87380->87380] S=[16384->16384] Wed Mar 22 14:43:30 2017 us=454463 Listening for incoming TCP connection on [AF_INET]213.25.35.131:443 Wed Mar 22 14:43:30 2017 us=454480 TCPv4_SERVER link local (bound): [AF_INET]213.25.35.131:443 Wed Mar 22 14:43:30 2017 us=454487 TCPv4_SERVER link remote: [AF_UNSPEC] Wed Mar 22 14:43:30 2017 us=454496 GID set to openvpn Wed Mar 22 14:43:30 2017 us=454504 UID set to openvpn Wed Mar 22 14:43:30 2017 us=454514 MULTI: multi_init called, r=256 v=256 Wed Mar 22 14:43:30 2017 us=454531 IFCONFIG POOL: base=172.16.120.130 size=60, ipv6=0 Wed Mar 22 14:43:30 2017 us=454544 MULTI: TCP INIT maxclients=60 maxevents=64 Wed Mar 22 14:43:30 2017 us=454567 Initialization Sequence Completed }}} '''client try to connect''' {{{ Wed Mar 22 14:43:55 2017 us=717818 MULTI: multi_create_instance called Wed Mar 22 14:43:55 2017 us=717866 Re-using SSL/TLS context Wed Mar 22 14:43:55 2017 us=717883 LZO compression initializing Wed Mar 22 14:43:55 2017 us=718000 Control Channel MTU parms [ L:1624 D:1182 EF:68 EB:0 ET:0 EL:3 ] Wed Mar 22 14:43:55 2017 us=718024 Data Channel MTU parms [ L:1624 D:1450 EF:124 EB:406 ET:0 EL:3 ] Wed Mar 22 14:43:55 2017 us=718107 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1560,tun-mtu 1500,proto TCPv4_SERVER,comp-lzo,keydir 0,cipher AES-128-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-server' Wed Mar 22 14:43:55 2017 us=718122 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1560,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,keydir 1,cipher AES-128-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-client' Wed Mar 22 14:43:55 2017 us=718122 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1560,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,keydir 1,cipher AES-128-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-client' Wed Mar 22 14:43:55 2017 us=718142 TCP connection established with [AF_INET]213.25.XX.YY:49651 Wed Mar 22 14:43:55 2017 us=718154 TCP_SERVER link local: (not bound) Wed Mar 22 14:43:55 2017 us=718154 TCP_SERVER link local: (not bound) Wed Mar 22 14:43:55 2017 us=718162 TCP_SERVER link remote: [AF_INET]213.25.XX.YY:49651 Wed Mar 22 14:43:55 2017 us=718263 213.25.XX.YY:49651 TLS: Initial packet from [AF_INET]213.25.XX.YY:49651, sid=659a173e 9a48f99f Wed Mar 22 14:43:55 2017 us=873996 213.25.XX.YY:49651 VERIFY OK: depth=1, O=Company, CN=Public VPN CA Wed Mar 22 14:43:55 2017 us=874309 213.25.XX.YY:49651 Validating certificate extended key usage Wed Mar 22 14:43:55 2017 us=874326 213.25.XX.YY:49651 ++ Certificate has EKU (str) TLS Web Client Authentication, expects TLS Web Client Authentication Wed Mar 22 14:43:55 2017 us=874335 213.25.XX.YY:49651 VERIFY EKU OK Wed Mar 22 14:43:55 2017 us=874341 213.25.XX.YY:49651 VERIFY OK: depth=0, O=Company, CN=Test User Wed Mar 22 14:43:55 2017 us=883163 213.25.XX.YY:49651 peer info: IV_GUI_VER=net.openvpn.connect.ios_1.1.1-212 Wed Mar 22 14:43:55 2017 us=883187 213.25.XX.YY:49651 peer info: IV_VER=3.1.2 Wed Mar 22 14:43:55 2017 us=883187 213.25.XX.YY:49651 peer info: IV_VER=3.1.2 Wed Mar 22 14:43:55 2017 us=883195 213.25.XX.YY:49651 peer info: IV_PLAT=ios Wed Mar 22 14:43:55 2017 us=883201 213.25.XX.YY:49651 peer info: IV_NCP=2 Wed Mar 22 14:43:55 2017 us=883213 213.25.XX.YY:49651 peer info: IV_TCPNL=1 Wed Mar 22 14:43:55 2017 us=883213 213.25.XX.YY:49651 peer info: IV_TCPNL=1 Wed Mar 22 14:43:55 2017 us=883220 213.25.XX.YY:49651 peer info: IV_PROTO=2 Wed Mar 22 14:43:55 2017 us=883220 213.25.XX.YY:49651 peer info: IV_PROTO=2 Wed Mar 22 14:43:55 2017 us=883227 213.25.XX.YY:49651 peer info: IV_LZO=1 Wed Mar 22 14:43:55 2017 us=883366 213.25.XX.YY:49651 PLUGIN_CALL: POST /etc/openvpn/plugin/radiusplugin-wo_acc.so/PLUGIN_AUTH_USER_PASS_VERIFY status=2 Wed Mar 22 14:43:55 2017 us=883388 213.25.XX.YY:49651 TLS: Username/Password authentication deferred for username 'testuser' [CN SET] Wed Mar 22 14:43:55 2017 us=883388 213.25.XX.YY:49651 TLS: Username/Password authentication deferred for username 'testuser' [CN SET] terminate called after throwing an instance of 'std::out_of_range' what(): basic_string::replace }}} {{{ # pstack 32200 #0 0x00a91424 in __kernel_vsyscall () #1 0x00414943 in __read_nocancel () from /lib/libc.so.6 #2 0x004ff380 in IpcSocket::recvInt() () from /etc/openvpn/plugin/radiusplugin-wo_acc.so #3 0x00504f4f in AuthenticationProcess::Authentication(PluginContext*) () from /etc/openvpn/plugin/radiusplugin-wo_acc.so #4 0x004fffdc in openvpn_plugin_open_v2 () from /etc/openvpn/plugin/radiusplugin-wo_acc.so #5 0x0809ae48 in plugin_list_open () #6 0x08061448 in open_plugins () #7 0x080657b1 in init_instance () #8 0x08066cee in init_instance_handle_signals () #9 0x08075da4 in tunnel_server_tcp () #10 0x0807fd70 in openvpn_main () #11 0x0807fe61 in main () }}} {{{ # free total used free shared buffers cached Mem: 1030244 229124 801120 472 45764 129808 -/+ buffers/cache: 53552 976692 Swap: 497976 0 497976 }}} " pkopchk Active Tickets 871 DHCP gateway stripping does not remove DHCP option 121 0.0.0.0 routes Networking OpenVPN 2.2.2 (Community Ed) Bug / Defect new 2017-04-07T20:25:31Z 2017-05-05T09:57:26Z "DHCP allows defining classless static routes using option 121. However, according to [RFC 3442](https://tools.ietf.org/html/rfc3442), if a route is defined using this option, option 3 (default gateway) must be ignored. Instead, the default gateway must be defined as the route for 0.0.0.0/0, using the same 121 option. OpenVPN doesn't seem to strip this route from option 121 when server-bridge with dhcp gateway stripping is enabled." roobre Active Tickets 892 Windows 10 64-bit - OpenVPN 2.4.2-I601 - Registry query failure in event log Generic / unclassified OpenVPN 2.4.2 (Community Ed) Bug / Defect new 2017-05-22T04:26:02Z 2017-05-22T19:51:29Z "NOTE: 2.4.2 doesn't appear to be a valid option under the Milestone or Version dropdowns for bug reporting. The following error log appears in the windows Event viewer upon boot. OpenVPN 2.4.2-I601 was installed with all default installation options on Windows 10 Pro 64-bit, using the installer provided at this URL: https://swupdate.openvpn.org/community/releases/openvpn-install-2.4.2-I601.exe The 'OpenVPNService' is set to start on system boot and is confirmed to be running following the error log time. The OpenVPN GUI client is set to start on system boot and is confirmed to be running following the error log time. NOTE: The GUI does not indicate any active VPN connections, but I've verified a VPN connection is established by running a 'what is my IP' check online. User-friendly error summary: {{{ openvpnserv error: The system cannot find the file specified. (0x2) Error querying registry value: HKLM\SOFTWARE\OpenVPN\ovpn_admin_group }}} Full error data provided by the event viewer, in the event the extra data is useful: {{{ 0 2 0 0x80000000000000 5129 Application SIERRA-DESKTOP openvpnserv error: The system cannot find the file specified. (0x2) Error querying registry value: HKLM\SOFTWARE\OpenVPN\ovpn_admin_group }}}" sierrakomodo Active Tickets 901 "Windows 10 starts a NON-admin cmd when using ""Explorer > Start OpenVPN on this config file ..""" Generic / unclassified Bug / Defect new 2017-06-06T13:26:38Z 2017-06-06T22:57:06Z "Windows 10 starts a NON-admin '''cmd''' window when using ""Explorer > Start OpenVPN on this config file .."" and the tunnel fails. (Setup with my default-client.ovpn which successfully connects otherwise) Tested on W10 with Openvpn v242 (will check other windows and openvpn versions in due course)" tct Active Tickets 908 inconsistent handling of password string input with LF at the end Windows GUI OpenVPN 2.4.3 (Community Ed) Bug / Defect new 2017-06-30T16:02:05Z 2017-12-15T21:02:26Z "adding 0x0a to a key password in the UI Password Dialog will accept the password but prevent the openvpn client from proceeding: Fri Jun 30 17:26:43 2017 MANAGEMENT: CMD 'hold release' -password entered- Fri Jun 30 17:26:53 2017 MANAGEMENT: CMD 'password [...]' Fri Jun 30 17:26:53 2017 MANAGEMENT: CMD '""' -now client hangs and does nothing- The change password dialog will reject the same password (with 0x0a added) as wrong. So string handling is probably different at these two places. This appears to be so since at least 2.3.8 (the oldest version i tested) up to 2.4.3. I stumbled upon this by creating a key/cert pair with a random password on a Linux system, putting the key password on Linux in a textfile via copy and paste (without explicit newline at the end of the password) and using this same file in windows notepad to copy and paste the password into the dialog. This way I added the invisible 0x0a to the password in Windows and the client - managed via the GUI just hangs (see above) but runs fine in a CMD window. And the password change dialog refuses the pasted password as wrong. This way you can also add additional commands to be sent to the management interface of the client. I don't know if that could be a serious issue unless the same routines are used in other places. At least string handling should be the same for password input and password change dialog. Regards, Tom" xTom Active Tickets 934 Client cannot connect using IPv6 transport IPv6 OpenVPN 2.4.0 (Community Ed) Bug / Defect new 2017-09-15T00:35:08Z 2019-10-08T11:55:15Z "This is for OpenVPN-openvpn-2.4.2 on OpenSuSE ""Tumbleweed"" 2017-09-14. When the server configuration specifies ""proto udp"" or ""proto tcp-server"" the server reports on syslog: Could not determine IPv4/IPv6 protocol. Using AF_INET (See also ticked 805, https://community.openvpn.net/openvpn/ticket/805 ) If the client conf says ""remote server.example.com 1194 udp6"" or ""remote server.example.com 443 tcp6-client"", packets arrive on the server but no connection ensues, because an AF_INET socket does not accept IPv6 traffic. This is the configuration that the sysadmin will try first and logically it should work, which is why I'm reporting this as a bug. But it's mostly a documentation problem. Workaround: The server configuration should say ""proto udp6"" or ""proto tcp6-server"". The AF_INET6 socket can accept IPv4 mapped source addresses. As far as I can tell, this can only be turned off by the IPV6_V6ONLY socket option (see setsockopt(2) and ipv6(7)). With the ""6"" the client successfully connects using both IPv4+6 transport and UDP and TCP protocol. Suggestion for a permanent solution: When the address family is not specified explicitly, use AF_INET6. For udp4 or tcp4 use AF_INET as you do now. For udp6 or tcp6 turn on the IPV6_V6ONLY socket option. The documentation needs to be more clear about address family selection. It should also be clear that with TCP the family should precede the mode, e.g. tcp6-client or tcp6-server. Also state that the same rules apply for the client's ""remote"" option and it needs ""tcp-client"" (or 4 or 6) (or server, for a static VPN) if the protocol (TCP) is specified explicitly. " jimc Active Tickets 970 """error=unsupported certificate purpose"" when building with OpenSSL 1.1.0" Certificates OpenVPN 2.4.4 (Community Ed) Bug / Defect new 2017-12-29T18:35:07Z 2017-12-29T18:35:07Z "Hi, this was reported by a Debian user in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885581. Between 2.4.4-1 and 2.4.4-2 we have switched to build with OpenSSL 1.1.0 (instead of 1.0.2). Now a previously working local CA does not work anymore with 2017-12-28 10:19:51.581535500 Thu Dec 28 10:19:51 2017 us=581446 TLS: Initial packet from [AF_INET]**.**.**.**:5000, sid=2b216141 7850038f 2017-12-28 10:19:51.615926500 Thu Dec 28 10:19:51 2017 us=615841 VERIFY ERROR: depth=1, error=unsupported certificate purpose: CN=Certificate Authority, DC=**, DC=** 2017-12-28 10:19:51.615980500 Thu Dec 28 10:19:51 2017 us=615952 OpenSSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed 2017-12-28 10:19:51.616033500 Thu Dec 28 10:19:51 2017 us=615975 TLS_ERROR: BIO read tls_read_plaintext error 2017-12-28 10:19:51.616080500 Thu Dec 28 10:19:51 2017 us=616005 TLS Error: TLS object -> incoming plaintext read error 2017-12-28 10:19:51.616097500 Thu Dec 28 10:19:51 2017 us=616018 TLS Error: TLS handshake failed Thanks for having a look. Bernhard" berni Active Tickets 971 """management tunnel "" ignores port" Management OpenVPN 2.4.4 (Community Ed) Bug / Defect new 2017-12-30T23:48:23Z 2021-06-15T20:30:00Z "This has been originally reported by a Debian user at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881901 Having upgraded to 2.4.0-6+deb9u2, the port number seems to be ignored, as you can see here: # grep management /etc/openvpn/vpn1.conf management tunnel 5656 # netstat -tlnp | grep openvpn tcp 0 0 172.12.34.14:43125 0.0.0.0:* LISTEN 495/openvpn Downgrading to 2.3.4-5+deb8u2 restores the previous behaviour. I've confirmed this to still be the case in 2.4.4" berni Active Tickets 1155 openvpn_plugin_func_v3 version documentation disagrees with code plug-ins / plug-in API OpenVPN git master branch (Community Ed) Bug / Defect new 2019-01-18T22:37:44Z 2022-12-22T08:19:55Z "The documentation for `openvpn_plugin_func_v3()` (as specified in `include/openvpn-plugin.h.in`) states that: > version: ... The plug-in should validate that this value is matching the OPENVPN_PLUGIN_VERSION value. However, `plugin_call_item()` which calls `openvpn_plugin_func_v3()` (as specified in `src/openvpn/plugin.c`) actually passes `OPENVPN_PLUGINv3_STRUCTVER` instead of the expected `OPENVPN_PLUGIN_VERSION` on line 561 as show below. {{{#!c status = (*p->func3)(OPENVPN_PLUGINv3_STRUCTVER, &args, &retargs); }}} This discrepancy causes all plug-ins that use `openvpn_plugin_func_v3()` and follow the recommendations of the documentation to fail for any OpenVPN versions where OPENVPN_PLUGIN_VERSION does not equal OPENVPN_PLUGINv3_STRUCTVER. A cursory examination reveals this to be all 2.3 versions and any 2.4 versions >= 2.4.2." gojolu Active Tickets 1205 inline login and password with NTLM squid + samba proxy Networking OpenVPN 2.4.7 (Community Ed) Bug / Defect new 2019-07-17T20:50:10Z 2020-08-30T21:01:35Z "I setup a squid proxy for corp using NTLM which works for IE/chrome but not openvpn. Apparently this was worked on awhile back but may not have been merged: [https://sourceforge.net/p/openvpn/mailman/openvpn-devel/thread/563371FD.70206%40Sophos.com/#msg34581339 mail thread] {{{ Date: Sun, 18 Dec 2016 17:46:55 +0100 From: Steffan Karger Subject: Re: [Openvpn-devel] [PATCHv2 1/2] Get NTLMv1 and NTLMv2 up and running }}} here is my squid.conf: {{{ acl localnet src 0.0.0.0/0 #allow whole internet acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp auth_param ntlm children 30 auth_param ntlm max_challenge_reuses 0 auth_param ntlm max_challenge_lifetime 2 minutes # ntlm_auth from Samba 3 supports NTLM NEGOTIATE packet auth_param ntlm use_ntlm_negotiate on auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwd auth_param basic children 5 auth_param basic realm Squid Basic Authentication auth_param basic credentialsttl 2 hours acl auth_users proxy_auth REQUIRED http_access allow all auth_users http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access allow localhost manager http_access deny manager http_access deny all http_port 3169 coredump_dir /var/spool/squid refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern (Release|Packages(.gz)*)$ 0 20% 2880 refresh_pattern . 0 20% 4320 }}} and my smb.conf {{{ # Global parameters [global] dns forwarder = 127.0.0.53 netbios name = OVPNTEST realm = TEST.OVPNTEST server role = active directory domain controller dns forwarder = 8.8.8.8 workgroup = OVPNTESTNET bind interfaces only = yes interfaces = lo winbind separator = + winbind use default domain = yes [netlogon] path = /var/lib/samba/sysvol/test.ovpntest/scripts read only = No [sysvol] path = /var/lib/samba/sysvol read only = No }}} and client.conf {{{ client dev tun proto tcp # this port is actually blocked, but our proxy gets us past that remote IP_ADDRESS 5150 persist-key persist-tun compress nobind verb 4 key-direction 1 # In the following line i also tried forcing ntlm and ntlm2, neither helped http-proxy IP_ADDRESS PROXY_PORT auto-nct # I also tried DOMAIN\user and DOMAIN\\user but neither worked. # winbind seperator is + so I expect that to work, but chrome and IE both # wanted DOMAIN\user DOMAIN+user SAMBAPASS }}} " krzee king Active Tickets 1374 Device name needs quoting in script arguments Configuration OpenVPN 2.5.0 (Community Ed) Bug / Defect new 2021-01-05T20:01:18Z 2021-02-16T09:14:08Z "I'm using OpenVPN as VPN client on Windows 10, and configured up/down commands in my .ovpn configuration file. The commands just calls a function defined in my powershell profile (without any additional arguments). In my function I've defined the necessary arguments according to the [https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/ documentation]: {{{#!default tun_dev tun_mtu link_mtu ifconfig_local_ip ifconfig_remote_ip [ init | restart ] }}} Result from log (device name is not set by me): {{{#!default OpenVPN Wintun 1500 1553 10.8.8.14 10.8.8.13 init }}} Expected (double quotes work too): {{{#!default 'OpenVPN Wintun' 1500 1553 10.8.8.14 10.8.8.13 init }}} Without quotes, device names containing whitespaces break argument parsing." Tamás Szabó Active Tickets 1447 Cannot reauthenticate clients using auth-token with management-client-auth Generic / unclassified OpenVPN 2.5.4 (Community Ed) Bug / Defect new 2022-01-27T16:36:55Z 2022-02-04T08:25:19Z "In order to implement MFA with both static and dynamic challenges, I've implemented a daemon to read CLIENT notifications from the Management Interface and send appropriate client-auth / client-deny responses. To allow MFA clients to start logged in for a long time, I've also set auth-gen-token. Basic/relevant lines of the server config are: {{{ reneg-sec 3600 auth-gen-token 172800 management ""/var/run/openvpn/vpn3.sock"" unix management-client-auth }}} Relevant lines from the client config are: {{{ auth-user-pass static-challenge ""Enter Verification Code"" 1 auth-retry interact }}} The issue is that on token refresh, clients that support auth-token fail to re-authenticate. The server reports the token as valid, but also as deferred without notifying the management interface and the client connection is lost. Typical server logs (verb 3) look like: {{{ Jan 27 11:53:41 vpnserver ovpn-vpn3[11627]: xxx.xxx.xxx.xxx:32819 TLS: Username/auth-token authentication succeeded for username 'vpnuser' Jan 27 11:53:41 vpnserver ovpn-vpn3[11627]: xxx.xxx.xxx.xxx:32819 TLS: Username/Password authentication deferred for username 'vpnuser' Jan 27 11:53:41 vpnserver ovpn-vpn3[11627]: xxx.xxx.xxx.xxx:32819 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, peer certificate: 2048 bit RSA, signature: RSA-SHA256 Jan 27 11:53:41 vpnserver ovpn-vpn3[11627]: xxx.xxx.xxx.xxx:32819 [vpnuser_profile] Peer Connection Initiated with [AF_INET6]::ffff:xxx.xxx.xxx.xxx:32819 Jan 27 11:53:42 vpnserver ovpn-vpn3[11627]: xxx.xxx.xxx.xxx:32819 PUSH: Received control message: 'PUSH_REQUEST' Jan 27 11:53:47 vpnserver ovpn-vpn3[11627]: xxx.xxx.xxx.xxx:32819 PUSH: Received control message: 'PUSH_REQUEST' Jan 27 11:53:53 vpnserver ovpn-vpn3[11627]: xxx.xxx.xxx.xxx:32819 PUSH: Received control message: 'PUSH_REQUEST' Jan 27 11:53:58 vpnserver ovpn-vpn3[11627]: xxx.xxx.xxx.xxx:32819 PUSH: Received control message: 'PUSH_REQUEST' Jan 27 11:54:03 vpnserver ovpn-vpn3[11627]: xxx.xxx.xxx.xxx:32819 PUSH: Received control message: 'PUSH_REQUEST' Jan 27 11:54:08 vpnserver ovpn-vpn3[11627]: xxx.xxx.xxx.xxx:32819 PUSH: Received control message: 'PUSH_REQUEST' Jan 27 11:54:13 vpnserver ovpn-vpn3[11627]: xxx.xxx.xxx.xxx:39075 [vpnuser_profile] Inactivity timeout (--ping-restart), restarting }}} In ssl_verify.c / verify_user_pass it looks like the token is validated... {{{ else if (ks->auth_token_state_flags == AUTH_TOKEN_HMAC_OK) { /* * We do not want the EXPIRED or EMPTY USER flags here so check * for equality with AUTH_TOKEN_HMAC_OK */ msg(M_WARN, ""TLS: Username/auth-token authentication "" ""succeeded for username '%s'"", up->username); skip_auth = true; } }}} ...which the causes the management interface not to be notified... {{{ if (!skip_auth) { #ifdef ENABLE_MANAGEMENT if (man_def_auth == KMDA_DEF) { man_def_auth = verify_user_pass_management(session, multi, up); } #endif ... } }}} ...but {{{man_def_auth == KMDA_DEF}}} means authenticated is set to the KS_AUTH_DEFERRED state... {{{ ks->authenticated = KS_AUTH_TRUE; if (plugin_status == OPENVPN_PLUGIN_FUNC_DEFERRED || script_status == OPENVPN_PLUGIN_FUNC_DEFERRED) { ks->authenticated = KS_AUTH_DEFERRED; } #ifdef ENABLE_MANAGEMENT if (man_def_auth != KMDA_UNDEF) { ks->authenticated = KS_AUTH_DEFERRED; } #endif }}} ...and the connection is not re-authenticated. It seems like an easy fix would be changing the last bit to: {{{ if (man_def_auth != KMDA_UNDEF && !skip_auth) { ks->authenticated = KS_AUTH_DEFERRED; } }}} But there may be a cleaner way to handle this. In the circumstances, I'm now using {{{auth-gen-token 172800 external-auth}}} which sends all re-authentication requests to the daemon which can then be handled appropriately." jermy Active Tickets 1468 non-ascii utf8 character in verify-x509-name Generic / unclassified OpenVPN 2.5.6 (Community Ed) Bug / Defect new 2022-06-30T13:59:16Z 2023-03-16T01:11:40Z "Linux distribution: Ubuntu 20.04 Focal Fossa OpenVPN 2.5.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jun 30 2022 library versions: OpenSSL 1.1.1f 31 Mar 2020, LZO 2.10 I have a X509 DN name that contains the non-ASCII character ""ß"": {{{ verify-x509-name ""C=de, L=bugß, O=foo, CN=bar, emailAddress=me@email.com"" }}} When I run openvpn with this configuration it prints {{{ Thu Jun 30 15:22:51 2022 VERIFY OK: depth=1, C=de, L=bugà }}} and then freezes. The problem is that ß=\xc3\x9f is translated to \xc3\x83\xc2\x9f. \xc3\x83 is à and \xc2\x9f is invalid in utf8. Therefore printf (or something similar) hangs. I tracked down the problem to `x509_get_subject()` in `ssl_verify_openssl.c` and found a workaround. When I remove `ASN1_STRFLGS_UTF8_CONVERT` from {{{ X509_NAME_print_ex(subject_bio, X509_get_subject_name(cert), 0, XN_FLAG_SEP_CPLUS_SPC | XN_FLAG_FN_SN |ASN1_STRFLGS_UTF8_CONVERT | ASN1_STRFLGS_ESC_CTRL); }}} the problem disapears and I get a VPN connection. I have no clue if there are other implications by removing it, but in my case it solved the problem. " mischejo Active Tickets 1482 openvpn 2.4.7 with auth-user-pass-optional breaks auth-gen-token Generic / unclassified OpenVPN 2.4.7 (Community Ed) Bug / Defect new 2022-11-02T11:19:03Z 2022-12-03T23:35:57Z "Hi, as far as I understand, we can use this on the server side: {{{ auth-user-pass-verify my-auth-script via-file reneg-sec 3600 auth-gen-token 57600 # 16 hours.. you need one reconnect/repassword daily }}} This should cause the user to get a 2FA prompt only once every 16 hours. If we then combine this with: {{{ auth-user-pass-optional }}} making the 2FA optional (*) and a client that does not provide a password, we get these errors on the server every 3600 seconds: {{{ TLS Auth Error: Auth-token verification failed for username '' TLS Error: local/remote TLS keys are out of sync: [AF_INET]: [0] TLS Error: local/remote TLS keys are out of sync: [AF_INET]: [0] ... }}} after which the connection is terminated in due time because the keepalives start to fail. I assume the cause is that the client doesn't know it should send any tokens at all, while the server starts expecting tokens after the first hour. There appear to be two workarounds for this: (1) Pass a bogus username/password from the client (and ignore the bogus values in the {{auth-user-pass-verify}} module): {{{ auth-user-pass /etc/protocols }}} (2) Don't use {{auth-gen-token}} in the server, but increase {{reneg-sec}}: {{{ reneg-sec 57600 # 16 hours.. you need one reconnect/repassword daily #auth-gen-token 57600 }}} This issue looks related, but not equal, to #1447. To me, it looks like the bogus username/password passing is the more secure option -- because then we do get renegotiation. But it is also the ugliest. Cheers, Walter Doekes OSSO B.V. (*) Why optional 2FA? For systems without humans attached we have separate security measures (IP whitelists, etc.). (**) This behaviour was observed with the default openvpn on Ubuntu/Focal. I did not find tickets/changes that looked like this was fixed in newer versions. " wdoekes Active Tickets 388 Should be able to use crypto API (windows) for CA certificate(s) Generic / unclassified OpenVPN git master branch (Community Ed) Feature Wish new 2014-04-10T03:52:29Z 2020-08-05T13:54:34Z "I would like to specify the CA from the Microsoft crypto store. (e.g. cryptoapiCAcert) - but I don't see such a directive. This is a feature request. It would prevent having to distribute some certificates twice: Once in the browser, and once in the client's OpenVPN config. I know it's a windows only feature - though someday, hopefully, someone will do the same for the MacOS keyring... " tlhackque Active Tickets 782 Expose connection info to up/down scripts via additional env variables Generic / unclassified Feature Wish new 2016-12-02T14:15:09Z 2016-12-02T14:15:09Z "# $trusted_ip/$untrusted_ip are not necessarily among the IPs a configured # remote domain will resolve to. Some providers return a random subset out of # hundreds of IPs on each query, and revdns entries are not guaranteed to # exist, or match any remote as defined in the config. current_remote := ""1"" | ""2"" | ... or current_remote := domain_name_or_ip_matching_configured_remote # Consitent with $trusted_ip/$untrusted_ip, $trusted_port/$untrusted_port. # Would allow setting precise firewall rules from an --up/--down script. trusted_proto := ""udp"" | ""tcp-client"" | ""tcp-server"" untrusted_proto := ""udp"" | ""tcp-client"" | ""tcp-server""" wknapik Active Tickets 866 Allow to disable Username and Password save Windows GUI OpenVPN 2.4.0 (Community Ed) Feature Wish new 2017-03-30T21:09:16Z 2019-04-27T18:26:30Z This is a simple decision which, I believe, ought to be down to the user. tct Active Tickets 932 Update from the OpenVPN GUI Windows GUI OpenVPN git master branch (Community Ed) Feature Wish new 2017-08-31T00:18:17Z 2017-08-31T00:18:17Z It would be most helpful to have the OpenVPN GUI to be able to determine if there is a new version of the VPN client or not. It would provide a download mechanism along with the ability to review the release notes within a window. There would be settings to disable, allow a check whenever the application starts, weekly or monthly for updates. tkrn Active Tickets 1046 Allow modifying OpenVPN internal routing table Management OpenVPN 2.4.6 (Community Ed) Feature Wish assigned 2018-03-21T14:55:20Z 2019-12-13T15:41:11Z On OpenVPN server side, when you want to route a network to a specific client, you add route directive to server config file (adds route to system routing table) and iroute directive to client config file in ccd directory (adds route to OpenVPN internal routing table). However, if the client is already connected, it needs to disconnect and reconnect in order for route to become active. I'd like to have the ability to activate the route without dropping client connection. Adding a route to system routing table is easy enough, but there is no way (that I can see) to modify OpenVPN internal routing table. Please allow modifying the internal routing table via management interface or some other means. niksa Active Tickets 1239 openvpn client returns 0 after failed login Generic / unclassified OpenVPN 2.4.8 (Community Ed) Feature Wish assigned 2019-12-04T17:12:28Z 2020-08-30T14:16:03Z "Centos 7, installed via EPEL repo. When login fails for reasons I've tested (deliberately breaking config, deliberately passing wrong creds) the openvpn process exits with retval=0. This makes monitoring difficult as one is forced to parse the command output rather than simply checking $? Please change the client so that when openvpn fails to connect for any reason it returns nonzero. Example using deliberately broken config (I removed the space between ""auth-user-pass"" and the path to the credentials file), using wrong creds looks similar: _[/etc/openvpn/client]_(root@test)_ # openvpn --config test.ovpn Wed Dec 4 08:54:28 2019 Unrecognized option or missing or extra parameter(s) in test.ovpn:104: auth-user-pass/etc/openvpn/client/ovpn.passwd (2.4.8) Wed Dec 4 08:54:28 2019 OpenVPN 2.4.8 x86_64-redhat-linux-gnu [Fedora EPEL patched] [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Nov 1 2019 Wed Dec 4 08:54:28 2019 library versions: OpenSSL 1.0.2k-fips 26 Jan 2017, LZO 2.06 Wed Dec 4 08:54:28 2019 WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead. Wed Dec 4 08:54:28 2019 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Wed Dec 4 08:54:28 2019 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication Wed Dec 4 08:54:28 2019 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication Wed Dec 4 08:54:28 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]redacted:1194 Wed Dec 4 08:54:28 2019 Socket Buffers: R=[212992->212992] S=[212992->212992] Wed Dec 4 08:54:28 2019 UDP link local: (not bound) Wed Dec 4 08:54:28 2019 UDP link remote: [AF_INET]redacted:1194 Wed Dec 4 08:54:28 2019 TLS: Initial packet from [AF_INET]redacted:1194, sid=9ee386c1 503662fa Wed Dec 4 08:54:28 2019 VERIFY OK: depth=1, CN=OpenVPN CA Wed Dec 4 08:54:28 2019 VERIFY OK: nsCertType=SERVER Wed Dec 4 08:54:28 2019 VERIFY OK: depth=0, CN=OpenVPN Server Wed Dec 4 08:54:28 2019 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA Wed Dec 4 08:54:28 2019 [OpenVPN Server] Peer Connection Initiated with [AF_INET]redacted:1194 Wed Dec 4 08:54:29 2019 SENT CONTROL [OpenVPN Server]: 'PUSH_REQUEST' (status=1) Wed Dec 4 08:54:29 2019 AUTH: Received control message: AUTH_FAILED Wed Dec 4 08:54:29 2019 SIGTERM[soft,auth-failure] received, process exiting _[/etc/openvpn/client]_(root@test)_ # echo $? 0 # yum info openvpn Installed Packages Name : openvpn Arch : x86_64 Version : 2.4.8 Release : 1.el7 Size : 1.2 M Repo : installed From repo : epel Summary : A full-featured SSL VPN solution URL : https://community.openvpn.net/ License : GPLv2 Description : OpenVPN is a robust and highly flexible tunneling application that uses all : of the encryption, authentication, and certification features of the : OpenSSL library to securely tunnel IP networks over a single UDP or TCP : port. It can use the Marcus Franz Xaver Johannes Oberhumers LZO library : for compression. Server info: # yum info openvpn-as Installed Packages Name : openvpn-as Arch : x86_64 Version : 2.7.4_777bcfe6 Release : CentOSrelease Size : 107 M Repo : installed Summary : openvpn-as License : Commercial Description : " mikeely Active Tickets 1286 Add option for the filename with pkcs11 token pin (password) Generic / unclassified Feature Wish new 2020-06-07T16:51:58Z 2020-06-07T16:51:58Z "There is currently no way to store pin (or password), requested by the external token, in a file, so that the file will be read instead of asking user to enter that password from the keyboard. The quick and dirty patch that re-uses ""askpass"" option as the password file for the pin: https://forums.openvpn.net/viewtopic.php?p=92325#p92325 However, probably there is a need for a separate option to do that." lvd2 Active Tickets 1298 feature wish: extend Linux VRF support to other OSes Networking OpenVPN git master branch (Community Ed) Feature Wish new 2020-06-30T09:17:51Z 2020-07-21T11:04:51Z "This is more a long-term thing... - collect information how ""multiple routing tables"", ""VRF"", etc. are done on various OSes - see if we can implement this in a sufficiently generic way What I've found so far: - Linux: SO_BINDTODEV will put the socket into ""a VRF"" if you bind to the (named) ""VRF device"" (-> vrf blue -> {{{bind-dev blue}}}). An interface is put into a VRF by enslaving it under the VRF master device. - FreeBSD: boot with ""net.fibs=N"" (default is 1, boot-time only), then a process can be put into a non-default fib with {{{setfib openvpn...}}} or setfib(2) or setsockopt(SO_SETFIB). An interface is put into a fib with {{{ifconfig ... -fib }}} - OpenBSD: {{{route}}} has {{{-T table}}} arguments to specifiy the routing table to use. {{{route -T table exec $command}}} seems to be similar to FreeBSD's {{{setfib i $command}}}. {{{ifconfig}}} has {{{rdomain $rdomainid}}} to specify a ""routing domain"". {{{setsockopt()}}} has SO_RTABLE ""set the routing table used for route lookups"", and {{{setrtable(2)}}} can be used to set the whole process's default table. (see man route, ifconfig, netintro, setsockopt) - NetBSD: ??? - MacOS: ??? - Windows: ??? " Gert Döring Active Tickets 1371 Allow TLS-Crypt-V2 keys to be password protected Generic / unclassified OpenVPN 2.5.0 (Community Ed) Feature Wish new 2020-12-31T20:17:12Z 2021-01-05T01:20:34Z "This is a standard security feature of all keys that I can think of, except this one. Obviously, I can do this outside of `openvpn` using `openssl` but then the key has to be decrypted before `openvpn` can load it. So I am asking for `openvpn` to manage this task. Openvpn would have to prompt for the password and users would also want to store passwords in plain text (because they always do..) This may be a lot of effort for a tiny feature so maybe just a ''pipe dream''." tct Active Tickets 1481 Please support `inactive` in `` Configuration Feature Wish new 2022-10-29T09:36:19Z 2022-12-03T23:43:17Z "I have several openvpn servers, and a well defined order of preference; I only want to connect to the 2nd or 3rd server if the 1st one is not available. If I don't specify `remote-random`, openvpn will try them in the correct order; however, if the first server is not reachable, it will get stuck on the first lower-preference server that ''is'' available. Currently there is no mechanism that would cause openvpn to periodically retry connecting to the first server. I imagine implementing a mechanism that keeps trying to connect to the first server while retaining the active connection to the 2nd one would be relatively difficult; however, allowing users to specify `inactive` in lower-preference `` blocks would be a poor man's way of doing this. I realize I can include `inactive` in the global configuration, but I would like to avoid disconnecting from the primary server if possible; I only want to disconnect from the secondaries. I can't implement this on the server side, because I only actually have one server instance that has several public IPs (which are on different uplinks). The next best solution would be to run a script from cron that checks where the running openvpn client is connected; if it's not the preferred server IP, then also checks whether the preferred server is available; and if yes, restarts the client. This feels even kludgier than abusing `inactive`." András Korn Active Tickets 756 Allow binding to --local interface Generic / unclassified OpenVPN 2.3.4 (Community Ed) User question new 2016-10-27T19:38:12Z 2023-03-04T13:36:30Z "My current setup is eth0 and an usb 3g dongle. I want the 3g dongle to be connected to an openvpn server somewhere. The problem is that I can't use --local ppp0 because it's not supported. I don't want to hardcode an ip, if the dongle's connection drops, new ip ! Also, the ppp connection doesn't need/have a gateway. I've even tried using --local with no luck it seems for some reason ! ( this might actually be a bug ). Can happily test any patches." d3xt3r01 Active Tickets 1018 OpenVPN Trademark violation by Mikrotik Generic / unclassified User question new 2018-02-14T09:26:57Z 2018-02-19T03:23:41Z "It`s only partial compatible client and server, no OpenVPN. They are misleading own customers: https://wiki.mikrotik.com/wiki/OpenVPN Only support login/pw auth No UDP No LZO So much etc." steemandlinux Active Tickets 753 OpenVPN should update systemd-resolved on systems running it Generic / unclassified OpenVPN git master branch (Community Ed) Bug / Defect David Sommerseth assigned 2016-10-24T22:23:49Z 2021-05-21T10:30:25Z "systemd-resolved is used by many programs (e.g. ssh, ping, psql) to do DNS lookups, and maintains a DNS cache. After starting openvpn on a system with systemd-resolved, this cache is not automatically flushed / updated, and therefore resources provided by the VPN are not accessible by name. There is a community supplied script that allows openvpn to update systemd directly. Please evaluate it and add post-initialization logic to openvpn to force systemd-resolved to update/flush its cache. https://github.com/jonathanio/update-systemd-resolved " flavor8 Active Tickets 847 "Long lived crypto ""state"" client lock-up" Crypto OpenVPN 2.3.10 (Community Ed) Bug / Defect Steffan Karger new 2017-02-24T23:49:08Z 2017-05-18T17:53:37Z "== Configuration setup == === Client === `[root@localhost ~]# openvpn --client --remote 192.168.122.1 --ca sample/sample-keys/ca.crt --key sample/sample-keys/client.key --cert sample/sample-keys/client.crt --verb 4 --dev tun --auth-user-pass --explicit-exit-notify --auth-nocache` === Server === `[root@localhost ~]# openvpn --dev tun --ca sample/sample-keys/ca.crt --key sample/sample-keys/server.key --cert sample/sample-keys/server.crt --dh sample/sample-keys/dh2048.pem --server 10.8.0.0 255.255.255.0 --script-security 3 --auth-user-pass-verify .auth.sh via-env --verb 7 --reneg-sec 10` == What happens == The client asks for username/password, connects and running ping on the client against 10.8.0.1 works as expected. A renegotiation is forced (due to `--reneg-sec 10`). At this point '''do not''' enter any credentials until the server have logged: {{{ Sat Feb 25 00:34:55 2017 us=576093 Test-Client/192.168.122.9:1194 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Sat Feb 25 00:34:55 2017 us=576099 Test-Client/192.168.122.9:1194 TLS Error: TLS handshake failed Sat Feb 25 00:34:55 2017 us=576104 Test-Client/192.168.122.9:1194 TLS: move_session: dest=TM_LAME_DUCK src=TM_ACTIVE reinit_src=1 }}} When this stage is completed, enter the proper username/password credentials. The client will re-connect properly (might need a couple of attempts, due to some client time-outs). But from this point of the server will no longer accept packets on the DATA channel from the client. Right before the rejection happens, this can be seen in the server log: {{{ Sat Feb 25 00:35:06 2017 us=972360 Test-Client/192.168.122.9:1194 Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key Sat Feb 25 00:35:06 2017 us=972379 Test-Client/192.168.122.9:1194 Data Channel Encrypt: CIPHER KEY: 3d4f9143 557d88ff 51cf05f7 4052abd8 93126d2e f2c1826c 1a7888a2 ef3cceb8 Sat Feb 25 00:35:06 2017 us=972401 Test-Client/192.168.122.9:1194 Data Channel Encrypt: CIPHER block_size=16 iv_size=12 Sat Feb 25 00:35:06 2017 us=972424 Test-Client/192.168.122.9:1194 Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key Sat Feb 25 00:35:06 2017 us=972449 Test-Client/192.168.122.9:1194 Data Channel Decrypt: CIPHER KEY: e8c6b960 88e078da ce001f18 8f465bb0 bc82adfa 63118cd3 7d29d6b1 70273ae4 Sat Feb 25 00:35:06 2017 us=972465 Test-Client/192.168.122.9:1194 Data Channel Decrypt: CIPHER block_size=16 iv_size=12 Sat Feb 25 00:35:06 2017 us=972540 Test-Client/192.168.122.9:1194 UDPv4 WRITE [247] to [AF_INET]192.168.122.9:1194: P_CONTROL_V1 kid=0 [ 5 ] pid=6 DATA len=221 }}} And after that, the following log lines appears for each packet the client tries to send over the VPN tunnel {{{ Sat Feb 25 00:35:06 2017 us=972653 Test-Client/192.168.122.9:1194 AEAD Decrypt error: cipher final failed }}} The bad thing about this is that this is persistent if the client stops its openvpn process (even with `--explicit-exit-notify`) and starts a completely fresh session. Restarting the server side re-enables the client again. " David Sommerseth Active Tickets 859 Client won't receive PUSH answer Generic / unclassified OpenVPN 2.4.0 (Community Ed) Bug / Defect Steffan Karger assigned 2017-03-22T22:37:22Z 2019-06-03T15:42:45Z "From my client log: Wed Mar 22 23:24:44 2017 OpenVPN 2.4.0 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 10 2017 Wed Mar 22 23:24:44 2017 library versions: OpenSSL 1.0.2g 1 Mar 2016, LZO 2.08 Wed Mar 22 23:24:44 2017 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Wed Mar 22 23:24:44 2017 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication Wed Mar 22 23:24:44 2017 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication Wed Mar 22 23:24:44 2017 TCP/UDP: Preserving recently used remote address: [AF_INET]193.175.73.200:1194 Wed Mar 22 23:24:44 2017 Socket Buffers: R=[212992->212992] S=[212992->212992] Wed Mar 22 23:24:44 2017 UDP link local: (not bound) Wed Mar 22 23:24:44 2017 UDP link remote: [AF_INET]193.175.73.200:1194 Wed Mar 22 23:24:44 2017 TLS: Initial packet from [AF_INET]193.175.73.200:1194, sid=78890186 f522bfd8 Wed Mar 22 23:24:44 2017 VERIFY OK: depth=1, C=DE, ST=Berlin, L=Berlin, O=Charite-VPN, OU=GB-IT, CN=Charite-VPN CA, name=EasyRSA, emailAddress=vpn@charite.de Wed Mar 22 23:24:44 2017 VERIFY OK: nsCertType=SERVER Wed Mar 22 23:24:44 2017 Validating certificate extended key usage Wed Mar 22 23:24:44 2017 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication Wed Mar 22 23:24:44 2017 VERIFY EKU OK Wed Mar 22 23:24:44 2017 VERIFY X509NAME OK: C=DE, ST=Berlin, L=Berlin, O=Charite-VPN, OU=GB-IT, CN=openvpn.charite.de, emailAddress=vpn@charite.de Wed Mar 22 23:24:44 2017 VERIFY OK: depth=0, C=DE, ST=Berlin, L=Berlin, O=Charite-VPN, OU=GB-IT, CN=openvpn.charite.de, emailAddress=vpn@charite.de Wed Mar 22 23:24:44 2017 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA Wed Mar 22 23:24:44 2017 [openvpn.charite.de] Peer Connection Initiated with [AF_INET]193.175.73.200:1194 Wed Mar 22 23:24:45 2017 SENT CONTROL [openvpn.charite.de]: 'PUSH_REQUEST' (status=1) Wed Mar 22 23:24:50 2017 SENT CONTROL [openvpn.charite.de]: 'PUSH_REQUEST' (status=1) Wed Mar 22 23:24:55 2017 SENT CONTROL [openvpn.charite.de]: 'PUSH_REQUEST' (status=1) Wed Mar 22 23:25:00 2017 SENT CONTROL [openvpn.charite.de]: 'PUSH_REQUEST' (status=1) Wed Mar 22 23:25:05 2017 SENT CONTROL [openvpn.charite.de]: 'PUSH_REQUEST' (status=1) Wed Mar 22 23:25:10 2017 SENT CONTROL [openvpn.charite.de]: 'PUSH_REQUEST' (status=1) Wed Mar 22 23:25:15 2017 SENT CONTROL [openvpn.charite.de]: 'PUSH_REQUEST' (status=1) Wed Mar 22 23:25:20 2017 SENT CONTROL [openvpn.charite.de]: 'PUSH_REQUEST' (status=1) Wed Mar 22 23:25:25 2017 SENT CONTROL [openvpn.charite.de]: 'PUSH_REQUEST' (status=1) Wed Mar 22 23:25:30 2017 SENT CONTROL [openvpn.charite.de]: 'PUSH_REQUEST' (status=1) Wed Mar 22 23:25:35 2017 SENT CONTROL [openvpn.charite.de]: 'PUSH_REQUEST' (status=1) Wed Mar 22 23:25:41 2017 SENT CONTROL [openvpn.charite.de]: 'PUSH_REQUEST' (status=1) Wed Mar 22 23:25:46 2017 No reply from server after sending 12 push requests Wed Mar 22 23:25:46 2017 SIGUSR1[soft,no-push-reply] received, process restarting Wed Mar 22 23:25:46 2017 Restart pause, 5 second(s) So I checked the server's log to see WTF happened: Mar 22 23:24:44 openvpn udp[976]: 91.65.62.252 TLS: Initial packet from [AF_INET6]::ffff:91.65.62.252:33631, sid=ef5e9f5d 3f4217f3 Mar 22 23:24:44 openvpn udp[976]: 91.65.62.252 VERIFY OK: depth=1, C=DE, ST=Berlin, L=Berlin, O=Charite-VPN, OU=GB-IT, CN=Charite-VPN CA, name=EasyRSA, emailAddress=vpn@charite.de Mar 22 23:24:44 openvpn udp[976]: 91.65.62.252 Validating certificate extended key usage Mar 22 23:24:44 openvpn udp[976]: 91.65.62.252 ++ Certificate has EKU (str) TLS Web Client Authentication, expects TLS Web Client Authentication Mar 22 23:24:44 openvpn udp[976]: 91.65.62.252 VERIFY EKU OK Mar 22 23:24:44 openvpn udp[976]: 91.65.62.252 VERIFY OK: depth=0, C=DE, ST=Berlin, L=Berlin, O=Charite-VPN, OU=GB-IT, CN=hildeb, emailAddress=vpn@charite.de Mar 22 23:24:44 openvpn udp[976]: 91.65.62.252 peer info: IV_VER=2.4.0 Mar 22 23:24:44 openvpn udp[976]: 91.65.62.252 peer info: IV_PLAT=linux Mar 22 23:24:44 openvpn udp[976]: 91.65.62.252 peer info: IV_PROTO=2 Mar 22 23:24:44 openvpn udp[976]: 91.65.62.252 peer info: IV_NCP=2 Mar 22 23:24:44 openvpn udp[976]: 91.65.62.252 peer info: IV_LZ4=1 Mar 22 23:24:44 openvpn udp[976]: 91.65.62.252 peer info: IV_LZ4v2=1 Mar 22 23:24:44 openvpn udp[976]: 91.65.62.252 peer info: IV_LZO=1 Mar 22 23:24:44 openvpn udp[976]: 91.65.62.252 peer info: IV_COMP_STUB=1 Mar 22 23:24:44 openvpn udp[976]: 91.65.62.252 peer info: IV_COMP_STUBv2=1 Mar 22 23:24:44 openvpn udp[976]: 91.65.62.252 peer info: IV_TCPNL=1 Mar 22 23:24:44 openvpn udp[976]: 91.65.62.252 TLS: Username/Password authentication succeeded for username 'hildeb' Mar 22 23:24:44 openvpn udp[976]: 91.65.62.252 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA Mar 22 23:24:44 openvpn udp[976]: 91.65.62.252 [hildeb] Peer Connection Initiated with [AF_INET6]::ffff:91.65.62.252:33631 Mar 22 23:24:44 openvpn udp[976]: hildeb/91.65.62.252 MULTI_sva: pool returned IPv4=172.29.0.32, IPv6=(Not enabled) Mar 22 23:24:45 openvpn udp[976]: hildeb/91.65.62.252 OPTIONS IMPORT: reading client specific options from: /tmp/openvpn_cc_9da7b1784f5db98918a667bf378a62a6.tmp Mar 22 23:24:45 openvpn udp[976]: hildeb/91.65.62.252 MULTI: Learn: 172.29.0.32 -> hildeb/91.65.62.252 Mar 22 23:24:45 openvpn udp[976]: hildeb/91.65.62.252 MULTI: primary virtual IP for hildeb/91.65.62.252: 172.29.0.32 Mar 22 23:24:45 openvpn udp[976]: Key [AF_INET6]::ffff:91.65.62.252:33631 [0] not initialized (yet), dropping packet. Mar 22 23:24:46 openvpn udp[976]: hildeb/87.142.97.40 Key [AF_INET6]::ffff:87.142.97.40:63480 [0] not initialized (yet), dropping packet. Mar 22 23:25:05 openvpn udp[976]: message repeated 23 times: [ hildeb/87.142.97.40 Key [AF_INET6]::ffff:87.142.97.40:63480 [0] not initialized (yet), dropping packet.] Not initialized yet? And what is that 87.142.97.40 IP? That's not my IP! So I checked the server's log for 87.142.97.40: Mar 22 23:22:18 openvpn udp[976]: 87.142.97.40 TLS: Initial packet from [AF_INET6]::ffff:87.142.97.40:63547, sid=601039fc 1ad49b35 Mar 22 23:22:19 openvpn udp[976]: 87.142.97.40 VERIFY OK: depth=1, C=DE, ST=Berlin, L=Berlin, O=Charite-VPN, OU=GB-IT, CN=Charite-VPN CA, name= EasyRSA, emailAddress=vpn@charite.de Mar 22 23:22:19 openvpn udp[976]: 87.142.97.40 Validating certificate extended key usage Mar 22 23:22:19 openvpn udp[976]: 87.142.97.40 ++ Certificate has EKU (str) TLS Web Client Authentication, expects TLS Web Client Authenticatio n Mar 22 23:22:19 openvpn udp[976]: 87.142.97.40 VERIFY EKU OK Mar 22 23:22:19 openvpn udp[976]: 87.142.97.40 VERIFY OK: depth=0, C=DE, ST=Berlin, L=Berlin, O=Charite-VPN, OU=GB-IT, CN=talthoff, emailAddres s=vpn@charite.de Mar 22 23:22:19 openvpn udp[976]: 87.142.97.40 peer info: IV_VER=2.3.6 Mar 22 23:22:19 openvpn udp[976]: 87.142.97.40 peer info: IV_PLAT=mac Mar 22 23:22:19 openvpn udp[976]: 87.142.97.40 peer info: IV_PROTO=2 Mar 22 23:22:19 openvpn udp[976]: 87.142.97.40 TLS: Username/Password authentication succeeded for username 'talthoff' Mar 22 23:22:19 openvpn udp[976]: 87.142.97.40 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key Mar 22 23:22:19 openvpn udp[976]: 87.142.97.40 Data Channel Encrypt: Using 256 bit message hash 'SHA256' for HMAC authentication Mar 22 23:22:19 openvpn udp[976]: 87.142.97.40 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key Mar 22 23:22:19 openvpn udp[976]: 87.142.97.40 Data Channel Decrypt: Using 256 bit message hash 'SHA256' for HMAC authentication Mar 22 23:22:19 openvpn udp[976]: 87.142.97.40 Control Channel: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA Mar 22 23:22:19 openvpn udp[976]: 87.142.97.40 [talthoff] Peer Connection Initiated with [AF_INET6]::ffff:87.142.97.40:63547 Mar 22 23:22:20 openvpn udp[976]: MULTI: Learn: 172.29.4.212 -> talthoff/87.142.97.40 Mar 22 23:22:20 openvpn udp[976]: MULTI: primary virtual IP for talthoff/87.142.97.40: 172.29.4.212 Mar 22 23:22:21 openvpn udp[976]: talthoff/87.142.97.40 PUSH: Received control message: 'PUSH_REQUEST' Mar 22 23:22:21 openvpn udp[976]: talthoff/87.142.97.40 SENT CONTROL [talthoff]: 'PUSH_REPLY,dhcp-option DNS 141.42.1.1,dhcp-option DOMAIN charite.de,register-dns,block-outside-dns,sndbuf 393216,rcvbuf 393216,route-gateway 172.29.0.1,topology subnet,ping 10,ping-restart 30,redirect-gateway def1,ifconfig 172.29.4.212 255.255.192.0,peer-id 18' (status=1) Mar 22 23:24:21 openvpn udp[976]: 87.142.97.40 TLS: Initial packet from [AF_INET6]::ffff:87.142.97.40:63480, sid=26e85a98 04474672 Mar 22 23:24:22 openvpn udp[976]: 87.142.97.40 VERIFY OK: depth=1, C=DE, ST=Berlin, L=Berlin, O=Charite-VPN, OU=GB-IT, CN=Charite-VPN CA, name=EasyRSA, emailAddress=vpn@charite.de Mar 22 23:24:22 openvpn udp[976]: 87.142.97.40 Validating certificate extended key usage Mar 22 23:24:22 openvpn udp[976]: 87.142.97.40 ++ Certificate has EKU (str) TLS Web Client Authentication, expects TLS Web Client Authentication Mar 22 23:24:22 openvpn udp[976]: 87.142.97.40 VERIFY EKU OK Mar 22 23:24:22 openvpn udp[976]: 87.142.97.40 VERIFY OK: depth=0, C=DE, ST=Berlin, L=Berlin, O=Charite-VPN, OU=GB-IT, CN=talthoff, emailAddress=vpn@charite.de Mar 22 23:24:22 openvpn udp[976]: 87.142.97.40 peer info: IV_VER=2.3.6 Mar 22 23:24:22 openvpn udp[976]: 87.142.97.40 peer info: IV_PLAT=mac Mar 22 23:24:22 openvpn udp[976]: 87.142.97.40 peer info: IV_PROTO=2 Mar 22 23:24:22 openvpn udp[976]: 87.142.97.40 TLS: Username/Password authentication succeeded for username 'talthoff' Mar 22 23:24:22 openvpn udp[976]: 87.142.97.40 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key Mar 22 23:24:22 openvpn udp[976]: 87.142.97.40 Data Channel Encrypt: Using 256 bit message hash 'SHA256' for HMAC authentication So it seems there was a mixup between my connection (hildeb, 91.65.62.252) and talthoff (87.142.97.40)" hildeb Active Tickets 911 interface mtu calculation in 2.4 significantly different from 2.3 Generic / unclassified OpenVPN 2.4.0 (Community Ed) Bug / Defect Steffan Karger accepted 2017-07-04T12:16:44Z 2017-07-20T20:26:51Z "debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867113 with {{{--link-mtu 1400}}}, 2.3 sets {{{ip ... mtu 1344}}} while 2.4 sets {{{ip ... mtu 1278}}} (which is too small for IPv6). I can see a few bytes being lost to account for worst-case crypto overhead before negotiation, but 80 extra bytes? This needs a closer look..." Gert Döring Active Tickets 931 TAP mode can loop packets back to the originating client Networking OpenVPN 2.4.3 (Community Ed) Bug / Defect Gert Döring accepted 2017-08-30T19:38:16Z 2018-06-28T06:25:04Z "In TAP mode with client-to-client enabled, if the server learns a MAC address as being at client A and then client A sends a packet with that MAC address as a destination, the packet is routed back to client A. This is wrong and not what real switches do. It causes issues as the packet bounces back and corrupts other switches' learning tables. If two OpenVPN clients are involved, it could also cause an infinite switching loop. This can be reproduced by setting up a TAP server with --server-bridge --client-to-client, and a client with --dev tap-cli, and then running the following two Python one-liners on the client (requires scapy): {{{ # python2 -c 'from scapy.all import *; sendp(Ether(dst=""00:00:00:00:01:aa"",src=""00:00:00:00:01:bb"",type=0xaaaa)/""test"", iface=""tap-cli"")' # python2 -c 'from scapy.all import *; sendp(Ether(dst=""00:00:00:00:01:bb"",src=""00:00:00:00:01:aa"",type=0xaaaa)/""test"", iface=""tap-cli"")' }}} The first packet causes OpenVPN to learn 00:00:00:00:01:bb for the client. The second one shows up twice in a tcpdump of tap-cli: the OpenVPN server resolves the 00:00:00:00:01:bb destination to the same client and loops it back. Doing this test on a real switch (or a linux bridge) does not yield the same behavior, which is expected, as normal switches never ""hairpin"" packets back to their source. This issue is particularly insidious because it randomly breaks connectivity between hosts which are on the same physical switch (not across the VPN link) just because an OpenVPN client TAP is also bridged to the same network. If Host A sends a packet to Host B and the real switch's MAC table entry for Host B has expired, it floods the packet to Host C which bridges it to OpenVPN, it gets looped back, and now the physical switch thinks Host A's MAC address lives on Host C's port and things break until Host A decides to talk again." marcan Active Tickets 945 systemd: LimitNPROC too low, wrong knob Generic / unclassified OpenVPN 2.4.4 (Community Ed) Bug / Defect David Sommerseth accepted 2017-10-09T22:10:32Z 2022-08-12T11:23:43Z "This has been originally reported to Debian at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861923. There is a way to reproduce this inside the bugreport. Basically you need to start several instances that run code as non-root Since the very first version of the systemd unit it contains the setting LimitNPROC=10 according to systemd.exec this translates to ""ulimit -u"". Even if set in the systemd unit this seems to translate to a generic ""limit the number of processes per UID on the whole system"" thing, which is certainly not the thing the author had in mind. https://bugs.launchpad.net/ubuntu/+source/openvpn/+bug/1631104 https://github.com/systemd/systemd/issues/6011#issuecomment-304617744" berni Active Tickets 957 X509v3 Name Constraints cause issues with recent OpenVPN Connect versions OpenVPN Connect Bug / Defect OpenVPN Inc. assigned 2017-11-08T12:38:14Z 2021-04-27T07:53:15Z "Since the recent OpenVPN Connect update our students are unable to connect to the OpenVPN server: OpenVPN core error: mbed TLS: error parsing ca certificate: X509 - The extension tag or value is invalid: ASN1 - ASN1 tag was of an unexpected value. Testing with mbedTLS 2.6.0 on a Linux computer with mbedtls_cert_app ca_file=cacertwithdns.pem mode=file shows mbedtls_x509_crt_parse returned -0x2562 with a modified version you see that it finds an unknown critical extension and bails out. It seems that it doesn't support X509v3 Name Constraints. In my opinion OpenVPN Connect should use a modified version of mbedTLS which ignores the X509v3 Name Constraints extension as long as they aren't supported by mbedTLS (DNS checks should be handled by OpenVPN directly) and gives a warning to the user and then the option to decide whether he/she wants to connect anyway. Probably you won't see many CAs with name constraints extensions in the wild, but they are useful when you want to create your own CA and protect your users and yourself from abuse (your own CA should only be able to create certificates for your domain and should not be misused for creating certificates for other domains)." sysadmin-htlleonding Active Tickets 967 Server not initializing Encrypt/Decrypt keys Crypto OpenVPN 2.4.4 (Community Ed) Bug / Defect Steffan Karger new 2017-12-14T10:05:57Z 2017-12-14T13:21:56Z "Hello, Following the email on openvpn-users list, https://sourceforge.net/p/openvpn/mailman/message/36155518/, here is the requested bug report: I am experiencing an issue only reported, after the upgrade of servers to v2.4.4. It only happens on a few percentage of the users, and only on a few locations :|, so far. And even to make things worst, it does not even happen every time. The issue, is that the server, sometimes, when a client is connecting for a first time, keeps reporting the following: Fri Dec 8 10:49:34 2017 us=532606 MrAnderson/2.2.2.2:49359 MULTI: primary virtual IP for MrAnderson/2.2.2.2:49359: 100.120.128.3 Fri Dec 8 10:49:34 2017 us=532674 MrAnderson/2.2.2.2:49359 SENT CONTROL [MrAnderson]: 'PUSH_REPLY,dhcp-option DNS 100.120.0.1,redirect-gateway def1,ping 9,ping-restart 30,explicit-exit-notify 1,route-gateway 100.120.128.1,topology subnet,redirect-gateway def1,ifconfig-ipv6 2001:db8:123::2/64 2001:db8:123::1,route-ipv6 2000::/3 2001:db8:123::1,explicit-exit-notify 2,compress,ifconfig 100.120.128.3 255.255.252.0,peer-id 0,cipher AES-256-GCM' (status=1) Fri Dec 8 10:49:34 2017 us=532783 MrAnderson/2.2.2.2:49359 MULTI: modified fd 8, mask 32768 Fri Dec 8 10:49:34 2017 us=532831 MrAnderson/2.2.2.2:49359 UDPv4 WRITE [399] to [AF_INET]2.2.2.2:49359: P_CONTROL_V1 kid=0 [ ] pid=7 DATA len=385 Fri Dec 8 10:49:34 2017 us=594533 GET INST BY REAL: 2.2.2.2:49359 [ok] Fri Dec 8 10:49:34 2017 us=594583 MrAnderson/2.2.2.2:49359 UDPv4 READ [22] from [AF_INET]2.2.2.2:49359: P_ACK_V1 kid=0 [ 7 ] Fri Dec 8 10:49:34 2017 us=594690 GET INST BY REAL: 2.2.2.2:49359 [ok] Fri Dec 8 10:49:34 2017 us=594718 MrAnderson/2.2.2.2:49359 UDPv4 READ [73] from [AF_INET]2.2.2.2:49359: P_DATA_V2 kid=0 DATA len=72 Fri Dec 8 10:49:34 2017 us=594733 MrAnderson/2.2.2.2:49359 Key [AF_INET]2.2.2.2:49359 [0] not initialized (yet), dropping packet. Fri Dec 8 10:49:34 2017 us=594757 GET INST BY REAL: 2.2.2.2:49359 [ok] Fri Dec 8 10:49:34 2017 us=594785 MrAnderson/2.2.2.2:49359 UDPv4 READ [96] from [AF_INET]2.2.2.2:49359: P_DATA_V2 kid=0 DATA len=95 Fri Dec 8 10:49:34 2017 us=594803 MrAnderson/2.2.2.2:49359 Key [AF_INET]2.2.2.2:49359 [0] not initialized (yet), dropping packet. Fri Dec 8 10:49:34 2017 us=594825 GET INST BY REAL: 2.2.2.2:49359 [ok] Fri Dec 8 10:49:34 2017 us=594841 MrAnderson/2.2.2.2:49359 UDPv4 READ [77] from [AF_INET]2.2.2.2:49359: P_DATA_V2 kid=0 DATA len=76 Fri Dec 8 10:49:34 2017 us=594854 MrAnderson/2.2.2.2:49359 Key [AF_INET]2.2.2.2:49359 [0] not initialized (yet), dropping packet. Fri Dec 8 10:49:34 2017 us=606809 GET INST BY REAL: 2.2.2.2:49359 [ok] Fri Dec 8 10:49:34 2017 us=606856 MrAnderson/2.2.2.2:49359 UDPv4 READ [77] from [AF_INET]2.2.2.2:49359: P_DATA_V2 kid=0 DATA len=76 Fri Dec 8 10:49:34 2017 us=606872 MrAnderson/2.2.2.2:49359 Key [AF_INET]2.2.2.2:49359 [0] not initialized (yet), dropping packet. Fri Dec 8 10:49:34 2017 us=611257 GET INST BY REAL: 2.2.2.2:49359 [ok] (Real IP and username replaced) So, since the keys appear not to be initialized, there is no communication from the server to the client, and eventually, the ping-timeout occurs. When that happens, there is a reconnection, and everything works as expected including the key definition. I can pretty much replicate this, with the help of some colleagues. What we were able to find out too, is that this issue does not occur, if the option --ncp-disable is set on the client's config file. I've already searched through the bug report database, and found nothing to support this behavior. Has anyone stumble upon this issue? Both client and server are v2.4.4. Please find the attached logs, for both server and client with --verb 7 Also, here are some specific answers for questions posted on the mailing list Q: Specify what kind of authentication mechanisms you are using. A: Both certs and username/password combination Q: Any additional scripts/plugins? A: --client-connect and --client-disconnect scripts are used. The --auth-user-pass-verify script is being executed on an plugin for deffered authentication. async push reply is also being used. Please do let me know if you need any other information. Thank you for you time. Cheers, Rui " ruisantos Active Tickets 1040 Same problem of #897 apollo lake cpu Crypto Bug / Defect Steffan Karger new 2018-03-16T06:31:31Z 2018-03-17T11:01:12Z "Hi, I have the same problem of the ticket #897. Different hardware (Zotac Ci327), different OS (freebsd 11.1 amd64), but same cpu apollo lake. Do you have any sokution/workaround. Moved the HD on a different hardware (different cpu) and VPN come up. Thank you. " dduck Active Tickets 1166 Key renotiation blocks openvpn server process Crypto OpenVPN 2.4.0 (Community Ed) Bug / Defect Steffan Karger new 2019-03-08T01:08:04Z 2022-12-23T03:16:21Z "Our wireless community uses OpenVPN servers (Debian Stretch, 2.4.0-6+deb9u3). Each server handles around 60 clients. Recently we noticed, that the OpenVPN server process periodically seems to block for about six seconds. During these six seconds, the OpenVPN tun interface traffic stops completely. Under normal circumstances around 30 to 60 MBit/s are transferred. The host itself operates normally - only the OpenVPN process seems to misbehave. After a good amount of digging around, I noticed that every single occurrence of these dropouts happens just at the time when one specific client processed its key renegotiation. This timing was easy to see, since that specific client is a bit older (2.3.6) and thus the key renegotiation leaves a warning message (regarding ""SWEET32"") in the server log. As soon as I restarted the OpenVPN process of that specific client, everything went back to normal: no visible (longer than one second) dropouts occur. The troublesome client uses exactly the same setup as many others. Thus there does not seem to be anything specific to this client. I cannot tell, what made him special. Then I looked more closely at the key renegotiation and minor dropouts (just a few packets getting lost). I think I notice the pattern that every key renegotiation (at least the ones with older clients emitting ""SWEET32"" warnings) seems to cause a chance of some packets getting lost. Now I am curious: is the key negotiation processed on the client or on the server? Does the server process block only for the server-side of this calculation or also for the client-side? (our servers are quite fast; but the clients are slow embedded devices) The following lines are the strace log during one of these dropouts: {{{ 00:24:53.207723 recvmsg(7, {msg_name={sa_family=AF_INET6, sin6_port=htons(60440), inet_pton(AF_INET6, ""::ffff:217.226.195.234"", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, msg_namelen=28, msg_iov=[{iov_base=""#?\236\330\341\243O\235\215\0\0\0\0\21:\344\26\3\1\0F\20\0\0BA\4n\376\v\375i""..., iov_len=2030}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 114 00:24:53.207796 time(NULL) = 1552001093 00:24:53.207852 time(NULL) = 1552001093 00:24:53.207907 time(NULL) = 1552001093 00:24:53.208175 time([1552001093]) = 1552001093 00:24:53.208244 time([1552001093]) = 1552001093 00:24:53.208573 time([1552001093]) = 1552001093 00:24:53.208636 time([1552001093]) = 1552001093 00:24:55.091926 time([1552001095]) = 1552001095 00:24:55.092029 time([1552001095]) = 1552001095 00:24:56.983555 time([1552001096]) = 1552001096 00:24:56.983674 time([1552001096]) = 1552001096 00:24:59.034857 time(NULL) = 1552001099 00:24:59.034998 time(NULL) = 1552001099 00:24:59.035056 time(NULL) = 1552001099 00:24:59.035124 time(NULL) = 1552001099 00:24:59.035170 time(NULL) = 1552001099 00:24:59.035241 time(NULL) = 1552001099 00:24:59.035311 time(NULL) = 1552001099 00:24:59.035368 poll([{fd=7, events=POLLOUT}, {fd=6, events=0}, {fd=3, events=POLLIN|POLLPRI}], 3, 0) = 1 ([{fd=7, revents=POLLOUT}]) 00:24:59.035450 time(NULL) = 1552001099 00:24:59.035505 sendmsg(7, {msg_name={sa_family=AF_INET6, sin6_port=htons(60440), inet_pton(AF_INET6, ""::ffff:217.226.195.234"", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, msg_namelen=28, msg_iov=[{iov_base=""+\375\251\1\23kk\r\6\1\0\0\0\21?\236\330\341\243O\235\215"", iov_len=22}], msg_iovlen=1, msg_control=[{cmsg_len=36, cmsg_level=SOL_IPV6, cmsg_type=0x32}], msg_controllen=40, msg_flags=0}, 0) = 22 00:24:59.035613 time(NULL) = 1552001099 00:24:59.035662 time(NULL) = 1552001099 00:24:59.035708 time(NULL) = 1552001099 }}} Please note the lack of activity between 00:24:53 and 00:24:59. Usually there are a few thousand lines of strace log output for every second." sumpfralle Active Tickets 1216 "Certificate via MI with OpenSSL 1.1.1 errors with ""Unknown Padding Type""" Generic / unclassified OpenVPN 2.4.7 (Community Ed) Bug / Defect plaisthos assigned 2019-09-20T19:50:04Z 2020-10-21T22:41:28Z "Hello, I believe there's a bug when using the management interface for private keys with openssl 1.1.1 (observed on both Debian and macOS). When using ''openssl/1.1.0t'', I have been able to provide certificates and keys via management interface. The `NEEDS-CERTIFICATE` and `RSA_SIGN` steps are executed successfully. When using ''openssl/1.1.1d'' with the same credentials, it executes the `NEEDS-CERTIFICATE`, but it errors with the following before ever calling `RSA_SIGN`. {{{ Fri Sep 20 11:24:28 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]192.0.2.123:1194 Fri Sep 20 11:24:28 2019 Socket Buffers: R=[131072->131072] S=[131072->131072] Fri Sep 20 11:24:28 2019 Attempting to establish TCP connection with [AF_INET]192.0.2.123:1194 [nonblock] Fri Sep 20 11:24:29 2019 TCP connection established with [AF_INET]192.0.2.123:1194 Fri Sep 20 11:24:29 2019 TCP_CLIENT link local: (not bound) Fri Sep 20 11:24:29 2019 TCP_CLIENT link remote: [AF_INET]192.0.2.123:1194 Fri Sep 20 11:24:29 2019 TLS: Initial packet from [AF_INET]192.0.2.123:1194, sid=25d11069 5432dddb Fri Sep 20 11:24:29 2019 VERIFY OK: depth=1, C=USA, O=Cloud Foundry, CN=openvpn Fri Sep 20 11:24:29 2019 VERIFY KU OK Fri Sep 20 11:24:29 2019 Validating certificate extended key usage Fri Sep 20 11:24:29 2019 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication Fri Sep 20 11:24:29 2019 VERIFY EKU OK Fri Sep 20 11:24:29 2019 VERIFY OK: depth=0, C=USA, O=Cloud Foundry, CN=server vvvv Fri Sep 20 11:24:29 2019 OpenSSL: error:04066076:rsa routines:rsa_ossl_private_encrypt:unknown padding type Fri Sep 20 11:24:29 2019 OpenSSL: error:141F0006:SSL routines:tls_construct_cert_verify:EVP lib ^^^^ Fri Sep 20 11:24:29 2019 TLS_ERROR: BIO read tls_read_plaintext error Fri Sep 20 11:24:29 2019 TLS Error: TLS object -> incoming plaintext read error Fri Sep 20 11:24:29 2019 TLS Error: TLS handshake failed Fri Sep 20 11:24:29 2019 Fatal TLS error (check_tls_errors_co), restarting Fri Sep 20 11:24:29 2019 SIGUSR1[soft,tls-error] received, process restarting Fri Sep 20 11:24:29 2019 Restart pause, 5 second(s) }}} Unfortunately, I am a bit out of my depth, but the following seems most notable to me: * Why does openvpn's behavior change based on whether the certificate came from configuration vs management interface? That is, where an embedded certificate/key in a profile works, if those same values come from management, it fails. * Recompiling with some additional logging, I'm able to see that it is caused by an explicit `RSAerr` when the padding does not match the expected `RSA_PKCS1_PADDING` ([https://github.com/OpenVPN/openvpn/blob/6ccb3b2e3ae841934ecb461461ac1e212da64109/src/openvpn/ssl_openssl.c#L1142 source]). * With 1.1.0 it implicitly uses `RSA_PKCS1_PADDING` via [https://github.com/openssl/openssl/blob/7ea5bd2b52d0e81eaef3d109b3b12545306f201c/crypto/rsa/rsa_pmeth.c#L146-L151 this branch]. * With 1.1.1 it uses `RSA_NO_PADDING` via [https://github.com/openssl/openssl/blob/97ace46e11dba4c4c2b7cb67140b6ec152cfaaf4/crypto/rsa/rsa_pmeth.c#L169-L177 this branch]. * It seems like `RSA_PKCS1_PSS_PADDING` instead of `RSA_PKCS1_PADDING` may be related to TLS 1.3 support? * There's a similar-sounding [https://github.com/openssl/openssl/issues/7968 openssl issue] about 1.1.1 now always using `RSA_NO_PADDING` (but the commentary is difficult for me to understand). * Possible similar scenario of [https://github.com/openssl/openssl/issues/8356 external private key with TLS 1.3]? Any guidance or insight would be appreciated. Thank you for your time. == Reproduction Steps For the test environment, I built the dependencies with [https://gist.github.com/dpb587-pivotal/d0d132c586ed4053323b4d4246664a07#file-build-sh build.sh]. For a smaller repro case, I wrote [https://gist.github.com/dpb587-pivotal/d0d132c586ed4053323b4d4246664a07#file-management-tool-sh some Go code] to run a management server from an existing, regular OpenVPN profile which contains an embedded `cert`/`key`. Then, assuming some existing profile, the following commands demonstrate the problem: {{{ profile=some/existing/openvpn.ovpn # 1.1.0 success ~/tmp/padding-bug/management-tool ""${profile}"" management & ~/tmp/padding-bug/with-openssl-1.1.0/sbin/openvpn <( ~/tmp/padding-bug/management-tool ""${profile}"" profile ) # 1.1.1 failure ~/tmp/padding-bug/management-tool ""${profile}"" management & ~/tmp/padding-bug/with-openssl-1.1.1/sbin/openvpn <( ~/tmp/padding-bug/management-tool ""${profile}"" profile ) ...snip... Fri Sep 20 11:24:29 2019 OpenSSL: error:04066076:rsa routines:rsa_ossl_private_encrypt:unknown padding type Fri Sep 20 11:24:29 2019 OpenSSL: error:141F0006:SSL routines:tls_construct_cert_verify:EVP lib Fri Sep 20 11:24:29 2019 TLS_ERROR: BIO read tls_read_plaintext error Fri Sep 20 11:24:29 2019 TLS Error: TLS object -> incoming plaintext read error Fri Sep 20 11:24:29 2019 TLS Error: TLS handshake failed Fri Sep 20 11:24:29 2019 Fatal TLS error (check_tls_errors_co), restarting }}}" dpb587 Active Tickets 1234 TAP device creation fails under Windows7x64 for TAP v. > 9.21.2 tap-windows6 OpenVPN 2.4.8 (Community Ed) Bug / Defect Samuli Seppänen assigned 2019-11-21T12:42:57Z 2019-11-21T16:17:09Z "Steps to reproduce: 1. VBox 2. Clean Windows7x64 guest 3. Installing TAP with OpenVPN community bundles v.2.4.8 or v2.4.7 4. Driver installed successfully but no device created TAP v.9.21.2 installed separately works just fine. More info: https://forums.openvpn.net/viewtopic.php?f=5&t=28334&p=88051" Digika Active Tickets 1250 """Import file"" fails to import critical files" Windows GUI OpenVPN 2.4.8 (Community Ed) Bug / Defect Selva Nair new 2020-02-04T23:34:13Z 2020-02-06T01:19:33Z "**Problem:** When you import a new VPN connection using the Open file feature, OpenVPN fails to copy over needed files. **How to reproduce:** With Netgear routers, one may download a zip file that has the files necessary to allow OpenVPN to connect to the router's VPN service. More info is at https://kb.netgear.com/23854/How-do-I-use-the-VPN-service-on-my-Nighthawk-router-with-my-Windows-client. If you unzip the contents of the zip file, you'll see these files: * ca.crt * client.crt * client.key * client1.ovpn The next step is to right-click on the OpenVPN systray icon and select **Import file**, navigate to the directory where the above four files are located, select **client1.ovpn**, then hit **Open**. At that point, what should happen is OpenVPN should pull over that .ovpn file and other files necessary to make the VPN connection work. What actually happens is ''only'' the .ovpn file is copied over. One has to manually figure out the OpenVPN config directory and copy the remaining files over" arencambre Active Tickets 1269 tap-windows6: add an identifier to the inf file to make win7/win10 driver versions different tap-windows6 Bug / Defect Samuli Seppänen assigned 2020-04-06T11:48:09Z 2020-04-06T15:50:06Z "This was brought up in a [https://www.mail-archive.com/openvpn-users@lists.sourceforge.net/msg05171.html long email thread] related to Windows 10 driver issues after ""factory reset"". From Selva Nair: ""Add an identifier to the inf file to make the two versions (win7/win10) different.""" Samuli Seppänen Active Tickets 1289 Using x509-username-field Crypto OpenVPN 2.4.7 (Community Ed) Bug / Defect Steffan Karger new 2020-06-12T17:37:38Z 2020-08-29T20:33:05Z "Hi We are using x509-username-field option in openvpn server configuration file as: .... tcp-nodelay x509-username-field ext:subjectAltName .... Our intention was to use Subject AltName in the client certificate instead of their CN. Clients connecting to this server do have x509v3 extensions in their certificates (like example) .... X509v3 Subject Alternative Name: DNS:client1.abc.io, DNS:client2.abc.io, DNS:client3.abc.io .... But when client tries to connect to the server we are seeing an error at the server and connection fails. Is there anything wrong in the configuration of anything missed? Fri Jun 12 10:23:16 2020 us=970524 119.82.104.234:39962 VERIFY ERROR: could not extract ext:subjectAltName from X509 subject string ('O=ABC, OU=abc-system, CN=client1.abc.io') -- note that the username length is limited to 64 characters " krishnamurthydv Active Tickets 1295 Windows 10 2004 breaks wintun driver Generic / unclassified OpenVPN 2.4.8 (Community Ed) Bug / Defect stipa assigned 2020-06-19T15:31:24Z 2022-09-15T15:16:59Z "I have been using the 2.5 technology preview wintun driver for several months and found it very stable. I just updated my machine to the 2004 release of Windows 10, and launching my OpenVPN connection prompts for my credentials as normal but then fails to connect with the error {{{ Fri Jun 19 16:14:55 2020 us=30856 open_tun Fri Jun 19 16:14:55 2020 us=37837 MANAGEMENT: Client disconnected Fri Jun 19 16:14:55 2020 us=37837 All wintun adapters on this system are currently in use. Fri Jun 19 16:14:55 2020 us=37837 Exiting due to fatal error }}} Looking at the Network Adapters control panel, the wintun driver is gone. Re-installing the package does not make it reappear. " RemoteOne Active Tickets 1331 wintun does not support dhcp-option DOMAIN Generic / unclassified Bug / Defect stipa assigned 2020-09-22T11:21:13Z 2022-12-21T17:38:24Z "Ref: https://forums.openvpn.net/viewtopic.php?f=23&t=30990 " tct Active Tickets 1358 port-share origin file scrambles IPv6 address IPv6 OpenVPN 2.4.9 (Community Ed) Bug / Defect Gert Döring new 2020-12-01T00:27:42Z 2020-12-06T19:47:57Z "The reason I'm messing with port-share client reporting is that I want to test if my Tor server is working. The test has these hops, many involving my semi-bastion host Claude and/or one of my wild-side gateways Surya or Jacinth. * An internal host (laptop) runs w3m (-4 or -6) with https_proxy. The URL (see below) is for the wild-side address of the gateway. * Proxy traffic goes to Privoxy on Claude port 8118. * It is forwarded (forward-socks5t) to Tor on Claude port 9050. This forwarded traffic is confirmed by tcpdump -i lo port 9050 * The Tor daemon sends it out to the cloud. * The Tor exit node sends the traffic to my wild side, surya.jfcarter.net. * OpenVPN on Surya proxies the traffic over to the webserver on Claude. * Claude runs a script (whatismyip.cgi) reporting the client's IP. When it recognizes a proxy situation, it does a HTTP query back to the gateway, specifying the proxy's IP and port in its query-string. * Surya's proxysrc.cgi looks in OpenVPN's proxy reporting directory, and assuming the file was found (it was never seen to fail), it sends back the file's content. * Claude's whatismyip.cgi sends back through the various hops a report of the client's IP (plus proxy info if applicable). * If the client IP belongs to a Tor exit node (or more realistically, doesn't belong to anything I recognize), then I get a simple positive confirmation that my Tor setup is working. * The command line on the laptop was: https_proxy=https://claude.cft.ca.us:8118/ w3m -4 \ https://surya.jfcarter.net/whatismyip.cgi?debug (alternatively w3m -6, or to jacinth.jfcarter.net) (for extra debugging info, give a query-string of 'debug'.) * Why aren't I using the Tor browser directly? Because most of the traffic to be protected by Tor is non-HTTP. * For the back story on why I have two gateways, Surya and Jacinth, one could take a quick look at https://www.jfcarter.net/~jimc/documents/cloud-server-1901.html The problem occurs in openvpn-2.4.9-1.1.x86_64 from OpenSuSE Tumbleweed. To avoid public wireless nets that block VPNs, I have OpenVPN on my gateway Surya port 443/tcp (as well as 1194/udp), and port sharing with this configuration command: port-share claude.cft.ca.us 443 /var/lib/wwwrun/openvpn-ps (Complete file below.) It successfully forwards non-OpenVPN traffic (always HTTPS) to the webserver Claude. It always uses IPv4; it's never been seen to use IPv6 though that would work if used. The symptom is that the client address in the origin file is incorrect. First, it is always reported as [AF_INET6] even for client ""w3m -4"". Then, even on authentic IPv6 the trailing 64 bits are not recognizable; they seem randomized. The leading 64 bits are at least partially correct: from w3m -6 on my laptop direct to Surya, the prefix of my LAN is seen intact; from my cellphone (on cellular data, LTE, IPv6) to Surya, the first 32 bits belong (per whois) to my carrier and I wouldn't know what the next 32 should be; and with an IPv4 source address (w3m -4) mapped to IPv6 the first 64 bits should be and are zero, although the expected FFFF is not seen and 16 or 32 bits of 0 are seen at the end, the rest being random. Assuming the bug tracker will allow it, I'm attaching the two scripts mentioned, though you will have to adjust the loginID of the executing user (wwwrun), the location of the origin file directory, and the address(es) of the OpenVPN/proxy server(s). To see the bug in action (or results after fixing) you're welcome to access the URL in the first section. OpenVPN configuration file minus most comments: Settings are (mostly) in the order appearing in the OpenSSL man page. mode server # Could it be that tcp6-server causes IPv4 clients to appear as mapped IPv6? proto tcp6-server float port 443 dev tun1 topology subnet ifconfig-nowarn tcp-nodelay keepalive 30 65 ping-timer-rem persist-tun persist-key persist-local-ip persist-remote-ip mlock cd /etc/openvpn writepid /run/openvpn/surya443.pid fast-io verb 2 mute 10 server 192.9.200.152 255.255.255.248 server-ipv6 2600:3c01:e000:306::4:0/112 push ""dhcp-option DNS 192.9.200.193"" client-to-client duplicate-cn port-share claude.cft.ca.us 443 /var/lib/wwwrun/openvpn-ps auth SHA256 ncp-ciphers AES-256-GCM:AES-256-CBC:AES-256-CFB:AES-128-GCM:AES-128-CBC:AES-128-CFB cipher AES-256-CBC compress lzo tls-server ca /etc/ssl/ca/host.pth dh /etc/ssl/hostcerts/dhparams.pem cert /etc/ssl/hostcerts/hostw.cia key /etc/ssl/private/hostw.key tls-cipher DEFAULT:+aRSA:+SHA:!aNULL:!DES:!3DES:!RC4:!MD5:!PSK:!DSS:!CAMELLIA:!SEED:!SRP:!AES256 key-direction 0 -----BEGIN OpenVPN Static key V1----- (snip) -----END OpenVPN Static key V1----- " jimc Active Tickets 1375 "Applying dhcp-option DOMAIN fails for wintun if domain contains hyphens (""-"")" Generic / unclassified OpenVPN 2.5.0 (Community Ed) Bug / Defect stipa assigned 2021-01-11T16:08:38Z 2021-02-25T20:46:01Z "OpenVPN fails to configure the adapter domain suffix for wintun adapter using dhcp-option DOMAIN for domain names containing hyphens (""-""). The log displays the following error message: {{{ TUN: adding dns domain failed using service: [Unknown Win32 Error] [status=44506 if_name=OpenVPN] }}} For instance, the following options causes the error: {{{ dhcp-option DOMAIN abc-net.mroland.at }}} The same option works fine if the domain name does not contain a hyphen, e.g. for {{{ dhcp-option DOMAIN abcnet.mroland.at }}} setting the adpater domain suffix works just fine (showing an entry ""DNS domain set using service"" in the log). The affected OpenVPN version is: {{{ OpenVPN 2.5.0 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Oct 28 2020 library versions: OpenSSL 1.1.1h 22 Sep 2020, LZO 2.10 Windows version 10.0 (Windows 10 or greater) 64bit }}} Wintun & OpenVPN GUI versions: {{{ Wintun 0.8.0.0 / 2019-12-10 OpenVPN GUI 11.20.0.0 }}} Client configurationfor my tests (with sensitive information removed): {{{ ip-win32 dynamic client dev tun dev-node ""OpenVPN"" windows-driver wintun proto tcp remote [REDACTED] [REDACTED] verify-x509-name [REDACTED] dhcp-option DOMAIN abc-net.mroland.at resolv-retry infinite nobind persist-key persist-tun auth-user-pass cipher AES-256-CBC auth SHA256 route-delay 4 verb 3 reneg-sec 0 [REDACTED] [REDACTED] [REDACTED] }}}" mroland Active Tickets 1398 wintun head/tail value is over capacity Generic / unclassified OpenVPN 2.5.1 (Community Ed) Bug / Defect stipa assigned 2021-04-07T10:41:47Z 2022-12-07T14:19:27Z "Our VPN connection using wintun, but does not work - no traffic passes. 2021-04-07 11:37:10 us=895201 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning. 2021-04-07 11:37:10 us=895201 Current Parameter Settings: 2021-04-07 11:37:10 us=895201 config = 'SVD_AT_RA.ovpn' 2021-04-07 11:37:10 us=895201 mode = 0 2021-04-07 11:37:10 us=895201 show_ciphers = DISABLED 2021-04-07 11:37:10 us=895201 show_digests = DISABLED 2021-04-07 11:37:10 us=895201 show_engines = DISABLED 2021-04-07 11:37:10 us=895201 genkey = DISABLED 2021-04-07 11:37:10 us=895201 genkey_filename = '[UNDEF]' 2021-04-07 11:37:10 us=895201 key_pass_file = '[UNDEF]' 2021-04-07 11:37:10 us=895201 show_tls_ciphers = DISABLED 2021-04-07 11:37:10 us=895201 connect_retry_max = 0 2021-04-07 11:37:10 us=895201 Connection profiles [0]: 2021-04-07 11:37:10 us=895201 proto = udp 2021-04-07 11:37:10 us=895201 local = '[UNDEF]' 2021-04-07 11:37:10 us=895201 local_port = '[UNDEF]' 2021-04-07 11:37:10 us=895201 remote = 'coles.25.hatms.co.uk' 2021-04-07 11:37:10 us=895201 remote_port = '1194' 2021-04-07 11:37:10 us=895201 remote_float = DISABLED 2021-04-07 11:37:10 us=895201 bind_defined = DISABLED 2021-04-07 11:37:10 us=895201 bind_local = DISABLED 2021-04-07 11:37:10 us=895201 NOTE: --mute triggered... 2021-04-07 11:37:10 us=895201 281 variation(s) on previous 20 message(s) suppressed by --mute 2021-04-07 11:37:10 us=895201 OpenVPN 2.5.1 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Feb 24 2021 2021-04-07 11:37:10 us=895201 Windows version 10.0 (Windows 10 or greater) 64bit 2021-04-07 11:37:10 us=895201 library versions: OpenSSL 1.1.1j 16 Feb 2021, LZO 2.10 Enter Management Password: 2021-04-07 11:37:10 us=895201 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25368 2021-04-07 11:37:10 us=895201 Need hold release from management interface, waiting... 2021-04-07 11:37:11 us=395513 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25368 2021-04-07 11:37:11 us=504619 MANAGEMENT: CMD 'state on' 2021-04-07 11:37:11 us=504619 MANAGEMENT: CMD 'log all on' 2021-04-07 11:37:11 us=582549 MANAGEMENT: CMD 'echo all on' 2021-04-07 11:37:11 us=582549 MANAGEMENT: CMD 'bytecount 5' 2021-04-07 11:37:11 us=582549 MANAGEMENT: CMD 'hold off' 2021-04-07 11:37:11 us=582549 MANAGEMENT: CMD 'hold release' 2021-04-07 11:37:13 us=691939 MANAGEMENT: CMD 'password [...]' 2021-04-07 11:37:13 us=691939 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this 2021-04-07 11:37:13 us=691939 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication 2021-04-07 11:37:13 us=691939 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication 2021-04-07 11:37:13 us=691939 Control Channel MTU parms [ L:1621 D:1140 EF:110 EB:0 ET:0 EL:3 ] 2021-04-07 11:37:13 us=691939 MANAGEMENT: >STATE:1617791833,RESOLVE,,,,,, 2021-04-07 11:37:13 us=723375 Data Channel MTU parms [ L:1621 D:1450 EF:121 EB:406 ET:0 EL:3 ] 2021-04-07 11:37:13 us=723375 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1601,tun-mtu 1500,proto UDPv4,keydir 1,cipher AES-256-CBC,auth SHA512,keysize 256,tls-auth,key-method 2,tls-client' 2021-04-07 11:37:13 us=723375 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1601,tun-mtu 1500,proto UDPv4,keydir 0,cipher AES-256-CBC,auth SHA512,keysize 256,tls-auth,key-method 2,tls-server' 2021-04-07 11:37:13 us=723375 TCP/UDP: Preserving recently used remote address: [AF_INET]82.71.233.57:1194 2021-04-07 11:37:13 us=723375 Socket Buffers: R=[65536->65536] S=[65536->65536] 2021-04-07 11:37:13 us=723375 UDP link local: (not bound) 2021-04-07 11:37:13 us=723375 UDP link remote: [AF_INET]####:1194 2021-04-07 11:37:13 us=723375 MANAGEMENT: >STATE:1617791833,WAIT,,,,,, 2021-04-07 11:37:13 us=741728 MANAGEMENT: >STATE:1617791833,AUTH,,,,,, 2021-04-07 11:37:13 us=741728 TLS: Initial packet from [AF_INET]####:1194, sid=dca5563f 1f2e4af8 2021-04-07 11:37:13 us=817068 VERIFY OK: ### 2021-04-07 11:37:13 us=817068 VERIFY OK: ### 2021-04-07 11:37:13 us=817068 VERIFY KU OK 2021-04-07 11:37:13 us=817068 Validating certificate extended key usage 2021-04-07 11:37:13 us=817068 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication 2021-04-07 11:37:13 us=817068 VERIFY EKU OK 2021-04-07 11:37:13 us=817068 VERIFY OK: depth=0 #### 2021-04-07 11:37:13 us=957802 [####] Peer Connection Initiated with [AF_INET]82.71.233.57:1194 2021-04-07 11:37:15 us=76336 MANAGEMENT: >STATE:1617791835,GET_CONFIG,,,,,, 2021-04-07 11:37:15 us=76336 SENT CONTROL [####]: 'PUSH_REQUEST' (status=1) 2021-04-07 11:37:15 us=97911 PUSH: Received control message: 'PUSH_REPLY,route 10.51.4.0 255.255.255.128,route 10.53.4.0 255.255.255.128,route 10.57.4.0 255.255.255.128,route 10.57.5.0 255.255.255.128,route 10.59.78.1,topology net30,ping 10,ping-restart 120,ifconfig 10.59.78.6 10.59.78.5,peer-id 0,cipher AES-256-GCM' 2021-04-07 11:37:15 us=97911 OPTIONS IMPORT: timers and/or timeouts modified 2021-04-07 11:37:15 us=97911 OPTIONS IMPORT: --ifconfig/up options modified 2021-04-07 11:37:15 us=97911 OPTIONS IMPORT: route options modified 2021-04-07 11:37:15 us=97911 OPTIONS IMPORT: peer-id set 2021-04-07 11:37:15 us=97911 OPTIONS IMPORT: adjusting link_mtu to 1624 2021-04-07 11:37:15 us=97911 OPTIONS IMPORT: data channel crypto options modified 2021-04-07 11:37:15 us=97911 Data Channel: using negotiated cipher 'AES-256-GCM' 2021-04-07 11:37:15 us=97911 Data Channel MTU parms [ L:1552 D:1450 EF:52 EB:406 ET:0 EL:3 ] 2021-04-07 11:37:15 us=97911 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key 2021-04-07 11:37:15 us=97911 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key 2021-04-07 11:37:15 us=97911 interactive service msg_channel=628 2021-04-07 11:37:15 us=97911 ROUTE_GATEWAY 138.104.152.254/255.255.0.0 I=26 HWADDR=54:bf:64:87:6d:d2 2021-04-07 11:37:15 us=97911 open_tun 2021-04-07 11:37:15 us=113548 Ring buffers registered via service 2021-04-07 11:37:15 us=113548 wintun device [Local Area Connection 2] opened 2021-04-07 11:37:15 us=113548 do_ifconfig, ipv4=1, ipv6=0 2021-04-07 11:37:15 us=113548 MANAGEMENT: >STATE:1617791835,ASSIGN_IP,,10.59.78.6,,,, 2021-04-07 11:37:15 us=113548 INET address service: add 10.59.78.6/30 2021-04-07 11:37:15 us=113548 IPv4 MTU set to 1500 on interface 75 using service 2021-04-07 11:37:15 us=113548 MANAGEMENT: >STATE:1617791835,ADD_ROUTES,,,,,, 2021-04-07 11:37:15 us=113548 C:\WINDOWS\system32\route.exe ADD 10.51.4.0 MASK 255.255.255.128 10.59.78.5 2021-04-07 11:37:15 us=144633 Route addition via service succeeded 2021-04-07 11:37:15 us=144633 C:\WINDOWS\system32\route.exe ADD 10.53.4.0 MASK 255.255.255.128 10.59.78.5 2021-04-07 11:37:15 us=160140 Route addition via service succeeded 2021-04-07 11:37:15 us=160140 C:\WINDOWS\system32\route.exe ADD 10.57.4.0 MASK 255.255.255.128 10.59.78.5 2021-04-07 11:37:15 us=175778 Route addition via service succeeded 2021-04-07 11:37:15 us=175778 C:\WINDOWS\system32\route.exe ADD 10.57.5.0 MASK 255.255.255.128 10.59.78.5 2021-04-07 11:37:15 us=175778 Route addition via service succeeded 2021-04-07 11:37:15 us=175778 C:\WINDOWS\system32\route.exe ADD 10.59.78.1 MASK 255.255.255.255 10.59.78.5 2021-04-07 11:37:15 us=191400 Route addition via service succeeded 2021-04-07 11:37:15 us=191400 Initialization Sequence Completed 2021-04-07 11:37:15 us=191400 MANAGEMENT: >STATE:1617791835,CONNECTED,SUCCESS,10.59.78.6,82.71.233.57,1194,, 2021-04-07 11:37:25 us=482783 write_wintun(): head/tail value is over capacity 2021-04-07 11:37:25 us=482783 write to TUN/TAP : No error (code=0) 2021-04-07 11:37:25 us=501785 write_wintun(): head/tail value is over capacity 2021-04-07 11:37:25 us=501785 write to TUN/TAP : No error (code=0) 2021-04-07 11:37:25 us=717841 write_wintun(): head/tail value is over capacity 2021-04-07 11:37:25 us=717841 write to TUN/TAP : No error (code=0) 2021-04-07 11:37:25 us=740846 write_wintun(): head/tail value is over capacity 2021-04-07 11:37:25 us=740846 write to TUN/TAP : No error (code=0) 2021-04-07 11:37:25 us=967909 write_wintun(): head/tail value is over capacity 2021-04-07 11:37:25 us=967909 write to TUN/TAP : No error (code=0) 2021-04-07 11:37:25 us=980913 write_wintun(): head/tail value is over capacity 2021-04-07 11:37:25 us=980913 write to TUN/TAP : No error (code=0) 2021-04-07 11:37:26 us=458040 write_wintun(): head/tail value is over capacity 2021-04-07 11:37:26 us=458040 write to TUN/TAP : No error (code=0) 2021-04-07 11:37:26 us=461038 write_wintun(): head/tail value is over capacity 2021-04-07 11:37:26 us=461038 write to TUN/TAP : No error (code=0) 2021-04-07 11:37:27 us=422435 write_wintun(): head/tail value is over capacity 2021-04-07 11:37:27 us=422435 write to TUN/TAP : No error (code=0) 2021-04-07 11:37:27 us=437808 write_wintun(): head/tail value is over capacity 2021-04-07 11:37:27 us=437808 write to TUN/TAP : No error (code=0) 2021-04-07 11:37:29 us=333273 write_wintun(): head/tail value is over capacity 2021-04-07 11:37:29 us=333273 write to TUN/TAP : No error (code=0) 2021-04-07 11:37:29 us=428153 write_wintun(): head/tail value is over capacity 2021-04-07 11:37:29 us=428153 write to TUN/TAP : No error (code=0) 2021-04-07 11:37:33 us=178431 write_wintun(): head/tail value is over capacity 2021-04-07 11:37:33 us=178431 write to TUN/TAP : No error (code=0) 2021-04-07 11:37:33 us=365649 write_wintun(): head/tail value is over capacity 2021-04-07 11:37:33 us=365649 write to TUN/TAP : No error (code=0) 2021-04-07 11:37:40 us=919327 write_wintun(): head/tail value is over capacity 2021-04-07 11:37:40 us=919327 write to TUN/TAP : No error (code=0) 2021-04-07 11:37:41 us=521171 write_wintun(): head/tail value is over capacity 2021-04-07 11:37:41 us=521171 write to TUN/TAP : No error (code=0) client dev tun windows-driver wintun proto udp auth SHA512 cipher AES-256-CBC resolv-retry infinite nobind persist-key persist-tun remote-cert-tls server verb 4 explicit-exit-notify 2 keepalive 10 120 mute 20 remote-random #################################################################### # # User configured bits go here # # Edit this section to specify where you keep keys and certificates # # Change the name of the certificate & key files to match your # e-mail address as shown for the e-mail address # eamonn.patton@mottmac.com tls-auth ""C:\\Users\\mad56570\\openvpn\\svdatra\\svdatra_ta.key"" 1 pkcs12 ""C:\\Users\\mad56570\\openvpn\\svdatra\\Joe.Madden-svdalertingtoolra.p12"" #################################################################### # # Uncomment the remote statement depending on your access need # Remove the ""#"" from the start of the line with the remote statement on it # remote #### 1194 #SWRCC remote #### 1194 Tap works fine, Not quite sure what the issue here is. " Joemadden1989 Active Tickets 1478 Consider remove TLS 1.0/1.1, and recommend using TLS 1.3, if not possible for now, mark TLS 1.0/1.1 as insecure, remove TLS 1.0/1.1 in the future. Generic / unclassified Feature Wish plaisthos assigned 2022-08-26T04:35:44Z 2022-12-03T23:45:32Z Consider remove TLS 1.0/1.1, and recommend using TLS 1.3, if not possible for now, mark TLS 1.0/1.1 as insecure, remove TLS 1.0/1.1 in the future. A Active Tickets 1479 Add support of X448 and X25519 key exchange algorithm, and prefer using X448/X25519 Crypto Feature Wish plaisthos assigned 2022-08-26T04:44:34Z 2023-07-14T04:01:22Z "Nowadays, OpenVPN doesn't support X448 (Ed448-Goldilocks) and X25519, which are recommend by SafeCurves and RFC 7748: RFC 7748: Elliptic Curves for Security https://datatracker.ietf.org/doc/html/rfc7748 SafeCurves: choosing safe curves for elliptic-curve cryptography https://safecurves.cr.yp.to/ But until OpenVPN 2.5.7, OpenVPN supports none of them: secp224r1 secp256k1 secp384r1 secp521r1 prime256v1 In fact, OpenSSL 3.0.1 has been supports X25519 and X448: openssl list -key-exchange-algorithms { 1.2.840.113549.1.3.1, DH, dhKeyAgreement } @ default { 1.3.101.110, X25519 } @ default { 1.3.101.111, X448 } @ default ECDH @ default TLS1-PRF @ default HKDF @ default { 1.3.6.1.4.1.11591.4.11, id-scrypt, SCRYPT } @ default I wish OpenVPN supports them. Last but not least, prefer using X448, X25519, then using other curves. In https://bench.cr.yp.to/results-dh.html amd64; Zen3 (a20f10); 2020 AMD Ryzen 9 5950X; 16 x 3400MHz; zen3, supercop-20220213 section, we can see: curve25519 (X25519) only need 102495 cycles to generate a key pair, 110991 cycles to compute a shared secret; ed448goldilocks (X448) only need 159723 cycles to generate a key pair, 527032 cycles to compute a shared secret; compare with NIST P-curves: nistp256 (P-256) need 223320 cycles to generate a key pair, 603146 cycles to compute a shared secret, it is the same security level of X25519 (in fact, it's less), nist521gs (P-521) need 884294 cycles to generate a key pair, 887358 cycles to compute a shared secret. " A Active Tickets 721 tap-windows6: Implement option to disable source IP check of ARP requests tap-windows6 Patch submission Gert Döring new 2016-08-16T06:36:24Z 2016-08-16T06:36:24Z The attached patch [https://sourceforge.net/p/openvpn/mailman/openvpn-devel/thread/169423fa-c98c-1e3b-42e9-f4bd9165bbb5%40familie-kuntze.de/#msg35210916 was sent] to openvpn-devel by Noel Kuntze. The patch was given a feature-ACK [wiki:Topics-2016-08-15 in a community meeting] on 15th August 2016. Code review is pending. Samuli Seppänen Active Tickets 835 OpenVPN exits on fatal error with large tun-mtu Networking OpenVPN 2.4.0 (Community Ed) Bug / Defect Steffan Karger accepted 2017-01-30T14:29:33Z 2017-01-30T15:09:34Z "There was a discussion in #openvpn on Freenode with users T1w claiming to see speeds increase from ~503Mbps up to 958Mbps by modifying --tun-mtu and setting to some crazy numbers (49k, 48k, even 60k). Curious, I asked for his config files and what he used for testing. == T1w Testing Environment == * OpenVPN 2.3.14 * OpenSSL 1.0.1e-fips (RHEL package) == ecrist Testing Environment == * OpenVPN 2.4.0 * OpenSSL 1.0.1s == IRC Chat Logs == {{{ 07:03:47 < BtbN> But it also creates quite a bit of lag on the network 07:05:13 <@ecrist> what/who does 60k MTUs as a ""common"" practice? 07:05:49 < T1w> ecrist: well.. at the moment I've gone up from ~503Mbit/s to 958Mbit/s just by going up with tun-mtu and disabling fragmentation and mss fix 07:06:57 < T1w> that's in a local test, so it's what I'd expect to see for a 1gbit link, but I've got a real life 1gbit line where I've never gone above ~120Mbit 07:07:15 < T1w> and I'd like to change that before investing in a black fiber to get the speed I need 07:07:50 <@ecrist> Is your current 1g link through a normal ISP? 07:07:52 < T1w> BtbN: lag is the least of my problems - as long as I get more throughput 07:07:53 < BtbN> saturating a gigabit link with openvpn is close to impossible though, even with all the tuning you can get 07:08:24 < T1w> ecrist: that probably pedends on what you mean by ""normal"" 07:08:30 < T1w> it's a datacenter 07:09:00 < T1w> BtbN: 958 is as close to saturated as I'd expect to see 07:09:06 <@ecrist> ah, most of those are grossly over-subscribed 07:09:30 <@ecrist> T1w: can you send me your config for client/server? I'd like to try that out 07:10:09 < T1w> BtbN: actually.. just trying the physical link between my testmachines (and not going through openvpn) I get a lower speed.. 07:10:30 < T1w> 942Mbit/s compared to the 958Mbit/s through openvpn 07:10:43 < T1w> that's.. interesting 07:10:46 < T1w> ecrist: sec.. 07:15:15 < T1w> ecrist: https://paste.sh/UgJDEDVG#u9Dnx5lXCZsBfSuHRY6QJV7a 07:15:39 < T1w> ecrist: it's where I've ended up after reading https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_Linux 07:15:41 <@vpnHelper> Title: Gigabit_Networks_Linux � OpenVPN Community (at community.openvpn.net) 07:16:29 < T1w> ecrist: and no.. our link is not oversubscribed - I can easily get really close to wirespeed when transferring other stuff from around EU (I'm located in Denmark) 07:17:45 < T1w> funny thing is that once I went above 50000 bytes MTU my iperf tests dies out 07:17:52 < T1w> 49000 is fine, 50000 is not 07:19:15 < T1w> ping is fine, but iperf dies out after the first few MB 07:21:46 < T1w> hm.. seemlingly because the serverside dies 07:22:37 < T1w> ah 07:22:38 < T1w> Mon Jan 30 14:09:29 2017 us=427893 gauss/10.5.99.205:42307 Assertion failed at lzo.c:202 (buf_safe (&work, zlen)) 07:22:38 < T1w> Mon Jan 30 14:09:29 2017 us=427963 gauss/10.5.99.205:42307 Exiting due to fatal error 07:22:44 < T1w> lets try without lzo 07:22:48 <@ecrist> T1w: what is your iperf syntax for your performance measurements? 07:23:11 < T1w> ecrist: server: -s -p 10000 -B 10.8.8.6 07:23:26 < T1w> ecrist: client: -p 10000 -c 10.8.8.6 -t 30 07:24:15 < T1w> I squzed a bit more out by renicing the client iperf to -19 (since the system is used for other stuff) 07:24:49 < T1w> only a few mbit, but it removed a few fluctuations where performance dropped down 07:28:05 <@ecrist> which version of openvpn? 07:28:29 < T1w> hah.. no without lzo it just gives me 07:28:30 < T1w> 49781 IP packet with unknown IP version=15 seen 07:28:50 < T1w> ecrist: 2.3.14 07:29:23 < T1w> the version avabilable in the EPEL 7 x86_64 repo 07:29:43 < T1w> OpenVPN 2.3.14 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Dec 7 2016 07:29:45 < T1w> using 07:29:57 < T1w> library versions: OpenSSL 1.0.1e-fips 11 Feb 2013, LZO 2.06 07:30:15 < T1w> (RHEL version of OpenSSL with backports) 07:30:44 < T1w> afk - back in 10-15 mins 07:31:03 <@ecrist> I'm trying this out - so far, just two servers connected to the same switch each over 1g uplinks, I see 936Mbps 07:31:10 <@ecrist> now to set up OpenVPN 07:51:47 <@ecrist> huh, this is a new one 07:51:49 <@ecrist> Mon Jan 30 07:39:16 2017 us=113384 Assertion failed at crypto.c:81 (packet_id_initialized(&opt->packet_id)) 07:51:49 <@ecrist> Mon Jan 30 07:39:16 2017 us=113393 Exiting due to fatal error [@ecrist(+i)] [5:#openvpn(+cgnprt)] [257 nicks (@9 %0 +2 246)] }}} == Results (read: problem) == The startup of the server side process is uneventful (logs attached). Startup of the client, however, results in a quick fatal error after full initialization. The same error is evident in the server logs, and that process also dies. === Server Log === {{{ Mon Jan 30 07:39:16 2017 us=32861 client/10.3.14.230 SENT CONTROL [client]: 'PUSH_REPLY,route 10.8.8.0 255.255.255.0,route 10.8.8.1,topology net30,ping 5,ping-restart 30,ifconfig 10.8.8.6 10.8.8.5,peer-id 0,cipher AES-256-GCM' (status=1) Mon Jan 30 07:39:16 2017 us=32907 client/10.3.14.230 Data Channel MTU parms [ L:48046 D:48046 EF:46 EB:8156 ET:0 EL:3 ] Mon Jan 30 07:39:16 2017 us=33059 client/10.3.14.230 Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key Mon Jan 30 07:39:16 2017 us=33096 client/10.3.14.230 Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key Mon Jan 30 07:39:21 2017 us=412962 client/10.3.14.230 Assertion failed at crypto.c:81 (packet_id_initialized(&opt->packet_id)) Mon Jan 30 07:39:21 2017 us=413099 client/10.3.14.230 Exiting due to fatal error Mon Jan 30 07:39:21 2017 us=413159 client/10.3.14.230 /sbin/route delete -net 10.8.8.0 10.8.8.2 255.255.255.0 delete net 10.8.8.0: gateway 10.8.8.2 Mon Jan 30 07:39:21 2017 us=415335 client/10.3.14.230 Closing TUN/TAP interface Mon Jan 30 07:39:21 2017 us=415525 client/10.3.14.230 /sbin/ifconfig tun1 destroy }}} === Client Log === {{{ Mon Jan 30 07:39:16 2017 us=36473 /sbin/route add -net 10.8.8.0 10.8.8.5 255.255.255.0 add net 10.8.8.0: gateway 10.8.8.5 Mon Jan 30 07:39:16 2017 us=37358 /sbin/route add -net 10.8.8.1 10.8.8.5 255.255.255.255 add net 10.8.8.1: gateway 10.8.8.5 Mon Jan 30 07:39:16 2017 us=38263 Initialization Sequence Completed WrMon Jan 30 07:39:16 2017 us=113384 Assertion failed at crypto.c:81 (packet_id_initialized(&opt->packet_id)) Mon Jan 30 07:39:16 2017 us=113393 Exiting due to fatal error Mon Jan 30 07:39:16 2017 us=113422 /sbin/route delete -net 10.8.8.0 10.8.8.5 255.255.255.0 delete net 10.8.8.0: gateway 10.8.8.5 Mon Jan 30 07:39:16 2017 us=114344 /sbin/route delete -net 10.8.8.1 10.8.8.5 255.255.255.255 delete net 10.8.8.1: gateway 10.8.8.5 Mon Jan 30 07:39:16 2017 us=115199 Closing TUN/TAP interface Mon Jan 30 07:39:16 2017 us=115268 /sbin/ifconfig tun0 destroy }}} I've attached two zip files, one for each the server and client configuration, including DH parameters, certificates, keys, and the HMAC static key." Eric Crist Active Tickets 853 AIX: down-root: fatal error: err.h: No such file or directory plug-ins / plug-in API OpenVPN git master branch (Community Ed) Bug / Defect Gert Döring accepted 2017-03-07T11:05:24Z 2020-09-09T12:09:39Z "Compiling source on AIX 7.1 stop with this error message. What is this err.h? I only found the one from openssl, available at /opt/freeware/include/openssl/err.h, but I think this is a different file. {{{ [...] Making all in down-root make[4]: Entering directory '/nfs/openvpn/src/plugins/down-root' /bin/sh ../../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../.. -I../../../include -I../../../include -I/opt/freeware/include -g -O2 -std=c99 -MT down-root.lo -MD -MP -MF .deps/down-root.Tpo -c -o down-root.lo down-root.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../.. -I../../../include -I../../../include -I/opt/freeware/include -g -O2 -std=c99 -MT down-root.lo -MD -MP -MF .deps/down-root.Tpo -c down-root.c -fPIC -DPIC -o .libs/down-root.o down-root.c:45:17: fatal error: err.h: No such file or directory #include ^ compilation terminated. Makefile:514: recipe for target 'down-root.lo' failed make[4]: *** [down-root.lo] Error 1 }}} Thank you, Giuseppe" eppesuigvpn Active Tickets 860 community.openvpn.net unreachable via SMTP Community services Bug / Defect Samuli Seppänen assigned 2017-03-23T10:28:04Z 2023-01-01T14:47:10Z "From my mailq: 3vpRJs161zzXDr1 4373 Thu Mar 23 00:50:53 Ralf.Hildebrandt@charite.de (connect to community.openvpn.net[54.241.178.103]:25: Connection timed out) trac@community.openvpn.net $ host -t mx community.openvpn.net community.openvpn.net has no MX record Looking at the logs: Mar 23 10:39:27 mail-cbf postfix/smtp[64028]: 3vpRJs161zzXDr1: to=, relay=none, delay=35314, delays=35284/0/30/0, dsn=4.4.1, status=deferred (connect to community.openvpn.net[54.241.178.103]:25: Connection timed out) trying from another network (mail.python.org): $ telnet -4 community.openvpn.net 25 Trying 54.241.178.103... ... connection times out... " hildeb Active Tickets 947 "Solaris 11 and ""error: no tap header could be found""" Building / Compiling OpenVPN git master branch (Community Ed) Bug / Defect Gert Döring assigned 2017-10-17T03:38:53Z 2020-09-01T12:53:35Z "I'm working on an i86 based Solaris 11.3 machine. Running configure results in: configure:15687: error: no tap header could be found Inspecting config.log, it appears a Windows test or Linux test is triggering the failure (see below). If I am parsing things properly, like bug reports and patches, Solaris patches were added several years ago around the 2.2 days. Confer, http://www.whiteboard.ne.jp/~admin2/tuntap/. If Solaris is not supported, then please forgive my ignorance. -------- {{{ configure:15653: checking tap-windows.h presence configure:15653: gcc -E -I/usr/local/include -DNDEBUG -D_XPG4_2 conftest.c conftest.c:156:25: fatal error: tap-windows.h: No such file or directory #include ^ compilation terminated. configure:15653: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME ""OpenVPN"" | #define PACKAGE_TARNAME ""openvpn"" | #define PACKAGE_VERSION ""2.4.4"" | #define PACKAGE_STRING ""OpenVPN 2.4.4"" | #define PACKAGE_BUGREPORT ""openvpn-users@lists.sourceforge.net"" | #define PACKAGE_URL """" | #define OPENVPN_VERSION_RESOURCE 2,4,4,0 | #define OPENVPN_VERSION_MAJOR 2 | #define OPENVPN_VERSION_MINOR 4 | #define OPENVPN_VERSION_PATCH "".4"" | #define PACKAGE ""openvpn"" | #define VERSION ""2.4.4"" | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define __EXTENSIONS__ 1 | #define _ALL_SOURCE 1 | #define _GNU_SOURCE 1 | #define _POSIX_PTHREAD_SEMANTICS 1 | #define _TANDEM_SOURCE 1 | #define TARGET_ALIAS ""i386-pc-solaris2.11"" | #define TARGET_SOLARIS 1 | #define TARGET_PREFIX ""S"" | #define IFCONFIG_PATH ""/sbin/ifconfig"" | #define IPROUTE_PATH """" | #define ROUTE_PATH ""/sbin/route"" | #define SYSTEMD_ASK_PASSWORD_PATH """" | #define HAVE_DLFCN_H 1 | #define LT_OBJDIR "".libs/"" | #define RETSIGTYPE void | #define HAVE_CPP_VARARG_MACRO_ISO 1 | #define HAVE_CPP_VARARG_MACRO_GCC 1 | #define EMPTY_ARRAY_SIZE 0 | #define SIZEOF_UNSIGNED_INT 4 | #define SIZEOF_UNSIGNED_LONG 8 | #define HAVE_STDIO_H 1 | #define HAVE_STDARG_H 1 | #define HAVE_LIMITS_H 1 | #define HAVE_TIME_H 1 | #define HAVE_ERRNO_H 1 | #define HAVE_FCNTL_H 1 | #define HAVE_CTYPE_H 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_SOCKET_H 1 | #define HAVE_SIGNAL_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_DLFCN_H 1 | #define HAVE_NETINET_IN_H 1 | #define HAVE_NETINET_IN_SYSTM_H 1 | #define HAVE_NETINET_TCP_H 1 | #define HAVE_ARPA_INET_H 1 | #define HAVE_NETDB_H 1 | #define HAVE_SYS_TIME_H 1 | #define HAVE_SYS_IOCTL_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_SYS_MMAN_H 1 | #define HAVE_SYS_FILE_H 1 | #define HAVE_SYS_WAIT_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_SIGNAL_H 1 | #define HAVE_LIBGEN_H 1 | #define HAVE_STROPTS_H 1 | #define HAVE_SYSLOG_H 1 | #define HAVE_PWD_H 1 | #define HAVE_GRP_H 1 | #define HAVE_SYS_SOCKIO_H 1 | #define HAVE_SYS_UIO_H 1 | #define HAVE_SYS_POLL_H 1 | #define HAVE_ERR_H 1 | #define HAVE_NET_IF_H 1 | #define HAVE_NETINET_IP_H 1 | #define HAVE_RESOLV_H 1 | #define HAVE_SYS_UN_H 1 | #define HAVE_IN_ADDR_T 1 | #define HAVE_IN_PORT_T 1 | #define HAVE_MSGHDR 1 | #define HAVE_CMSGHDR 1 | #define HAVE_IN_PKTINFO 1 | #define HAVE_SA_FAMILY_T 1 | #define HAVE_IPI_SPEC_DST 1 | #define HAVE_DECL_SO_MARK 0 | #define HAVE_ANONYMOUS_UNION_SUPPORT /**/ | #define HAVE_DECL_SIGHUP 1 | #define HAVE_DECL_SIGINT 1 | #define HAVE_DECL_SIGUSR1 1 | #define HAVE_DECL_SIGUSR2 1 | #define HAVE_DECL_SIGTERM 1 | #define HAVE_FORK 1 | #define HAVE_VFORK 1 | #define HAVE_WORKING_VFORK 1 | #define HAVE_WORKING_FORK 1 | #define HAVE_DAEMON 1 | #define HAVE_CHROOT 1 | #define HAVE_GETPWNAM 1 | #define HAVE_SETUID 1 | #define HAVE_NICE 1 | #define HAVE_SYSTEM 1 | #define HAVE_GETPID 1 | #define HAVE_DUP 1 | #define HAVE_DUP2 1 | #define HAVE_GETPASS 1 | #define HAVE_SYSLOG 1 | #define HAVE_OPENLOG 1 | #define HAVE_MLOCKALL 1 | #define HAVE_GETGRNAM 1 | #define HAVE_SETGID 1 | #define HAVE_SETGROUPS 1 | #define HAVE_STAT 1 | #define HAVE_READV 1 | #define HAVE_WRITEV 1 | #define HAVE_TIME 1 | #define HAVE_GETTIMEOFDAY 1 | #define HAVE_CTIME 1 | #define HAVE_MEMSET 1 | #define HAVE_VSNPRINTF 1 | #define HAVE_STRDUP 1 | #define HAVE_SETSID 1 | #define HAVE_CHDIR 1 | #define HAVE_PUTENV 1 | #define HAVE_UNLINK 1 | #define HAVE_FTRUNCATE 1 | #define HAVE_EXECVE 1 | #define HAVE_UMASK 1 | #define HAVE_BASENAME 1 | #define HAVE_DIRNAME 1 | #define HAVE_ACCESS 1 | #define HAVE_SENDMSG 1 | #define HAVE_RECVMSG 1 | #define HAVE_INET_NTOP 1 | #define HAVE_INET_PTON 1 | #define HAVE_SOCKET 1 | #define HAVE_RECV 1 | #define HAVE_RECVFROM 1 | #define HAVE_SEND 1 | #define HAVE_SENDTO 1 | #define HAVE_LISTEN 1 | #define HAVE_ACCEPT 1 | #define HAVE_CONNECT 1 | #define HAVE_BIND 1 | #define HAVE_SELECT 1 | #define HAVE_GETHOSTBYNAME 1 | #define HAVE_INET_NTOA 1 | #define HAVE_SETSOCKOPT 1 | #define HAVE_GETSOCKOPT 1 | #define HAVE_GETSOCKNAME 1 | #define HAVE_POLL 1 | /* end confdefs.h. */ | #include configure:15653: result: no configure:15653: checking for tap-windows.h configure:15653: result: no configure:15664: checking whether TUNSETPERSIST is declared configure:15664: gcc -c -m64 -std=c99 -I/usr/local/include -DNDEBUG -D_XPG4_2 conftest.c >&5 conftest.c: In function 'main': conftest.c:170:10: error: 'TUNSETPERSIST' undeclared (first use in this function) (void) TUNSETPERSIST; ^ conftest.c:170:10: note: each undeclared identifier is reported only once for each function it appears in configure:15664: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME ""OpenVPN"" | #define PACKAGE_TARNAME ""openvpn"" | #define PACKAGE_VERSION ""2.4.4"" | #define PACKAGE_STRING ""OpenVPN 2.4.4"" | #define PACKAGE_BUGREPORT ""openvpn-users@lists.sourceforge.net"" | #define PACKAGE_URL """" | #define OPENVPN_VERSION_RESOURCE 2,4,4,0 | #define OPENVPN_VERSION_MAJOR 2 | #define OPENVPN_VERSION_MINOR 4 | #define OPENVPN_VERSION_PATCH "".4"" | #define PACKAGE ""openvpn"" | #define VERSION ""2.4.4"" | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define __EXTENSIONS__ 1 | #define _ALL_SOURCE 1 | #define _GNU_SOURCE 1 | #define _POSIX_PTHREAD_SEMANTICS 1 | #define _TANDEM_SOURCE 1 | #define TARGET_ALIAS ""i386-pc-solaris2.11"" | #define TARGET_SOLARIS 1 | #define TARGET_PREFIX ""S"" | #define IFCONFIG_PATH ""/sbin/ifconfig"" | #define IPROUTE_PATH """" | #define ROUTE_PATH ""/sbin/route"" | #define SYSTEMD_ASK_PASSWORD_PATH """" | #define HAVE_DLFCN_H 1 | #define LT_OBJDIR "".libs/"" | #define RETSIGTYPE void | #define HAVE_CPP_VARARG_MACRO_ISO 1 | #define HAVE_CPP_VARARG_MACRO_GCC 1 | #define EMPTY_ARRAY_SIZE 0 | #define SIZEOF_UNSIGNED_INT 4 | #define SIZEOF_UNSIGNED_LONG 8 | #define HAVE_STDIO_H 1 | #define HAVE_STDARG_H 1 | #define HAVE_LIMITS_H 1 | #define HAVE_TIME_H 1 | #define HAVE_ERRNO_H 1 | #define HAVE_FCNTL_H 1 | #define HAVE_CTYPE_H 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_SOCKET_H 1 | #define HAVE_SIGNAL_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_DLFCN_H 1 | #define HAVE_NETINET_IN_H 1 | #define HAVE_NETINET_IN_SYSTM_H 1 | #define HAVE_NETINET_TCP_H 1 | #define HAVE_ARPA_INET_H 1 | #define HAVE_NETDB_H 1 | #define HAVE_SYS_TIME_H 1 | #define HAVE_SYS_IOCTL_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_SYS_MMAN_H 1 | #define HAVE_SYS_FILE_H 1 | #define HAVE_SYS_WAIT_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_SIGNAL_H 1 | #define HAVE_LIBGEN_H 1 | #define HAVE_STROPTS_H 1 | #define HAVE_SYSLOG_H 1 | #define HAVE_PWD_H 1 | #define HAVE_GRP_H 1 | #define HAVE_SYS_SOCKIO_H 1 | #define HAVE_SYS_UIO_H 1 | #define HAVE_SYS_POLL_H 1 | #define HAVE_ERR_H 1 | #define HAVE_NET_IF_H 1 | #define HAVE_NETINET_IP_H 1 | #define HAVE_RESOLV_H 1 | #define HAVE_SYS_UN_H 1 | #define HAVE_IN_ADDR_T 1 | #define HAVE_IN_PORT_T 1 | #define HAVE_MSGHDR 1 | #define HAVE_CMSGHDR 1 | #define HAVE_IN_PKTINFO 1 | #define HAVE_SA_FAMILY_T 1 | #define HAVE_IPI_SPEC_DST 1 | #define HAVE_DECL_SO_MARK 0 | #define HAVE_ANONYMOUS_UNION_SUPPORT /**/ | #define HAVE_DECL_SIGHUP 1 | #define HAVE_DECL_SIGINT 1 | #define HAVE_DECL_SIGUSR1 1 | #define HAVE_DECL_SIGUSR2 1 | #define HAVE_DECL_SIGTERM 1 | #define HAVE_FORK 1 | #define HAVE_VFORK 1 | #define HAVE_WORKING_VFORK 1 | #define HAVE_WORKING_FORK 1 | #define HAVE_DAEMON 1 | #define HAVE_CHROOT 1 | #define HAVE_GETPWNAM 1 | #define HAVE_SETUID 1 | #define HAVE_NICE 1 | #define HAVE_SYSTEM 1 | #define HAVE_GETPID 1 | #define HAVE_DUP 1 | #define HAVE_DUP2 1 | #define HAVE_GETPASS 1 | #define HAVE_SYSLOG 1 | #define HAVE_OPENLOG 1 | #define HAVE_MLOCKALL 1 | #define HAVE_GETGRNAM 1 | #define HAVE_SETGID 1 | #define HAVE_SETGROUPS 1 | #define HAVE_STAT 1 | #define HAVE_READV 1 | #define HAVE_WRITEV 1 | #define HAVE_TIME 1 | #define HAVE_GETTIMEOFDAY 1 | #define HAVE_CTIME 1 | #define HAVE_MEMSET 1 | #define HAVE_VSNPRINTF 1 | #define HAVE_STRDUP 1 | #define HAVE_SETSID 1 | #define HAVE_CHDIR 1 | #define HAVE_PUTENV 1 | #define HAVE_UNLINK 1 | #define HAVE_FTRUNCATE 1 | #define HAVE_EXECVE 1 | #define HAVE_UMASK 1 | #define HAVE_BASENAME 1 | #define HAVE_DIRNAME 1 | #define HAVE_ACCESS 1 | #define HAVE_SENDMSG 1 | #define HAVE_RECVMSG 1 | #define HAVE_INET_NTOP 1 | #define HAVE_INET_PTON 1 | #define HAVE_SOCKET 1 | #define HAVE_RECV 1 | #define HAVE_RECVFROM 1 | #define HAVE_SEND 1 | #define HAVE_SENDTO 1 | #define HAVE_LISTEN 1 | #define HAVE_ACCEPT 1 | #define HAVE_CONNECT 1 | #define HAVE_BIND 1 | #define HAVE_SELECT 1 | #define HAVE_GETHOSTBYNAME 1 | #define HAVE_INET_NTOA 1 | #define HAVE_SETSOCKOPT 1 | #define HAVE_GETSOCKOPT 1 | #define HAVE_GETSOCKNAME 1 | #define HAVE_POLL 1 | /* end confdefs.h. */ | | #ifdef HAVE_LINUX_IF_TUN_H | #include | #endif | | | | int | main () | { | #ifndef TUNSETPERSIST | #ifdef __cplusplus | (void) TUNSETPERSIST; | #else | (void) TUNSETPERSIST; | #endif | #endif | | ; | return 0; | } configure:15664: result: no configure:15687: error: no tap header could be found }}} " noloader Active Tickets 1023 "OpenVPN Connect for Android: Can't install: ""No Carrier""" OpenVPN Connect Bug / Defect OpenVPN Inc. assigned 2018-02-20T07:01:56Z 2021-04-27T07:53:15Z "Dear OpenVPN team, I tried to install OpenVPN Connect for Android from Google Play, but I'm getting ""No Carrier"" error message from Play store, so I can't even download it. My android device is an Nvidia Shield TV, and I suppose the reason why I'm getting ""No Carrier"" it is because this device doesn't have any SIM card slot. However, it is a fully functional device with wired/wifi network interfaces. Would it be possible to remove ""No Carrier"" restriction in future releases of OpenVPN Connect? Thanks & best regards, Andris " bandipapa Active Tickets 1170 broken gmane links Community services Bug / Defect novaflash assigned 2019-03-14T13:50:03Z 2022-12-22T08:05:24Z "https://openvpn.net/community-resources/mailing-lists/ links to gmane are broken" fakeuser Active Tickets 1195 Man page example 3 refers to dh1024.pem which does not exist Documentation OpenVPN 2.4.7 (Community Ed) Bug / Defect David Sommerseth assigned 2019-06-09T11:47:08Z 2019-11-10T13:23:41Z "Man page example 3 refers to dh1024.pem which does not exist in openvpn-2.4.7/sample/sample-keys/. Better to replace it there with `dh2048.pem`: {{{ Example 3: A tunnel with full TLS-based security ... For Diffie Hellman parameters you can use the included >>> file dh1024.pem. Note that all client, server, and certificate authority certificates and keys included in the OpenVPN distribution are totally insecure and should be used for testing only. ... On alice: openvpn --remote bob.example.com --dev tun1 --ifconfig 10.4.0.2 >>> 10.4.0.1 --tls-server --dh dh1024.pem --ca ca.crt --cert server.crt --key server.key --reneg-sec 60 --verb 5 ... }}}" mnowak Active Tickets 1253 Tray ToolTip does not display complete IP in Windows GUI Windows GUI OpenVPN 2.4.7 (Community Ed) Bug / Defect Selva Nair new 2020-02-16T18:22:07Z 2020-02-16T23:45:33Z "Version: openvpn-install-2.4.8-I602-Win7 OS Name Microsoft Windows 8.1 Pro Version 6.3.9600 Build 9600 System Type x64-based PC Adapter Description Intel(R) HD Graphics 630 Driver Version 21.20.16.4678 Resolution 2560 x 1440 x 60 hertz Bits/Pixel 32 When connecting to one and only one AirVPN Profile, OpenVPN GUI displays the full IPv4 in the connection balloon, but does not display the final octet in the ToolTip, as shown in the attached screen capture video. All other installed profiles display correctly. In addition to the video, the attached ZIP archive includes the profile, log, etc." John Navas Active Tickets 1462 "Windows installer (MSI): Uninstall ""Time remaining"" counts up not down" Generic / unclassified Bug / Defect stipa assigned 2022-04-07T14:51:58Z 2022-04-07T14:54:54Z tct Active Tickets 815 UUID via environment for each session Generic / unclassified OpenVPN git master branch (Community Ed) Feature Wish David Sommerseth new 2017-01-05T19:54:52Z 2022-07-10T12:34:52Z "== Problem == When writing scripts to parse the status log, there is no common unique identifier per OpenVPN client session. This makes tracking usage per-session difficult since we have no affirmative data that this is still the same VPN session when parsing a connection on update of the status file or --client-disconnect scripts. == Desired Feature == Expose a UUID or other unique identify that is static for the duration of a client session. This should be identical across re-keying operations or during --float changes. IDs should be unique per session so that simultaneous connections from the same CN would show as different sessions. This allows for more accurate per-session tracking so that reports could be derived that show a detailed phone-bill type reporting could be generated. Without a unique ID, it may be difficult to determine when one session has ended and another has started. There are hints in the file, like remote address and process ID that can be used to help make a unique session indicator, but these are not foolproof. == Example Report == ||=User=||=Source=||=Private Address=||=Received=||=Sent=||=Start=||=End=|| ||jdoe||44.44.44.2||10.0.8.2||49357||1687777||2017-01-04 08:00:00|| -- || ||jdoe||44.44.44.2||10.0.8.3||26777||29007||2017-01-04 08:03:00|| 2017-01-04 08:05:01 || ||jdoe||172.78.31.134||10.0.8.3||969357||2385767||2017-01-04 09:19:44|| -- ||" Eric Crist Active Tickets 1016 iOS: OpenVPN Connect clears unsaved credentials on exit with save slider enabled OpenVPN Connect OpenVPN Connect for iOS v1.2.7 Feature Wish OpenVPN Inc. assigned 2018-02-08T04:53:45Z 2021-04-27T07:53:15Z "When attempting to enter NEW credentials for an ovpn profile, exiting or re-entering the app at any point will clear both the username and password fields. It will not matter which order the fields are populated, or if the save slider is enabled at the time of exit. The App only seems to ""Save"" on a connection attempt. I propose that the credential values get saved on exit if the Save slider is enabled. For context: I keep my credentials in a password repository, and I can only copy one value at a time. The problem is that for someone who must enter either the username or the password separately, at no point will the credentials be complete if the user needs to exit to retrieve the other value. The only way I have found to enter credentials in this way is to enter the valid password (or valid username and bogus password), attempt a connection (bad credentials). Exit, retrieve the other value, enter it, and reconnect (good credentials). rated minor for workaround, and typed it a feature request instead of a bug due to the clearing being clearly by design. " hunterx1 Active Tickets 1144 Update man page -> several invocations of tls-verify, one per cert of the chain Documentation OpenVPN git master branch (Community Ed) Feature Wish David Sommerseth assigned 2018-12-04T21:45:11Z 2019-11-10T17:27:54Z "I have been testing openvpn 2.4.6, with a tls-verify script that checks a certificate. My surprise was that I was getting the whole chain of certificates. That is: - CA certificate - X509 client certificate If possible would it be possible to update the man page (tls-verify section), to state that the script might get invoked for each certificate in the chain, putting special attention to the depth section. I foumd it hard to find out how it worked (and got the working from the source code), and I thougt it would be useful to feed this info back. " nitomartinez Active Tickets 1352 Support for proxy-protocol on server Access Server Feature Wish OpenVPN Inc. assigned 2020-11-14T04:37:45Z 2021-05-30T14:47:42Z "It's often useful to run an OpenVPN server on port 443 to be able to allow clients to exit restrictive firewalls. Many servers run additional services on port 443. I know OpenVPN has the share-port option, and it's helpful, but integrating OpenVPN can still be difficult. Many people run proxies upstream on port 443 and then distribute the traffic accordingly, however this strips the connection origin information unless transparent proxying is set up, which can also be difficult as it requires modifying the firewall configuration for return data. Proxy-protocol preserves the connection source information and is supported by several proxy applications, such as HAProxy and Nginx. See https://www.haproxy.com/blog/haproxy/proxy-protocol/ It would be extremely useful and greatly simplify setting up OpenVPN behind a proxy if it could support proxy-protocol on the server. " plinss Active Tickets 1235 Tap-windows version is not updated on Wiki Community services Bug / Defect Samuli Seppänen assigned 2019-11-26T19:05:51Z 2022-11-29T16:56:56Z "Hello, According https://community.openvpn.net/openvpn/wiki/GettingTapWindows, last version (for Windows Vista and above) of Tap-windows is **9.21.2** According https://build.openvpn.net/downloads/releases/, last version of Tap-Windows is **9.24.2** for Windows 7 and for Windows 10. Could you update https://community.openvpn.net/openvpn/wiki/GettingTapWindows following the new releases of Tap-windows?" chtof Active Tickets 1238 trac can fail to email the reporter Community services Bug / Defect Samuli Seppänen reopened 2019-12-03T19:22:39Z 2021-05-19T21:53:16Z "These trac tickets did not email to me on replies: https://community.openvpn.net/openvpn/ticket/1217 https://community.openvpn.net/openvpn/ticket/1164 Please add a simple reply to this ticket for my test. Don't modify cc etc. " tct Active Tickets 1268 repository cosmetic bug Packaging OpenVPN git master branch (Community Ed) Bug / Defect David Sommerseth assigned 2020-04-02T19:01:38Z 2022-12-21T17:41:43Z "Hi, I used this procedure to install openvpn3 client [https://community.openvpn.net/openvpn/wiki/OpenVPN3Linux#Quickstart-howtouseOpenVPN3Linux ] works nice, thanks. But, when updating I get this: ''N: Skipping acquire of configured file 'main/binary-i386/Packages' as repository 'https://swupdate.openvpn.net/community/openvpn3/repos buster InRelease' doesn't support architecture 'i386' '' Worked around by changing this file ''/etc/apt/sources.list.d/openvpn3.list '' **deb https://swupdate.openvpn.net/community/openvpn3/repos buster main ** into ** deb [arch=amd64] https://swupdate.openvpn.net/community/openvpn3/repos buster main** best regards, Joost " joost.ringoot Active Tickets 1429 Fix Fedora Copr instructions in the OpenvpnSoftwareRepos doc Documentation Bug / Defect David Sommerseth assigned 2021-10-12T13:33:41Z 2021-10-19T17:42:30Z "Hello! The Wiki offers to install OpenVPN software from Fedora Copr: https://community.openvpn.net/openvpn/wiki/OpenvpnSoftwareRepos Actually, adding such a repository is not recommended since it breaks the supply chain security on that system. The Open Source Security Foundation (OpenSSF, https://openssf.org/) is doing a lot to persuade the community that the supply chain is important. That is especially true for OpenVPN software, which is critical for information security. I would recommend adding a proper disclaimer to the Wiki chapter about Fedora Copr usage or at least add a detailed description of how to check the OpenVPN package signatures. Thanks! Alexander" a13x Active Tickets 352 'keepalive' reconnect fails if 'remote' is specified with hostname from /etc/hosts file. Generic / unclassified OpenVPN 2.3.2 (Community Ed) Bug / Defect new 2013-12-04T22:32:00Z 2021-12-29T20:22:40Z "O/S: Centos 6.4 Architecture: i686 When client configuration file has 'remote ' and hostname is defined in /etc/hosts file, OpenVPN startup is successful. Using 'keepalive 10 120', if the remote server goes down (reboots), when the client determines that it needs to attempt reconnect, it tries and cannot. Repeated log messages show 'RESOLVE: Cannot resolve host address: : No address associated with hostname'. Works fine if 'remote ' is used instead of 'remote '. # uname -a Linux node0002 2.6.32-358.23.2.el6.i686 #1 SMP Wed Oct 16 17:21:31 UTC 2013 i686 i686 i386 GNU/Linux # openvpn --version OpenVPN 2.3.2 i686-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Sep 12 2013 Originally developed by James Yonan Copyright (C) 2002-2010 OpenVPN Technologies, Inc. Compile time defines: enable_crypto=yes enable_debug=yes enable_def_auth=yes enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_eurephia=yes enable_fast_install=yes enable_fragment=yes enable_http_proxy=yes enable_iproute2=yes enable_libtool_lock=yes enable_lzo=yes enable_lzo_stub=no enable_management=yes enable_multi=yes enable_multihome=yes enable_pam_dlopen=no enable_password_save=yes enable_pedantic=no enable_pf=yes enable_pkcs11=yes enable_plugin_auth_pam=yes enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_pthread=yes enable_selinux=no enable_server=yes enable_shared=yes enable_shared_with_static_runtimes=no enable_small=no enable_socks=yes enable_ssl=yes enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=no enable_win32_dll=yes enable_x509_alt_username=yes with_crypto_library=openssl with_gnu_ld=yes with_iproute_path=/sbin/ip with_mem_check=no with_plugindir='$(libdir)/openvpn/plugins' with_sysroot=no " mis@… Active Tickets 482 Win64 client NDIS6 does not shut down TAP interface clearly upon disconnect tap-windows6 OpenVPN 2.3.5 (Community Ed) Bug / Defect assigned 2014-11-21T19:04:27Z 2020-09-09T15:46:53Z "I have openvpn-2.3.5-i602-x64 installed on Win8.1Ent (with latest updates). I have multiple connection profiles and single TAP interface. Client is being used in 'dev tap' mode. When I disconnect from one server and connect to another, the IP settings on TAP interface are not applied properly but look like left intact from previous connection. The workarounds are: 1. Use dedicated TAP adapter for each connection profile or 2. Manually disable and reenable the TAP adapter after disconnection using 'adapter settings' windows snap-in." Nfisher Active Tickets 549 Use vfork() instead of fork() where possible Crypto OpenVPN 2.3.5 (Community Ed) Bug / Defect new 2015-05-05T13:32:07Z 2015-05-05T15:14:17Z "The official PKCS#''''''''''11 Users Guide suggests that on {{{fork()}}}, a child process should immediately call the {{{C_Initialize()}}} method of any loaded PKCS#''''''''''11 providers, to ensure that there is no confusion about their state being carried over from the parent, in which the provider is still active. This advice is a little confusing, because it's entirely pointless when you are really just doing a fork-and-exec. There's no point in doing '''anything''' in the child process between the {{{fork()}}} and the {{{execve()}}}. And it causes more problems than it solves, because some provider modules don't cope with it. Including the OpenSC module which is common on Linux and other open source platforms for most smartcard access, and the p11-kit-proxy module which is also common ''(and which we now load by default)''. Nevertheless, this is the behaviour of the pkcs11-helper library that OpenVPN uses. The offending modules are broken and should get fixed, of course. However, if even two of the '''common''' open source modules can suffer issues, what do we expect from the various closed-source PKCS#''''''''''11 provider modules? If they only really test hard on Windows, they're certainly never going to encounter esoteric issues with behaviour on {{{fork()}}} which doesn't even exist there. In accordance with Jon Postel's [http://tools.ietf.org/html/rfc1122#page-12 Robustness Principle] we should ''be liberal in what we accept, and conservative in what we send''. It would be trivial to work around a number of these issues by using {{{vfork()}}} instead of {{{fork()}}} in the case where we are doing a simple fork-and-exec, as in {{{openvpn_execve()}}}. In my opinion, we should do so. OpenVPN exists as a VPN solution and should do its best to work in all environments, rather than being a torture test for esoteric aspects of spec compliance. I posted at patch at http://sourceforge.net/p/openvpn/mailman/message/34076444/ in which I incorrectly claimed it should solve ticket #538. It doesn't, since that's a different issue. But we should apply this patch anyway." dwmw2 Active Tickets 558 problem after server restart - client doesn't accept new ip Networking OpenVPN 2.3.2 (Community Ed) Bug / Defect new 2015-06-01T11:25:08Z 2019-11-28T16:01:55Z "When openvpn server restarts, in some cases some clients don't change their IPs to the new ones assigned by server, but still routinely exchange keepalives and think everything is ok (however, data packets aren't transmitted or received). The problem occurs rarely and is hard to catch. Below is my server log cleaned up to one of that particular client. This is the initial connection by 1-st client (note it's IP address 10.9.3.70): May 29 09:59:53 www ovpn-server1[21681]: 89.151.172.78:10002 Re-using SSL/TLS context May 29 09:59:53 www ovpn-server1[21681]: 89.151.172.78:10002 LZO compression initialized May 29 09:59:53 www ovpn-server1[21681]: 89.151.172.78:10002 Control Channel MTU parms [ L:1546 D:138 EF:38 EB:0 ET:0 EL:0 ] May 29 09:59:53 www ovpn-server1[21681]: 89.151.172.78:10002 Data Channel MTU parms [ L:1546 D:1200 EF:46 EB:135 ET:0 EL:0 AF:3/1 ] May 29 09:59:53 www ovpn-server1[21681]: 89.151.172.78:10002 Fragmentation MTU parms [ L:1546 D:1200 EF:45 EB:135 ET:1 EL:0 AF:3/1 ] May 29 09:59:53 www ovpn-server1[21681]: 89.151.172.78:10002 Local Options String: 'V4,dev-type tun,link-mtu 1546,tun-mtu 1500,proto UDPv4,comp-lzo,mtu-dynamic,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server' May 29 09:59:53 www ovpn-server1[21681]: 89.151.172.78:10002 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1546,tun-mtu 1500,proto UDPv4,comp-lzo,mtu-dynamic,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client' May 29 09:59:53 www ovpn-server1[21681]: 89.151.172.78:10002 Local Options hash (VER=V4): '8e7959c7' May 29 09:59:53 www ovpn-server1[21681]: 89.151.172.78:10002 Expected Remote Options hash (VER=V4): 'c086e1aa' May 29 09:59:53 www ovpn-server1[21681]: 89.151.172.78:10002 TLS: Initial packet from [AF_INET]89.151.172.78:10002, sid=48c7d4e6 d6477d7d May 29 09:59:55 www ovpn-server1[21681]: 89.151.172.78:10002 CRL CHECK OK: C=[hidden], L=[hidden], O=[hidden], CN=[hidden], emailAddress=[hidden] May 29 09:59:55 www ovpn-server1[21681]: 89.151.172.78:10002 VERIFY OK: depth=1, C=[hidden], L=[hidden], O=[hidden], CN=[hidden], emailAddress=[hidden] May 29 09:59:55 www ovpn-server1[21681]: 89.151.172.78:10002 CRL CHECK OK: C=[hidden], L=[hidden], O=[hidden], OU=[hidden], CN=69bd6a89-aeaf-4d10-bf74-0e53facb9d69 May 29 09:59:55 www ovpn-server1[21681]: 89.151.172.78:10002 VERIFY OK: depth=0, C=[hidden], L=[hidden], O=[hidden], OU=[hidden], CN=69bd6a89-aeaf-4d10-bf74-0e53facb9d69 May 29 09:59:56 www ovpn-server1[21681]: 89.151.172.78:10002 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key May 29 09:59:56 www ovpn-server1[21681]: 89.151.172.78:10002 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication May 29 09:59:56 www ovpn-server1[21681]: 89.151.172.78:10002 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key May 29 09:59:56 www ovpn-server1[21681]: 89.151.172.78:10002 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication May 29 09:59:56 www ovpn-server1[21681]: 89.151.172.78:10002 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA May 29 09:59:56 www ovpn-server1[21681]: 89.151.172.78:10002 [69bd6a89-aeaf-4d10-bf74-0e53facb9d69] Peer Connection Initiated with [AF_INET]89.151.172.78:10002 May 29 09:59:56 www ovpn-server1[21681]: 69bd6a89-aeaf-4d10-bf74-0e53facb9d69/89.151.172.78:10002 MULTI_sva: pool returned IPv4=10.9.3.70, IPv6=(Not enabled) May 29 09:59:56 www ovpn-server1[21681]: 69bd6a89-aeaf-4d10-bf74-0e53facb9d69/89.151.172.78:10002 MULTI: Learn: 10.9.3.70 -> 69bd6a89-aeaf-4d10-bf74-0e53facb9d69/89.151.172.78:10002 May 29 09:59:56 www ovpn-server1[21681]: 69bd6a89-aeaf-4d10-bf74-0e53facb9d69/89.151.172.78:10002 MULTI: primary virtual IP for 69bd6a89-aeaf-4d10-bf74-0e53facb9d69/89.151.172.78:10002: 10.9.3.70 May 29 09:59:58 www ovpn-server1[21681]: 69bd6a89-aeaf-4d10-bf74-0e53facb9d69/89.151.172.78:10002 PUSH: Received control message: 'PUSH_REQUEST' May 29 09:59:58 www ovpn-server1[21681]: 69bd6a89-aeaf-4d10-bf74-0e53facb9d69/89.151.172.78:10002 send_push_reply(): safe_cap=940 May 29 09:59:58 www ovpn-server1[21681]: 69bd6a89-aeaf-4d10-bf74-0e53facb9d69/89.151.172.78:10002 SENT CONTROL [69bd6a89-aeaf-4d10-bf74-0e53facb9d69]: 'PUSH_REPLY,route 10.8.0.0 255.255.0.0,route 91.189.94.4 255.255.255.255,route 91.189.89.199 255.255.255.255,route 194.186.207.162 255.255.255.255,route 10.9.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.9.3.70 10.9.3.69' (status=1) Here is server restart occurs (notice PID change) May 30 04:01:59 www ovpn-server1[6896]: 89.151.172.78:21430 Re-using SSL/TLS context May 30 04:01:59 www ovpn-server1[6896]: 89.151.172.78:21430 LZO compression initialized May 30 04:01:59 www ovpn-server1[6896]: 89.151.172.78:21430 Control Channel MTU parms [ L:1546 D:138 EF:38 EB:0 ET:0 EL:0 ] May 30 04:01:59 www ovpn-server1[6896]: 89.151.172.78:21430 Data Channel MTU parms [ L:1546 D:1200 EF:46 EB:135 ET:0 EL:0 AF:3/1 ] May 30 04:01:59 www ovpn-server1[6896]: 89.151.172.78:21430 Fragmentation MTU parms [ L:1546 D:1200 EF:45 EB:135 ET:1 EL:0 AF:3/1 ] May 30 04:01:59 www ovpn-server1[6896]: 89.151.172.78:21430 Local Options String: 'V4,dev-type tun,link-mtu 1546,tun-mtu 1500,proto UDPv4,comp-lzo,mtu-dynamic,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server' May 30 04:01:59 www ovpn-server1[6896]: 89.151.172.78:21430 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1546,tun-mtu 1500,proto UDPv4,comp-lzo,mtu-dynamic,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client' May 30 04:01:59 www ovpn-server1[6896]: 89.151.172.78:21430 Local Options hash (VER=V4): '8e7959c7' May 30 04:01:59 www ovpn-server1[6896]: 89.151.172.78:21430 Expected Remote Options hash (VER=V4): 'c086e1aa' May 30 04:01:59 www ovpn-server1[6896]: 89.151.172.78:21430 TLS: Initial packet from [AF_INET]89.151.172.78:21430, sid=2e03d667 4ec4a92f May 30 04:02:01 www ovpn-server1[6896]: 89.151.172.78:21430 CRL CHECK OK: C=[hidden], L=[hidden], O=[hidden], CN=[hidden], emailAddress=[hidden] May 30 04:02:01 www ovpn-server1[6896]: 89.151.172.78:21430 VERIFY OK: depth=1, C=[hidden], L=[hidden], O=[hidden], CN=[hidden], emailAddress=[hidden] May 30 04:02:01 www ovpn-server1[6896]: 89.151.172.78:21430 CRL CHECK OK: C=[hidden], L=[hidden], O=[hidden], OU=[hidden], CN=69bd6a89-aeaf-4d10-bf74-0e53facb9d69 May 30 04:02:01 www ovpn-server1[6896]: 89.151.172.78:21430 VERIFY OK: depth=0, C=[hidden], L=[hidden], O=[hidden], OU=[hidden], CN=69bd6a89-aeaf-4d10-bf74-0e53facb9d69 May 30 04:02:01 www ovpn-server1[6896]: 89.151.172.78:21430 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key May 30 04:02:01 www ovpn-server1[6896]: 89.151.172.78:21430 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication May 30 04:02:01 www ovpn-server1[6896]: 89.151.172.78:21430 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key May 30 04:02:01 www ovpn-server1[6896]: 89.151.172.78:21430 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication May 30 04:02:01 www ovpn-server1[6896]: 89.151.172.78:21430 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA May 30 04:02:01 www ovpn-server1[6896]: 89.151.172.78:21430 [69bd6a89-aeaf-4d10-bf74-0e53facb9d69] Peer Connection Initiated with [AF_INET]89.151.172.78:21430 May 30 04:02:01 www ovpn-server1[6896]: 69bd6a89-aeaf-4d10-bf74-0e53facb9d69/89.151.172.78:21430 MULTI_sva: pool returned IPv4=10.9.0.242, IPv6=(Not enabled) May 30 04:02:01 www ovpn-server1[6896]: 69bd6a89-aeaf-4d10-bf74-0e53facb9d69/89.151.172.78:21430 MULTI: Learn: 10.9.0.242 -> 69bd6a89-aeaf-4d10-bf74-0e53facb9d69/89.151.172.78:21430 New address assigned May 30 04:02:01 www ovpn-server1[6896]: 69bd6a89-aeaf-4d10-bf74-0e53facb9d69/89.151.172.78:21430 MULTI: primary virtual IP for 69bd6a89-aeaf-4d10-bf74-0e53facb9d69/89.151.172.78:21430: 10.9.0.242 Another client connecting May 30 04:02:04 www ovpn-server1[6896]: 188.133.184.6:50152 Re-using SSL/TLS context May 30 04:02:04 www ovpn-server1[6896]: 188.133.184.6:50152 LZO compression initialized May 30 04:02:04 www ovpn-server1[6896]: 188.133.184.6:50152 Control Channel MTU parms [ L:1546 D:138 EF:38 EB:0 ET:0 EL:0 ] May 30 04:02:04 www ovpn-server1[6896]: 188.133.184.6:50152 Data Channel MTU parms [ L:1546 D:1200 EF:46 EB:135 ET:0 EL:0 AF:3/1 ] May 30 04:02:04 www ovpn-server1[6896]: 188.133.184.6:50152 Fragmentation MTU parms [ L:1546 D:1200 EF:45 EB:135 ET:1 EL:0 AF:3/1 ] May 30 04:02:04 www ovpn-server1[6896]: 188.133.184.6:50152 Local Options String: 'V4,dev-type tun,link-mtu 1546,tun-mtu 1500,proto UDPv4,comp-lzo,mtu-dynamic,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server' May 30 04:02:04 www ovpn-server1[6896]: 188.133.184.6:50152 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1546,tun-mtu 1500,proto UDPv4,comp-lzo,mtu-dynamic,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client' May 30 04:02:04 www ovpn-server1[6896]: 188.133.184.6:50152 Local Options hash (VER=V4): '8e7959c7' May 30 04:02:04 www ovpn-server1[6896]: 188.133.184.6:50152 Expected Remote Options hash (VER=V4): 'c086e1aa' May 30 04:02:04 www ovpn-server1[6896]: 188.133.184.6:50152 TLS: Initial packet from [AF_INET]188.133.184.6:50152, sid=444dad21 593d95fa May 30 04:02:11 www ovpn-server1[6896]: 188.133.184.6:50152 CRL CHECK OK: C=[hidden], L=[hidden], O=[hidden], CN=[hidden], emailAddress=[hidden] May 30 04:02:11 www ovpn-server1[6896]: 188.133.184.6:50152 VERIFY OK: depth=1, C=[hidden], L=[hidden], O=[hidden], CN=[hidden], emailAddress=[hidden] May 30 04:02:11 www ovpn-server1[6896]: 188.133.184.6:50152 CRL CHECK OK: C=[hidden], L=[hidden], O=[hidden], OU=[hidden], CN=8cde99a0-be9d-422b-8c6a-753095c5df87 May 30 04:02:11 www ovpn-server1[6896]: 188.133.184.6:50152 VERIFY OK: depth=0, C=[hidden], L=[hidden], O=[hidden], OU=[hidden], CN=8cde99a0-be9d-422b-8c6a-753095c5df87 May 30 04:02:11 www ovpn-server1[6896]: 69bd6a89-aeaf-4d10-bf74-0e53facb9d69/89.151.172.78:21430 TLS Error: local/remote TLS keys are out of sync: [AF_INET]89.151.172.78:21430 [3] May 30 04:02:12 www ovpn-server1[6896]: 188.133.184.6:50152 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key May 30 04:02:12 www ovpn-server1[6896]: 188.133.184.6:50152 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication May 30 04:02:12 www ovpn-server1[6896]: 188.133.184.6:50152 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key May 30 04:02:12 www ovpn-server1[6896]: 188.133.184.6:50152 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication May 30 04:02:12 www ovpn-server1[6896]: 188.133.184.6:50152 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA May 30 04:02:12 www ovpn-server1[6896]: 188.133.184.6:50152 [8cde99a0-be9d-422b-8c6a-753095c5df87] Peer Connection Initiated with [AF_INET]188.133.184.6:50152 May 30 04:02:12 www ovpn-server1[6896]: 8cde99a0-be9d-422b-8c6a-753095c5df87/188.133.184.6:50152 MULTI_sva: pool returned IPv4=10.9.3.70, IPv6=(Not enabled) May 30 04:02:12 www ovpn-server1[6896]: 8cde99a0-be9d-422b-8c6a-753095c5df87/188.133.184.6:50152 MULTI: Learn: 10.9.3.70 -> 8cde99a0-be9d-422b-8c6a-753095c5df87/188.133.184.6:50152 The original IP of first client assigned to another client May 30 04:02:12 www ovpn-server1[6896]: 8cde99a0-be9d-422b-8c6a-753095c5df87/188.133.184.6:50152 MULTI: primary virtual IP for 8cde99a0-be9d-422b-8c6a-753095c5df87/188.133.184.6:50152: 10.9.3.70 May 30 04:02:14 www ovpn-server1[6896]: 8cde99a0-be9d-422b-8c6a-753095c5df87/188.133.184.6:50152 PUSH: Received control message: 'PUSH_REQUEST' May 30 04:02:14 www ovpn-server1[6896]: 8cde99a0-be9d-422b-8c6a-753095c5df87/188.133.184.6:50152 send_push_reply(): safe_cap=940 May 30 04:02:14 www ovpn-server1[6896]: 8cde99a0-be9d-422b-8c6a-753095c5df87/188.133.184.6:50152 SENT CONTROL [8cde99a0-be9d-422b-8c6a-753095c5df87]: 'PUSH_REPLY,route 10.8.0.0 255.255.0.0,route 91.189.94.4 255.255.255.255,route 91.189.89.199 255.255.255.255,route 194.186.207.162 255.255.255.255,route 10.9.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.9.3.70 10.9.3.69' (status=1) May 30 04:02:14 www ovpn-server1[6896]: 69bd6a89-aeaf-4d10-bf74-0e53facb9d69/89.151.172.78:21430 TLS Error: local/remote TLS keys are out of sync: [AF_INET]89.151.172.78:21430 [3] May 30 04:02:15 www ovpn-server1[6896]: 69bd6a89-aeaf-4d10-bf74-0e53facb9d69/89.151.172.78:21430 TLS Error: local/remote TLS keys are out of sync: [AF_INET]89.151.172.78:21430 [3] May 30 04:02:17 www ovpn-server1[6896]: 69bd6a89-aeaf-4d10-bf74-0e53facb9d69/89.151.172.78:21430 TLS Error: local/remote TLS keys are out of sync: [AF_INET]89.151.172.78:21430 [3] May 30 04:02:21 www ovpn-server1[6896]: 69bd6a89-aeaf-4d10-bf74-0e53facb9d69/89.151.172.78:21430 TLS Error: local/remote TLS keys are out of sync: [AF_INET]89.151.172.78:21430 [3] May 30 04:02:29 www ovpn-server1[6896]: 69bd6a89-aeaf-4d10-bf74-0e53facb9d69/89.151.172.78:21430 TLS Error: local/remote TLS keys are out of sync: [AF_INET]89.151.172.78:21430 [3] May 30 04:02:39 www ovpn-server1[6896]: 69bd6a89-aeaf-4d10-bf74-0e53facb9d69/89.151.172.78:21430 TLS Error: local/remote TLS keys are out of sync: [AF_INET]89.151.172.78:21430 [3] May 30 04:02:45 www ovpn-server1[6896]: 69bd6a89-aeaf-4d10-bf74-0e53facb9d69/89.151.172.78:21430 TLS Error: local/remote TLS keys are out of sync: [AF_INET]89.151.172.78:21430 [3] May 30 04:02:55 www ovpn-server1[6896]: 69bd6a89-aeaf-4d10-bf74-0e53facb9d69/89.151.172.78:21430 TLS Error: local/remote TLS keys are out of sync: [AF_INET]89.151.172.78:21430 [3] May 30 04:03:17 www ovpn-server1[6896]: 69bd6a89-aeaf-4d10-bf74-0e53facb9d69/89.151.172.78:21430 MULTI: bad source address from client [10.9.3.70], packet dropped May 30 04:03:17 www ovpn-server1[6896]: 69bd6a89-aeaf-4d10-bf74-0e53facb9d69/89.151.172.78:21430 MULTI: bad source address from client [10.9.3.70], packet dropped May 30 04:04:21 www ovpn-server1[6896]: 69bd6a89-aeaf-4d10-bf74-0e53facb9d69/89.151.172.78:21430 MULTI: bad source address from client [10.9.3.70], packet dropped May 30 04:04:22 www ovpn-server1[6896]: 69bd6a89-aeaf-4d10-bf74-0e53facb9d69/89.151.172.78:21430 MULTI: bad source address from client [10.9.3.70], packet dropped May 30 04:04:24 www ovpn-server1[6896]: 69bd6a89-aeaf-4d10-bf74-0e53facb9d69/89.151.172.78:21430 MULTI: bad source address from client [10.9.3.70], packet dropped ... etc. (this message lasts forever until the client gets killed) May 30 05:02:12 www ovpn-server1[6896]: 8cde99a0-be9d-422b-8c6a-753095c5df87/188.133.184.6:50152 TLS: soft reset sec=0 bytes=2799031/0 pkts=6706/0 May 30 05:02:14 www ovpn-server1[6896]: 8cde99a0-be9d-422b-8c6a-753095c5df87/188.133.184.6:50152 CRL CHECK OK: C=[hidden], L=[hidden], O=[hidden], CN=[hidden], emailAddress=[hidden] May 30 05:02:14 www ovpn-server1[6896]: 8cde99a0-be9d-422b-8c6a-753095c5df87/188.133.184.6:50152 VERIFY OK: depth=1, C=[hidden], L=[hidden], O=[hidden], CN=[hidden], emailAddress=[hidden] May 30 05:02:14 www ovpn-server1[6896]: 8cde99a0-be9d-422b-8c6a-753095c5df87/188.133.184.6:50152 CRL CHECK OK: C=[hidden], L=[hidden], O=[hidden], OU=[hidden], CN=8cde99a0-be9d-422b-8c6a-753095c5df87 May 30 05:02:14 www ovpn-server1[6896]: 8cde99a0-be9d-422b-8c6a-753095c5df87/188.133.184.6:50152 VERIFY OK: depth=0, C=[hidden], L=[hidden], O=[hidden], OU=[hidden], CN=8cde99a0-be9d-422b-8c6a-753095c5df87 May 30 05:02:14 www ovpn-server1[6896]: 8cde99a0-be9d-422b-8c6a-753095c5df87/188.133.184.6:50152 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key May 30 05:02:14 www ovpn-server1[6896]: 8cde99a0-be9d-422b-8c6a-753095c5df87/188.133.184.6:50152 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication May 30 05:02:14 www ovpn-server1[6896]: 8cde99a0-be9d-422b-8c6a-753095c5df87/188.133.184.6:50152 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key May 30 05:02:14 www ovpn-server1[6896]: 8cde99a0-be9d-422b-8c6a-753095c5df87/188.133.184.6:50152 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication May 30 05:02:14 www ovpn-server1[6896]: 8cde99a0-be9d-422b-8c6a-753095c5df87/188.133.184.6:50152 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA There is nothing special in logs at the client side. More info in this forum thread: https://forums.openvpn.net/topic18311.html" leshik Active Tickets 585 Authentication should be processed in parallel to avoid trafic disruption plug-ins / plug-in API OpenVPN 2.2.1 (Community Ed) Bug / Defect new 2015-07-31T00:06:18Z 2023-01-01T21:13:56Z "The whole story is discussed on openvpn-devel (https://sourceforge.net/p/openvpn/mailman/message/34333737/). Basically, what happened is that due to one radius server being offline for maintenance, the radius authentication plugin waits for a timeout before trying the the other server and succeed. In the meanwhile the openvpn trafic is stalled. So I'm suggesting that authentication plugin calls should be done somehow in parallel with trafic processing, e.g. by doing it in a thread, just like ssl negociation is apparently done in a separate thread. That way trafic processing won't be delayed by authentication timeouts." sthibault Active Tickets 664 management interface missing source port for ipv6 addresses Management OpenVPN 2.3.4 (Community Ed) Bug / Defect new 2016-03-02T03:38:32Z 2018-12-18T14:20:31Z "When running any of the 'status' commands from the management interface, the ""Real Address"" column has a source port for ipv4 addresses, but not for ipv6 addresses. For consistency, is it possible to add the source port for ipv6 addresses? (possibly using the typical [ipv6address]:port schema?)" furlongm Active Tickets 665 Route: Waiting for TUN/TAP interface to come up... Generic / unclassified OpenVPN 2.3.10 (Community Ed) Bug / Defect new 2016-03-02T13:38:28Z 2017-12-06T07:10:03Z "On a pristine Win10 installation, the TAP interface won't come up: Wed Mar 02 14:26:57 2016 OpenVPN 2.3.10 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Jan 4 2016 Wed Mar 02 14:26:57 2016 Windows version 6.2 (Windows 8 or greater) Wed Mar 02 14:26:57 2016 library versions: OpenSSL 1.0.1q 3 Dec 2015, LZO 2.09 Enter Management Password: Wed Mar 02 14:26:57 2016 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340 Wed Mar 02 14:26:57 2016 Need hold release from management interface, waiting... Wed Mar 02 14:26:58 2016 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340 Wed Mar 02 14:26:58 2016 MANAGEMENT: CMD 'state on' Wed Mar 02 14:26:58 2016 MANAGEMENT: CMD 'log all on' Wed Mar 02 14:26:58 2016 MANAGEMENT: CMD 'hold off' Wed Mar 02 14:26:58 2016 MANAGEMENT: CMD 'hold release' Wed Mar 02 14:27:12 2016 MANAGEMENT: CMD 'username ""Auth"" ""tsotsasn""' Wed Mar 02 14:27:12 2016 MANAGEMENT: CMD 'password [...]' Wed Mar 02 14:27:12 2016 Control Channel Authentication: tls-auth using INLINE static key file Wed Mar 02 14:27:12 2016 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication Wed Mar 02 14:27:12 2016 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication Wed Mar 02 14:27:12 2016 Socket Buffers: R=[65536->65536] S=[65536->65536] Wed Mar 02 14:27:12 2016 MANAGEMENT: >STATE:1456925232,RESOLVE,,, Wed Mar 02 14:27:12 2016 UDPv4 link local: [undef] Wed Mar 02 14:27:12 2016 UDPv4 link remote: [AF_INET]193.175.73.200:1194 Wed Mar 02 14:27:12 2016 MANAGEMENT: >STATE:1456925232,WAIT,,, Wed Mar 02 14:27:13 2016 MANAGEMENT: >STATE:1456925233,AUTH,,, Wed Mar 02 14:27:13 2016 TLS: Initial packet from [AF_INET]193.175.73.200:1194, sid=6d40a300 9f685b6b Wed Mar 02 14:27:13 2016 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this Wed Mar 02 14:27:13 2016 VERIFY OK: depth=1, C=DE, ST=Berlin, L=Berlin, O=Charite-VPN, OU=GB-IT, CN=Charite-VPN CA, name=EasyRSA, emailAddress=vpn@charite.de Wed Mar 02 14:27:13 2016 VERIFY OK: nsCertType=SERVER Wed Mar 02 14:27:13 2016 Validating certificate extended key usage Wed Mar 02 14:27:13 2016 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication Wed Mar 02 14:27:13 2016 VERIFY EKU OK Wed Mar 02 14:27:13 2016 VERIFY X509NAME OK: C=DE, ST=Berlin, L=Berlin, O=Charite-VPN, OU=GB-IT, CN=openvpn.charite.de, emailAddress=vpn@charite.de Wed Mar 02 14:27:13 2016 VERIFY OK: depth=0, C=DE, ST=Berlin, L=Berlin, O=Charite-VPN, OU=GB-IT, CN=openvpn.charite.de, emailAddress=vpn@charite.de Wed Mar 02 14:27:13 2016 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key Wed Mar 02 14:27:13 2016 Data Channel Encrypt: Using 256 bit message hash 'SHA256' for HMAC authentication Wed Mar 02 14:27:13 2016 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key Wed Mar 02 14:27:13 2016 Data Channel Decrypt: Using 256 bit message hash 'SHA256' for HMAC authentication Wed Mar 02 14:27:13 2016 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA Wed Mar 02 14:27:13 2016 [openvpn.charite.de] Peer Connection Initiated with [AF_INET]193.175.73.200:1194 Wed Mar 02 14:27:14 2016 MANAGEMENT: >STATE:1456925234,GET_CONFIG,,, Wed Mar 02 14:27:15 2016 SENT CONTROL [openvpn.charite.de]: 'PUSH_REQUEST' (status=1) Wed Mar 02 14:27:15 2016 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 141.42.3.33,dhcp-option DNS 141.42.2.22,dhcp-option DOMAIN charite.de,register-dns,block-outside-dns,route-gateway 172.29.0.1,topology subnet,ping 10,ping-restart 30,route 10.28.0.0 255.255.0.0,route 10.32.0.0 255.224.0.0,route 172.16.0.0 255.254.0.0,route 192.168.192.0 255.255.192.0,route 141.42.0.0 255.255.0.0,route 193.175.72.0 255.255.255.0,route 193.175.74.0 255.255.254.0,route 194.94.4.0 255.255.254.0,peer-id 16,ifconfig 172.29.8.203 255.255.192.0' Wed Mar 02 14:27:15 2016 OPTIONS IMPORT: timers and/or timeouts modified Wed Mar 02 14:27:15 2016 OPTIONS IMPORT: --ifconfig/up options modified Wed Mar 02 14:27:15 2016 OPTIONS IMPORT: route options modified Wed Mar 02 14:27:15 2016 OPTIONS IMPORT: route-related options modified Wed Mar 02 14:27:15 2016 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified Wed Mar 02 14:27:15 2016 OPTIONS IMPORT: peer-id set Wed Mar 02 14:27:15 2016 OPTIONS IMPORT: adjusting link_mtu to 1573 Wed Mar 02 14:27:15 2016 ROUTE_GATEWAY 192.168.1.1/255.255.255.0 I=6 HWADDR=00:03:7f:bf:0a:eb Wed Mar 02 14:27:15 2016 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0 Wed Mar 02 14:27:15 2016 MANAGEMENT: >STATE:1456925235,ASSIGN_IP,,172.29.8.203, Wed Mar 02 14:27:15 2016 open_tun, tt->ipv6=0 Wed Mar 02 14:27:15 2016 TAP-WIN32 device [Ethernet] opened: \\.\Global\{CE798891-9C1C-4C0C-8FAF-27116B9D3226}.tap Wed Mar 02 14:27:15 2016 TAP-Windows Driver Version 9.21 Wed Mar 02 14:27:15 2016 Set TAP-Windows TUN subnet mode network/local/netmask = 172.29.0.0/172.29.8.203/255.255.192.0 [SUCCEEDED] Wed Mar 02 14:27:15 2016 Notified TAP-Windows driver to set a DHCP IP/netmask of 172.29.8.203/255.255.192.0 on interface {CE798891-9C1C-4C0C-8FAF-27116B9D3226} [DHCP-serv: 172.29.63.254, lease-time: 31536000] Wed Mar 02 14:27:15 2016 NOTE: FlushIpNetTable failed on interface [2] {CE798891-9C1C-4C0C-8FAF-27116B9D3226} (status=1168) : Element nicht gefunden. Wed Mar 02 14:27:20 2016 TEST ROUTES: 0/8 succeeded len=8 ret=0 a=0 u/d=up Wed Mar 02 14:27:20 2016 Route: Waiting for TUN/TAP interface to come up... Wed Mar 02 14:27:25 2016 TEST ROUTES: 0/8 succeeded len=8 ret=0 a=0 u/d=up Wed Mar 02 14:27:25 2016 Route: Waiting for TUN/TAP interface to come up... Wed Mar 02 14:27:27 2016 TEST ROUTES: 0/8 succeeded len=8 ret=0 a=0 u/d=up Wed Mar 02 14:27:27 2016 Route: Waiting for TUN/TAP interface to come up... Wed Mar 02 14:27:28 2016 TEST ROUTES: 0/8 succeeded len=8 ret=0 a=0 u/d=up Wed Mar 02 14:27:28 2016 Route: Waiting for TUN/TAP interface to come up... Wed Mar 02 14:27:29 2016 TEST ROUTES: 0/8 succeeded len=8 ret=0 a=0 u/d=up Wed Mar 02 14:27:29 2016 Route: Waiting for TUN/TAP interface to come up... Wed Mar 02 14:27:31 2016 TEST ROUTES: 0/8 succeeded len=8 ret=0 a=0 u/d=up Wed Mar 02 14:27:31 2016 Route: Waiting for TUN/TAP interface to come up... Wed Mar 02 14:27:32 2016 TEST ROUTES: 0/8 succeeded len=8 ret=0 a=0 u/d=up Wed Mar 02 14:27:32 2016 Route: Waiting for TUN/TAP interface to come up... Wed Mar 02 14:27:33 2016 TEST ROUTES: 0/8 succeeded len=8 ret=0 a=0 u/d=up Wed Mar 02 14:27:33 2016 Route: Waiting for TUN/TAP interface to come up... Wed Mar 02 14:27:34 2016 TEST ROUTES: 0/8 succeeded len=8 ret=0 a=0 u/d=up Wed Mar 02 14:27:34 2016 Route: Waiting for TUN/TAP interface to come up... Wed Mar 02 14:27:36 2016 TEST ROUTES: 0/8 succeeded len=8 ret=0 a=0 u/d=up Wed Mar 02 14:27:36 2016 Route: Waiting for TUN/TAP interface to come up... Wed Mar 02 14:27:37 2016 TEST ROUTES: 0/8 succeeded len=8 ret=0 a=0 u/d=up Wed Mar 02 14:27:37 2016 Route: Waiting for TUN/TAP interface to come up... Wed Mar 02 14:27:38 2016 TEST ROUTES: 0/8 succeeded len=8 ret=0 a=0 u/d=up Wed Mar 02 14:27:38 2016 Route: Waiting for TUN/TAP interface to come up... Wed Mar 02 14:27:39 2016 TEST ROUTES: 0/8 succeeded len=8 ret=0 a=0 u/d=up Wed Mar 02 14:27:39 2016 Route: Waiting for TUN/TAP interface to come up... Wed Mar 02 14:27:40 2016 TEST ROUTES: 0/8 succeeded len=8 ret=0 a=0 u/d=up Wed Mar 02 14:27:40 2016 Route: Waiting for TUN/TAP interface to come up... Wed Mar 02 14:27:41 2016 TEST ROUTES: 0/8 succeeded len=8 ret=0 a=0 u/d=up Wed Mar 02 14:27:41 2016 Route: Waiting for TUN/TAP interface to come up... Wed Mar 02 14:27:42 2016 TEST ROUTES: 0/8 succeeded len=8 ret=0 a=0 u/d=up Wed Mar 02 14:27:42 2016 Route: Waiting for TUN/TAP interface to come up... Wed Mar 02 14:27:43 2016 TEST ROUTES: 0/8 succeeded len=8 ret=0 a=0 u/d=up Wed Mar 02 14:27:43 2016 Route: Waiting for TUN/TAP interface to come up... Wed Mar 02 14:27:44 2016 TEST ROUTES: 0/8 succeeded len=8 ret=0 a=0 u/d=up Wed Mar 02 14:27:44 2016 Route: Waiting for TUN/TAP interface to come up... Wed Mar 02 14:27:45 2016 TEST ROUTES: 0/8 succeeded len=8 ret=0 a=0 u/d=up Wed Mar 02 14:27:45 2016 Route: Waiting for TUN/TAP interface to come up... Wed Mar 02 14:27:46 2016 TEST ROUTES: 0/8 succeeded len=8 ret=0 a=0 u/d=up Wed Mar 02 14:27:46 2016 Route: Waiting for TUN/TAP interface to come up... Wed Mar 02 14:27:47 2016 TEST ROUTES: 0/8 succeeded len=8 ret=0 a=0 u/d=up Wed Mar 02 14:27:47 2016 Route: Waiting for TUN/TAP interface to come up... Wed Mar 02 14:27:48 2016 TEST ROUTES: 0/8 succeeded len=8 ret=0 a=0 u/d=up Wed Mar 02 14:27:48 2016 Route: Waiting for TUN/TAP interface to come up... Wed Mar 02 14:27:49 2016 TEST ROUTES: 0/8 succeeded len=8 ret=0 a=0 u/d=up Wed Mar 02 14:27:49 2016 Route: Waiting for TUN/TAP interface to come up... Wed Mar 02 14:27:50 2016 TEST ROUTES: 0/8 succeeded len=8 ret=0 a=0 u/d=up Wed Mar 02 14:27:50 2016 MANAGEMENT: >STATE:1456925270,ADD_ROUTES,,, Wed Mar 02 14:27:50 2016 C:\WINDOWS\system32\route.exe ADD 10.28.0.0 MASK 255.255.0.0 172.29.0.1 Wed Mar 02 14:27:50 2016 Warning: route gateway is not reachable on any active network adapters: 172.29.0.1 Wed Mar 02 14:27:50 2016 Route addition via IPAPI failed [adaptive] Wed Mar 02 14:27:50 2016 Route addition fallback to route.exe Wed Mar 02 14:27:50 2016 env_block: add PATH=C:\WINDOWS\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem Wed Mar 02 14:27:50 2016 C:\WINDOWS\system32\route.exe ADD 10.32.0.0 MASK 255.224.0.0 172.29.0.1 Wed Mar 02 14:27:50 2016 Warning: route gateway is not reachable on any active network adapters: 172.29.0.1 Wed Mar 02 14:27:50 2016 Route addition via IPAPI failed [adaptive] Wed Mar 02 14:27:50 2016 Route addition fallback to route.exe Wed Mar 02 14:27:50 2016 env_block: add PATH=C:\WINDOWS\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem Wed Mar 02 14:27:50 2016 C:\WINDOWS\system32\route.exe ADD 172.16.0.0 MASK 255.254.0.0 172.29.0.1 Wed Mar 02 14:27:50 2016 Warning: route gateway is not reachable on any active network adapters: 172.29.0.1 Wed Mar 02 14:27:50 2016 Route addition via IPAPI failed [adaptive] Wed Mar 02 14:27:50 2016 Route addition fallback to route.exe Wed Mar 02 14:27:50 2016 env_block: add PATH=C:\WINDOWS\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem Wed Mar 02 14:27:50 2016 C:\WINDOWS\system32\route.exe ADD 192.168.192.0 MASK 255.255.192.0 172.29.0.1 Wed Mar 02 14:27:50 2016 Warning: route gateway is not reachable on any active network adapters: 172.29.0.1 Wed Mar 02 14:27:50 2016 Route addition via IPAPI failed [adaptive] Wed Mar 02 14:27:50 2016 Route addition fallback to route.exe Wed Mar 02 14:27:50 2016 env_block: add PATH=C:\WINDOWS\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem Wed Mar 02 14:27:50 2016 C:\WINDOWS\system32\route.exe ADD 141.42.0.0 MASK 255.255.0.0 172.29.0.1 Wed Mar 02 14:27:50 2016 Warning: route gateway is not reachable on any active network adapters: 172.29.0.1 Wed Mar 02 14:27:50 2016 Route addition via IPAPI failed [adaptive] Wed Mar 02 14:27:50 2016 Route addition fallback to route.exe Wed Mar 02 14:27:50 2016 env_block: add PATH=C:\WINDOWS\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem Wed Mar 02 14:27:50 2016 C:\WINDOWS\system32\route.exe ADD 193.175.72.0 MASK 255.255.255.0 172.29.0.1 Wed Mar 02 14:27:50 2016 Warning: route gateway is not reachable on any active network adapters: 172.29.0.1 Wed Mar 02 14:27:50 2016 Route addition via IPAPI failed [adaptive] Wed Mar 02 14:27:50 2016 Route addition fallback to route.exe Wed Mar 02 14:27:50 2016 env_block: add PATH=C:\WINDOWS\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem Wed Mar 02 14:27:50 2016 C:\WINDOWS\system32\route.exe ADD 193.175.74.0 MASK 255.255.254.0 172.29.0.1 Wed Mar 02 14:27:50 2016 Warning: route gateway is not reachable on any active network adapters: 172.29.0.1 Wed Mar 02 14:27:50 2016 Route addition via IPAPI failed [adaptive] Wed Mar 02 14:27:50 2016 Route addition fallback to route.exe Wed Mar 02 14:27:50 2016 env_block: add PATH=C:\WINDOWS\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem Wed Mar 02 14:27:50 2016 C:\WINDOWS\system32\route.exe ADD 194.94.4.0 MASK 255.255.254.0 172.29.0.1 Wed Mar 02 14:27:50 2016 Warning: route gateway is not reachable on any active network adapters: 172.29.0.1 Wed Mar 02 14:27:50 2016 Route addition via IPAPI failed [adaptive] Wed Mar 02 14:27:50 2016 Route addition fallback to route.exe Wed Mar 02 14:27:50 2016 env_block: add PATH=C:\WINDOWS\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem SYSTEM ROUTING TABLE 0.0.0.0 0.0.0.0 192.168.1.1 p=0 i=6 t=4 pr=3 a=186243 h=0 m=25/0/0/0/0 10.28.0.0 255.255.0.0 172.29.0.1 p=0 i=6 t=4 pr=3 a=0 h=0 m=26/0/0/0/0 10.32.0.0 255.224.0.0 172.29.0.1 p=0 i=6 t=4 pr=3 a=0 h=0 m=26/0/0/0/0 127.0.0.0 255.0.0.0 127.0.0.1 p=0 i=1 t=3 pr=2 a=1474645 h=0 m=306/0/0/0/0 127.0.0.1 255.255.255.255 127.0.0.1 p=0 i=1 t=3 pr=2 a=1474645 h=0 m=306/0/0/0/0 127.255.255.255 255.255.255.255 127.0.0.1 p=0 i=1 t=3 pr=2 a=1474645 h=0 m=306/0/0/0/0 141.42.0.0 255.255.0.0 172.29.0.1 p=0 i=6 t=4 pr=3 a=0 h=0 m=26/0/0/0/0 172.16.0.0 255.254.0.0 172.29.0.1 p=0 i=6 t=4 pr=3 a=0 h=0 m=26/0/0/0/0 192.168.1.0 255.255.255.0 192.168.1.24 p=0 i=6 t=3 pr=2 a=186243 h=0 m=281/0/0/0/0 192.168.1.24 255.255.255.255 192.168.1.24 p=0 i=6 t=3 pr=2 a=186243 h=0 m=281/0/0/0/0 192.168.1.255 255.255.255.255 192.168.1.24 p=0 i=6 t=3 pr=2 a=186243 h=0 m=281/0/0/0/0 192.168.192.0 255.255.192.0 172.29.0.1 p=0 i=6 t=4 pr=3 a=0 h=0 m=26/0/0/0/0 193.175.72.0 255.255.255.0 172.29.0.1 p=0 i=6 t=4 pr=3 a=0 h=0 m=26/0/0/0/0 193.175.74.0 255.255.254.0 172.29.0.1 p=0 i=6 t=4 pr=3 a=0 h=0 m=26/0/0/0/0 194.94.4.0 255.255.254.0 172.29.0.1 p=0 i=6 t=4 pr=3 a=0 h=0 m=26/0/0/0/0 224.0.0.0 240.0.0.0 127.0.0.1 p=0 i=1 t=3 pr=2 a=1474645 h=0 m=306/0/0/0/0 224.0.0.0 240.0.0.0 192.168.1.24 p=0 i=6 t=3 pr=2 a=1474597 h=0 m=281/0/0/0/0 255.255.255.255 255.255.255.255 127.0.0.1 p=0 i=1 t=3 pr=2 a=1474645 h=0 m=306/0/0/0/0 255.255.255.255 255.255.255.255 192.168.1.24 p=0 i=6 t=3 pr=2 a=1474597 h=0 m=281/0/0/0/0 SYSTEM ADAPTER LIST Atheros AR5005GS-Drahtlosnetzwerkadapter Index = 6 GUID = {43FA17D6-0B42-4B95-B760-092C876CA43B} IP = 192.168.1.24/255.255.255.0 MAC = 00:03:7f:bf:0a:eb GATEWAY = 192.168.1.1/255.255.255.255 DHCP SERV = 192.168.1.1/255.255.255.255 DHCP LEASE OBTAINED = Wed Mar 02 12:52:53 2016 DHCP LEASE EXPIRES = Wed Mar 09 12:52:53 2016 DNS SERV = 192.168.1.1/255.255.255.255 Wed Mar 02 14:27:50 2016 Initialization Sequence Completed With Errors ( see http://openvpn.net/faq.html#dhcpclientserv ) Wed Mar 02 14:27:50 2016 MANAGEMENT: >STATE:1456925270,CONNECTED,ERROR,172.29.8.203,193.175.73.200 Wed Mar 02 14:27:50 2016 Start net commands... Wed Mar 02 14:27:50 2016 C:\WINDOWS\system32\net.exe stop dnscache Wed Mar 02 14:27:58 2016 C:\WINDOWS\system32\net.exe start dnscache Wed Mar 02 14:27:58 2016 ERROR: Windows ipconfig command failed: returned error code 2 Wed Mar 02 14:27:58 2016 C:\WINDOWS\system32\ipconfig.exe /flushdns Wed Mar 02 14:27:58 2016 C:\WINDOWS\system32\ipconfig.exe /registerdns Wed Mar 02 14:28:01 2016 End net commands... Wed Mar 02 14:30:46 2016 SIGTERM received, sending exit notification to peer Wed Mar 02 14:30:47 2016 C:\WINDOWS\system32\route.exe DELETE 194.94.4.0 MASK 255.255.254.0 172.29.0.1 Wed Mar 02 14:30:47 2016 Warning: route gateway is not reachable on any active network adapters: 172.29.0.1 Wed Mar 02 14:30:47 2016 Route deletion via IPAPI failed [adaptive] Wed Mar 02 14:30:47 2016 Route deletion fallback to route.exe Wed Mar 02 14:30:47 2016 env_block: add PATH=C:\WINDOWS\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem Wed Mar 02 14:30:47 2016 C:\WINDOWS\system32\route.exe DELETE 193.175.74.0 MASK 255.255.254.0 172.29.0.1 Wed Mar 02 14:30:47 2016 Warning: route gateway is not reachable on any active network adapters: 172.29.0.1 Wed Mar 02 14:30:47 2016 Route deletion via IPAPI failed [adaptive] Wed Mar 02 14:30:47 2016 Route deletion fallback to route.exe Wed Mar 02 14:30:47 2016 env_block: add PATH=C:\WINDOWS\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem Wed Mar 02 14:30:47 2016 C:\WINDOWS\system32\route.exe DELETE 193.175.72.0 MASK 255.255.255.0 172.29.0.1 Wed Mar 02 14:30:47 2016 Warning: route gateway is not reachable on any active network adapters: 172.29.0.1 Wed Mar 02 14:30:47 2016 Route deletion via IPAPI failed [adaptive] Wed Mar 02 14:30:47 2016 Route deletion fallback to route.exe Wed Mar 02 14:30:47 2016 env_block: add PATH=C:\WINDOWS\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem Wed Mar 02 14:30:47 2016 C:\WINDOWS\system32\route.exe DELETE 141.42.0.0 MASK 255.255.0.0 172.29.0.1 Wed Mar 02 14:30:47 2016 Warning: route gateway is not reachable on any active network adapters: 172.29.0.1 Wed Mar 02 14:30:47 2016 Route deletion via IPAPI failed [adaptive] Wed Mar 02 14:30:47 2016 Route deletion fallback to route.exe Wed Mar 02 14:30:47 2016 env_block: add PATH=C:\WINDOWS\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem Wed Mar 02 14:30:47 2016 C:\WINDOWS\system32\route.exe DELETE 192.168.192.0 MASK 255.255.192.0 172.29.0.1 Wed Mar 02 14:30:47 2016 Warning: route gateway is not reachable on any active network adapters: 172.29.0.1 Wed Mar 02 14:30:47 2016 Route deletion via IPAPI failed [adaptive] Wed Mar 02 14:30:47 2016 Route deletion fallback to route.exe Wed Mar 02 14:30:47 2016 env_block: add PATH=C:\WINDOWS\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem Wed Mar 02 14:30:47 2016 C:\WINDOWS\system32\route.exe DELETE 172.16.0.0 MASK 255.254.0.0 172.29.0.1 Wed Mar 02 14:30:47 2016 Warning: route gateway is not reachable on any active network adapters: 172.29.0.1 Wed Mar 02 14:30:47 2016 Route deletion via IPAPI failed [adaptive] Wed Mar 02 14:30:47 2016 Route deletion fallback to route.exe Wed Mar 02 14:30:47 2016 env_block: add PATH=C:\WINDOWS\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem Wed Mar 02 14:30:47 2016 C:\WINDOWS\system32\route.exe DELETE 10.32.0.0 MASK 255.224.0.0 172.29.0.1 Wed Mar 02 14:30:47 2016 Warning: route gateway is not reachable on any active network adapters: 172.29.0.1 Wed Mar 02 14:30:47 2016 Route deletion via IPAPI failed [adaptive] Wed Mar 02 14:30:47 2016 Route deletion fallback to route.exe Wed Mar 02 14:30:47 2016 env_block: add PATH=C:\WINDOWS\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem Wed Mar 02 14:30:47 2016 C:\WINDOWS\system32\route.exe DELETE 10.28.0.0 MASK 255.255.0.0 172.29.0.1 Wed Mar 02 14:30:47 2016 Warning: route gateway is not reachable on any active network adapters: 172.29.0.1 Wed Mar 02 14:30:47 2016 Route deletion via IPAPI failed [adaptive] Wed Mar 02 14:30:47 2016 Route deletion fallback to route.exe Wed Mar 02 14:30:47 2016 env_block: add PATH=C:\WINDOWS\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem Wed Mar 02 14:30:47 2016 Closing TUN/TAP interface Wed Mar 02 14:30:47 2016 SIGTERM[soft,exit-with-notification] received, process exiting Wed Mar 02 14:30:47 2016 MANAGEMENT: >STATE:1456925447,EXITING,exit-with-notification,, Windows 10 pro 4 GB RAM 64 Bit, x86 " hildeb Active Tickets 668 route_vpn_gateway environment variable not set when no routes pushed Generic / unclassified OpenVPN 2.3.10 (Community Ed) Bug / Defect new 2016-03-20T05:27:42Z 2022-12-16T09:30:18Z The route_vpn_gateway environment variable is not set for the up script unless a route is also pushed. There are a variety of use cases where you need route_vpn_gateway but don't have pushed routes, like where you're policy routing over OpenVPN, or otherwise want or need your up script to handle routing. route_vpn_gateway should never be excluded where it's known/exists. cbuechler Active Tickets 375 Improve MTU behavior Networking OpenVPN git master branch (Community Ed) Feature Wish new 2014-02-25T18:03:39Z 2023-04-12T05:51:27Z "Current behavior with respect to MTU seems suboptimal. It mostly works for TCP (due to all kinds of magic related to mssfix), but it's problematic for everything else. Currently, if mtu-disc is ""yes"", then an openvpn tunnel is a PMTU blackhole. (This is arguably a real bug, not just a feature request.) If mtu-disc is ""maybe"", then openvpn will send fragmented UDP packets if the encapsulated packet is too large and doesn't compress enough, which sucks Here are a few thoughts for improving the situation. 1. Add an option to respect the DF bit. If openvpn receives a packet that (in the worst case) would cause the encapsulated packet to be too large, then openvpn should drop it and generate an ICMP error. This might be a bit tricky to get completely right, especially on non-Linux platforms. Even on Linux, I'm not sure how easy it is to tell *which* UDP packet was dropped due to being too large. On the other hand, generating ICMP errors only for packets that would exceed the current estimated link mtu would probably be good enough for most uses, especially if openvpn were to send a very large ping at startup to bootstrap the PMTU discovery process. 2. Automatically set the tunnel MTU. On Linux, at least, this could even be done dynamically. Even without dynamically changing the tunnel MTU, openvpn could quickly estimate link MTU at startup and get the tunnel MTU right most of the time. This way, at least when the tunnel MTU is right, PMTU discovery inside the VPN would work correctly. If either of these options ends up working well, then turning them on (and possibly using mtu-disc=yes) might be a sensible default. This could remove any need to fiddle with tun-mtu, link-mtu, fragment, etc. (OK, this is a slight lie -- if the determined MTU is low enough that the implied tunnel MTU < 576 (IIRC), then fragment mode would have to be enabled to get a usable link.)" amluto Active Tickets 501 environment variables don't pass to windows up script Generic / unclassified OpenVPN git master branch (Community Ed) Feature Wish new 2015-01-12T17:50:57Z 2015-05-27T20:27:35Z in windows up script none of the environment variables that were set by the command that calls openvpn are set. It would be nice to keep or copy all the variables over to the script so that they can be used, or define a way to get these variables. jktseug Active Tickets 577 Provide a socks5 server port for user apps to use Generic / unclassified OpenVPN 2.3.7 (Community Ed) Feature Wish new 2015-07-09T22:45:37Z 2021-02-27T19:15:05Z "OpenVPN should provide a socks5 server port so that individual user apps may specify OpenVPN as their socks5 server to use, thereby sending all their traffic directly into OpenVPN, with OpenVPN then sending that traffic out over the VPN tunnel to the far side. For example, the Tor daemon of torproject.org provides a socks5 server port for use by applications. This will provide a simpler VPN usage model for situations where the complexities of the host's kernel routing table and packet rules, the weight of VM's, design conflicts, etc... are not ideal, possible, or warranted. searchwords: socks5 socksv5 socks proxy tor " grarpamp Active Tickets 596 Add option to change the InterfaceMetric on the TAP32 adapter Generic / unclassified OpenVPN 2.3.8 (Community Ed) Feature Wish new 2015-08-14T12:16:27Z 2017-03-14T14:11:44Z "There seem to be some (just some!) installations of win10 which (like previous versions of windows) seem to have issues with the ""interface order"". What we're seeing is that our INTERNAL DNS is not being used, since the LAN/WIFI adapters have higher priority. In Windows BEFORE version 10 one could simply change this in the network settings panel, and it would even survive a reboot. In Windows 10 one has to fiddle with the interface metrics as described here: http://answers.microsoft.com/en-us/insider/forum/insider_wintp-insider_web/cannot-change-network-binding-order-in-windows-10/08d775da-24d6-4b26-96fe-355920e879a0?page=2 My idea: wouldn't it be cool if I could specify a ""InterfaceMetric"" for the TAP32 adapter in the config. Then it could be chosen suifficiently low (e.g. to zero)... As a workaround I though of creating a pre-up script that would invoke a powershell script upon startup..." hildeb Active Tickets 131 client management interface user authentication abort inconsistency Management OpenVPN 2.3.1 (Community Ed) Bug / Defect new 2011-05-12T16:11:33Z 2022-12-25T19:08:49Z "Setup: - OpenVPN client on Windows started by the OpenVPN service wrapper - Configuration with auth-user-pass, management-hold, management-query-passwords and auth-retry interact Demo: - telnet to the management port - enter hold release (you are queried for username/password) - change your mind (imagine pressing cancel instead of ok in a GUI) - enter signal SIGHUP or signal SIGUSR1 Result: The OpenVPN process exits. This Shouldn't Happen(tm). It even happens if you complete entering username and password but enter the signal within a certain time frame." bwess Active Tickets 167 UNDEF user with big uptime Generic / unclassified Bug / Defect new 2011-10-05T12:18:23Z 2022-12-21T16:08:16Z "In status file I see user with name ""UNDEF"". Google says, that it's unauthorized user, and the name should be resolved shortly, or user should be disconnected. But, in my case, this user stays online over 7 hours, and has 50 mb traffic. Here is status file example (reduced for tidiness): Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since UNDEF,173.10.81.161:55555,5534537,49579722,Fri Sep 30 00:26:53 2011 Virtual Address,Common Name,Real Address,Last Ref 00:ff:d7:11:b6:55,UNDEF,173.10.81.161:55555,Fri Sep 30 07:56:09 2011 " svimik Active Tickets 345 management interface reports incorrect state after TLS handshake failure and renegotiation Management OpenVPN 2.2.1 (Community Ed) Bug / Defect new 2013-11-14T14:32:55Z 2018-07-17T09:30:25Z "OpenVPN 2.2.1 on Ubuntu 12.04, both clients and servers. VPN connections are over somewhat unreliable networks. We've seen this happen regularly over the past few weeks. Once we see an error like this, the ""state"" command on the management interface reports the incorrect state, and continues to do so until the client or server are restarted. The tunnel is up and functioning, just the management interface reports it wrong. {{{ $ echo state | nc localhost 1151 >INFO:OpenVPN Management Interface Version 1 -- type 'help' for more info 1384405371,WAIT,,, END }}} The expected output should be: {{{ ... 1384405371,CONNECTED,SUCCESS,10.42.1.2,1.2.3.4 END }}} Here's the log snippet (CA and IP's and hostnames changed to protect the innocent) of when it actually happened, until then the proper output was displayed. It appears the TLS re-negotiation failed at 05:02:36, then re-established the connection at 05:02:51. {{{ Nov 14 04:01:35 vpn.client openvpn-inband[14143]: TLS: tls_process: killed expiring key Nov 14 04:01:36 vpn.client openvpn-inband[14143]: TLS: soft reset sec=0 bytes=1837717/0 pkts=8844/0 Nov 14 04:01:36 vpn.client openvpn-inband[14143]: VERIFY OK: depth=2, /C=CA/O=My_Company/CN=Root_CA/emailAddress=certs@mycompany.com Nov 14 04:01:36 vpn.client openvpn-inband[14143]: VERIFY OK: depth=1, /C=CA/O=My_Company/CN=Subordinate_CA/emailAddress=certs@mycompany.com Nov 14 04:01:36 vpn.client openvpn-inband[14143]: VERIFY OK: depth=0, /C=CA/ST=/L=/O=My_Company/OU=/CN=vpn.server-server/emailAddress=pki@mycompany.com Nov 14 04:01:36 vpn.client openvpn-inband[14143]: Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key Nov 14 04:01:36 vpn.client openvpn-inband[14143]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Nov 14 04:01:36 vpn.client openvpn-inband[14143]: Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key Nov 14 04:01:36 vpn.client openvpn-inband[14143]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Nov 14 04:01:36 vpn.client openvpn-inband[14143]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA Nov 14 05:01:36 vpn.client openvpn-inband[14143]: TLS: soft reset sec=0 bytes=1909669/0 pkts=9129/0 Nov 14 05:02:36 vpn.client openvpn-inband[14143]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Nov 14 05:02:36 vpn.client openvpn-inband[14143]: TLS Error: TLS handshake failed Nov 14 05:02:36 vpn.client openvpn-inband[14143]: TLS: move_session: dest=TM_LAME_DUCK src=TM_ACTIVE reinit_src=1 Nov 14 05:02:51 vpn.client openvpn-inband[14143]: TLS: Initial packet from [AF_INET]1.2.3.4:11194, sid=386f21f8 147b9048 Nov 14 05:02:51 vpn.client openvpn-inband[14143]: VERIFY OK: depth=2, /C=CA/O=My_Company/CN=Root_CA/emailAddress=certs@mycompany.com Nov 14 05:02:51 vpn.client openvpn-inband[14143]: VERIFY OK: depth=1, /C=CA/O=My_Company/CN=Subordinate_CA/emailAddress=certs@mycompany.com Nov 14 05:02:51 vpn.client openvpn-inband[14143]: VERIFY OK: depth=0, /C=CA/ST=/L=/O=My_Company/OU=/CN=vpn.server-server/emailAddress=pki@mycompany.com Nov 14 05:02:52 vpn.client openvpn-inband[14143]: Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key Nov 14 05:02:52 vpn.client openvpn-inband[14143]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Nov 14 05:02:52 vpn.client openvpn-inband[14143]: Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key Nov 14 05:02:52 vpn.client openvpn-inband[14143]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Nov 14 05:02:52 vpn.client openvpn-inband[14143]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA }}} Client configuration file (with CA info and server IP changed) {{{ ca /etc/ssl/certs/my-ca-chain.pem cert /etc/openvpn/ssl/vpn.client.cert key /etc/openvpn/ssl/vpn.client.key client remote 1.2.3.4 port 11194 proto udp dev tap3 ping 10 ping-restart 60 persist-tun persist-key daemon openvpn-inband comp-lzo user nobody group nogroup verb 3 mssfix 1464 management 127.0.0.1 1151 script-security 2 up /etc/openvpn/vpn_up.sh down /etc/openvpn/vpn_down.sh }}} And the corresponding server configuration: {{{ ca /etc/ssl/certs/my-ca-chain.pem cert /etc/openvpn/ssl/vpn.server-server.cert key /etc/openvpn/ssl/vpn.server-server.key dh /etc/openvpn/ssl/dh2048.pem dev tap3 tls-server server 10.42.1.0 255.255.255.0 topology subnet port 1194 proto udp max-clients 1 ping 10 ping-restart 120 persist-tun persist-key daemon openvpn-inband comp-lzo user nobody group nogroup verb 3 mssfix 1464 management 127.0.0.1 1151 script-security 2 up /etc/openvpn/vpnup.sh client-connect /etc/openvpn/client_connect.sh ifconfig-pool-persist /var/run/openvpn/clients.db 60 }}}" hart.mike@… Active Tickets 386 Cryptoapicert SUBJ: selector doc Documentation OpenVPN 2.2.2 (Community Ed) Bug / Defect new 2014-04-10T03:42:53Z 2022-12-21T18:36:53Z "I got --cryptoapicert to work with ""SUBJ:"" selectors. The documentation for the ""SUBJ:"" form of the option is a bit lacking. Consider this subject (as viewed in IE tools->options->content): E = john@answers.example.net CN = John Smith OU = Group A OU = Department O = Minicorp L = City S = State C = US To match the whole thing (as John Smith may have more than one cert), one needs: ""SUBJ:US, State, City, Minicorp, Department, Group, John Smith, john@answers.example.net"" This is what Microsoft calls a CERT_SIMPLE_NAME_STR - the doc for which is astoundingly opaque. The required ordering is not what IE presents for the RDN, but one can get it from openssl: openssl x509 -in john.cer -noout -subject subject= /C=US/ST=State/L=City/O=Minicorp/OU=Department/OU=Group/CN=John Smith/emailAddress=john@answers.example.net The above is one line, but mail will probably wrap it. I'm not sure if simply reversing the MS presentation is reliable. Further, the MS documentation suggest that a 'plus space' delimiter is used for multiple attributes. It's not clear what that means. " tlhackque Active Tickets 405 Use --cd in config causes instance to terminate on SIGHUP Generic / unclassified OpenVPN 2.3.4 (Community Ed) Bug / Defect new 2014-05-15T10:23:22Z 2015-05-28T12:41:44Z "Use of --cd to change the directory in a config file causes the OpenVPN process to terminate as the process can no longer find the config file when SIGHUP is issued. Even if all files referenced in the config file are absolute paths the process expect to find the current running config in the current directory, which it is not due to the use of --cd Proposed behaviour to solve this issue: Have the code for --cd store the current directory at loading the config file and restore this directory on SIGHUP, in a similar manner as PUSHD / POPD. " debbie10t Active Tickets 468 multiple clients with same cert leads to problems Generic / unclassified OpenVPN git master branch (Community Ed) Bug / Defect new 2014-10-30T00:24:56Z 2019-11-28T18:58:36Z "Hi there, Steffan Karger said to put the ticket in I've got a corner case I've picked up during testing that makes me wonder if there's a bug in openvpn Our openvpn server ""tests"" incoming clients to ensure they comply with our openvpn client standards - killing their session if they don't (basically client-less NAC). One thing we're doing is allowing ""duplicate-cn"", but using our NAC test to reject clients using the same cert (get better logging of the offenders that way). Anyway, I have a Mac and Windows box set up to use the same cert to test this, and it causes an interesting situation... First client connects, second client connects, NAC script notices the same cert in use and kills the first connection. Second client later hangs up. If I then look at the first client hours later, it still thinks it's logged in! There is no error, it still has the tun interface up, but no traffic flows. The server shows no connection via either client (I use the management api to confirm that) We use ""--ping"", and tcpdump confirms the first client and server are still exchanging packets - but the server does not classify the client as being connected. But as the openvpn pings are still working, the client doesn't know it's actually disconnected. A simple ""kill -HUP"" on the client fixes everything as it forces a full restart So I have two questions: 1. The client uses ""explicit-exit-notify"" - but it looks like using the kill management command on the server does not tell the client it is hanging up? Wouldn't that be a good idea? 2. The fact that ping is still working makes me think that means ping must be *separate* from session management? Isn't that a bad idea? Hopefully I'm wrong and someone will tell me I'm doing it incorrectly server is 2.3_git, and this is over UDP of course (I doubt this is an issue over TCP, although I haven't tested)" jhaar Active Tickets 533 openvpn should check the tap interface will work before even attempting server connection Generic / unclassified OpenVPN 2.3.5 (Community Ed) Bug / Defect new 2015-03-21T21:24:51Z 2020-09-27T20:57:52Z "Hi there We run openvpn under Windows as a service and have had a couple of situations where users for one reason or another have decided to disable openvpn by disabling the TAP interface instead of shutting down the openvpn service. The problem is that openvpn doesn't appear to look too hard at the enable/disable state of the adaptor and goes through the entire connection to server, negotiating ip addresses, etc - before noticing and crashing/exiting. This causes an infinite loop: the client connects, crashes, sleeps, connects, etc - and the load on the server goes through the roof - all from one user. We can blame the service manager for that - but frankly I *want* it to restart openvpn on error - just not this error Telling users what to do is fine and sensible, but has a 0% chance of working. Wouldn't it be better than openvpn checks the state of the interface right at the beginning and simply refuses to connect if it's in an unusable state? I'd rather the client went into an infinite loop of starting, checking, exiting, starting, etc than involve the server (which affects other users). A 5-10 second delay after such a condition was detected would help reduce any client impact too of course" jhaar Active Tickets 551 --ipchange: openvpn does not pass parameters correctly Generic / unclassified OpenVPN git master branch (Community Ed) Bug / Defect new 2015-05-07T22:06:11Z 2019-11-28T20:40:57Z "According to the OpenVPN Manual: {{{#!td style=""background: #eef"" --'''ipchange'''[[BR]][[BR]] When cmd is executed __two arguments are appended__ after any arguments specified in cmd , as follows:[[BR]][[BR]] '''cmd ip_address port_number''' }}} However, this is __not__ the case ... __Client.conf (default more or less)__: {{{ ipchange 'ipchange.sh TEST' }}} __ipchange.sh__: {{{ echo $(date) echo P1: $1 echo P2: $2 echo P3: $3 }}} __Client log__: {{{ Thu May 7 22:37:01 BST 2015 P1: TEST P2: [AF_INET]172.17.2.222 37323 P3: }}} The string '''[AF_INET]''' and parameters '''ip_address''' and '''port_number''' are passed as one long string to '''one''' positional parameter. " debbie10t Active Tickets 607 Default route not cleared on network fail. Networking OpenVPN 2.3.8 (Community Ed) Bug / Defect new 2015-09-22T10:33:35Z 2018-05-29T20:48:41Z "Steps to reproduce:- Set up and start openvpn connection with default route via tunnel (i.e. config redirect-gateway defl). Disable/Enable network (e.g. pull network cable, wait for failure, and reconnect). Expected behaviour: openvpn reconnects. Actual behaviour: openvpn client cannot re-connect to server, because the default route is still via the now down tunnel (see below). Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 128.0.0.0 UG 0 0 0 tun0 0.0.0.0 0.0.0.0 UG 0 0 0 eth0 ... Proposed solution: Either remove the default route, when the link goes down, or don't remove the route entry for the server (when the link is up, I also have the following route line) 255.255.255.255 UGH 0 0 0 eth0 This is a daily occurrance for me, as I commonly move from my desk to meetings, and disconnect from the physical network on the way. The current workaround is to manually restart the openvpn service every time this happens. # openvpn --version OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Dec 1 2014 Originally developed by James Yonan Copyright (C) 2002-2010 OpenVPN Technologies, Inc. Compile time defines: enable_crypto=yes enable_debug=yes enable_def_auth=yes enable_dependency_tracking=no enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_eurephia=yes enable_fast_install=yes enable_fragment=yes enable_http_proxy=yes enable_iproute2=yes enable_libtool_lock=yes enable_lzo=yes enable_lzo_stub=no enable_maintainer_mode=no enable_management=yes enable_multi=yes enable_multihome=yes enable_pam_dlopen=no enable_password_save=yes enable_pedantic=no enable_pf=yes enable_pkcs11=yes enable_plugin_auth_pam=yes enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_selinux=no enable_server=yes enable_shared=yes enable_shared_with_static_runtimes=no enable_small=no enable_socks=yes enable_ssl=yes enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=no enable_win32_dll=yes enable_x509_alt_username=yes with_crypto_library=openssl with_gnu_ld=yes with_ifconfig_path=/sbin/ifconfig with_iproute_path=/sbin/ip with_mem_check=no with_plugindir='${prefix}/lib/openvpn' with_route_path=/sbin/route with_sysroot=no # cat /etc/openvpn/my.conf client dev tun remote 1194 nobind resolv-retry infinite persist-key persist-tun ca /etc/openvpn/ca.crt cert /etc/openvpn/client.crt key /etc/openvpn/client.key tls-auth /etc/openvpn/server-ta.key 1 comp-lzo proto tcp ping 15 ping-restart 45 ping-timer-rem redirect-gateway def1 dhcp-option DNS 8.8.8.8 up /etc/openvpn/server.up # Just rewrites resolv.conf - but note server, above, is specified by IP address " Guinness2702 Active Tickets 627 """learn-address delete"" not executed" Generic / unclassified OpenVPN 2.3.4 (Community Ed) Bug / Defect new 2015-11-09T13:44:31Z 2015-11-09T14:48:28Z "Openvpn does not execute ""learn-address delete"" if a ""client-disconnect"" script is defined. learn-address add/update and client-connect are executed as expected. Is this expected behavior that I could not find in the documentation or a bug? " pplars Active Tickets 635 "Password for file ""openvpn.xdb"" is missing" Documentation Bug / Defect reopened 2015-11-29T16:06:59Z 2016-02-26T03:04:55Z "At this site: * https://community.openvpn.net/openvpn/wiki/XCA the user * eugenekay has stored the file * OpenVPN.xdb The file is password-protected (as every *.xdb - file). The password is not written down on the website. So the file can not be used. I wanted to use the templates from the .xdb - file." martin kubiak Active Tickets 672 OpenVPN does not recognize network change Networking OpenVPN 2.3.8 (Community Ed) Bug / Defect new 2016-04-06T10:27:53Z 2018-01-17T07:22:48Z "From time to time my Ubuntu client changes network from WiFi to LAN and vice versa or simply suspends and resumes. Since half a year I have occasionally to force a OpenVPN restart to get the connection back. It looks like OpenVPN is not detecting the network and connectivity loss. My Ubuntu is running in a VM. openvpn 2.3.7-1ubuntu1 Linux version 4.2.0-34-generic (buildd@lgw01-54) (gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2) ) #39-Ubuntu SMP Thu Mar 10 22:13:01 UTC 2016 " thhart Active Tickets 676 Variables route_net_gateway and route_vpn_gateway not set on server in topology subnet Generic / unclassified OpenVPN git master branch (Community Ed) Bug / Defect new 2016-04-20T09:49:03Z 2016-04-20T14:26:21Z "Variables `$route_net_gateway` and `$route_vpn_gateway` are '''not set on the server side''' when `--topoloy subnet` is used. (The client side does set these variables regardless of topology) As per JJK's answer: Explicitly using `route 10.8.0.0 255.255.255.0` in the server config solves this issue .. " debbie10t Active Tickets 346 Set tap device link status based on openvpn connection state Generic / unclassified OpenVPN 2.3.2 (Community Ed) Feature Wish new 2013-11-22T19:42:02Z 2018-05-17T17:00:54Z "I would like to bond openvpn tap interfaces together using the Linux bonding driver with miimon style link detection. This doesn't easily work because tap devices are created being ""up"", and openvpn doesn't manage their link state. A possible workaround is to have {{{route-up}}} and {{{up}}} scripts that explicitly set the link state on the tap device (although in one case I had to use a {{{tls-verify}}} script because the {{{route-up}}} script was not called for some reason). However, it would be cleaner if OpenVPN could (optionally?) set the link state of the tap device as follows: * on startup: down * when connection fully established (peer authenticated), but before adding routes: up * connection failure or peer disconnect: down (Obviously this is less interesting for server mode but it would help a lot in 1:1 mode.) Alternatively, script hooks should be provided that can be used to set the tap link state as appropriate, so that I don't have to set the link ''down'' from an {{{up}}} script and set it ''uo'' from a {{{tls-verify}}} script (yuck :). " András Korn Active Tickets 424 Add tap emulation to the iOS and Android clients OSS OpenVPN Clients Feature Wish new 2014-07-08T06:17:26Z 2018-11-18T15:59:15Z "This feature is quite important for the iOS clients, since a lot of Apple services make use of Bonjour/mDNS-SD, which cannot be propagated over a layer 3 tunnel, thus bridging is required in order for this to work. Here is an example of a possible implementation: https://code.google.com/p/guizmovpn/source/browse/trunk/openvpn/tapemu.c?spec=svn3&r=3" yuanqi Active Tickets 438 openvpn should detect dns is working before even attempting profile actions Generic / unclassified Feature Wish new 2014-09-03T20:33:03Z 2015-05-28T06:36:10Z "Hi there I'm running openvpn as a service and one ""glitch"" it suffers from is timing out on """" profile attempts because there is no working network link at that moment. I see this a lot due to running it as a service on a laptop which is sleeping/unsleeping What I've noticed is both Android and IOS do a series of ""random hostname"" DNS lookups before deciding they have a working network link. ie they generate some fake DNS records, look them up, and if they don't generate a DNS ""no such host"" error, then the OSes decide the network is not up yet - so all apps don't even get woken As openvpn runs on multiple OSes and they don't all do that, maybe it could be added directly to openvpn (I think maybe Chrome browser does this too?). ie when openvpn starts, it should first do such random DNS lookups, and only if it gets sensible answers even bother to start attempting a connection. BTW: In my case our profile starts with a connection section for an intranet server, so this is meant to fail when on ""the Internet"" - so simply blocking openvpn until the server hostnames resolve would not be a good idea (for us!) (later on there are Internet openvpn servers of course: the idea is when on the LAN, openvpn goes to an internal server and when off the LAN [on the Internet] it goes somewhere else - works well) Thanks Jason" jhaar Active Tickets 513 Bonjour networking support Networking OpenVPN git master branch (Community Ed) Feature Wish new 2015-02-08T10:43:26Z 2015-05-28T08:22:23Z As an OpenVPN user I noticed that Bonjour networking (autoconf etc..) seems to be filtered out by the VPN server. OpenVPN servers on wifi routers do not seem to have an obvious option that allows multicast and bonjour networking to pass. This results in functionality loss such as access to bonjour enabled printers, time machine backups, AirPrint, audio streaming. goedtkindt Active Tickets 532 Misleading messages when trying to connect with an expired certificate Generic / unclassified OpenVPN 2.3.5 (Community Ed) Feature Wish new 2015-03-20T16:02:50Z 2015-04-26T23:10:05Z "I recently tried to connect to my OpenVPN server with a client certificate that expired 2 weeks ago. Of course it failed, but without giving any hint about what went wrong. In fact it even gave a very misleading piece of advice: ""check your network connectivity"". Shortened version of the client log: {{{ ~ % sudo openvpn --cd /etc/openvpn --config /etc/openvpn/profile.conf -v6 [...] Fri Mar 20 16:29:48 2015 us=912819 OpenVPN 2.3.6 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Dec 2 2014 Fri Mar 20 16:29:48 2015 us=912837 library versions: OpenSSL 1.0.2a 19 Mar 2015, LZO 2.09 Fri Mar 20 16:29:48 2015 us=916928 LZO compression initialized Fri Mar 20 16:29:48 2015 us=916959 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1400) Fri Mar 20 16:29:48 2015 us=917049 Control Channel MTU parms [ L:1458 D:138 EF:38 EB:0 ET:0 EL:0 ] Fri Mar 20 16:29:48 2015 us=917106 Socket Buffers: R=[212992->131072] S=[212992->131072] Fri Mar 20 16:29:48 2015 us=917142 Data Channel MTU parms [ L:1458 D:1450 EF:58 EB:135 ET:0 EL:0 AF:3/1 ] Fri Mar 20 16:29:48 2015 us=917174 Local Options String: 'V4,dev-type tun,link-mtu 1458,tun-mtu 1400,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-client' Fri Mar 20 16:29:48 2015 us=917190 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1458,tun-mtu 1400,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-server' Fri Mar 20 16:29:48 2015 us=917212 Local Options hash (VER=V4): '4355902f' Fri Mar 20 16:29:48 2015 us=917226 Expected Remote Options hash (VER=V4): 'fa437c7c' Fri Mar 20 16:29:48 2015 us=917240 UDPv4 link local: [undef] Fri Mar 20 16:29:48 2015 us=917250 UDPv4 link remote: [AF_INET]1.2.3.4:1194 WRFri Mar 20 16:29:48 2015 us=936285 TLS: Initial packet from [AF_INET]1.2.3.4:1194, sid=57104f20 f5298bc8 WWWWRRRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRFri Mar 20 16:29:49 2015 us=120245 VERIFY OK: depth=1, /C=FR/ST=Region/L=City/O=Company/OU=Tech/CN=company_CA/emailAddress=root@company.com Fri Mar 20 16:29:49 2015 us=120396 VERIFY OK: nsCertType=SERVER Fri Mar 20 16:29:49 2015 us=120411 VERIFY X509NAME OK: /C=FR/ST=Region/O=company/OU=Tech/CN=1.2.3.4 Fri Mar 20 16:29:49 2015 us=120419 VERIFY OK: depth=0, /C=FR/ST=Region/O=company/OU=Tech/CN=1.2.3.4 WRWRWRWRWRWWWWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWWWWWWWWWWWWWWWWWFri Mar 20 16:30:48 2015 us=999245 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Fri Mar 20 16:30:48 2015 us=999283 TLS Error: TLS handshake failed Fri Mar 20 16:30:48 2015 us=999487 TCP/UDP: Closing socket Fri Mar 20 16:30:48 2015 us=999525 SIGUSR1[soft,tls-error] received, process restarting Fri Mar 20 16:30:48 2015 us=999537 Restart pause, 2 second(s) }}} The server is running OpenVPN 2.3.2 on IPFire. I don't know what's in the server logs, but IMHO such an error should be reported on the client side anyway. Thanks, Thomas" Schnouki Active Tickets 584 Please add `ifconfig_netbits` environment variable for IPv4 Generic / unclassified OpenVPN 2.3.8 (Community Ed) Feature Wish new 2015-07-29T21:12:15Z 2019-12-05T21:30:45Z "The environment variables passed to {{{--up}}} scripts express the netmask differently for IPv4 and IPv6: for IPv4 you get {{{ ifconfig_local=203.0.113.2 ifconfig_broadcast=203.0.113.255 ifconfig_netmask=255.255.255.0 }}} but for IPv6 you get {{{ ifconfig_ipv6_local=2001:DB80:0001::2 ifconfig_ipv6_netbits=64 }}} The Linux network configuration tool {{{ip}}} wants to be told the netmask in /nn syntax for both IPv4 and IPv6. Calculating a /nn value from a dotted-quad netmask in a shell script is difficult. It would be nice, therefore, if we could have an {{{ifconfig_netbits}}} environment variable for IPv4." zackw Active Tickets 594 HTTPS (SSL) proxy support Generic / unclassified Feature Wish new 2015-08-11T21:58:39Z 2016-03-17T03:29:00Z I'd like to see so-called HTTPS proxy support in OpenVPN. Basically this is usual HTTP proxy with TLS layer above it. This is not standardized and currently supported by Chromium and Firefox only. Since handshake process with this proxy looks like a usual SSL (HTTPS) handshake, adding support would help to bypass OpenVPN protocol blocks in some countries like Turkmenistan and China (probably others too) and it should not be that hard to add because OpenVPN supports usual HTTP (CONNECT) proxy. ValdikSS Active Tickets 536 """There are no TAP-Windows adapters on this system"" after installing Windows 10 build 10049" tap-windows6 OpenVPN 2.3.6 (Community Ed) Bug / Defect jamesyonan new 2015-03-31T17:57:57Z 2021-09-05T22:19:23Z "Hi there, This is my first time reporting a ""bug"" in OpenVPN, and I suspect it may have more to do with a change Microsoft made in Windows, so please forgive me if this post is not appropriate or if there's a better means to report it. OpenVPN is a HUGE help for me and I just want to help in return! OpenVPN has been working fine on Windows 10 Technical Preview until I upgraded to build 10049 this morning. After upgrading to this build, OpenVPN would not connect, log file tail below: {{{ Tue Mar 31 11:45:48 2015 MANAGEMENT: Client disconnected Tue Mar 31 11:45:48 2015 There are no TAP-Windows adapters on this system. You should be able to create a TAP-Windows adapter by going to Start -> All Programs -> TAP-Windows -> Utilities -> Add a new TAP-Windows virtual ethernet adapter. Tue Mar 31 11:45:48 2015 Exiting due to fatal error }}} I ran the batch files to delete / reinstall the TAP adapters, reinstalled OpenVPN, even modified my config file to use dev-tun to locate the TAP adapter by name, but no dice. Using ProcMon to compare to a known working system (Windows 8.1, if that matters), I noticed that as openvpn.exe was enumerating network adapters in {{{ HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318} }}} it querues for a REG_SZ value named ComponentId. On my Windows 10 build 10049, this value was missing. It appears that when this value is missing, it does not proceed to query NetCfgInstanceId, which is why I suspect reports that no TAP adapters were found. I checked my working system (again, Windows 8.1), and ComponentId was set to 'tap0901' (the same as MatchingDeviceId). From the stack trace in ProcMon, it appears that openvpn.exe is directly querying this value (as opposed to calling some Windows API which then queries the value). After I manually added HKLM\System\CurrentControlSet\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}\0017\ComponentId (the 0017 is specific to my system, of course) with REG_SZ value 'tap0901' (no quotes), I was successfully able to connect. I hope this helps and I will gladly provide any information I can if needed. Thank you!!!!!!! Sincerely, Chris Schrimsher " chrisschrimsher Active Tickets 564 openvpn connection stops when network interface is removed Management OpenVPN 2.3.6 (Community Ed) Bug / Defect Samuli Seppänen assigned 2015-06-16T23:15:02Z 2019-11-28T16:16:01Z "Hi https://forums.openvpn.net/topic18973.html I have openvpn 2.3.6 installed on a W8.1 laptop. I use it via the service option, so always on. The config is meant to continually try connecting back to the main office. But when I unplug my usb ethernet oepnvpn crashes, but not the service just the current connection You can see in the lots here {{{ Thu Jun 11 07:17:02 2015 us=5212 NETSH: C:\Windows\system32\netsh.exe interface ipv6 delete address Ethernet 4 2002:ca4a:2000:2017:4000::1021 store=active Thu Jun 11 07:17:02 2015 us=36460 ERROR: netsh command failed: returned error code 1 Thu Jun 11 08:57:28 2015 us=230295 NETSH: command failed Thu Jun 11 08:57:28 2015 us=230295 Exiting due to fatal error }}} This is a bug/problem, as the service doesn't crash so windows can't restart it. Openvpn stops trying to process the config as it crashes. I think it should be restarting, just because it failds to remove the old routes from an old interface shouldn't be the reason it stops working. " alexs_yb Active Tickets 592 Tap-Windows Adapter not work Windows 10 tap-windows6 OpenVPN 2.3.8 (Community Ed) Bug / Defect Samuli Seppänen accepted 2015-08-06T21:58:44Z 2021-01-01T22:18:54Z "No work Windows 10 Tap-Windows Adapter Add ComponentId: tap0901 not fix the problem" hmsgcr Active Tickets 595 Failed to auto startup in Win10 Generic / unclassified OpenVPN 2.2.2 (Community Ed) Bug / Defect Samuli Seppänen assigned 2015-08-13T18:41:38Z 2016-12-29T12:18:12Z "After upgrade from Win 7 to Win 10, OpenVPN fails to do his job. Configurations in windows 7: Installed version was OpenVPN 2.2.2. It was configured in ""Control Panel > Administrative tools > Services"" to Start Automatically on Windows Startup After migration to windows 10, the software version and configurations remained the same, but the connection is no longer established. However, in either ""Services"" (in control panel) and in ""Services"" (in the Task Manager) the system reports it as ""in execution"" and after a ""Restart"" command in ""Services"" the connections is established correctly Latest version does not fix the problem." maverick74 Active Tickets 420 plugin API: allow for temporary failure Generic / unclassified Feature Wish David Sommerseth assigned 2014-06-30T15:16:12Z 2021-11-25T17:09:54Z "I notice in the plugin api that we can only return success and failure, not something like temporary failure (retry later). the idea is that you want auth-retry to be none, because you don't want clients to keep retrying when they are set with wrong passwords. however, when you need maintenance on your ldap server (with the auth-ldap) plugin, or via the verify script, and you turn off the ldap server for a few minutes, reconnects of existing tunnels will fail and exit. i like the plugin api (and the verify script) to be able to return a 3rd state (temporary failure), which still registers as failed, but still allows the authentication to retry after some time, even if the auth-retry is off. This allows for example: maintenance on an authentication server, where clients don't automatically re-authenticate." AL13N Active Tickets 245 Encoding problem when running openvpn on Windows Command Prompt Generic / unclassified OpenVPN git master branch (Community Ed) Bug / Defect Heiko Hund assigned 2012-12-20T17:43:02Z 2022-12-21T16:31:54Z "broken scenario OS: WinXP OpenVPN: 2.3_rc2 Description: I execute openvpn.exe --version on Command Prompt, then any non-english character that I type is misunderstood by the shell. broken scenario 2 OS: WinXP 7 OpenVPN: 2.3_rc2 Description: I execute openvpn.exe --version on Command Prompt, then I type any character followed by a return then the Command Prompt window automatically is closed. working scenario OS: WinXP OpenVPN: 2.2.2 Description: Here, everything works as expected." abacate Active Tickets 434 Config file parser can't handle CR linefeeds Generic / unclassified OpenVPN 2.3.4 (Community Ed) Bug / Defect new 2014-08-19T08:38:39Z 2015-05-28T06:51:48Z "It seems the config file parser can only handle LF linefeeds and fails in mysterious ways if it encounters a CR: * [https://forums.openvpn.net/topic16665.html OpenVPN Server on 2008 R2 - most weird config parse errors] * [ticket:433 TAP from 2.3.4 not working + weird config parse errors as cause]" Samuli Seppänen Active Tickets 495 src/plugins/down-root/down-root.c should not include directly plug-ins / plug-in API OpenVPN git master branch (Community Ed) Bug / Defect Gert Döring accepted 2014-12-29T16:37:57Z 2020-09-09T10:21:51Z "configure script will detect the existence of , if exist, down-root.c will include ith with config.h, if err.h is exist, it should not use err() and warn() from err.h. This bug cause openvpn fail to build on AIX platform with default configure option. us '--disable-plugin-down-root' is a workaround. " bluestonechina Active Tickets 496 src/plugins/down-root/down-root.c should use src/compat/compat-daemon.c when daemon() not exist plug-ins / plug-in API OpenVPN git master branch (Community Ed) Bug / Defect Gert Döring accepted 2014-12-29T16:42:17Z 2020-09-09T10:21:10Z "when daemon() does not exist, down-root.c cannot use daemon() function from src/compat/compat-daemon.c. This cause openvpn build faild on AIX. " bluestonechina Active Tickets 560 HOWTO improvements - chroot locations Documentation Bug / Defect new 2015-06-04T09:19:39Z 2015-06-04T09:19:39Z " The official OpenVPN [[HOWTO]] could need some improvements to avoid bad configurations. On todays Linux systems, there may be security mechanisms (SELinux, apparmor, Tomoyo, etc) which may restrict where chroots can be located. If a wrong location is used, OpenVPN will not work. We cannot and should not have specific guides for any of these security mechanisms - as how they are configured and works is a broad topic. But the default security configurations normally follow fairly standard and defacto specifications. So for example, they will most likely not appreciate chroots in /etc. So I propose we add some information about typical/common directories for chroots which covers the Unix ""spirit"". The goal is to teach users to do the right thing, which hopefully will reduce the amount of support on these topics. If there are similar options in OpenVPN which could be covered by this ticket, feel free to expand this ticket for those options. But don't let it be too broad ;-)" David Sommerseth Active Tickets 530 OpenVPN-GUI Dynamic client FQDN and cryptoapi certificate selection Windows GUI OpenVPN 2.3.5 (Community Ed) Feature Wish Heiko Hund assigned 2015-03-16T16:44:43Z 2015-05-28T08:20:50Z "Hello. I am trying to use OpenVPN-GUI using the CryptoAPI to retrieve the machine's certificate which is working fine (so fine I think it resolves bug 388?). The issue is that the SUBJ: requirement for locating the correct certificate is specific to each system, meaning I cannot use a common ovpn configuration file, or would need to generate it dynamically for each installation. The default for Active Directory Certificate Services is to use the machine FQDN (hostname.AD-domain-name) as the certificate CN for autoenrolled or manually-enrolled computer certificates. I would like OpenVPN-GUI to use information in the registry to compile this FQDN and submit it to the openvpn.exe as a parameter to the CryptoAPICert command for the SUBJ: field, meaning no client-specific changes to a configuration file. this also means the client can work out-the-box more easily for sites that deploy computer certificates in this way (once a valid configuration file is defined). The machine FQDN can be complied by retrieving the following two Windows Registry String values: HKLM/System/CurrentControlSet/services/Tcpip/Parameters: Hostname HKLM/System/CurrentControlSet/services/Tcpip/Parameters: Domain There are NV Domain and NV Hostname parameters also present, but I do not believe they are more functional than the two above: Any disparity between the values of each respective key is likely a highly customised environment not worth supporting in this way. Apologies for not proposing a GUI enhancement myself, but this seems like something a tickbox would achieve in the GUI, with an associated registry key which can be easily controlled by Windows policy. I would propose a directive in the configuration file but this may not be appropriate as it does not apply to non-windows clients." liamdennehy Active Tickets 23 Integrate code security analysis tools into Buildbot Generic / unclassified OpenVPN 2.1.0 / 2.1.1 (Community Ed) TODO (General task list) Samuli Seppänen accepted 2010-07-16T09:34:54Z 2022-12-21T15:56:08Z "In the [http://thread.gmane.org/gmane.network.openvpn.devel/3571 IRC meeting] on 22nd Apr 2010 it was agreed that all patches should be checked with (security) auditing tools such as Valgrind and Coverity. These tools need to be integrated into our Continuous integration server app, Buildbot. " Samuli Seppänen Active Tickets 684 improper process termination Generic / unclassified OpenVPN 2.3.10 (Community Ed) release 2.3.14 Bug / Defect new 2016-05-17T10:23:40Z 2017-09-06T23:31:00Z "sometimes parent does not wait() for child processes once it receives SIGTERM. I'm sending this signal for the process to start fresh and load a new configuration. having this process hang is a major problem in my setup. steps to reproduce (does not happen in 80% of cases): # killall openvpn # ps axww | grep openvpn 3524 ? S 0:00 supervise openvpn_tcp 19122 ? Sl 0:01 /usr/sbin/openvpn --config /etc/openvpn/openvpn-tcp.conf --syslog 19125 ? Z 0:00 [openvpn] 19126 ? Z 0:04 [openvpn] openvpn should completely terminate at this point. instead the master process is still doing a read() from a dead child: # strace -f -s1000 -p 19122 Process 19122 attached with 2 threads [pid 19562] futex(0x80e988160dc, FUTEX_WAIT_PRIVATE, 37, NULL [pid 19122] read(7, # ls -al /proc/19122/fd/7 lrwx------ 1 root root 64 May 17 09:53 /proc/19122/fd/7 -> socket:[1465476] # lsof | grep 1465476 openvpn 19122 openvpn 7u unix 0x0000000000000000 0t0 1465476 P0 type=DGRAM openvpn 19122 19562 openvpn 7u unix 0x0000000000000000 0t0 1465476 P0 type=DGRAM # ps axjf 3513 3524 3493 3493 ? -1 S 0 0:00 | \_ supervise openvpn_tcp 3524 19122 3493 3493 ? -1 Sl 108 0:01 | | \_ /usr/sbin/openvpn --config /etc/openvpn/openvpn-tcp.conf --syslog 19122 19125 3493 3493 ? -1 Z 0 0:00 | | \_ [openvpn] 19122 19126 3493 3493 ? -1 Z 0 0:04 | | \_ [openvpn] versions: # emerge --info Portage 2.2.28 (python 2.7.10-final-0, hardened/linux/amd64/no-multilib, gcc-4.9.3, glibc-2.22-r4, 4.4.8-grsec-i010 x86_64) ================================================================= System uname: Linux-4.4.8-grsec-i010-x86_64-Intel-R-_Core-TM-_i3-2100_CPU_@_3.10GHz-with-gentoo-2.2 KiB Mem: 1015728 total, 160540 free KiB Swap: 524284 total, 523360 free Timestamp of repository gentoo: Tue, 17 May 2016 05:30:01 +0000 # openvpn --version OpenVPN 2.3.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on May 5 2016 library versions: OpenSSL 1.0.2h 3 May 2016, LZO 2.08 Originally developed by James Yonan Copyright (C) 2002-2010 OpenVPN Technologies, Inc. Compile time defines: enable_crypto=yes enable_crypto_ofb_cfb=yes enable_debug=yes enable_def_auth=yes enable_dependency_tracking=no enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=needless enable_fragment=yes enable_http_proxy=yes enable_iproute2=yes enable_libtool_lock=yes enable_lzo=yes enable_lzo_stub=no enable_management=yes enable_multi=yes enable_multihome=yes enable_pam_dlopen=no enable_pedantic=no enable_pf=yes enable_pkcs11=no enable_plugin_auth_pam=no enable_plugin_down_root=no enable_plugins=yes enable_port_share=yes enable_selinux=no enable_server=yes enable_shared=yes enable_shared_with_static_runtimes=no enable_silent_rules=no enable_small=no enable_socks=no enable_ssl=yes enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=no enable_win32_dll=yes enable_x509_alt_username=no with_crypto_library=openssl with_gnu_ld=yes with_mem_check=no with_plugindir=//usr/lib64/openvpn with_sysroot=no ./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --disable-silent-rules --libdir=/usr/lib64 --docdir=/usr/share/doc/openvpn-2.3.10-r1 --with-plugindir=//usr/lib64/openvpn --enable-ssl --enable-crypto --enable-lzo --disable-pkcs11 --enable-plugins --enable-iproute2 --disable-socks --disable-plugin-auth-pam --disable-plugin-down-root --disable-systemd the openvpn configuration does use an external radius plugin. " petrerodan Active Tickets 640 Windows 7 wrong snd/rcv buffer size Generic / unclassified OpenVPN 2.3.8 (Community Ed) release 2.3.14 Bug / Defect reopened 2015-12-15T19:11:04Z 2020-09-15T11:37:41Z "Although the docs and a first look at the source indicate that the default buffer size should be 64k, its 8k in most cases, and sometimes 4k on Windows 7. ( Socket Buffers: R=[8192->8192] S=[8192->8192]) . This has a serious impact on speed for servers that are far away. I work for a vpn provider, this happens on all my machines and measuring from logs that customers send, on all customer machines. This happened for at least the last year, I fixed this long ago by pushing sndbuf and rcvbuf 131072 to the clients. I report this as a bug now because I was sending other bug reports and remembered that I wanted to report this issue some time ago :) Regards Lars " pplars Active Tickets 603 Tunnel latency issues on Windows 7 Networking OpenVPN 2.3.8 (Community Ed) release 2.3.14 Bug / Defect Samuli Seppänen assigned 2015-09-04T02:45:51Z 2019-12-11T15:56:30Z "OpenVPN users on Windows 7 are suffering from high, seemingly ""random"" tunnel latency. The problem can be reproduced very easily by following these steps (make sure that all client traffic is routed through the tunnel): 1. Do a fresh install of Windows 7. 2. Install the Firefox Web browser. 3. Establish a connection to an OpenVPN server (protocol does _not_ matter, both UDP and TCP are affected). 4. Run a ping to any reliable server, I used 8.8.8.8 (google public DNS). 5. Launch the Firefox web browser. Ping will spike multiple times for seemingly no reason. This does not only happen when launching the web browser but also on other events. This effectively renders the tunnel unusuable, downloads will slow down to a crawl until they finally time out, etc. I tried to reproduce this bug on several operating systems and linux distributions using the same config and binaries (Windows 2000, Windows XP, Debian 7, Arch) and didn't notice anything unusual, so it seems that only Windows 7 is affected. I can provide a packet dump if neccesary." JohnDoe123 Active Tickets 384 OpenVPN-GUI : password defaults to RTL (right-to-left) Windows GUI OpenVPN 2.3.2 (Community Ed) release 2.3.14 Bug / Defect Selva Nair assigned 2014-03-30T12:09:03Z 2023-01-07T09:59:14Z "Windows 7 Pro, SP1. OpenVPN GUI v.5 (via openvpn-install-2.3.2-I003-x86_64.exe) My Windows default language is English with Hebrew support. When OpenVPN GUI asks for a password it defaults (or switch) to the alternate language instead of staying in English. This is extra annoying if you have a RTL language such as Hebrew or Arabic installed on your system. It forces the user to switch back to English every time s/he tries to connect." maayant Active Tickets 660 Suggested source Code changes to avoid fragmentation by the network stack when using UDP transport Networking OpenVPN 2.3.10 (Community Ed) release 2.3.14 Bug / Defect Gert Döring assigned 2016-02-05T13:20:56Z 2020-03-18T19:01:01Z "For some time I have been unable to use OpenVPN over an IPv6 network with UDP as the carrier. The problem arises because: a/ Fragmented IPv6 packets generated by the OpenVPN server IPv6 stack are blocked at the client-side firewall. (IPv6 fragment reassembly is required prior to deep packet inspection and the memory resource demand can lead to an undesirable DDoS attack surface). b/ the Internet feeds as implemented by the local ISPs restrict the MTU to 1492 due to the 8 byte PPPoE header (for both native IPv6 and IPv4). c/ OpenVPN creates payload which is too large for the IPv6 encapsulation because it fails to calculate the maximum header space. The problems above are most severe for UDP. The kluge using the hardcoded default mssfix=1450 doesn't work for UDP/IPv6 with MTU of 1492. When using a datagram protocol (UDP) the payload generating program (in this case OpenVPN) expects that the datagrams will be delivered with their implicit boundaries intact. There may be duplicates, missing datagrams, or datagrams out of order but they will still be delivered as single entities with neither concatenation nor fragmentation. TCP on the other hand is a stream protocol. It does not attempt to guarantee that datagrams are delivered as implicit entities; they may be concatenated into one delivery or delivered in parts. But the bytes will be in order with no duplicates and nothing missing. It is very easy for the network stack of the sending device to perform fragmentation of TCP streams as necessary. For IPv4 (but not IPv6) intervening devices may also perform fragmentation and aggregation of TCP data. However there is still an efficiency cost (extra traffic overhead, reassembly for deep packet inspection, extra CPU load on communication equipment) of performing TCP fragmentation and the best solution is to tell the initial transmitting process the MTU of the entire link so that fragmentation is unnecessary. So why not just use TCP as the carrier? TCP transport of TCP payload has some nasty behaviour when delays or packet loss occurs because both layers perform backoff and retransmissions and can they interact leading to TCP session failures. UDP carrier is also better for payloads such as RTP/UDP where the latency from retransmission of lost packets is less desirable than simply skipping the data. I decided to examine the OpenVPN source code to find out where this was failing when using UDP/IPv6 on a link with 1492 MTU and found a number of coding errors. The majority of analysis was performed on OpenVPN 2.3.8 and then applied to and checked against the latest version released (2.3.10). The code tested successfully with IPv6 and IPv4 using the clients - Mavericks/Tunnelblick/OpenVPN 2.3.8, - Windows7/MI GUI/OpenVPn2.3.2, - Android 4.1.2/OpenVPN0.6.44 - IOS 8.2 (IPv4 only) I am not in a position to setup to perform the formal development process so instead I have documented the code changes I made and the theory behind these changes. All analysis and changes were performed using just grep, tcpdump and vi on Centos 6.7. I did not setup any IDE to assist with the process. This document is not very well structured but I thought it better to present it incase any of the developers wishes to make the code changes suggested. The source code changes are listed at the bottom of this information. For the purposes of this analysis other relevant conditions are a/ the transport packets may be either IPv6 or IPv4 but the tests are all with IPv4 payload so that it is easily recognisable and separately routed from the IPv6 transport packets. b/ The OpenVPN clients and OpenVPN server were on separate ISP feeds - ADSL using PPPoE and Australian NBN fibre (GPON) using PPPoA - with Cisco routers at both ends. c/ The OpenVPN server had a single ethernet interface (""on a stick"") and the test web servers were on the same subnet. d/ The local LAN router at the server end (also Cisco) redirected any traffic it received addressed to the OpenVPN clients to the OpenVPN server for tunnelling. e/ ICMP unreachable and ICMPv6 packet-too-big messages were not blocked at any point. f/ Large test packets were generated by downloading JPG and PNG images which could not be compressed further by the OpenVPN compression process. g/ OpenVPN's own fragmentation is not enabled h/ OpenVPN compression is enabled to add the 1 byte header when compression fails. i/ OpenVPN encryption is enabled j/ TUN (tunnel) mode is being used operating at layer 3 - not TAP which is a bridging mode operating at layer 2. k/ Connections used a tls-auth key, a certificate on both client and server and required user authentication thus requiring the additional handshake traffic during session setup. Before detailing the observations and proposed bug fixes there are some points to make about the naming used in the code and a summary of the steps needed to calculate the packet sizes. == Naming == The OpenVPN function and variable naming fails in places to give a clear indication of the purpose of the items named. The main ones relating to this analysis follow. == Bytes versus Octets == The various block sizes transmitted on the network are stored in unsigned 8-bit bytes (uint8_t) so this document uses the term 'bytes' rather than 'octet'. == Tunnel and TUN. == OpenVPN essentially has two traffic interfaces - a raw payload side which communicates with the web server etc. and is commonly referred to as 'TUN' or 'tun' in the source code because it uses the 'tun0' or similar interface. - a tunnelled side where the payload is encrypted, compressed etc and the transported using public IP addresses so it is routable across the Internet. This is logically a 'tunnel' and called the 'link' or 'socket' in the source code. Unfortunately the loose naming convention makes the code unclear in places as to whether the tun side or tunnel side is being referenced.raffic. == struct frame. == 'struct frame' is a control structure within OpenVPN that provides a template for the various processes which build the encapsulated payload. Two modes are supported being 'TUN' and 'TAP'. It is confusing that this structure is called 'frame' because in 'TUN' mode the payload encapsulation is of a layer 3 'packet' and not a layer 2 'frame'. Ideally 'struct frame' should be an object accessed solely by methods or functions but there are direct operations on the attributes/members scattered throughout other modules. One of the code changes proposed requires an extra field (socket_proto) to be added to 'struct frame', populated and later read back. Keeping in the prevalent style of the current code these changes were applied directly to the socket_proto member. Inline macros or functions/methods could be used instead. == Frame, Packet and Datagram size calculations == The narrowest part of the path for payload IP packets which are to be transported through the encrypted tunnel without fragmentation is the tunnel itself. The tunnel's transport packet must fit into the smallest MTU of the layer 2 framing available along the path. If we take a normal ethernet packet on most modern networks and switches the default MTU is 1500. The ethernet frame is normally 14 bytes longer than this making the on-wire frame 1514 bytes (or octets) though on an 802.1Q VLAN trunk it will be 1518 bytes and metro ethernet (Q-on-Q)1522 bytes. In data centres with 1Gbps or faster media ethernet jumbo frames of around 9000 bytes may be used but many managed ISP connections do not support anything above an MTU of 1500 for customer packets. Where PPPoE services, and in some cases PPPoA too, are provided by ISPs on ADSL or GPON (fibre), the PPP overhead needs 8 bytes thus reducing the availble MTU to 1492. Transporting IPv6 over native IPv4 ('6in4', '6to4', '6rd', 'teredo', 'isatap', 'gre') or IPv4 payload over IPv6 will further reduce the MTU. E.g If using IPv6 through an IPv6 over IPv4 tunnel '6-in-4' with IP type 41 to Hurricane Electric needs a further 20 bytes of header so the IPv6 MTU is 1480 (1472 with PPPoE as well). For the purposes of this document I will use 1492 as the Internet MTU with Native IPv4 and IPv6 to match my native test environment. OpenVPN calls this MTU the 'link-mtu'. For testing I set this parameter to 1492 - it can't be any bigger. Normally MTU should be learned and adjusted automatically along the IPv4 or IPv6 path through ICMP unreachable or ICMPv6 packet-too-big messages. In IPv4 routers fragmentation can be implemented at any router along the path unless the DF (Don't Fragment) bit is set in the header. IPv6 does not permit routers to perform fragmentation so it is essential that MTU adjustments can occur at the initial transmitting stack and adjusted automatically by routers sending Packet-Too-Big messages in ICMPv6 Unreachable messages. OpenVPN does not appear to directly support these control messages yet but the network stack on the host computer does. MTU can be reduced further for a particular pair of endpoint addresses. In this case the MTU for the IP address pair is cached in the network stack of the two terminating devices. Because OpenVPN may not yet understand ICMPv6 packet too big messages assume that the link-mtu configuration parameter is set small enough to not require further dynamic adjustment. IPv6 has an explicit lower limit for MTU being 1280 bytes (RFC 2460). Any path which has a smaller MTU cannot support IPv6 packets. With the link MTU in my environment known to be limited to 1492 (as a consequence of the PPPoE header) we can work out the largest raw payload packet that can be transported without fragmentation. == Allow for network IP header == The layer 3 network header will be either IPv4 or IPv6. IPv4 headers are 20 bytes long and under normal circumstances this is constant. IPv6 headers are nominally 40 bytes long but IPv6 has the concept of extension headers which may add extra length. Fortunately this issue is unlikely to impact OpenVPN transport under normal conditions. The most likely extension header is the one used for fragmentation when this is performed by the transmitting network stack. If this headfer is needed the layer 3 fragmentation process performed by the stack will take this extra length into account. The IPv6 fragmentation header adds overhead to both of the resulting fragment packets so that the fragments can be recognised, matched and reassembled at the receiving stack and in intervening packet filters and content inspection devices. Another type of extension header is used for the IPSec encryption built natively into the IPv6 specifications. However with OpenVPN performing its own encryption it is highly unlikely that this header will also be used. It is possible that the extension headers related to 'IP Mobility' may need to be accommodated at some stage but for the moment I will ignore this possibility. So on this basis it is reasonably safe to assume that IPv6 header will be just 40 bytes. OpenVPN obtains the values of 20 for IPv4 and 40 for IPv6 in at least two independent ways. In proto.h structures are defined for the two header types 'struct openvpn_iphdr' and 'struct openvpn_ipv6hdr'. 'sizeof()' is then used to obtain the two values. Separately in socket.h a set of IPv[4|6]_[TCP|UDP]_HEADER_SIZE symbolic constant definitions combine hardcoded numbers using 20 and 40 as the IP header part of the values. Given that in this example we are using IPv6 transport and the MTU is 1492 the maximum space available for the UDP datagram or segment is 1492 - 40 = 1452 bytes. Anything bigger will cause the IPv6 stack to fragment the content and generate two packets - one of 1492 bytes and the other of around 57 bytes == Allow for transport UDP/TCP header == The next header working inwards through the encapsulation is the UDP or TCP header. The UDP header is a constant 8 bytes. TCP header is nominally 20 bytes but like IPv6 headers supports extension headers. Most current common network stacks support TCP Window Scaling by default. This is a negotiated feature during the TCP handshake and provides a mechanism to assist with congestion behaviour. The extension header adds a further 12 bytes to the TCP header for the majority of data segments. Note TCP Windows scaling adds 24 bytes to SYN segments and 20 bytes for SYN/ACK segments but as these segments are otherwise relatively short there is no need to allow explicitly for this. OpenVPN obtains the values of 8 for UDP and 20 for TCP in at least two independent ways. In proto.h structures are defined for the two header types 'struct openvpn_udphdr' and 'struct openvpn_tcphdr'. 'sizeof()' is then used to obtain the two values 8 and 20. There is no allowance for the common TCP Window Sharing extension. In socket.h a set of IPv[4|6]_[TCP|UDP]_HEADER_SIZE symbolic constant definitions combine hardcoded numbers using 8 and 20 as part of the values. Again the TCP Window Sharing extension is not included. In the suggested program changes I have change the 20 to 32 to allow for Windows Scaling when using this source of the values. NB A macro in proto.h also defines a conversion of MTU to MSS for TCP when MSS capping is used on the raw payload. The macro subtracts the sizeof(struct openvpn_iphdr) and sizeof(struct openvpn_tcphdr) from the mtu passed to it - making MSS 40 bytes less than MTU. This is correct for the definition of MSS only when using TCP over IPv4. MSS is defined as the maximum size of the total TCP payload including any TCP extension headers so the value is correct - but only for IPv4. There is no equivalent function for TCP over IPv6 so the program incorrectly uses the IPv4 header size instead. A second macro should be created but have not included this in the suggested program changes. MSS is not the best way to avoid fragmentation - MTU should be used instead as it works for all transported protocols not just TCP. Given that in this example we are using UDP over IPv6 transport and the available UDP datagram space is 1452 the maximum space available for the encrypted message is 1452 - 8 = 1444 bytes. == Other headers == A series of calls fetch the relevant header space required for the current configuration resulting in my case as a total length of 58 bytes. - compression indicator = 1 - The pad cipher block = 16 (same as iv_size) - The cipher kt mode = 16 - hmac header = 20 - ssl flag = 1 - various alignment allowances (No explicit OpenVPN fragmentation is being performed.) Compression is done first. If the result of the compression algorithm makes the data longer then the compression result the latter is ignored and the uncompressed data is used instead. Compression is not effective for pictures etc. which are already highly compressed. It is necessary to signal whether the compression has been applied so a one byte header is added. The worst case will thus be that 1 byte more is needed for the link payload. The exact numbers of bytes needed for all the headers will vary with the configuration but in the test setup a total 58 bytes were needed. On this basis we now know that the maximum space available for the original payload IP packet is 1444 - 58 = 1386 bytes. Note TLS authentication packets used between the OpenVPN program on the server and its peer on the client also requires a maximum size calculation using the 'struct frame' template. This calculation may have a different header size depending on the algorithms being used. The authentication process also needs to handle large packets to share certificate related information so must also calculate a maximum size by subtracting the header demand from the available link MTU. == Restricting the payload IP packet size. == We now know that for the configuration of UDP over IPv6 transport, 1492 MTU Internet connection, SSL, LZO, HMAC and various flags that any initial payload greater than 1386 bytes long is going to result in fragmentation at the link stack. The simplest and most universal way to get this message to the transmitter of the raw payload is to set the MTU on the tunnel (TUN) interface to this value. This is relatively simple as the value can be configured when the TUNx interface is initially created. Everything else will work automatically as long as ICMPv6 Packet-too big messages (and ICMP unreachables for IPv4) can get to, and will be accepted by, the transmitting devices. Whilst there is some reluctance from some network administrators it is poor practice to block ICMP messages of these types. Modern network stacks should be able to resist ICMP attacks. Firewalls have ICMP rate limiting too to kill-off excessive ICMP traffic. Note OpenVPN places the specified MTU for the link into the 'struct frame' structure as link_mtu. However it uses link_mtu_dynamic as the setting to be used to calculate the MTU on the Tunnel interface. link_mtu_dynamic is initially the same as link_mtu BUT may be made smaller due to other factors such as packet too big messages specific to the IP addresses. == Using MSS as a workaround for poor MTU implementations == MTU handling on some operating systems has been poor and the issue exacerbated by network security administrators who block ICMP unreachable/packet-too-big messages which are an essential control process for MTU feedback. However for those implementations where MTU feedback via ICMP proves impossible or unacceptable then MSS (Maximum Segment Size) provides a partial solution applicable for TCP ONLY. MSS settings provide no assistance for other protocols such as large UDP packets (DNS/UDP carrying DNSEC certificates or records used for DKIM), AH and ESP protocols as none of these other layer 4 protocols has any concept of MSS. NOTE by default OpenVPN sets the value of mssfix to 1450. This becomes an upper limit in the payload MTU calculations. In the current code mssfix = 1450 is a workaround for UDP/IPv4 transport only. The setting is too large to support UDP/IPv6. With the suggested code changes that follow the default hard-coded mssfix setting causes an unnecessarily small packet to be created. The fix is to override the hardcoded workaround by setting mssfix value the same as link-mtu and then allowing the calculations to do their job. == Suggested code changes. == The following code changes have been tested on the equipment I have available to me using two native IPv6 Internet connections with both restricted to 1492 byte MTU. IPv6 fragmentation headers are blocked at the client end but ICMP and ICMPv6 packet too big is permitted to support PMTUD. The LANs at both ends run 1500byte MTU. The OpenVPN server is Centos 6.7 with OpenVPN 2.3.10. The clients were Mavericks with Tunnelblick and OpenVPN2.3.8, Windows 7 with OpenVPN 2.3.2 and Android 4.2 with the latest available OpenVPN. IOS 8.2 on an iPad does not appear to work correctly with IPv6 (a different problem) but does work correctly with IPv4 1. Fix HEADERSIZE values in socket.h to allow for Window scaling with TCP (32 bytes instead of 20) Change * * Overhead added to packets by various protocols. */ #define IPv4_UDP_HEADER_SIZE 28 #define IPv4_TCP_HEADER_SIZE 40 #define IPv6_UDP_HEADER_SIZE 48 #define IPv6_TCP_HEADER_SIZE 60 to * * Overhead added to packets by various protocols. */ #define IPv4_UDP_HEADER_SIZE 28 #define IPv4_TCP_HEADER_SIZE '''52''' #define IPv6_UDP_HEADER_SIZE 48 #define IPv6_TCP_HEADER_SIZE '''72''' 2. Fix proto_overhead[] array to match enum proto_num in socket.c. At some stage the proto_enum in socket.h has been modified but the array in socket.c has not. Change const int proto_overhead[] = { /* indexed by PROTO_x */ 0, IPv4_UDP_HEADER_SIZE, /* IPv4 */ IPv4_TCP_HEADER_SIZE, IPv4_TCP_HEADER_SIZE, IPv6_UDP_HEADER_SIZE, /* IPv6 */ IPv6_TCP_HEADER_SIZE, IPv6_TCP_HEADER_SIZE, IPv6_TCP_HEADER_SIZE, }; to const int proto_overhead[] = { /* indexed by PROTO_x */ 0, IPv4_UDP_HEADER_SIZE, /* IPv4 */ IPv4_TCP_HEADER_SIZE, IPv4_TCP_HEADER_SIZE, ''' IPv4_TCP_HEADER_SIZE,''' IPv6_UDP_HEADER_SIZE, /* IPv6 */ IPv6_TCP_HEADER_SIZE, IPv6_TCP_HEADER_SIZE, IPv6_TCP_HEADER_SIZE, }; 3. Modify the 'struct frame' definition in mtu.h so that it can carry the protocol. The reason for this is so that the information is available to the control frame setup when needed. An alternative is to pass the value through quite a few function calls as a parameter. 'struct frame' is used to carry the packet template so it is a fairly natural place to keep track of the layer 3 protocol which does not change after initialisation. Add this additional entry at the bottom of the definition of struct frame in mtu.h struct frame { ... ''' int socket_proto; /* The value is set in initialisation and used for datagram_overhead() calculations */''' }; 4. Modify do_init_frame() in init.c by adding these two lines at the top of the function. The first line ensures that the transport headers (IPv4/IPv6 and TCP/UDP) are included in the calculation instead of relying on the mssfix default value kluge. The second line copies the protocol into the frame structure so we can get at it elsewhere. static void do_init_frame (struct context *c) { ''' frame_add_to_extra_frame(&c->c2.frame, datagram_overhead(c->options.ce.proto) ); (&c->c2.frame)->socket_proto = c->options.ce.proto;''' #ifdef ENABLE_LZO ... 5. Modify the initialisation of the control frame which is copied from the data frame. Modify ssl.c function tls_init_control_channel_frame_parameters(). The first line copies the socket_proto into the control frame and caches a local variable for the second line. The second line uses the protocol to obtain the additional header length. /* inherit link MTU and extra_link from data channel */ frame->link_mtu = data_channel_frame->link_mtu; frame->extra_link = data_channel_frame->extra_link; ''' int socket_proto = frame->socket_proto = data_channel_frame->socket_proto;''' ... frame_add_to_extra_frame (frame, SID_SIZE + sizeof (packet_id_type)); ''' frame_add_to_extra_frame(frame, datagram_overhead(socket_proto));''' ... 6. Modify the configuration files by adding the following commands. 1492 is used for the test as this is the reduced MTU caused by PPPoE encapsulation for ADSL and GPON conections The first line tells OpenVPN about the MTU limitation early enough for it to work properly. The second line is optional It overides the default value of 1450 for mssfix which is not necessary when the calculations are working. If left at 1450. link-mtu-dynamic will be smaller than necessary and cause MSS messages to be sent to the internal systems to reduce their MSS smalled than needed. '''link-mtu 1492''' '''mssfix 1492''' Other potential issues that should be examined • These changes appear to work when only one end of the link has been modified. In tests the clients were running unmodified earlier versions of OpenVPN. The changes do not appear to lead to any compatibility issues. • The startup calculations and MTU adjustment should check that the tunnel interface (e.g. tun0) is not set to a MTU that is less than 1280 which would contravene RFC 2460 for IPv6 minimum MTU. • The effects of enabling fragmentation within OpenVPN has not been checked with the modified code. Ideally enabling fragmentation should remove the need to shrink the MTU on the tunnel interface and instead calculate when to fragment and how many fragments - 2 or possibly 3 - then create roughly equals size packets so that they are treated similarly along the path (order they are delivered, path taken, latency variation) by queueing algorithms on intervening switches and routers. • Need to determine if OpenVPN understands ICMPv6 packet too big messages so that it can adjust the link MTU if necessary. • Need to determine the behaviour where multiple OpenVPN clients are behind a common NAT address and just some of these requires a reduced MTU for the transport. These clients will need to reduce the MTU on the tunnel interface below that required for the other clients on the same tunnel interface. • Need to check that MSS continues to operate for those end devices (e.g. web servers) which are configured to ignore MTU settings from ICMP messages. This, of course, only works for TCP payload. " john7000 Active Tickets 641 OpenVPN 2.3.9 no longer prompts for certificate private key password Generic / unclassified OpenVPN 2.3.8 (Community Ed) release 2.3.15 Bug / Defect David Sommerseth assigned 2015-12-28T15:53:26Z 2021-04-02T14:39:19Z "After upgrading to OpenVPN 2.3.8 from 2.3.5 attempts to start an OpenVPN connection via systemd do not include a prompt for certificate private key password. Instead, only the username and password prompts appear. Executing OpenVPN outside of systemd via command line works correctly and prompts for username, password, and certificate private key password are provided. There are no errors that I can see. Removing --daemon from the unit file results in the prompt for the private key password appearing, but this is not ideal. Adding --askpass to the unit file does not appear to have any effect. Upgraded to 2.3.9 and the issue persists. Additional info: OpenVPN 2.3.9 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Dec 24 2015 Possible Related Tickets: https://community.openvpn.net/openvpn/ticket/618 https://community.openvpn.net/openvpn/ticket/630 Arch Linux Ticket: https://bugs.archlinux.org/task/47481 Steps to reproduce: Launch openvpn via systemd with a private key requiring a password." sgt_b2002 Active Tickets 1361 Unicode BOM in Configuration Files Configuration OpenVPN 2.3.8 (Community Ed) release 2.3.8 Bug / Defect new 2020-12-08T15:17:44Z 2020-12-15T19:47:55Z "The default Windows Notepad safes UTF-8 files with a BOM at the beginning of a text file if there are unicode chars contained, this can result in invalid login data or invalid config files. (https://en.wikipedia.org/wiki/Byte_order_mark) This special char isn't displayed during editing within a lot of editors and finding the cause of this small error can be annoying. The routine to read the files (*.ovpn or 'auth-user-pass'-file) should make use of this BOM identifier." anotherCoward Active Tickets 547 OpenVPN Client conflicts with Cisco AnyConnect Secure Mobility Client on Windows 7 Windows GUI OpenVPN git master branch (Community Ed) release 2.4 Bug / Defect new 2015-05-04T14:13:51Z 2020-03-12T08:14:00Z "Cisco AnyConnect Secure Mobility Client is installed by default on many CORP workstations, it functions as a firewall, Wifi manager, and VPN manager to the corporation's resources. After installing OpenVPN client (used to connect to a different VPN), once I connect to that VPN with OpenVPN client (while connected to a public Wifi using the Cisco AnyConnect application), the OpenVPN client will connect successfully, but immediately after that the Cisco AnyConnect client will drop the connection with the Wifi. The only workaround I have right now is to run OpenVPN client inside a VM machine while the host machine is connected to the Wifi using the Cisco AnyConnect application. This error was observed on: Windows 7 x64 OpenVPN-Client 2.4 Cisco AnyConnect Secure Mobility Client 3.1.04059" Lior Ben-Porat Active Tickets 412 persist-tun and redirect-gateway def1 don't work together when multiple remotes are defined Networking OpenVPN 2.2.2 (Community Ed) release 2.4 Bug / Defect new 2014-05-29T18:36:14Z 2015-06-24T13:05:32Z "Hello, We have several servers for robustness. Our clients use our server as a total VPN, with the redirect-gateway def1 option. We initially thought about using the persist-tun option, so as to improve robustness whenever a server falls down. However, it actually makes things worse, because of the following scenario: - client connects to serveur S1 - client adds route to S1 via the local gateway - client adds 0.0.0.0/1 and 128.0.0.0/1 via the tunnel - S1 falls down - client tries to connect to serveur S2 - it fails because trafic to S2 is routed through the tunnel due to the /1 routes. and it only manages to get back to work after a whole restart. So in the end, we can not use the persist-tun option. A way to make it to work would be to not only add the route to S1 via the local gateway, but also the routes to all other remotes of the configuration, so that one can switch between any of them without having to re-setup the tun device." sthibault Active Tickets 580 DHCP option ROUTERS gets dropped on packets not targetting the OpenVPN client Networking OpenVPN git master branch (Community Ed) release 2.4 Bug / Defect new 2015-07-15T11:10:28Z 2019-11-28T22:38:32Z "Hi, '''Issue:''' If I read this correctly [https://github.com/OpenVPN/openvpn/blob/master/src/openvpn/dhcp.c], OpenVPN simply scratches away the ROUTERS option of DHCP replies, regardless of their destination. The reason for dropping ROUTERS from a DHCP replies makes perfect sense on the VPN client itself, as the new defualt route would actually be inside the VPN link, thus breaking the client's connectivity. However, OpenVPN drops the ROUTERS option even on packets that are not meant for the machine OpenVPN runs on. This behavior is not desirable in my setup : {{{ (tap) OpenVPN Server; DHCP server (10.20.0.1/24) ^ | VPN v (tap) OpenVPN Client; uses DHCP but drops ROUTERS (10.20.0.2/24) (default via ISP GW) | bridge (eth) | RJ45 (eth) Laptop; DHCP client; needs DHCP and ROUTERS option (10.20.0.100/24) Expected: default via 10.20.0.1 Actual: no default route }}} The OpenVPN client bridges its tap interface with an ethernet interface, allowing an other device to magically drop into the VPN. As this client launches its DHCP request, it gets to the OpenVPN server (thanks to the bridge). '''Proposed solution:''' Check the destination of the DHCP reply packet being rewritten: * If the DHCP reply targets the OpenVPN client, then rewrite it as usual * Else, let the packet through without harming it (I know 0 C, so can't help produce a patch)" moviuro Active Tickets 161 GET INST BY VIRT error is too obscure quiet Generic / unclassified OpenVPN 2.0.x (Community Ed) release 2.4 Bug / Defect Samuli Seppänen accepted 2011-09-20T12:12:37Z 2016-08-22T11:48:03Z "This error means that your packets are being dropped: {{{ Tue Sep 20 12:47:53 2011 us=236940 GET INST BY VIRT: 196.12.12.88 [failed] }}} Unfortunately it's very easy to miss. It's not visible at debug level 6 and it's not obvious at all. Perhaps it could be made more severe, and say something like: ""No internal route (iroute) to 196.12.12.88, dropping packet, see http://openvpn.net/index.php/open-source/faq/79-client/317-qmulti-bad-source-address-from-client--packet-droppedq-or-qget-inst-by-virt-failedq.html"" Cheers, Chris." gcc Active Tickets 360 on linux server, --proto udp is ipv4-only Generic / unclassified OpenVPN git master branch (Community Ed) release 2.4 Bug / Defect plaisthos new 2014-01-11T11:18:25Z 2015-09-21T19:16:26Z "On Linux, an UDP server configured with ""--proto udp"" will open an IPv4-only socket (most likely due to getaddrinfo(AI_PASSIVE) returning INADDR_ANY). This is different from other platforms (on FreeBSD, it will open a dual-stack udp46 socket), and violates the expectation that ""proto udp"" should not fix one specific AFI. This does not affect the 2.3 branch (proto udp there was defined to be ipv4-only, and proto udp4 was not available), only git master after commit 8832c6c4cf7d14256. A workaround is available, but we should fix it before 2.4 anyway." Gert Döring Active Tickets 479 Ensure documentation recommends using /var/run for --status files Documentation OpenVPN 2.3.2 (Community Ed) release 2.4 Bug / Defect new 2014-11-13T10:59:39Z 2016-12-13T20:19:01Z "Update: this should be /var/run, not /var/log. See comments. There are several misconfigurations which makes openvpn fail due to --status /etc/openvpn/openvpn-status.log being used instead of /var/log/openvpn-status.log. This happens especially on systems with SELinux enabled, as most SELinux policies does not grant the openvpn process write privileges in /etc. As the --status file is more like a log file (most examples even use .log extension), placing it in /var/log makes more sense and matches most SELinux policies as well. I suggest using /var/log/openvpn-status.log in all examples. {{{ # semanage fcontext --list | grep openvpn-status /var/log/openvpn-status\.log.* regular file system_u:object_r:openvpn_status_t:s0 }}} More reports on this issue in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1002240 https://bugzilla.redhat.com/show_bug.cgi?id=1134967 " David Sommerseth Active Tickets 828 Bridged Windows 7 Connection Not Functional tap-windows6 OpenVPN 2.4.0 (Community Ed) release 2.4.11 Bug / Defect new 2017-01-23T21:24:24Z 2021-04-01T08:39:43Z "I suspect that Microsoft has recently changed the way Windows 7 Ultimate x64 handles bridged connections. Now a bridged TAP and LAN adapter is put in the ""Unidentified Network"" category which results in no Internet connection. openvpn-install-2.4.0-I601.exe was installed." mpfrench Active Tickets 959 Environment variable time_unix not reset if renegenotiation occurs Generic / unclassified OpenVPN 2.4.4 (Community Ed) release 2.4.11 Bug / Defect new 2017-11-17T19:59:40Z 2021-04-01T13:00:07Z "Hello, I've stumbled upon this issue after migrating from OpenVPN 2.3.14 to OpenVPN 2.4.4. Description: time_unix environment variable is set prior to execution of the --client-connect script, and stays present throughout the entire client connection time, and gets freed when the client disconnects the tunnel. When the next client connects, that same variable is then, as it was on the previous client, not present on the first --auth-user-pass-verify script. Problem: The above behavior, the expected one I think, will not occur if a session renegotiation takes place. After a renegotiation occurs, and the client disconnects the tunnel, subsequent clients get the time_unix environment variable filled on the first --auth-user-pass-verify script. Also, the value of that environment value is the same as the one present on the previous client. Steps to reproduce: 1) Connect client: time_unix is not present on --auth-user-pass-verify script 2) Wait for renegotiation 3) Disconnect client 4) Connect client: time_unix is present on --auth-user-pass-verify script OpenVPN 2.4.4 server. Set --reneg-sec to a value low enough not to wait an hour. Thank for you time on this issue. " ruisantos Active Tickets 1283 BSoD on Windows in Bridged Mode Generic / unclassified release 2.4.11 Bug / Defect new 2020-05-20T15:09:42Z 2021-04-06T15:41:40Z "Ref: openvpn-install-2.4.9-I601-Win10.exe Computers - 2 - One AMD based, the other Intel based. Both use the same LAN chip - Realtek RTL-8111 Realtek LAN driver 10.39.212.2020 (latest available from Realtek) OS - Win 10 Pro 10 Version 10.0.18363 Build 18363 I am running an OpenVPN server in bridged mode on Windows 10 Pro on two computers where Windows was freshly installed. I sporadically get a Blue Screen of Death (BSoD) and an automatic Windows restart as shown by the event log. This BSoD event happens whether or not the OpenVPN server is connected to a remote client. I happened to be sitting at the computer console on two such events and observed the BSoD on-screeen message: ""SYSTEM_THREAD_EXCEPTION_NOT_HANDLED BRIDGE.SYS"" It appears that there is a problem with the interaction of Windows BRIDGE.SYS, the Realtek LAN driver, and the OpenVPN TAP driver. However, even updating the LAN driver to the latest version does not solve the problem and I do not know of anything else that is under my control left to do. I have attached the latest memory dump analysis which shows the following key line: PRIMARY_PROBLEM_CLASS: AV_STACKPTR_ERROR_bridge!unknown_function I am not knowledgeable enough to know what this last error indicator is telling us. However, both computers function without BSoDs unless a network bridge is formed. Frankly, it looks to me that there is a design problem with the OpenVPN TAP driver." mpfrench Active Tickets 1313 OCC warnings about cipher and auth mismatch are misleading Generic / unclassified OpenVPN 2.4.9 (Community Ed) release 2.4.11 Bug / Defect new 2020-08-10T09:46:03Z 2021-04-01T08:11:26Z "In a setup where NCP is active, a client might warn in its logfile about cipher mismatch (if it has a different {{{cipher}}} configured than the server), but it is of no consequences because NCP will do the right thing anyway. I think this needs to be fixed - possibly by announcing NCP status in the OCC messages, and ""if I have NCP and the other side has NCP, ignore mismatches in {{{cipher}}} and {{{auth}}}"". Or maybe ""if I am NCP *capable* and the server has NCP *enabled*"" (because 2.4 with --ncp-disable talking to a 2.5 server will still get a proper cipher back)." Gert Döring Active Tickets 1187 http-proxy fails with: Assertion failed at proxy.c:250 (strlen(p->up.username) > 0) Networking OpenVPN 2.4.7 (Community Ed) release 2.4.11 Bug / Defect plaisthos assigned 2019-05-11T12:50:32Z 2023-04-05T12:52:24Z "Hi, http-proxy seems NOT to cache username/password anymore. When it first connects, it is asking for username/password to management-console and successfully connects with this credentials. But when openvpn-client re-connects, it fails with: Assertion failed at proxy.c:250 (strlen(p->up.username) > 0) and the logging does not show that it was asking for username/password again. For me it seems that the client thinks he has still his username/password cached (maybe a flag somewhere) but the memory of username and password is already deleted. My setup is working fine on Version 2.3.18, so there must be a change in http-proxy between 2.3.18 and 2.4.x (I also tested it with 2.4.3, 2.4.4, 2.4.5, same failure) thanks Simu" simu Active Tickets 963 OpenVPN 2.4.4 OpenSSL 1.1.x issues with ECC ciphers (client only) Generic / unclassified OpenVPN 2.4.4 (Community Ed) release 2.4.11 Bug / Defect Steffan Karger accepted 2017-12-01T16:31:23Z 2021-04-01T12:45:37Z "- openvpn 2.4.4 + openssl 1.1.0g compiled from source. - certificates using curve sect571r1 On connect, client hangs, and on server i get: OpenSSL: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher This is only with openssl 1.1 , with 1.0.x it works just fine. After some reading, i saw this change on OpenSSL: *) Change the ECC default curve list to be this, in order: x25519, secp256r1, secp521r1, secp384r1. [Rich Salz] Somehow openssl defaults to x25519 , and my certificates are using sect571r1, and passing ecdh-curve to openvpn does not solve it. What i tried was adding this: SSL_CTX_set1_curves_list(ctx->ctx, ""sect571r1""); in src/openvpn/ssl_openssl.c, on line 271, just under SSL_CTX_set_default_passwd_cb This only happens on the client, it doesn't seem to have anything to do with the server. Maybe someone can implement a proper fix to adapt to openssl 1.1 changes ... Issue can also be seen here: https://github.com/schwabe/ics-openvpn/issues/721 " mke208 Active Tickets 1157 Centos 7, Openvpn not working with Yubikey and pkcs11 OSS OpenVPN Clients OpenVPN 2.4.6 (Community Ed) release 2.4.11 Bug / Defect David Sommerseth assigned 2019-01-25T07:30:16Z 2022-12-22T08:15:29Z "Hi All I think there is a bug with the way Openvpn interacts with pkcs11 on centos 7. I have trawled the sites/forums to see if there is any resolution but there seems to be none. I have attached relevant files for investigation your perusal. I have successfully authenticated my centos 7 (4.19.7-1.el7.elrepo.x86_64) client with a linksys lrt214 router using the openvpn --config /etc/openvpn/client/info.ovpn command. The ovpn file working.ovpn is attached with relevant information. I moved the cert and private key from working.ovpn, to slot 9e on a yubikey5, and replaced them with the following 2 lines in the /etc/openvpn/client/info.ovpn file. pkcs11-id piv_II/PKCS\\x2315\\x20emulated/00000000/REMOVED/04 pkcs11-providers /usr/lib64/opensc-pkcs11.so When now attempting to connect to the router with the yubikey attached the openvpn command returns these last few lines and hangs at the creation of the tun device .The complete log with verb5 is openvpn.output-verb5 Thu Jan 24 15:50:46 2019 us=29344 ROUTE_GATEWAY 172.20.10.1/255.255.255.240 IFACE=wlp2s0 HWADDR=34:41:5d:36:e2:c3 Thu Jan 24 15:50:46 2019 us=29959 TUN/TAP device tun0 opened Thu Jan 24 15:50:46 2019 us=30109 TUN/TAP TX queue length set to 100 Thu Jan 24 15:50:46 2019 us=30181 do_ifconfig, tt->did_ifconfig_ipv6_setup=0 Thu Jan 24 15:50:46 2019 us=30242 /sbin/ip link set dev tun0 up mtu 1500 <- HANGS HERE A successful connection generated by the working.ovpn looks like Tue Jan 22 15:20:55 2019 TUN/TAP device tun0 opened Tue Jan 22 15:20:55 2019 TUN/TAP TX queue length set to 100 Tue Jan 22 15:20:55 2019 do_ifconfig, tt->did_ifconfig_ipv6_setup=0 Tue Jan 22 15:20:55 2019 /sbin/ip link set dev tun0 up mtu 1500 Tue Jan 22 15:20:55 2019 /sbin/ip addr add dev tun0 local 172.32.0.6 peer 172.32.0.5 Tue Jan 22 15:20:55 2019 /sbin/ip route add 10.1.0.0/24 via 172.32.0.5 Tue Jan 22 15:20:55 2019 /sbin/ip route add 172.32.0.0/24 via 172.32.0.5 Tue Jan 22 15:20:55 2019 Initialization Sequence Completed A review of ""ip ad"" for a failed connection shows that the tun is partially created but not in its entirety. 19: tun0: mtu 1500 qdisc noop state DOWN group default qlen 100 link/none Manually creating the ip address and routes does not help. A successful tun looks like 20: tun0: mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100 link/none inet 172.32.0.6 peer 172.32.0.5/32 scope global tun0 valid_lft forever preferred_lft forever inet6 fe80::5280:9a6b:7d5c:e8d7/64 scope link flags 800 valid_lft forever preferred_lft forever I would appreciate if you could advise why this is happening when the yubikey is attached. and whether there is any work-around? Glad to supply more info if required. PS - I have confirmed that the same yubikey with the attached keys/certs works with OpenVPN on windows 10. " BigDog Active Tickets 1254 TAP-Windows Adapter V9 on Windows 7 get Code 52 error Packaging OpenVPN 2.4.8 (Community Ed) release 2.4.11 Bug / Defect Samuli Seppänen assigned 2020-02-18T18:58:35Z 2021-04-01T08:12:21Z "On clean install of Windows Professional ver. 6.1. (build 7601: Service Pack 1) get the Code 52 driver error of TAP-Windows Adapter V9 when installed from [https://swupdate.openvpn.org/community/releases/openvpn-install-2.4.8-I602-Win7.exe openvpn-install-2.4.8-I602-Win7]. Looks like this error is caused by driver signing type(sha256) from openvpn installation package. As mentioned at this [https://forums.openvpn.net/viewtopic.php?f=5&t=28334 forum thread] last working version of tap-driver for clean Windows 7 install is 9.21.2, which has double signing: sha1 and sha256. Versions after 9.21.2 has only sha256 signing, and prior versions are signed with sha1. After installing KB4474419 driver error 52 has been resolved, and TAP driver works fine. KB4474419 introduces SHA-2 code sign support.Looks like this behavior is related to changes in drivers and updates signing of Microsoft products. Additional information can be found at Microsoft support article: [https://support.microsoft.com/en-us/help/4472027/2019-sha-2-code-signing-support-requirement-for-windows-and-wsus 2019 SHA-2 Code Signing Support requirement for Windows and WSUS]. If there is a requirement for update(KB4474419) or other to run OpenVPN on Windows 7, it'll be nice to check this at install time." asantaatnasa Active Tickets 783 --enable-async-push --disable-plugins build failure for multi.c Building / Compiling OpenVPN git master branch (Community Ed) release 2.4.11 Bug / Defect stipa assigned 2016-12-04T03:36:15Z 2021-04-01T13:09:31Z "Given the following configure: {{{ ./configure --enable-async-push --disable-plugins }}} multi.c will fail to compile with the following error: {{{ gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include -I../../include -I../../src/compat -g -O2 -std=c99 -MT multi.o -MD -MP -MF .deps/multi.Tpo -c -o multi.o multi.c multi.c: In function ‘multi_process_post’: multi.c:2215:19: error: ‘struct key_state’ has no member named ‘auth_control_file’ if (ks && ks->auth_control_file && ks->auth_deferred && !was_authenticated) ^ multi.c:2218:70: error: ‘struct key_state’ has no member named ‘auth_control_file’ long watch_descriptor = inotify_add_watch(m->top.c2.inotify_fd, ks->auth_control_file, IN_CLOSE_WRITE | IN_ONESHOT); }}} struct key_state is defined in ssl_common.h, and the missing member auth_control_file is defined as follows: {{{ #ifdef PLUGIN_DEF_AUTH unsigned int auth_control_status; time_t acf_last_mod; char *auth_control_file; #endif }}} This PLUGIN_DEF_AUTH expects --enable-plugins however the code in question: {{{ #if defined(ENABLE_ASYNC_PUSH) && defined(ENABLE_DEF_AUTH) if (ks && ks->auth_control_file && ks->auth_deferred && !was_authenticated) { /* watch acf file */ long watch_descriptor = inotify_add_watch(m->top.c2.inotify_fd, ks->auth_control_file, IN_CLOSE_WRITE | IN_ONESHOT); }}} Checks for ENABLE_DEF_AUTH without attempting to check for plugins being enabled/disable causing this compile to fail. It seems that replacing defined(ENABLE_DEF_AUTH) with defined(PLUGIN_DEF_AUTH) would avoid this." cpwgem Active Tickets 1103 MTU test fails with client v2.4.5 OSS OpenVPN Clients OpenVPN 2.4.5 (Community Ed) release 2.4.11 Bug / Defect plaisthos new 2018-09-11T00:00:11Z 2022-12-22T08:32:47Z "Our wireless community uses OpenVPN. In order to discover MTU problems, we use {{{--mtu-test}}} for determining the MTU size. This worked well for years with various combinations of client and server versions (e.g. 2.2 and 2.3). Currently we experience problems with a client v2.4.5-3 (part of OpenWrt v18.06). It fails to run the MTU test against any available server version (2.2, 2.3, 2.4). Other OpenVPN clients (e.g. 2.3) work well with all server versions. The client version 2.4.5 shows the following behaviour during the MTU test: * an inactivity timeout (based on the {{{keepalive}}} setting of the server) is triggered: {{{[example.org] Inactivity timeout (--ping-restart), restarting}}} * after prolonging the {{{keepalive}}} option from {{{10 60}}} to {{{60 400}}}, the MTU test fails on the client with the following error message: {{{failed to empirically measure MTU (requires OpenVPN 1.5 or higher at other end of connection).}}} * the server log does not exhibit any warnings or other messages Thus there seem to be two issues that did not happen with older client versions: * the client fails to recognize keepalive-pings during the MTU test * the client fails to conclude the MTU test even with a prolonged keepalive timeout All tests were conducted with IPv4 as well as IPv6. I would appreciate hints for debugging this issue. Thank you!" sumpfralle Active Tickets 1073 Linux: VPN is unavailable and connection does not terminate Networking OpenVPN 2.4.4 (Community Ed) release 2.4.4 Bug / Defect David Sommerseth assigned 2018-06-30T19:23:52Z 2018-08-04T02:59:04Z "After some time, the connection is broken. «Connection» isn't automatically restored and after reconnecting to the VPN server too. Connection to the VPN server (during reconnection) occurs, but the network is unavailable. === Requirements Have a VPN connection in network-manager-openvpn (plug-in for network manager). === Steps to reproduce * Connect to the VPN-network (in my case, it happens automatically and IPv4/IPv6 are configured to use resources on the network). * After some time (from 2 to 4 hours), the VPN connection stops working, but we remain connected to it (!). * Reconnect manually VPN. === Observed Behavior Connection is not lost. === Expected Behavior VPN does not work, and reconnection does not help. === How to fix it * Disconnect the WiFi connection and reconnect to the WiFi * Connect to the VPN (I have it automatically) === Environment * OpenVPN 2.4.4ubuntu1, latest from Ubuntu repository Logs in systemlog: {{{ $ grep VPN /var/log/syslog Jun 30 13:32:06 emerald NetworkManager[587]: [1530354726.8280] vpn-connection[0x563f19fa0110,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",4:(tun0)]: Data: Static Route: 192.168.228.0/22 Next Hop: 0.0.0.0 Jun 30 13:32:06 emerald NetworkManager[587]: [1530354726.8281] vpn-connection[0x563f19fa0110,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",4:(tun0)]: Data: Internal DNS: 74.82.42.42 Jun 30 13:32:06 emerald NetworkManager[587]: [1530354726.8281] vpn-connection[0x563f19fa0110,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",4:(tun0)]: Data: Internal DNS: 77.88.8.8 Jun 30 13:32:06 emerald NetworkManager[587]: [1530354726.8281] vpn-connection[0x563f19fa0110,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",4:(tun0)]: Data: DNS Domain: '(none)' Jun 30 13:32:06 emerald NetworkManager[587]: [1530354726.8281] vpn-connection[0x563f19fa0110,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",4:(tun0)]: Data: IPv6 configuration: Jun 30 13:32:06 emerald NetworkManager[587]: [1530354726.8282] vpn-connection[0x563f19fa0110,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",4:(tun0)]: Data: Internal Address: 2a00:1838:30:7110::12f2 Jun 30 13:32:06 emerald NetworkManager[587]: [1530354726.8282] vpn-connection[0x563f19fa0110,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",4:(tun0)]: Data: Internal Prefix: 112 Jun 30 13:32:06 emerald NetworkManager[587]: [1530354726.8282] vpn-connection[0x563f19fa0110,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",4:(tun0)]: Data: Internal Point-to-Point Address: 2a00:1838:30:7110::1 Jun 30 13:32:06 emerald NetworkManager[587]: [1530354726.8283] vpn-connection[0x563f19fa0110,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",4:(tun0)]: Data: Static Route: 2a00:1838:36:67::3d86/64 Next Hop: 2a00:1838:30:7110::1 Jun 30 13:32:06 emerald NetworkManager[587]: [1530354726.8283] vpn-connection[0x563f19fa0110,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",4:(tun0)]: Data: Static Route: 2a00:1838:35:80::8432/64 Next Hop: 2a00:1838:30:7110::1 Jun 30 13:32:06 emerald NetworkManager[587]: [1530354726.8283] vpn-connection[0x563f19fa0110,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",4:(tun0)]: Data: Static Route: 2001:678:384::/48 Next Hop: 2a00:1838:30:7110::1 Jun 30 13:32:06 emerald NetworkManager[587]: [1530354726.8284] vpn-connection[0x563f19fa0110,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",4:(tun0)]: Data: Static Route: 2620:10f:d000::/44 Next Hop: 2a00:1838:30:7110::1 Jun 30 13:32:06 emerald NetworkManager[587]: [1530354726.8284] vpn-connection[0x563f19fa0110,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",4:(tun0)]: Data: Static Route: 2a02:6b8::/32 Next Hop: 2a00:1838:30:7110::1 Jun 30 13:32:06 emerald NetworkManager[587]: [1530354726.8284] vpn-connection[0x563f19fa0110,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",4:(tun0)]: Data: Static Route: 2a02:5180::/32 Next Hop: 2a00:1838:30:7110::1 Jun 30 13:32:06 emerald NetworkManager[587]: [1530354726.8285] vpn-connection[0x563f19fa0110,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",4:(tun0)]: Data: Static Route: 2a00:1148::/32 Next Hop: 2a00:1838:30:7110::1 Jun 30 13:32:06 emerald NetworkManager[587]: [1530354726.8285] vpn-connection[0x563f19fa0110,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",4:(tun0)]: Data: Static Route: 2a00:a300::/32 Next Hop: 2a00:1838:30:7110::1 Jun 30 13:32:06 emerald NetworkManager[587]: [1530354726.8285] vpn-connection[0x563f19fa0110,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",4:(tun0)]: Data: Static Route: 2a00:b4c0::/32 Next Hop: 2a00:1838:30:7110::1 Jun 30 13:32:06 emerald NetworkManager[587]: [1530354726.8286] vpn-connection[0x563f19fa0110,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",4:(tun0)]: Data: Static Route: 2a04:4b40::/29 Next Hop: 2a00:1838:30:7110::1 Jun 30 13:32:06 emerald NetworkManager[587]: [1530354726.8286] vpn-connection[0x563f19fa0110,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",4:(tun0)]: Data: Static Route: 2a00:1838:30:7110::12f2/128 Next Hop: :: Jun 30 13:32:06 emerald NetworkManager[587]: [1530354726.8286] vpn-connection[0x563f19fa0110,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",4:(tun0)]: Data: Static Route: 2a00:1838:30:7110::1/128 Next Hop: :: Jun 30 13:32:06 emerald NetworkManager[587]: [1530354726.8287] vpn-connection[0x563f19fa0110,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",4:(tun0)]: Data: DNS Domain: '(none)' Jun 30 13:32:06 emerald NetworkManager[587]: [1530354726.8288] vpn-connection[0x563f19fa0110,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",4:(tun0)]: VPN plugin: state changed: started (4) Jun 30 13:32:06 emerald NetworkManager[587]: [1530354726.8442] vpn-connection[0x563f19fa0110,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",4:(tun0)]: VPN connection: (IP Config Get) complete Jun 30 20:33:43 emerald NetworkManager[587]: [1530380023.0278] vpn-connection[0x563f19fa0110,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",0]: VPN plugin: state changed: stopping (5) Jun 30 20:33:43 emerald NetworkManager[587]: [1530380023.4267] vpn-connection[0x563f19fa0110,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",0]: VPN plugin: state changed: stopped (6) Jun 30 20:33:46 emerald NetworkManager[587]: [1530380026.1654] vpn-connection[0x563f19fa0310,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",0]: Started the VPN service, PID 8411 Jun 30 20:33:46 emerald NetworkManager[587]: [1530380026.2005] vpn-connection[0x563f19fa0310,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",0]: Saw the service appear; activating connection Jun 30 20:33:46 emerald NetworkManager[587]: [1530380026.2568] vpn-connection[0x563f19fa0310,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",0]: VPN plugin: state changed: starting (3) Jun 30 20:33:46 emerald NetworkManager[587]: [1530380026.2579] vpn-connection[0x563f19fa0310,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",0]: VPN connection: (ConnectInteractive) reply received Jun 30 20:33:46 emerald nm-openvpn[8415]: OpenVPN 2.4.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 10 2018 Jun 30 20:33:55 emerald NetworkManager[587]: [1530380035.1014] vpn-connection[0x563f19fa0310,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",0]: VPN connection: (IP Config Get) reply received. Jun 30 20:33:55 emerald NetworkManager[587]: [1530380035.1108] vpn-connection[0x563f19fa0310,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",5:(tun0)]: VPN connection: (IP4 Config Get) reply received Jun 30 20:33:55 emerald NetworkManager[587]: [1530380035.1227] vpn-connection[0x563f19fa0310,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",5:(tun0)]: VPN connection: (IP6 Config Get) reply received Jun 30 20:33:55 emerald NetworkManager[587]: [1530380035.1246] vpn-connection[0x563f19fa0310,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",5:(tun0)]: Data: VPN Gateway: 94.242.59.156 Jun 30 20:33:55 emerald NetworkManager[587]: [1530380035.1247] vpn-connection[0x563f19fa0310,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",5:(tun0)]: Data: Tunnel Device: ""tun0"" Jun 30 20:33:55 emerald NetworkManager[587]: [1530380035.1247] vpn-connection[0x563f19fa0310,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",5:(tun0)]: Data: IPv4 configuration: Jun 30 20:33:55 emerald NetworkManager[587]: [1530380035.1248] vpn-connection[0x563f19fa0310,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",5:(tun0)]: Data: Internal Gateway: 192.168.228.1 Jun 30 20:33:55 emerald NetworkManager[587]: [1530380035.1248] vpn-connection[0x563f19fa0310,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",5:(tun0)]: Data: Internal Address: 192.168.228.90 Jun 30 20:33:55 emerald NetworkManager[587]: [1530380035.1248] vpn-connection[0x563f19fa0310,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",5:(tun0)]: Data: Internal Prefix: 22 Jun 30 20:33:55 emerald NetworkManager[587]: [1530380035.1249] vpn-connection[0x563f19fa0310,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",5:(tun0)]: Data: Internal Point-to-Point Address: 192.168.228.90 Jun 30 20:33:55 emerald NetworkManager[587]: [1530380035.1249] vpn-connection[0x563f19fa0310,0f21dc01-4103-4a84-a3f9-73f70e6478fc,""VK VPN"",5:(tun0)]: Data: Static Route: 74.82.42.42/32 Next Hop: 192.168.228.1 }}} " sakikoman Active Tickets 930 Inconsistent tun-mtu calculated between client and server Networking OpenVPN 2.4.3 (Community Ed) release 2.5.3 Bug / Defect new 2017-08-26T18:12:10Z 2021-04-01T12:49:39Z "I have a '''Linux server''' (QNAP NAS) and a '''Windows 10 client''' both running OpenVPN 2.4.3 with subnet topology. The server is connected via fiber and the cilent via ADSL (PPP). Link MTU is 1492 bytes. Therefore I set ''link-mtu'' to 1464. Then a value of tun-mtu is calculated by OpenVPN and applied to the tun interface on Linux while this needs to be done manually on Windows. I wrote an up script that sets the MTU associated with TAP-Windows interface. On Linux (server), ''tun-mtu'' set with ifconfig and passed to the up script (I checked) is the same : 1342. On Windows (client) '''two values coexist''': {{{ Sat Aug 26 19:14:37 2017 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1342) }}} here computed ''tun-mtu'' appears to be 1342 (same value applied by OpenVPN on server side) while 1411 (second argument) is passed to the ''up'' script: {{{ Sat Aug 26 19:14:39 2017 set-mtu.bat OpenVPN 1411 1464 10.31.0.2 255.255.255.0 init }}} However by ping testing from the client with no MTU constraints on TAP-Windows (MTU=1500) and ""do not fragment"" flag set, __1411 seems to be the right working limit__: request goes through the tunnel and response comes back properly fragmented." toine512 Active Tickets 1149 ssl_verify_openssl.c: missing CRL errors cause omission of verify_cert() routine Certificates OpenVPN git master branch (Community Ed) release 2.5.3 Bug / Defect new 2018-12-13T12:49:27Z 2021-04-01T07:51:56Z "In ssl_verify_openssl.c, line 80: /* Log and ignore missing CRL errors */ If certificate error is X509_V_ERR_UNABLE_TO_GET_CRL, which is considered here as warning only, this IF branch performs: ret = 1; goto cleanup; ... causing omission of the subsequent verify_cert() (line 103) procedure." sdl Active Tickets 1310 --tls-crypt-v2-verify causes incorrect client connection status (Potential DDoS) Generic / unclassified release 2.5.3 Bug / Defect new 2020-07-29T17:56:59Z 2021-05-10T22:38:09Z "**Notice**: `--max-clients n` is not required. `--tls-crypt-v2-verify` is the root cause. It was simply that I found it when testing with `--max-clients` When using `--max-clients n` with `--tls-crypt-v2-verify`, openvpn treats a failed connection from a client as a connected client until `Inactivity timeout (--ping-restart)` of the failed connection. This can lead to a potential DDOS situation. **Example 1**: `--max-clients 2` plus `--tls-crypt-v2-verify`: A standard server and three standard clients tying to connect. Two of the clients have incorrect credentials to complete the connection. This example uses one valid certificate; one client which has been ''disabled'' by `--tls-crypt-v2-verify` script and one revoked certificate, which is also rejected by `--tls-crypt-v2-verify` script. If the two failing clients attempt to connect before the valid client then the valid client will not be allowed to connect. The error in the server log is: `MULTI: new incoming connection would exceed maximum number of clients (2)` The potential **DDOS** situation: A malicious client can swamp the server with connection attempts by using `--connect-retry 1 2` and multiple client instances. On a previous run I allowed the malicious clients to successfully block the valid client for over 30 minutes. Another run, made after drafting this report, had two clients block the third for ~20 minutes. Mitigating actions available: Do not use `--max-clients` and `--tls-crypt-v2-verify` in the same server config. **Example 2**: Connections filtered by x509 code for revoked certificates and `--client-config-dir` file using `--disable`: Using the same standard server but without using `--tls-crypt-v2-verify`, a revoked client certificate attempting a connection is not listed as connected but will continue to attempt connecting, indefinitely. A client which is disabled via a `--client-config-dir` file `--disable` option is forcibly shut down by `SIGTERM[soft,auth-failure] received, process exiting`. Thus, this is not an issue for this server. **Example 1 - Server Log snippets:** Server port is 10127 (management port 12701) Client c05 is valid from port 12705 Client c06 is revoked from port 12706 Client c08 is disabled from port 12708 **Initialization & first malicious client, first connection attempt:** {{{ 2020-07-29 15:17:14 us=112930 Initialization Sequence Completed 2020-07-29 15:17:16 us=204704 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:12701 2020-07-29 15:17:20 us=38287 MANAGEMENT: CMD 'status 2' 2020-07-29 15:17:28 us=481597 Control Channel: using tls-crypt-v2 key 2020-07-29 15:17:28 us=481675 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key 2020-07-29 15:17:28 us=481699 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication 2020-07-29 15:17:28 us=481716 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key 2020-07-29 15:17:28 us=481730 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication 2020-07-29 15:17:28 us=481747 MULTI: multi_create_instance called 2020-07-29 15:17:28 us=481786 127.0.0.1:12708 Re-using SSL/TLS context 2020-07-29 15:17:28 us=481825 127.0.0.1:12708 tls-crypt-v2 server key: Cipher 'AES-256-CTR' initialized with 256 bit key 2020-07-29 15:17:28 us=481843 127.0.0.1:12708 tls-crypt-v2 server key: Using 256 bit message hash 'SHA256' for HMAC authentication 2020-07-29 15:17:28 us=481938 127.0.0.1:12708 Control Channel MTU parms [ L:1621 D:1212 EF:38 EB:0 ET:0 EL:3 ] 2020-07-29 15:17:28 us=481951 127.0.0.1:12708 Data Channel MTU parms [ L:1621 D:1450 EF:121 EB:406 ET:0 EL:3 ] 2020-07-29 15:17:28 us=481980 127.0.0.1:12708 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server' 2020-07-29 15:17:28 us=481991 127.0.0.1:12708 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client' 2020-07-29 15:17:28 us=482020 127.0.0.1:12708 TLS: Initial packet from [AF_INET]127.0.0.1:12708, sid=d3d74946 b95f0e8c 2020-07-29 15:17:28 us=482031 127.0.0.1:12708 Control Channel: using tls-crypt-v2 key 2020-07-29 15:17:28 us=482050 127.0.0.1:12708 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key 2020-07-29 15:17:28 us=482065 127.0.0.1:12708 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication 2020-07-29 15:17:28 us=482076 127.0.0.1:12708 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key 2020-07-29 15:17:28 us=482092 127.0.0.1:12708 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication * TLS-crypt-v2-verify (index) ==> easytls OK ==> custom_group tincantech OK ==> Key age 0 days OK ==> identity OK ==> Client is disabled c08 2020-07-29 15:17:28 us=493190 127.0.0.1:12708 WARNING: Failed running command (--tls-crypt-v2-verify): external program exited with error status: 2 2020-07-29 15:17:28 us=493309 127.0.0.1:12708 TLS CRYPT V2 VERIFY SCRIPT ERROR 2020-07-29 15:17:28 us=493339 127.0.0.1:12708 TLS Error: can not extract tls-crypt-v2 client key from [AF_INET]127.0.0.1:12708 }}} **Second malicious client, first connection attempt:** {{{ 2020-07-29 15:17:33 us=600278 127.0.0.1:12706 TLS: Initial packet from [AF_INET]127.0.0.1:12706, sid=05eb2908 bf922bd9 2020-07-29 15:17:33 us=600289 127.0.0.1:12706 Control Channel: using tls-crypt-v2 key 2020-07-29 15:17:33 us=600307 127.0.0.1:12706 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key 2020-07-29 15:17:33 us=600322 127.0.0.1:12706 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication 2020-07-29 15:17:33 us=600334 127.0.0.1:12706 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key 2020-07-29 15:17:33 us=600348 127.0.0.1:12706 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication * TLS-crypt-v2-verify (index) ==> easytls OK ==> custom_group tincantech OK ==> Key age 0 days OK ==> identity OK ==> Enabled OK ==> Client certificate is revoked: AEABDB92FE2CCF8A9973EF10E32DCAE2 c06 2020-07-29 15:17:33 us=616040 127.0.0.1:12706 WARNING: Failed running command (--tls-crypt-v2-verify): external program exited with error status: 1 2020-07-29 15:17:33 us=616291 127.0.0.1:12706 TLS CRYPT V2 VERIFY SCRIPT ERROR 2020-07-29 15:17:33 us=616344 127.0.0.1:12706 TLS Error: can not extract tls-crypt-v2 client key from [AF_INET]127.0.0.1:12706 }}} **First connection attempt from valid client:** {{{ 2020-07-29 15:17:37 us=949072 Control Channel: using tls-crypt-v2 key 2020-07-29 15:17:37 us=949135 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key 2020-07-29 15:17:37 us=949169 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication 2020-07-29 15:17:37 us=949190 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key 2020-07-29 15:17:37 us=949212 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication 2020-07-29 15:17:37 us=949237 MULTI: multi_create_instance called 2020-07-29 15:17:37 us=949285 127.0.0.1:12705 Re-using SSL/TLS context 2020-07-29 15:17:37 us=949322 127.0.0.1:12705 tls-crypt-v2 server key: Cipher 'AES-256-CTR' initialized with 256 bit key 2020-07-29 15:17:37 us=949340 127.0.0.1:12705 tls-crypt-v2 server key: Using 256 bit message hash 'SHA256' for HMAC authentication 2020-07-29 15:17:37 us=949434 127.0.0.1:12705 Control Channel MTU parms [ L:1621 D:1212 EF:38 EB:0 ET:0 EL:3 ] 2020-07-29 15:17:37 us=949449 127.0.0.1:12705 Data Channel MTU parms [ L:1621 D:1450 EF:121 EB:406 ET:0 EL:3 ] 2020-07-29 15:17:37 us=949479 127.0.0.1:12705 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server' 2020-07-29 15:17:37 us=949491 127.0.0.1:12705 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client' 2020-07-29 15:17:37 us=949503 127.0.0.1:12705 MULTI: new incoming connection would exceed maximum number of clients (2) 2020-07-29 15:17:39 us=33526 Control Channel: using tls-crypt-v2 key 2020-07-29 15:17:39 us=33607 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key 2020-07-29 15:17:39 us=33631 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication 2020-07-29 15:17:39 us=33647 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key 2020-07-29 15:17:39 us=33665 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication 2020-07-29 15:17:39 us=33685 MULTI: multi_create_instance called 2020-07-29 15:17:39 us=33721 127.0.0.1:12705 Re-using SSL/TLS context 2020-07-29 15:17:39 us=33751 127.0.0.1:12705 tls-crypt-v2 server key: Cipher 'AES-256-CTR' initialized with 256 bit key 2020-07-29 15:17:39 us=33769 127.0.0.1:12705 tls-crypt-v2 server key: Using 256 bit message hash 'SHA256' for HMAC authentication 2020-07-29 15:17:39 us=33835 127.0.0.1:12705 Control Channel MTU parms [ L:1621 D:1212 EF:38 EB:0 ET:0 EL:3 ] 2020-07-29 15:17:39 us=33852 127.0.0.1:12705 Data Channel MTU parms [ L:1621 D:1450 EF:121 EB:406 ET:0 EL:3 ] 2020-07-29 15:17:39 us=33890 127.0.0.1:12705 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server' 2020-07-29 15:17:39 us=33903 127.0.0.1:12705 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client' 2020-07-29 15:17:39 us=33920 127.0.0.1:12705 MULTI: new incoming connection would exceed maximum number of clients (2) }}} **After killing the malicious clients:** {{{ Last failed attempt from valid client .. 2020-07-29 15:21:22 us=425693 127.0.0.1:12705 MULTI: new incoming connection would exceed maximum number of clients (2) Clients were killed ~30 seconds ago .. 2020-07-29 15:21:39 us=261289 127.0.0.1:12706 [UNDEF] Inactivity timeout (--ping-restart), restarting 2020-07-29 15:21:39 us=261394 127.0.0.1:12706 SIGUSR1[soft,ping-restart] received, client-instance restarting 2020-07-29 15:21:44 us=152170 127.0.0.1:12708 [UNDEF] Inactivity timeout (--ping-restart), restarting 2020-07-29 15:21:44 us=152272 127.0.0.1:12708 SIGUSR1[soft,ping-restart] received, client-instance restarting 2020-07-29 15:21:57 us=671333 Control Channel: using tls-crypt-v2 key 2020-07-29 15:21:57 us=671437 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key 2020-07-29 15:21:57 us=671482 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication 2020-07-29 15:21:57 us=671509 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key 2020-07-29 15:21:57 us=671547 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication 2020-07-29 15:21:57 us=671590 MULTI: multi_create_instance called 2020-07-29 15:21:57 us=671683 127.0.0.1:12705 Re-using SSL/TLS context 2020-07-29 15:21:57 us=671786 127.0.0.1:12705 tls-crypt-v2 server key: Cipher 'AES-256-CTR' initialized with 256 bit key 2020-07-29 15:21:57 us=671820 127.0.0.1:12705 tls-crypt-v2 server key: Using 256 bit message hash 'SHA256' for HMAC authentication 2020-07-29 15:21:57 us=671951 127.0.0.1:12705 Control Channel MTU parms [ L:1621 D:1212 EF:38 EB:0 ET:0 EL:3 ] 2020-07-29 15:21:57 us=671982 127.0.0.1:12705 Data Channel MTU parms [ L:1621 D:1450 EF:121 EB:406 ET:0 EL:3 ] 2020-07-29 15:21:57 us=672051 127.0.0.1:12705 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server' 2020-07-29 15:21:57 us=672074 127.0.0.1:12705 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client' 2020-07-29 15:21:57 us=672135 127.0.0.1:12705 **TLS: Initial packet from** [AF_INET]127.0.0.1:127**05**, sid=b9203aa7 18a979f2 2020-07-29 15:21:57 us=672159 127.0.0.1:12705 Control Channel: using tls-crypt-v2 key 2020-07-29 15:21:57 us=672204 127.0.0.1:12705 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key 2020-07-29 15:21:57 us=672236 127.0.0.1:12705 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication 2020-07-29 15:21:57 us=672260 127.0.0.1:12705 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key 2020-07-29 15:21:57 us=672288 127.0.0.1:12705 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication 2020-07-29 15:21:57 us=687208 127.0.0.1:12705 TLS CRYPT V2 VERIFY SCRIPT OK 2020-07-29 15:21:57 us=700779 127.0.0.1:12705 VERIFY OK: depth=1, CN=ChangeMe 2020-07-29 15:21:57 us=700942 127.0.0.1:12705 VERIFY OK: depth=0, CN=c05 2020-07-29 15:21:57 us=701394 127.0.0.1:12705 peer info: IV_VER=2.5_git 2020-07-29 15:21:57 us=701439 127.0.0.1:12705 peer info: IV_PLAT=linux 2020-07-29 15:21:57 us=701456 127.0.0.1:12705 peer info: IV_PROTO=6 2020-07-29 15:21:57 us=701472 127.0.0.1:12705 peer info: IV_NCP=2 2020-07-29 15:21:57 us=701488 127.0.0.1:12705 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM 2020-07-29 15:21:57 us=701503 127.0.0.1:12705 peer info: IV_LZ4=1 2020-07-29 15:21:57 us=701518 127.0.0.1:12705 peer info: IV_LZ4v2=1 2020-07-29 15:21:57 us=701533 127.0.0.1:12705 peer info: IV_LZO=1 2020-07-29 15:21:57 us=701549 127.0.0.1:12705 peer info: IV_COMP_STUB=1 2020-07-29 15:21:57 us=701568 127.0.0.1:12705 peer info: IV_COMP_STUBv2=1 2020-07-29 15:21:57 us=701595 127.0.0.1:12705 peer info: IV_TCPNL=1 2020-07-29 15:21:57 us=701609 127.0.0.1:12705 peer info: IV_HWADDR=24:b6:fd:31:bc:ca 2020-07-29 15:21:57 us=701625 127.0.0.1:12705 peer info: IV_SSL=OpenSSL_1.1.1__11_Sep_2018 2020-07-29 15:21:57 us=701638 127.0.0.1:12705 peer info: UV_LONG_STRING=012345678-1-2345678-2-2345678-3-2345678-4-2345678-5-2345678-6-234 2020-07-29 15:21:57 us=702105 127.0.0.1:12705 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bit RSA 2020-07-29 15:21:57 us=702161 127.0.0.1:12705 [c05] Peer Connection Initiated with [AF_INET]127.0.0.1:12705 2020-07-29 15:21:57 us=702196 c05/127.0.0.1:12705 MULTI_sva: pool returned IPv4=10.127.121.6, IPv6=(Not enabled) 2020-07-29 15:21:57 us=702248 c05/127.0.0.1:12705 MULTI: Learn: 10.127.121.6 -> c05/127.0.0.1:12705 2020-07-29 15:21:57 us=702271 c05/127.0.0.1:12705 MULTI: primary virtual IP for c05/127.0.0.1:12705: 10.127.121.6 2020-07-29 15:21:57 us=702310 c05/127.0.0.1:12705 Data Channel: using negotiated cipher 'AES-256-GCM' 2020-07-29 15:21:57 us=702341 c05/127.0.0.1:12705 Data Channel MTU parms [ L:1549 D:1450 EF:49 EB:406 ET:0 EL:3 ] 2020-07-29 15:21:57 us=702455 c05/127.0.0.1:12705 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key 2020-07-29 15:21:57 us=702483 c05/127.0.0.1:12705 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key 2020-07-29 15:21:57 us=702538 c05/127.0.0.1:12705 SENT CONTROL [c05]: 'PUSH_REPLY,explicit-exit-notify 3,route 10.127.121.1,topology net30,ping 5,ping-restart 30,ifconfig 10.127.121.6 10.127.121.5,peer-id 0,cipher AES-256-GCM' (status=1) 2020-07-29 15:23:23 us=459454 c05/127.0.0.1:12705 SIGTERM[soft,remote-exit] received, client-instance exiting ^C2020-07-29 15:24:30 us=118164 event_wait : Interrupted system call (code=4) 2020-07-29 15:24:30 us=118331 TCP/UDP: Closing socket 2020-07-29 15:24:30 us=118400 net_route_v4_del: 10.127.121.0/28 via 10.127.121.2 dev [NULL] table 0 metric -1 2020-07-29 15:24:30 us=118552 Closing TUN/TAP interface 2020-07-29 15:24:30 us=118577 net_addr_ptp_v4_del: 10.127.121.1 dev tun12701 2020-07-29 15:24:30 us=141686 SIGINT[hard,] received, process exiting }}} **Server status log showing the two malicious client connections:** {{{ >INFO:OpenVPN Management Interface Version 3 -- type 'help' for more info status 2 TITLE,OpenVPN 2.5_git [git:master/20b394746a7a351d] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jul 28 2020 TIME,2020-07-29 15:17:20,1596032240 HEADER,CLIENT_LIST,Common Name,Real Address,Virtual Address,Virtual IPv6 Address,Bytes Received,Bytes Sent,Connected Since,Connected Since (time_t),Username,Client ID,Peer ID,Data Channel Cipher HEADER,ROUTING_TABLE,Virtual Address,Common Name,Real Address,Last Ref,Last Ref (time_t) GLOBAL_STATS,Max bcast/mcast queue length,0 END status OpenVPN CLIENT LIST Updated,2020-07-29 15:17:52 Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since UNDEF,127.0.0.1:12706,1828,0,2020-07-29 15:17:33 UNDEF,127.0.0.1:12708,1828,0,2020-07-29 15:17:28 ROUTING TABLE Virtual Address,Common Name,Real Address,Last Ref GLOBAL STATS Max bcast/mcast queue length,0 END status 2 TITLE,OpenVPN 2.5_git [git:master/20b394746a7a351d] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jul 28 2020 TIME,2020-07-29 15:18:47,1596032327 HEADER,CLIENT_LIST,Common Name,Real Address,Virtual Address,Virtual IPv6 Address,Bytes Received,Bytes Sent,Connected Since,Connected Since (time_t),Username,Client ID,Peer ID,Data Channel Cipher CLIENT_LIST,UNDEF,127.0.0.1:12706,,,1371,0,2020-07-29 15:18:35,1596032315,UNDEF,3,1,BF-CBC CLIENT_LIST,UNDEF,127.0.0.1:12708,,,1828,0,2020-07-29 15:18:33,1596032313,UNDEF,2,0,BF-CBC HEADER,ROUTING_TABLE,Virtual Address,Common Name,Real Address,Last Ref,Last Ref (time_t) GLOBAL_STATS,Max bcast/mcast queue length,0 END }}} " tct Active Tickets 1385 Bridged Windows 10 Causes Sporadic Crashes Generic / unclassified OpenVPN 2.5.0 (Community Ed) release 2.5.3 Bug / Defect new 2021-02-10T23:17:07Z 2022-01-19T09:26:10Z "This bug is a continuation of bug 828 which I mistakenly thought was repaired in OpenVPN version 2.5.0. However, the frequency of the computer crashes has diminished in version 2.5.0 compared with earlier versions. I maintain three Windows 10 servers that each run OpenVPN 2.5.0. All have exhibited this same flaw - sporadic crashes. Each server bridges the computer Ethernet adapter to the OpenVPN TAP adapter so that remote computers can use the server's LAN for Windows networking. For the bulk of the time, the system functions as intended. I've done extensive testing and have observed the following: 1) The crashes occur whether or not the OpenVPN services are running. 2) The crashes occur only when the server is being written to by any program, e.g. an FTPS client, while the network bridge is installed. (Each server is concurrently running the Filezilla FTPS server.) 3) The crashes never occur unless the OpenVPN TAP is bridged to the computer's Ethernet adapter. I've captured some screen shots from one of the servers while it was being written to by a Filezilla client while the OpenVPN server was installed but deactivated, i.e., none of the OpenVPN services were running. However, the Ethernet adapter was bridged to the TAP adapter. About 2 TB of data was being moved from the client to the server via Filezilla with the client set to automatically retry upon a failure. The screen shots were captured after the data transfer was completed. I also perform this same data transfer without the bridge and had no crashes. So it appears that there is some unfavorable interaction between OpenVPN TAP adapter and Windows." mpfrench Active Tickets 1389 OpenVPN v2.5.1 --fragment does not work Generic / unclassified OpenVPN 2.5.0 (Community Ed) release 2.5.3 Bug / Defect new 2021-03-05T13:59:31Z 2022-03-07T13:14:39Z "Hi everybody, I have a running OpenVPN TUN tunnel between two boxes configured with the --fragment option on both ends. One side (Box1) is running an OpenVPN v2.3.2 and the other (Box2) is running a newer version. I have tried running v2.4.9 and v2.5.1 on Box2. I see a different behaviour of --fragment on Box2 when running v2.4.9 and v2.5.1. It seems as though v2.5.1 is not handling fragment right. Box1 config: {{{ # openvpn --version OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Dec 1 2014 .. ## OpenVPN config part: # openvpn --proto udp --dev tun --fragment 1210 ... }}} Box2 config: {{{ # openvpn --version OpenVPN 2.5.1 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [AEAD] built on Mar 4 2021 .. ## OpenVPN config part: # openvpn --proto udp --dev tun --fragment 1210 ... }}} I ping through the tunnel from Box1 (OVPN 10.5.0.1) to Box2 (OVPN 10.5.0.2) {{{ # ping -M do -s 1400 -c 3 10.5.0.2 PING 10.5.0.2 (10.5.0.2) 1400(1428) bytes of data. 1408 bytes from 10.5.0.2: icmp_seq=1 ttl=64 time=2.30 ms 1408 bytes from 10.5.0.2: icmp_seq=2 ttl=64 time=2.33 ms 1408 bytes from 10.5.0.2: icmp_seq=3 ttl=64 time=2.30 ms --- 10.5.0.2 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 2.302/2.313/2.335/0.042 ms }}} ... and I check the size of the packets on the interface where the OpenVPN traffic flows with tcpdump on Box1 {{{ # tcpdump -i eth1 -nnnvvv port 1194 tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes 14:30:56.304008 IP (tos 0x0, ttl 64, id 40423, offset 0, flags [DF], proto UDP (17), length 109) 172.16.0.9.1194 > 172.16.0.3.1194: [bad udp cksum 0x5897 -> 0x019d!] UDP, length 81 14:30:57.069682 IP (tos 0x0, ttl 64, id 40595, offset 0, flags [DF], proto UDP (17), length 813) 172.16.0.9.1194 > 172.16.0.3.1194: [bad udp cksum 0x5b57 -> 0x1d73!] UDP, length 785 14:30:57.069790 IP (tos 0x0, ttl 64, id 40596, offset 0, flags [DF], proto UDP (17), length 813) 172.16.0.9.1194 > 172.16.0.3.1194: [bad udp cksum 0x5b57 -> 0x5982!] UDP, length 785 14:30:57.071626 IP (tos 0x0, ttl 64, id 6423, offset 0, flags [+], proto UDP (17), length 1500) 172.16.0.3.1194 > 172.16.0.9.1194: UDP, length 1489 14:30:58.071669 IP (tos 0x0, ttl 64, id 40692, offset 0, flags [DF], proto UDP (17), length 813) 172.16.0.9.1194 > 172.16.0.3.1194: [bad udp cksum 0x5b57 -> 0x25af!] UDP, length 785 14:30:58.071780 IP (tos 0x0, ttl 64, id 40693, offset 0, flags [DF], proto UDP (17), length 813) 172.16.0.9.1194 > 172.16.0.3.1194: [bad udp cksum 0x5b57 -> 0x2f35!] UDP, length 785 14:30:58.073553 IP (tos 0x0, ttl 64, id 6519, offset 0, flags [+], proto UDP (17), length 1500) 172.16.0.3.1194 > 172.16.0.9.1194: UDP, length 1489 14:30:59.073357 IP (tos 0x0, ttl 64, id 40928, offset 0, flags [DF], proto UDP (17), length 813) 172.16.0.9.1194 > 172.16.0.3.1194: [bad udp cksum 0x5b57 -> 0xf769!] UDP, length 785 14:30:59.073465 IP (tos 0x0, ttl 64, id 40929, offset 0, flags [DF], proto UDP (17), length 813) 172.16.0.9.1194 > 172.16.0.3.1194: [bad udp cksum 0x5b57 -> 0x6442!] UDP, length 785 14:30:59.075222 IP (tos 0x0, ttl 64, id 6603, offset 0, flags [+], proto UDP (17), length 1500) 172.16.0.3.1194 > 172.16.0.9.1194: UDP, length 1489 ^C 10 packets captured 10 packets received by filter 0 packets dropped by kernel }}} So, I see packets originating from Box1 (172.16.0.9) to Box2 (172.16.0.3) which are fragmented as expected in two packets with length 785 bytes. However, the packets from Box2 are NOT fragmented at all, with a length of 1489 bytes! If I use OpenVPN v2.4.9 on Box2 and repeat the same steps, I get to see fragmented packets coming from both ends: {{{ 06:15:54.765351 IP (tos 0x0, ttl 64, id 57831, offset 0, flags [DF], proto UDP (17), length 813) 172.16.0.9.1194 > 172.16.0.3.1194: [bad udp cksum 0x5b57 -> 0xd9cd!] UDP, length 785 06:15:54.765466 IP (tos 0x0, ttl 64, id 57832, offset 0, flags [DF], proto UDP (17), length 813) 172.16.0.9.1194 > 172.16.0.3.1194: [bad udp cksum 0x5b57 -> 0x952a!] UDP, length 785 06:15:54.767943 IP (tos 0x0, ttl 64, id 2973, offset 0, flags [DF], proto UDP (17), length 813) 172.16.0.3.1194 > 172.16.0.9.1194: [udp sum ok] UDP, length 785 06:15:54.767998 IP (tos 0x0, ttl 64, id 2974, offset 0, flags [DF], proto UDP (17), length 813) 172.16.0.3.1194 > 172.16.0.9.1194: [udp sum ok] UDP, length 785 06:15:55.766768 IP (tos 0x0, ttl 64, id 57952, offset 0, flags [DF], proto UDP (17), length 813) 172.16.0.9.1194 > 172.16.0.3.1194: [bad udp cksum 0x5b57 -> 0x9a31!] UDP, length 785 06:15:55.766877 IP (tos 0x0, ttl 64, id 57953, offset 0, flags [DF], proto UDP (17), length 813) 172.16.0.9.1194 > 172.16.0.3.1194: [bad udp cksum 0x5b57 -> 0xf09b!] UDP, length 785 06:15:55.768896 IP (tos 0x0, ttl 64, id 2980, offset 0, flags [DF], proto UDP (17), length 813) 172.16.0.3.1194 > 172.16.0.9.1194: [udp sum ok] UDP, length 785 06:15:55.768974 IP (tos 0x0, ttl 64, id 2981, offset 0, flags [DF], proto UDP (17), length 813) 172.16.0.3.1194 > 172.16.0.9.1194: [udp sum ok] UDP, length 785 06:15:56.768946 IP (tos 0x0, ttl 64, id 58047, offset 0, flags [DF], proto UDP (17), length 813) 172.16.0.9.1194 > 172.16.0.3.1194: [bad udp cksum 0x5b57 -> 0xb52c!] UDP, length 785 06:15:56.769054 IP (tos 0x0, ttl 64, id 58048, offset 0, flags [DF], proto UDP (17), length 813) 172.16.0.9.1194 > 172.16.0.3.1194: [bad udp cksum 0x5b57 -> 0xf280!] UDP, length 785 06:15:56.770776 IP (tos 0x0, ttl 64, id 3078, offset 0, flags [DF], proto UDP (17), length 813) 172.16.0.3.1194 > 172.16.0.9.1194: [udp sum ok] UDP, length 785 06:15:56.770820 IP (tos 0x0, ttl 64, id 3079, offset 0, flags [DF], proto UDP (17), length 813) 172.16.0.3.1194 > 172.16.0.9.1194: [udp sum ok] UDP, length 785 }}} Thanks for any help! Alex " alexvelkov Active Tickets 1384 Connections can fail if ping-restart < connect-retry (UDP, static key) Configuration OpenVPN 2.4.7 (Community Ed) release 2.5.3 Bug / Defect Gert Döring accepted 2021-02-10T00:05:54Z 2021-06-17T08:21:54Z "I have a case here with server and client both using `keepalive 10 120` and the default `connect-retry 5 300`, where both sides fail to connect because they are in caught in a vicious circle of 7min loops: * Reconnecting `Re-using pre-shared static key` * Not receiving any pings for 120 sec * Declaring an `Inactivity timeout` and pausing for 300sec and because one side's reconnect happens right when the other side pauses, they always miss each other. See the merged log snippet below. What had happened was that because of DNS issues, both sides could not connect for several days, until `connect-retry` had grown from initially 5sec to 300sec. By the time the DNS issue got resolved, both where in 7min cycle (2min running, 5min pause), and by chance their 2min ""running"" phases didn't overlap. This can happen at least in my case with UDP and a shared secret, see configs below. There it can occur if one side's `connect-retry` is larger than the other side's `ping-restart`, and vice versa. I guess this problem is unique to the //Static Key encryption mode//, because in TLS mode the server side would not pause? Note that the default maximum for `connect-retry` is 300, and that an often recommended setting for `ping-restart` is 120 (e.g. via `keepalive 10 60`). If my analysis is correct and still the case, I'd consider it a bug in the documentation and the default values. I'd recommend to: * Document under which circumstances this can happen, e.g. in the man page * Reduce the default maximum for `connect-retry` from 300 to something smaller than the frequently found `ping-restart 120` (at least in susceptible modes) * In susceptible modes throw a warning when `ping-restart` is set and not larger than the `connect-retry` maximum (not to be confused with `connect-retry-max`!) (This is not entirely exact, as one would have to compare `ping-restart` on one side to the `connect-retry` maximum of the other side. But given that most users mirror those settings on both sides, maybe the best way forward). We are using OpenVPN 2.4.7-1ubuntu2 on Ubuntu 20.04. ---- Snippets from the server's and client's log: {{{ # SERVER: Feb 09 22:11:35 server[605]: Inactivity timeout (--ping-restart), restarting Feb 09 22:11:35 server[605]: SIGUSR1[soft,ping-restart] received, process restarting Feb 09 22:11:35 server[605]: Restart pause, 300 second(s) # SERVER PAUSES FOR 300sec # CLIENT: Feb 09 22:12:34 client[614041]: Re-using pre-shared static key Feb 09 22:12:34 client[614041]: Preserving previous TUN/TAP instance: tun0 Feb 09 22:12:34 client[614041]: TCP/UDP: Preserving recently used remote address: [AF_INET]xx.yyy.xxx.yy:1194 Feb 09 22:12:34 client[614041]: Socket Buffers: R=[212992->212992] S=[212992->212992] Feb 09 22:12:34 client[614041]: UDPv4 link local (bound): [AF_INET][undef]:1194 Feb 09 22:12:34 client[614041]: UDPv4 link remote: [AF_INET]xx.yyy.xxx.yy:1194 # Server is dead, so no pings fopr 120sec Feb 09 22:14:34 client[614041]: Inactivity timeout (--ping-restart), restarting Feb 09 22:14:34 client[614041]: SIGUSR1[soft,ping-restart] received, process restarting Feb 09 22:14:34 client[614041]: Restart pause, 300 second(s) # CLIENT PAUSES FOR 300sec # SERVER WAKES UP: Feb 09 22:16:35 server[605]: Re-using pre-shared static key Feb 09 22:16:35 server[605]: Preserving previous TUN/TAP instance: tun0 Feb 09 22:16:35 server[605]: Socket Buffers: R=[212992->212992] S=[212992->212992] Feb 09 22:16:35 server[605]: UDPv4 link local (bound): [AF_INET][undef]:1194 Feb 09 22:16:35 server[605]: UDPv4 link remote: [AF_UNSPEC] # Client is pausing, so no pings for 120sec Feb 09 22:18:35 server[605]: Inactivity timeout (--ping-restart), restarting Feb 09 22:18:35 server[605]: SIGUSR1[soft,ping-restart] received, process restarting Feb 09 22:18:35 server[605]: Restart pause, 300 second(s) # SERVER PAUSES FOR 300sec }}} ... and so on and so forth ad infinitum ---- Server config: {{{ user openvpn group openvpn chroot /var/lib/openvpn cd /var/lib/openvpn tmp-dir state verb 3 status state/status.log 60 port 1194 proto udp4 secret /etc/openvpn/private/shared.key 0 persist-key dev tun persist-tun ifconfig 172.29.0.1 172.29.0.2 keepalive 10 120 compress ncp-disable cipher AES-256-CBC auth SHA256 replay-persist state/rpstate route x.x.x.x y.y.y.y }}} Client config: {{{ user openvpn group openvpn chroot /var/lib/openvpn tmp-dir state verb 3 remote server 1194 udp4 secret /etc/openvpn/private/shared.key 1 persist-key dev tun persist-tun ifconfig 172.29.0.2 172.29.0.1 keepalive 10 120 compress ncp-disable cipher AES-256-CBC auth SHA256 route x.x.x.x y.y.y.y }}}" nils.toedtmann Active Tickets 1229 mingw builds: version number missing in LZO DLL Building / Compiling OpenVPN git master branch (Community Ed) release 2.5.3 Bug / Defect Samuli Seppänen assigned 2019-11-09T15:59:41Z 2022-12-22T07:59:09Z "as discussed on the hackathon: something in our mingw builds of liblzo is missing the insertion of the version number (as a resource binary) into liblzo.dll. It works for other stuff we build, so ""how hard can it be"" :-) Assigning to Samuli so this is not lost." Gert Döring Active Tickets 1209 full and consistent support of dhcp-option DOMAIN and DOMAIN-SEARCH Networking OpenVPN 2.4.7 (Community Ed) release 2.5.4 Feature Wish new 2019-08-22T05:38:23Z 2022-12-22T07:47:29Z "It would be good if there was a consistent use of the dhcp-option to set the domain name suffix for the connection as well as the domain search list. Currently, it's a mix of using DOMAIN only, using it as connection suffix if it's a single one or using it as search list if there are multiple. Some clients use DOMAIN-SEARCH for search list. However, that's not even in the official documentation. It's really not easy to set this up properly for all kinds of clients if it's not clear from the configuration/server side to start with. The connection suffix and the search list are two separate things, two separate dhcp options and should be handled separately. In my opinion, DOMAIN should be the connection suffix as it is described in the documentation, the equivalent of DHCP option 15 Domain Name. The dns domain search list, i.e. the equivalent of DHCP option 119 Domain Search should be a separate configuration option, e.g. DOMAIN-SEARCH as it is already used by some. On client side, this should obviously be handled the same way it would be handled if options were not pushed by openvpn but instead the client would actually use DHCP with a DHCP server delivering exactly those two options as described." gvde Active Tickets 1147 token authentication issues Generic / unclassified OpenVPN git master branch (Community Ed) release 2.5.4 Bug / Defect plaisthos assigned 2018-12-10T18:21:24Z 2021-06-15T17:50:18Z "I'm copying in the content of Arne's long mail in <4c8dbc1b-71c9-6187- 5ecf-f1dbfb957561@rfc2549.org> so it won't get lost: -------------------------------------------------------- The discussion has gone on a bit about this patch. I would like to step back and give an overview to make this mess better understandable as we have multiple problem mixed together. Current client behaviour: - (a) OpenVPN 3. Forgets auth-token on reconnect, can be told to forget auth-token during a session with AUTH_FAILED,SESSION - (b) OpenVPN 2.x Once it gets an auth-token, the auth-token replace the password and the client will never anything else from that point on Proposed new behaviour: - (c) OpenVPN 2.x should behave exactly like OpenVPN 3 - (d) OpenVPN 2.x if not intrustucted otherwise will keep auth-token on reconnect but will forget it as soon as it gets an AUTH-FAILED (what my patch proposed) Current OpenVPN server behaviour: - (i) Custom client-connect script with auth-token can send an auth-token and can also check the same token on reconnect - (ii) auth-gen-token sends an auth-token but the auth-token is only valid for the session. The token can also set to expiry earlier in which case the server fails to notify the client about th failed auth-token. Currently working combinations are (i)+(a) and ii+b. OpenVpn 3 with custom script (i+b) will also work but will query for password/OTP password on every reconnect/network change. Current problems: - (1) OpenVPN 2.x server does only signal AUTH-FAILED on the initial tls session but not on later ones (I am ingoring the management special case here) - (2) OpenVPN 2.x client does not understand AUTH_FAILED,SESSION - (3) OpenVPN 2.x client (b) against an auth-gen-token server (ii): Client will use the auth-token buth the server does not know anything anymore about the token and the authentication fails Problem (1) and (2) are unproblematic as far as the discussion goes as there is no doubt that we should ""just"" implement them in 2.x. Fixes for (3), client side: - Using new behaviour (c), like OpenVPN 3. This will work but will make the custom script solution (i) worse and also has more real authentication on network changes. At least I see no reason why a token after an OTP password should be invalidated after a network change. - Using new behaviour (d): Will continue to work with custom script as before. Will also be able to recover when connecting to to an *unpatched* auth-gen-token server but will need two attempts on a reconnect since the first fails with an AUTH_FAILED. - In either (c) and (d) as new client behaviour, there should be a pushable option that allows the server to select the auth-token behaviour on reconnect (forget or keep) Fixes for the server side for (3): - implement persistent auth-tokens: Will allow old clients (b) to reconnect. Maybe change expire time to be ""after not being used for x hours"". Old clients will still fail to reconnect if the server is restarted unless tokens survive server restart. - do not send auth-token to client that have behaviour (b). For this to happen the server needs to know if a client has behaviour (b) or not. My suggestion here was to increase IV_PROTO to 3. The 3 here should only signal that the client has some way of dealng with an expiring token on reconnect and that the current behaviour of auth-gen-token is safe to use. It does not matter if the client recovers from AUTH-FAILED when a token is in use or if the client forgets the token. (minimal common behsaviour). IV_PROTO should also include ""understand AUTH_FAILED,SESSION"" This has been a long mail but I hope it clear ups some of the onfusion. Arne " Gert Döring Active Tickets 1279 openvpn spuriouslyk records each and every used IPv6 of the range IPv6 OpenVPN 2.4.7 (Community Ed) release 2.5.4 Bug / Defect Gert Döring new 2020-05-02T13:28:14Z 2021-06-17T06:49:05Z "Hello, We are using OpenVPN to route whole /64 public IPv6 networks. We are however seeing things like this in the openvpn status log: 2a0c:e300:4:14::125eC,XXX,YYY,Sat May 2 15:09:00 2020 2a0c:e300:4:14::12b7C,XXX,YYY,Sat May 2 15:08:37 2020 2a0c:e300:4:14::2e76C,XXX,YYY,Sat May 2 15:09:15 2020 2a0c:e300:4:14::567aC,XXX,YYY,Sat May 2 15:08:45 2020 2a0c:e300:4:14::675C,XXX,YYY,Sat May 2 15:08:56 2020 2a0c:e300:4:14::68bC,XXX,YYY,Sat May 2 15:09:01 2020 2a0c:e300:4:14::8c15C,XXX,YYY,Sat May 2 15:08:30 2020 2a0c:e300:4:14::944dC,XXX,YYY,Sat May 2 15:09:13 2020 2a0c:e300:4:20::13ddC,XXX,YYY,Sat May 2 15:08:42 2020 2a0c:e300:4:20::28e8C,XXX,YYY,Sat May 2 15:09:19 2020 2a0c:e300:4:20::330eC,XXX,YYY,Sat May 2 15:09:23 2020 2a0c:e300:4:20::35a3C,XXX,YYY,Sat May 2 15:08:29 2020 2a0c:e300:4:20::3c44C,XXX,YYY,Sat May 2 15:09:10 2020 2a0c:e300:4:20::4017C,XXX,YYY,Sat May 2 15:09:07 2020 2a0c:e300:4:20::46b3C,XXX,YYY,Sat May 2 15:08:34 2020 2a0c:e300:4:20::46c2C,XXX,YYY,Sat May 2 15:08:53 2020 2a0c:e300:4:20::46cdC,XXX,YYY,Sat May 2 15:08:48 2020 2a0c:e300:4:20::9c56C,XXX,YYY,Sat May 2 15:08:53 2020 2a0c:e300:4:20::b285C,XXX,YYY,Sat May 2 15:08:45 2020 2a0c:e300:4:20::b5e2C,XXX,YYY,Sat May 2 15:09:22 2020 2a0c:e300:4:20::ccc4C,XXX,YYY,Sat May 2 15:08:54 2020 2a0c:e300:4:20::de87C,XXX,YYY,Sat May 2 15:08:42 2020 2a0c:e300:4:20::ff9C,XXX,YYY,Sat May 2 15:09:06 2020 2a0c:e300:4:96::1da3C,XXX,YYY,Sat May 2 15:08:42 2020 2a0c:e300:4:96::2907C,XXX,YYY,Sat May 2 15:09:21 2020 2a0c:e300:4:96::68cC,XXX,YYY,Sat May 2 15:08:38 2020 2a0c:e300:4:96::69aC,XXX,YYY,Sat May 2 15:08:33 2020 2a0c:e300:4:96::a6a4C,XXX,YYY,Sat May 2 15:09:25 2020 2a0c:e300:4:96::c957C,XXX,YYY,Sat May 2 15:09:12 2020 2a0c:e300:4:96::d312C,XXX,YYY,Sat May 2 15:09:14 2020 2a0c:e300:4:96::f6c8C,XXX,YYY,Sat May 2 15:08:58 2020 2a0c:e300:4:96::fe22C,XXX,YYY,Sat May 2 15:09:03 2020 etc. i.e. openvpn's routing table is full of single IPv6 entries. The basic reason for these is that people on the Internet apparently try ping all IP addresses in the /112 subnets. Of course ideally that shouldn't happen, but well, that's the wild Internet and openvpn should be robust against this. And it happens that there is no use for these, since the routing table already contains: 2a0c:e300:4:14::/64,XXX,YYY,Sat May 2 10:50:07 2020 2a0c:e300:4:20::/64,XXX,YYY,Fri May 1 21:42:43 2020 2a0c:e300:4:93::/64,XXX,YYY,Sat May 2 15:16:04 2020 2a0c:e300:4:96::/64,XXX,YYY,Sat May 2 10:06:00 2020 which already cover all these IPs. openvpn could thus just avoid recording each and every IPv6 of these already-recorded ranges. Worse, when using --learn-address, these IPs are passed to the script, which may thus leak to routing daemons etc. which consequently get overwhelmed as well... Samuel" sthibault Active Tickets 1357 Get token/auth/async fixes into 2.5.1 Generic / unclassified OpenVPN 2.5.0 (Community Ed) release 2.5.4 Bug / Defect Gert Döring assigned 2020-11-29T12:16:28Z 2021-06-15T18:07:26Z "master has this commit now commit 88dc4276485bf2a4cecae3cff55d2e146dcd31ca Author: Arne Schwabe Date: Fri Oct 23 14:02:59 2020 +0200 Make any auth failure tls_authentication_status return auth failed which fixes the bad interactions between token auth and async PAM (but needs prerequisite patches, which do extensive refactoring). Apply what is needed to fix the bug to 2.5.0" Gert Döring Active Tickets 1378 Route error other than openvpn server Generic / unclassified OpenVPN 2.5.0 (Community Ed) release 2.5.4 Bug / Defect Antonio Quartulli assigned 2021-01-24T10:32:03Z 2021-06-15T18:13:11Z "Hi all, I have a root command problem with openvpn 2.5 On debian-10.7.0 I have not installed NET-TOOLS, because in version 2.5 there is no need This is the contents of my configuration file: /etc/openvpn/ccd/client4 {{{ ifconfig-push 192.168.101.18 192.168.101.17 push ""route 192.168.101.0 255.255.255.0 192.168.1.253"" }}} But the push route command returns the error: ""Network is unreachable, Linux route add command failed"" the ip address 192.168.1.253 is active and is pinged by the openvpn client, also because it is on the same local network I use this setup on other clients and it works fine, the other clients have NET-TOOLS installed Can it still be needed with openvpn version 2.5? I am attaching the boot log file ip a {{{ 2: enp0s12: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:14:fd:12:32:f0 brd ff:ff:ff:ff:ff:ff inet 192.168.1.200/24 brd 192.168.1.255 scope global enp0s12 valid_lft forever preferred_lft forever }}} [https://github.com/OpenVPN/openvpn/pull/147#issuecomment-765889213] {{{ This said: are you trying to set up a route by means of ""push route"" that is not actually going towards the tun interface? This is slightly unusual config, but it might hint at a bug in the sitnl layer. }}} That's right, I'm trying to set up a push route that doesn't go to the tun interface I report below what is done on openvpn 2.4.9 {{{ openvpn --version OpenVPN 2.4.9 armv7l-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on May 9 2020 library versions: OpenSSL 1.1.1d 10 Sep 2019, LZO 2.10 Originally developed by James Yonan Copyright (C) 2002-2018 OpenVPN Inc Compile time defines: enable_async_push=no enable_comp_stub=no enable_crypto=yes enable_crypto_ofb_cfb=yes enable_debug=yes enable_def_auth=yes enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=needless enable_fragment=yes enable_iproute2=no enable_libtool_lock=yes enable_lz4=yes enable_lzo=yes enable_management=yes enable_multihome=yes enable_pam_dlopen=no enable_pedantic=no enable_pf=yes enable_pkcs11=no enable_plugin_auth_pam=no enable_plugin_down_root=no enable_plugins=no enable_port_share=yes enable_selinux=no enable_server=yes enable_shared=yes enable_shared_with_static_runtimes=no enable_small=no enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=no enable_werror=no enable_win32_dll=yes enable_x509_alt_username=no with_aix_soname=aix with_crypto_library=openssl with_gnu_ld=yes with_mem_check=no with_sysroot=no }}} I report below what is done on openvpn 2.4.9 route {{{ Tabella di routing IP del kernel Destination Gateway Genmask Flags Metric Ref Use Iface default _gateway 0.0.0.0 UG 0 0 0 enp1s0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 enp1s0 192.168.2.0 192.168.1.20 255.255.255.0 UG 0 0 0 enp1s0 192.168.101.0 192.168.1.20 255.255.255.0 UG 0 0 0 enp1s0 192.168.101.0 192.168.101.59 255.255.255.0 UG 0 0 0 tun0 192.168.101.59 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 }}} The openvpn server is set as the default gateway {{{ 192.168.101.0 192.168.101.59 255.255.255.0 UG 0 0 0 tun0 }}} This is right, But then I inside the file: /etc/openvpn/ccd/client57 I entered the route: {{{ push ""route 192.168.101.0 255.255.255.0 192.168.1.20"" }}} and as you can see from the route command: {{{ 192.168.101.0 192.168.1.20 255.255.255.0 UG 0 0 0 enp1s0 }}} This works, and I change the default gateway of the VPN tunnel This works great, so I manage everything from the file /etc/openvpn/ccd/client* Without intervening on the various clients, But with openvpn 2.5 I found the problem I exposed at the beginning of the ticket I attach the log" langioletto Active Tickets 1049 --preresolve is undocumented Documentation OpenVPN 2.4.0 (Community Ed) release 2.5.4 Bug / Defect plaisthos assigned 2018-04-04T06:52:57Z 2021-06-15T18:08:03Z "just tried to point someone to our ""pre-resolve DNS and cache the result"" option and could not find it. Introduced in e719a0535345db8f0781c0b80408ca5417597469 it seems to work nicely, but lacks a manpage entry..." Gert Döring Active Tickets 1395 Windows Installer always sets Option to start openvpn-gui on system start Installation OpenVPN 2.5.1 (Community Ed) release 2.5.4 Bug / Defect stipa assigned 2021-03-23T13:47:01Z 2021-06-17T09:10:46Z "Most of our Users do not use openvpn-GUI, so they all uncheck the option, which makes openvpn-GUI to start on Login, in Preferences or openvpn-GUI. The update to 2.5.1 (CE) did reset all options for every user. Desired behaviour: on Update, respect the existing user setting and do not re-apply the default again." stefan.beckers Active Tickets 1296 Openssl Error OpenVPN 2.4.9 Windows 10 Crypto OpenVPN 2.4.9 (Community Ed) release 2.5.5 Bug / Defect Steffan Karger new 2020-06-24T11:35:02Z 2022-01-18T08:57:46Z "I am using the Virtual Smart Card on my TPM Chip to have my private key there unexportable. Since I changed to version 2.4.9 I got this errors: OpenSSL: error:C506D064:microsoft cryptoapi:NCryptSignHash:Diese Smartcard unterstützt das angeforderte Feature nicht. (smartcard does not support feature) OpenSSL: error:141F0006:SSL routines:tls_construct_cert_verify:EVP lib TLS_ERROR: BIO read tls_read_plaintext error TLS Error: TLS object -> incoming plaintext read error TLS Error: TLS handshake failed If I go back to 2.4.8. it works well without any changes " krudas74 Active Tickets 1425 "netlink routes does not work with ""push route""" Generic / unclassified OpenVPN 2.5.0 (Community Ed) release 2.5.5 Bug / Defect Antonio Quartulli assigned 2021-08-27T16:18:02Z 2023-03-02T13:38:53Z "Moving to openvpn 2.5, netlink is now used in place of ifconfig/route commands https://github.com/OpenVPN/openvpn/blob/release/2.5/Changes.rst > On Linux, if configured without --enable-iproute2, configuring IP >addresses and adding/removing routes is now done via the netlink(3) kernel interface. This is much faster than calling ifconfig or route and also enables OpenVPN to run with less privileges. What is happening, is that when the interface / routing is created with netlink, this is the routing entry that we see: `172.17.14.0/24 via 172.17.14.1 dev tun-su` while with the old route we have: `172.17.14.0/24 dev tun-su proto kernel scope link src 172.17.14.127` Because of that (subnet not ""known"" by the kernel) any further command to add a route via push, eg `push ""route 172.17.16.0 255.255.255.0 vpn_gateway 100""` Fail with {{{ 2021-08-27 10:49:45 us=890376 net_route_v4_add: 172.17.16.0/24 via 172.18.14.1 dev [NULL] table 0 metric 100 2021-08-27 10:49:45 us=890389 sitnl_send: rtnl: generic error (-101): Network is unreachable }}} This is not necessarily an error in push, because also trying to add the route manually gives this error: {{{ # route add -net 172.17.16.0/24 gw 172.17.14.1 metric 100 SIOCADDRT: Network is unreachable # }}} To me, seems that the whole ""push"" mechanism has been compromised, but i've not performed extensive test. This bug is also described in https://bbs.archlinux.org/viewtopic.php?id=260625 But the workaround is not working for me. I've replicated the bug in Debian 11. openvpn server config {{{ [...] push ""topology subnet"" ifconfig 172.17.14.1 255.255.255.0 ifconfig-pool 172.17.14.126 172.17.14.252 route 172.17.14.0 255.255.255.0 push ""route 172.17.14.0 255.255.255.0"" push ""route-gateway 172.17.14.1"" push ""route 172.17.16.0 255.255.255.0 vpn_gateway 100"" mode server topology subnet tls-server [...] }}} Recompiling the package with --with-iproute2 fix the issue." dpalumbo Active Tickets 1432 Windows Installer Does Not Preserve OpenVPN GUI Settings (CE 2.5.4) Installation OpenVPN 2.5.4 (Community Ed) release 2.5.5 Bug / Defect stipa assigned 2021-10-15T15:37:34Z 2021-10-19T17:40:14Z "When updating Community Edition from 2.5.3 to 2.5.4 on Windows 8.1 Pro, the installer did not preserve my Launch on User Login setting. I had to manually turn it back On after the update. Also, the installer creates a desktop shortcut without asking. That should be a user option. " John Navas Active Tickets 880 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1) Generic / unclassified OpenVPN 2.4.0 (Community Ed) release 2.6 Bug / Defect new 2017-04-29T23:29:26Z 2023-01-10T10:43:03Z "I have come across an issue in 2.4rc1 (i asked dazo if its been seen yet, since we're past rc1 and he did not think so). I have a server that currently only has a single client (until I finish a migration). If I connect the client, and then disconnect / reconnect it, I have awhile where I only get: Sat Apr 29 12:05:31 2017 us=322963 SENT CONTROL [theygot]: 'PUSH_REQUEST' (status=1) Sat Apr 29 12:05:36 2017 us=450560 SENT CONTROL [theygot]: 'PUSH_REQUEST' (status=1) Sat Apr 29 12:05:41 2017 us=576189 SENT CONTROL [theygot]: 'PUSH_REQUEST' (status=1) Sat Apr 29 12:05:46 2017 us=802110 SENT CONTROL [theygot]: 'PUSH_REQUEST' (status=1) Sat Apr 29 12:05:52 2017 us=28164 SENT CONTROL [theygot]: 'PUSH_REQUEST' (status=1) while the server (verb 4) shows nothing in the log. The client disconnects after not getting a response to the push_request, and this persists for awhile unless I restart the server process or wait (I'm not sure how long) {{{ client: #daemon client remote 1194 port 1194 proto udp4 dev tun comp-lzo no ca ca.crt cert 5151.crt key 5151.key persist-key persist-tun tls-crypt crypt.key up up.sh script-security 2 verb 4 auth SHA256 tls-version-min 1.2 ns-cert-type server log vpn.log }}} {{{ server: cd /etc/openvpn/new_ec daemon local port 1194 proto udp4 dev rpn3 dev-type tun comp-lzo no ca ca.crt cert theygot.crt key theygot.key dh none server 10.9.70.0 255.255.255.0 topology subnet keepalive 10 120 persist-key persist-tun tls-crypt crypt.key verb 4 auth SHA256 tls-version-min 1.2 ifconfig-pool-persist ipp.txt log theygot.log ns-cert-type client management 127.0.0.1 13370 }}} I have not tried updating to the latest 2.4 code yet, I apologize if it's already fixed." krzee king Active Tickets 1047 ifconfig_remote environment variable not passed to --up script Generic / unclassified OpenVPN 2.4.5 (Community Ed) release 2.6 Bug / Defect reopened 2018-03-27T23:02:20Z 2022-12-15T15:21:09Z "I can see variables like: {{{ ifconfig_ipv6_remote ifconfig_ipv6_netbits ifconfig_ipv6_local ifconfig_broadcast ifconfig_netmask ifconfig_local }}} but there's no ifconfig_remote passed to my --up script. OpenVPN config: {{{ dev t-a-chara remote 109.232.227.132 1194 config ""airvpn.inc"" }}} Included file: {{{ resolv-retry infinite nobind persist-key persist-tun route-delay 5 verb 3 explicit-exit-notify 5 ca ""../auth/airvpn-ca.crt"" cert ""../auth/airvpn-user.crt"" key ""../auth/airvpn-user.key"" tls-auth ""../auth/airvpn-ta.key"" 1 remote-cert-tls server cipher AES-256-CBC comp-lzo no proto udp client dev-type tun pull-filter ignore redirect-gateway script-security 2 up ""../update-netns.py"" }}}" kir-pich Active Tickets 1403 retry logic is strange on hand-window fails Generic / unclassified OpenVPN git master branch (Community Ed) release 2.6 Bug / Defect new 2021-04-28T09:16:35Z 2021-04-28T12:28:15Z "Building a test rig for FP auth, I played with intentionally-failing client certs, and found that our understanding of {{{--connect-retry-max 1}}} is... interesting. {{{ $ ../bin/openvpn.master --client ... --connect-retry 1 --connect-retry-max 1 --hand-window 10 ... 2021-04-28 11:04:08 OpenVPN 2.6_git [git:vw1master/7064ccb9fd3578c0+] amd64-unknown-freebsd12.2 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Mar 23 2021 2021-04-28 11:04:08 library versions: OpenSSL 1.1.1h-freebsd 22 Sep 2020, LZO 2.10 2021-04-28 11:04:08 TCP/UDP: Preserving recently used remote address: [AF_INET6]2001:608:0:814::f000:11:51200 2021-04-28 11:04:08 Socket Buffers: R=[42080->42080] S=[9216->9216] 2021-04-28 11:04:08 UDP link local: (not bound) 2021-04-28 11:04:08 UDP link remote: [AF_INET6]2001:608:0:814::f000:11:51200 2021-04-28 11:04:08 TLS: Initial packet from [AF_INET6]2001:608:0:814::f000:11:51200, sid=c4256588 7d0c0b97 2021-04-28 11:04:08 VERIFY KU OK 2021-04-28 11:04:08 Validating certificate extended key usage 2021-04-28 11:04:08 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication 2021-04-28 11:04:08 VERIFY EKU OK 2021-04-28 11:04:08 VERIFY OK: depth=0, C=US, ST=California, L=Pleasanton, O=OpenVPN community project, CN=server, emailAddress=samuli@openvpn.net 2021-04-28 11:04:18 TLS Error: TLS key negotiation failed to occur within 10 seconds (check your network connectivity) 2021-04-28 11:04:18 TLS Error: TLS handshake failed 2021-04-28 11:04:18 SIGUSR1[soft,tls-error] received, process restarting 2021-04-28 11:04:18 Restart pause, 1 second(s) 2021-04-28 11:04:19 TCP/UDP: Preserving recently used remote address: [AF_INET]194.97.140.11:51200 2021-04-28 11:04:19 Socket Buffers: R=[42080->42080] S=[9216->9216] 2021-04-28 11:04:19 UDP link local: (not bound) 2021-04-28 11:04:19 UDP link remote: [AF_INET]194.97.140.11:51200 2021-04-28 11:04:19 TLS: Initial packet from [AF_INET]194.97.140.11:51200, sid=1402ed84 5446de2a 2021-04-28 11:04:19 VERIFY KU OK 2021-04-28 11:04:19 Validating certificate extended key usage 2021-04-28 11:04:19 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication 2021-04-28 11:04:19 VERIFY EKU OK 2021-04-28 11:04:19 VERIFY OK: depth=0, C=US, ST=California, L=Pleasanton, O=OpenVPN community project, CN=server, emailAddress=samuli@openvpn.net 2021-04-28 11:04:29 TLS Error: TLS key negotiation failed to occur within 10 seconds (check your network connectivity) 2021-04-28 11:04:29 TLS Error: TLS handshake failed 2021-04-28 11:04:29 SIGUSR1[soft,tls-error] received, process restarting 2021-04-28 11:04:29 Restart pause, 1 second(s) 2021-04-28 11:04:30 All connections have been connect-retry-max (1) times unsuccessful, exiting 2021-04-28 11:04:30 Exiting due to fatal error }}} so it actually tries twice, and then declares ""all my (1) tries have failed""... It does correctly count these on other connect fails... This happens for 2.4 and master, so I assume it is a very long-standing bug." Gert Döring Active Tickets 1470 early startup message printing is all confusing Generic / unclassified OpenVPN git master branch (Community Ed) release 2.6 Bug / Defect new 2022-07-21T17:56:22Z 2022-08-13T18:56:50Z "{{{ gert@ubuntu2004:~/t_server.git$ SU src/openvpn/openvpn --client --ca /home/gert/t_client_keys/ca.crt --cert /home/gert/t_client_keys/cron2-ubuntu-2004-amd64.crt --key /home/gert/t_client_keys/cron2-ubuntu-2004-amd64.key --remote-cert-tls server --nobind --verb 3 --tls-cert-profile insecure --providers legacy default --setenv UV_NOCOMP 1 --push-peer-info --dev tun471 --proto udp4 --remote conn-test-server.openvpn.org --port 51194 2022-07-21 19:54:30 Note: mbed TLS provider functionality is not available 2022-07-21 19:54:30 Note: mbed TLS provider functionality is not available 2022-07-21 19:54:30 Note: --cipher is not set. OpenVPN versions before 2.5 defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback 'BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers. 2022-07-21 19:54:30 net_iface_type: type of tun471: tun 2022-07-21 19:54:30 Interface tun471 exists and is non-DCO. Disabling data channel offload 2022-07-21 19:54:30 OpenVPN 2.6_git [git:05v11/11f03f2a5a0be586+] x86_64-pc-linux-gnu [SSL (mbed TLS)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] [DCO] built on Jul 21 2022 }}} ... can we please print the ""this is openvpn version blabla"" message BEFORE half the options warnings...?" Gert Döring Active Tickets 1354 IV_HWADDR - test ipv6-only, document better Generic / unclassified OpenVPN git master branch (Community Ed) release 2.6 Feature Wish new 2020-11-18T14:06:17Z 2020-11-18T14:06:51Z "{{{ IV_HWADDR= -- the MAC address of clients default gateway }}} is definitely less than clear in the documentation - it tries to say ""of the interface used to reach the default gateway"". Besides this, it might be broken if there is no IPv4 default gateway, and IPv6 is used to reach the VPN server - so this should be turned into ""the MAC address of the interface used to reach the VPN server"", with a specific route lookup for IPv4, or the result of the (already specific) lookup for IPv6." Gert Döring Active Tickets 1366 Allow TLS partial chains in OpenSSL Certificates release 2.6 Feature Wish new 2020-12-13T22:58:42Z 2020-12-15T22:50:33Z "When using a non-chained intermediate CA cert as the trusted CA, OpenVPN fails with an OpenSSL ""certificate verify failed"" error. That's because, by default, OpenSSL doesn't allow intermediate CAs to be trust anchors, only root CAs (even when both the server and client certificates are issued by the subCA). This can be prevented using the X509_V_FLAG_PARTIAL_CHAIN flag, [https://github.com/openssl/openssl/commit/51e7a4378a78bb0870a2cdc5c524c230c929ebcb added] in OpenSSL 1.1.0. (-partial_chain param on the OpenSSL CLI) It would be a good feature having the option to use that flag in OpenVPN, enabling intermediate CAs to be used as certificate issuers with no need to chain their root CA. " elizabethdev Active Tickets 226 '--auth-user-pass-verify