ticket summary component version milestone type owner status created _changetime _description _reporter 1085 --topology subnet is not ignore --dev tap mode Generic / unclassified OpenVPN git master branch (Community Ed) release 2.7 Bug / Defect Gert Döring accepted 2018-08-18T20:59:33Z 2022-12-22T08:41:29Z "On FreeBSD 11.2 with OpenVPN 2.4.6, contrary to the lines in the man page: {{{ --topology mode Configure virtual addressing topology when running in --dev tun mode. This directive has no meaning in --dev tap mode, which always uses a subnet topology. }}} using the line ""topology subnet"" in a config file with ""dev tap"" results in subnet mode being turned off and point-to-point mode seemingly being turned on. On the server side, one sees the following: {{{ root@opensecrets:/usr/local/etc/openvpn# ifconfig tap0 tap0: flags=8843 metric 0 mtu 1500 options=80000 ether 00:bd:55:98:05:00 inet6 fe80::2bd:55ff:fe98:500%tap0 prefixlen 64 tentative scopeid 0x5 inet6 2001:470:b09d:17::1 prefixlen 64 tentative inet 10.128.64.1 netmask 0xfffff000 broadcast 10.128.64.2 nd6 options=29 media: Ethernet autoselect status: active groups: tap Opened by PID 88373 }}} With the supposed point-to-point peer IP address as the broadcast address. On the client side with both those lines in the config file, you see this: {{{ root@authns1:/var/log/openvpn # ifconfig tap0 tap0: flags=8843 metric 0 mtu 1500 options=80000 ether 00:bd:18:b9:1d:00 hwaddr 00:bd:18:b9:1d:00 inet6 fe80::2bd:18ff:feb9:1d00%tap0 prefixlen 64 scopeid 0x4 inet6 2001:470:b09d:17::10 prefixlen 64 inet 10.128.64.16 netmask 0xfffff000 broadcast 10.128.64.1 nd6 options=21 media: Ethernet autoselect status: active groups: tap Opened by PID 7148 }}} Again with the supposed point-to-point peer address as the broadcast. Commenting out ""topology subnet"" line results in the expected values. Server: {{{ root@opensecrets:/usr/local/etc/openvpn# ifconfig tap0 tap0: flags=8843 metric 0 mtu 1500 options=80000 ether 00:bd:56:a5:14:00 inet6 fe80::2bd:56ff:fea5:1400%tap0 prefixlen 64 tentative scopeid 0x5 inet6 2001:470:b09d:17::1 prefixlen 64 tentative inet 10.128.64.1 netmask 0xfffff000 broadcast 10.128.79.255 nd6 options=29 media: Ethernet autoselect status: active groups: tap Opened by PID 88524 }}} Client: {{{ root@authns1:/var/log/openvpn # ifconfig tap0 tap0: flags=8843 metric 0 mtu 1500 options=80000 ether 00:bd:68:3c:1f:00 hwaddr 00:bd:68:3c:1f:00 inet6 fe80::2bd:68ff:fe3c:1f00%tap0 prefixlen 64 tentative scopeid 0x4 inet6 2001:470:b09d:17::10 prefixlen 64 inet 10.128.64.16 netmask 0xfffff000 broadcast 10.128.79.255 nd6 options=21 media: Ethernet autoselect status: active groups: tap Opened by PID 7425 }}} Since the man page says that --topology has no meaning in --dev tap mode, one would expect that it would have no effect at all." Bytor 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 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 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 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 1322 "Use actual VPN gateway address to determine ""default"" route" Networking OpenVPN git master branch (Community Ed) release 2.7 Feature Wish Gert Döring accepted 2020-09-08T10:03:56Z 2023-01-10T11:07:29Z "Align IPv4 code with IPv6 code, so ""get_default_gateway()"" grows an extra field for ""destination address to query"", and fill that with the VPN gateway's (IPv4) address. After all, this is what we're interested in, not ""some /0 route that might not be the route actually used"" (machines with multiple interfaces are getting more common)" Gert Döring 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 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 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 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 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 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 840 Server --auth-gen-token and client --auth-nocache do not work together Configuration OpenVPN 2.4.0 (Community Ed) release 2.6 Bug / Defect David Sommerseth accepted 2017-02-07T14:05:17Z 2023-01-01T20:15:27Z "If a server pushes an auth-token to a client using auth-nocache the client does not cache the token. Thus renegotiating a connection after --reneg-sec/bytes/pkts causes client to drop the current connection and request password from user. Currently the fix is: do '''not''' use --auth-nocache in client config. More information: https://www.mail-archive.com/openvpn-users@lists.sourceforge.net/msg03511.html" tct 877 Clients bound to a specific IP don't use a random outgoing port Configuration OpenVPN 2.4.0 (Community Ed) release 2.6 Feature Wish Gert Döring accepted 2017-04-26T15:42:02Z 2021-12-06T17:34:15Z "On one of my systems, I'm running an OpenVPN server as well as a client. This system has 5 public IPs with the OpenVPN server bound to 0.0.0.0:1194, and the client bound to one of the public IPs (--local 1.1.1.1), connecting to server2.domain.com:1194 (using --remote server2.domain.com 1194) As --port defaults to 1194, the client was bound to 1.1.1.1:1194 and not receiving data (was being received by the server instead). --lport should probably default to 0 (random) and --rport to 1194." NHellFire 626 Routing entry not deleted when MAC address moves from client to server Networking OpenVPN git master branch (Community Ed) release 2.7 Bug / Defect Gert Döring accepted 2015-11-09T11:24:51Z 2022-12-21T16:56:05Z "'''Context:''' A TAP OpenVPN connection is made between two virtual machine hypervisors. The TAP devices are bridged with the VM interfaces, thus creating a L2 bridge between the VMs on different hosts. A virtual machine (192.168.42.102) is moved from a hypervisor host (node02) to another one (node01). '''Initial situation:''' {{{ .---------------------------------. .---------------------------------. | node01 | | node02 | | OpenVPN server | | OpenVPN client | | | | | | .-----------------------. | | .-----------------------. | | | br0 | | | | br0 | | | | .-------------------. | | | | .-------------------. | | | | | tap0 | | | | | | tap1 | | | | | | 192.168.42.1 |<----------------OpenVPN----------------| 192.168.42.2 | | | | | | de:57:b6:64:0e:c8 | | | | | | 2e:60:ce:c9:63:d1 | | | | | '-------------------' | | | | '-------------------' | | | | | | | | .-------------------. | | | | | | | | | vnet0 | | | | | | | | | | 192.168.42.102 | | | | | | | | | | 52:54:00:de:ad:02 | | | | | | | | | '-------------------' | | | '-----------------------' | | '-----------------------' | '---------------------------------' '---------------------------------' }}} '''Final situation:''' {{{ .---------------------------------. .---------------------------------. | node01 | | node02 | | OpenVPN server | | OpenVPN client | | | | | | .-----------------------. | | .-----------------------. | | | br0 | | | | br0 | | | | .-------------------. | | | | .-------------------. | | | | | tap0 | | | | | | tap1 | | | | | | 192.168.42.1 |<----------------OpenVPN----------------| 192.168.42.2 | | | | | | de:57:b6:64:0e:c8 | | | | | | 2e:60:ce:c9:63:d1 | | | | | '-------------------' | | | | '-------------------' | | | | .-------------------. | | | | | | | | | vnet0 | | | | | | | | | | 192.168.42.102 | | | | | | | | | | 52:54:00:de:ad:02 | | | | | | | | | '-------------------' | | | | | | | '-----------------------' | | '-----------------------' | '---------------------------------' '---------------------------------' }}} '''What I do:''' Ping 192.168.42.2 (node02) from 192.168.42.102 (the VM). '''What happens:''' Once the machine is moved from node02 to node01, no ping reply reaches the VM. '''What should happen instead:''' Ping replies should reach the VM. ---- OpenVPN version: {{{ OpenVPN 2.3.8 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Aug 4 2015 library versions: OpenSSL 1.0.1e-fips 11 Feb 2013, LZO 2.06 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=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=yes 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 }}} Linux version: {{{ CentOS Linux release 7.1.1503 (Core) Linux node02 4.1.12-default #1 SMP Thu Nov 5 16:00:51 CET 2015 x86_64 x86_64 x86_64 GNU/Linux }}} Server config: {{{ local 198.51.100.7 port 1194 proto udp dev tap0 mode server tls-server ca /etc/openvpn/pki/whatever-ca-crt.pem cert /etc/openvpn/pki/whatever-server-crtchain.pem key /etc/openvpn/pki/whatever-server-key.pem dh /etc/openvpn/pki/whatever-ca-dh.pem tls-auth /etc/openvpn/pki/ta.key 0 server-bridge 192.168.11.1 255.255.255.0 192.168.11.100 192.168.11.200 client-to-client duplicate-cn keepalive 10 120 #comp-lzo max-clients 4 user nobody group nobody persist-key persist-tun status openvpn-status.log log-append openvpn.log verb 9 script-security 2 }}} Client config: {{{ client dev tap1 proto udp remote 198.51.100.7 1194 resolv-retry infinite nobind persist-key persist-tun ca /etc/openvpn/pki/whatever-ca-crt.pem cert /etc/openvpn/pki/whatever-client02-crtchain.pem key /etc/openvpn/pki/whatever-client02-key.pem ns-cert-type server tls-auth /etc/openvpn/pki/ta.key 1 #comp-lzo verb 9 log-append openvpnclient.log script-security 2 keepalive 30 120 float status openvpn-status.log }}} ---- Here are the log excerpt for a ping packet from the VM the other hypervisor: Server sends ping packet: {{{ read from TUN/TAP returned 98 GET INST BY VIRT: 2e:60:ce:c9:63:d1 -> OpenVPNClient02/198.51.100.8:45186 via 2e:60:ce:c9:63:d1 OpenVPNClient02/198.51.100.8:45186 TUN READ [98] OpenVPNClient02/198.51.100.8:45186 ENCRYPT FROM: 0000006c 2e60cec9 63d15254 00dead02 08004500 0054f4ea 0000ff01 f104c0a[more...] OpenVPNClient02/198.51.100.8:45186 ENCRYPT TO: 8bc767c2 ebacf0f8 120e8996 092c2d68 675bd569 33189ea8 2aa88961 998fcfb[more...] OpenVPNClient02/198.51.100.8:45186 UDPv4 WRITE [133] to [AF_INET]198.51.100.8:45186: P_DATA_V1 kid=0 DATA c2fe31ee 55bf2043 c24309d1 fef442c3 78d1002d 8bc767c2 ebacf0f8 120e899[more...] OpenVPNClient02/198.51.100.8:45186 UDPv4 write returned 133 }}} Client receives ping packet: {{{ UDPv4 READ [133] from [AF_INET]198.51.100.7:1194: P_DATA_V1 kid=0 DATA c2fe31ee 55bf2043 c24309d1 fef442c3 78d1002d 8bc767c2 ebacf0f8 120e899[more...] DECRYPT TO: 0000006c 2e60cec9 63d15254 00dead02 08004500 0054f4ea 0000ff01 f104c0a[more...] PID_TEST [0] [SSL-0] [112233445566778899>>>>>>>>>>>>>>>>EEEEEEEEEEEEEEEEEEEEEEEEEEEEEE] 0:107 0:108 t=1447061166[0] r=[-2,64,15,0,1] sl=[21,64,64,528] TUN WRITE [98] write to TUN/TAP returned 98 }}} Client sends pong packet: {{{ TUN READ [98] ENCRYPT FROM: 0000006a 525400de ad022e60 cec963d1 08004500 00541a02 00004001 8aeec0a[more...] ENCRYPT TO: 7cc560fa 28a6349d bad24eca 5fee496c b570067a 0b0e3d6e 4f5f518f 4615351[more...] UDPv4 WRITE [133] to [AF_INET]198.51.100.7:1194: P_DATA_V1 kid=0 DATA 31716baa 29bd16a4 68e4a888 a2ffccca 673cbd94 7cc560fa 28a6349d bad24ec[more...] UDPv4 write returned 133 }}} Server receives pong packet and sends it back to client: {{{ OpenVPNClient02/198.51.100.8:45186 UDPv4 READ [133] from [AF_INET]198.51.100.8:45186: P_DATA_V1 kid=0 DATA 31716baa 29bd16a4 68e4a888 a2ffccca 673cbd94 7cc560fa 28a6349d bad24ec[more...] OpenVPNClient02/198.51.100.8:45186 DECRYPT TO: 0000006a 525400de ad022e60 cec963d1 08004500 00541a02 00004001 8aeec0a[more...] OpenVPNClient02/198.51.100.8:45186 GET INST BY VIRT: 52:54:00:de:ad:02 -> OpenVPNClient02/198.51.100.8:45186 via 52:54:00:de:ad:02 OpenVPNClient02/198.51.100.8:45186 ENCRYPT FROM: 0000006d 525400de ad022e60 cec963d1 08004500 00541a02 00004001 8aeec0a[more...] OpenVPNClient02/198.51.100.8:45186 ENCRYPT TO: 5526778c dc9e2db5 64674da6 9d1eab5c c8511d8e bf3ed564 75acdc5c 4dbfa2e[more...] OpenVPNClient02/198.51.100.8:45186 UDPv4 WRITE [133] to [AF_INET]198.51.100.8:45186: P_DATA_V1 kid=0 DATA b70e40a4 2c9e44c2 43545727 7513c0f7 a61148c1 5526778c dc9e2db5 64674da[more...] OpenVPNClient02/198.51.100.8:45186 UDPv4 write returned 133 }}} Client receives pong packet: {{{ UDPv4 read returned 133 UDPv4 READ [133] from [AF_INET]198.51.100.7:1194: P_DATA_V1 kid=0 DATA b70e40a4 2c9e44c2 43545727 7513c0f7 a61148c1 5526778c dc9e2db5 64674da[more...] DECRYPT TO: 0000006d 525400de ad022e60 cec963d1 08004500 00541a02 00004001 8aeec0a[more...] TUN WRITE [98] write to TUN/TAP returned 98 }}} TCPdump on client shows the pong packet coming back: {{{ 10:38:31.163434 IP 192.168.42.102 > 192.168.42.2: ICMP echo request, id 48223, seq 806, length 64 10:38:31.163472 IP 192.168.42.2 > 192.168.42.102: ICMP echo reply, id 48223, seq 806, length 64 10:38:31.165248 IP 192.168.42.2 > 192.168.42.102: ICMP echo reply, id 48223, seq 806, length 64 }}} ---- Getting the server's status report indicates that the MAC address of 192.168.42.102 (the VM) is still considered to be reachable through the VPN client while it now should be considered a local address: {{{ OpenVPN CLIENT LIST Updated,Mon Nov 9 10:30:52 2015 Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since OpenVPNClient02,198.51.100.8:45186,63009,96567,Mon Nov 9 10:21:58 2015 ROUTING TABLE Virtual Address,Common Name,Real Address,Last Ref 2e:60:ce:c9:63:d1,OpenVPNClient02,198.51.100.8:45186,Mon Nov 9 10:30:51 2015 52:54:00:de:ad:02,OpenVPNClient02,198.51.100.8:45186,Mon Nov 9 10:30:51 2015 GLOBAL STATS Max bcast/mcast queue length,1 END }}} ---- Reading the source code indicates that multi_learn_addr() in multi.c does not update routes when the destination addr is local: https://github.com/OpenVPN/openvpn/blob/ea66a2b5cdb21422139c421b4d3733e1c1c3937e/src/openvpn/multi.c#L1016 Thus, the bad route is kept and is used while it should have been deleted. When I move the VM between two hypervisors that are both clients of the OpenVPN server (instead of moving it from a client to the server), the condition is respected, the routing table is updated and the network has no problem: {{{ OpenVPNClient02/198.51.100.8:56038 MULTI: Learn: 52:54:00:de:ad:02 -> OpenVPNClient02/198.51.100.8:56038 }}} ---- So, to sum up the diagnostic: When a MAC address moves from a client to the server, the entry in the routing table is not deleted, and the trafic to the MAC address is sent to the client connection where it was last seen while it should be handled locally. Should I write and submit a patch? " zewaren 735 netbsd: named tap devices not auto-created Networking OpenVPN git master branch (Community Ed) release 2.7 Bug / Defect Gert Döring accepted 2016-09-13T20:48:14Z 2022-12-22T09:10:02Z "running OpenVPN {{{ --dev tap3 }}} on NetBSD 7.0.1 only works if that device has been manually created by {{{ ifconfig tap3 create }}} before - and then, it still isn't behaving ""properly"" because ifconfig/route changes are not cleaned up on exit. Mainly recording this so someone can look into it. Code in question is in tun.c around line 1600 {{{ if (!dynamic_opened) { /* has named device existed before? if so, don't destroy at end */ if ( if_nametoindex( dev ) > 0 ) { msg (M_INFO, ""TUN/TAP device %s exists previously, keep at program end"", dev ); tt->persistent_if = true; } if ((tt->fd = open (tunname, O_RDWR)) < 0) msg (M_ERR, ""Cannot open TUN/TAP dev %s"", tunname); } }}} adding an {{{ #ifdef TARGET_NETBSD }}} .. {{{ else if strncmp(dev, tap) == 0 ... exec(""ifconfig $dev create"") }}} would work, but not make the code much prettier... (plus, it needs {{{ destroy }}} at tun_close)." Gert Döring 498 Support dynamic IPv6 prefixes in server config rather than hardcoded prefixes. IPv6 OpenVPN git master branch (Community Ed) release 2.7 Feature Wish Gert Döring accepted 2015-01-02T20:31:40Z 2022-12-21T16:59:00Z "The use of DHCPv6-PD by many ISPs creates a headache in using IPv6 for an OpenVPN tunnel because OpenVPN currently requires the IPv6 prefix be hardcoded into the server config. It would be nice to have OpenVPN use whatever prefix is assigned to the TUN adapter by DHCPv6. For example, let's say the OpenVPN server machine receives a /60 address from the ISP: 2001:db8::/60. The DHCPv6 client on machine then assigns a /64 to the OpenVPN tun adapter: 2001:db8:0:1::1/64. Now I want OpenVPN to assign IPv6 addresses to connecting clients using WHATEVER prefix was assigned to the tun adapter. Seems like the way to accomplish this would be as follows: 1) Remove the ""ifconfig-ipv6"" command from the server config. Thus IPv6 assignment to the TUN adapter on the server could be handled by the DHCPv6 client on the machine as and when it receives a new prefix from the ISP. (In the current state, if the IPv6 address is given to the TUN adapter by DHCPv6, then OpenVPN also calls ifconfig to assign the address and produces a file-already-exists error and OpenVPN exits as a result. However, the ""ifconfig-ipv6"" command cannot currently be removed from the server config because...) 2) Currently ""ifconfig-ipv6-pool"" also requires that ""ifconfig-ipv6"" is used. Remove this requirement so ""ifconfig-ipv6-pool"" can be used without ""ifconfig-ipv6"". 3) Allow syntax for ""ifconfig-ipv6-pool"" that only specifies the suffix. For example ""ifconfig-ipv6-pool ::100/64"" would assign IPv6 addresses to connecting clients starting at ::100. The would be whatever is assigned to the TUN adapter. 4) When the IPv6 prefix assigned by DHCPv6-PD to the TUN adapter on the server changes, re-issue new IPv6 addresses to connected clients with the new prefix. The only workaround I have come up with is to use ULA addresses, which can be hardcoded. This works for local traffix, but prevents me redirecting all IPv6 internet-bound traffic through the tunnel (because clients do not receive a publicly routable IPv6 address)." brith2o 1399 Linux: configure custom routing table id in client OSS OpenVPN Clients release 2.7 Feature Wish Antonio Quartulli accepted 2021-04-10T12:54:10Z 2023-02-26T22:53:55Z "To the best of my knowledge, on Linux by default route changes get committed to the ""main"" table 254. I would like to be able to configure my OpenVPN client to use a different routing table instead. The problem I try to solve is routing traffic from some daemons over a VPN connection, but not traffic from other applications or daemons. An elegant solution would be for IPTables to mark traffic from applications running as a certain user- or group-id with a particular index i, e.g. ""iptables -t mangle -A OUTPUT -p tcp -m owner --uid-owner [uid] -j MARK --set-mark 10"" Using ""ip rule add fwmark 10 table [table-id]"", I can then route traffic for those applications according to the routing table written by OpenVPN, while other traffic continues to use the default routing table. Manually scripting up routing table entries may be possible using route-up scripts, but in the presence of dynamic IPs and pushed/pulled route changes this use-case might be cleaner to achieve with a simple ""route-table"" option in a VPNs configuration file." RSpliet 1405 make persist-key always on, remove other code path Configuration OpenVPN git master branch (Community Ed) release 2.7 Feature Wish Antonio Quartulli accepted 2021-05-03T15:45:23Z 2023-02-26T22:52:50Z "As discussed (suggested) on the openvpn-devel list in this thread http://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg22098.html nobody seems to see a good reason to keep the code path {{{no --persist-key}}}. So, feature wish: make it always-on, remove the ""off"" code path, document." Gert Döring 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 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 556 bind to multiple IPv4 and IPv6 addresses Networking release 2.7 Feature Wish Antonio Quartulli assigned 2015-05-18T10:06:59Z 2023-05-14T15:01:54Z "Hi, it looks like it is not possible not bind OpenVPN in dual stack mode on specific IPs. If I run the server plain with udp6 he is listening on all interfaces (v4 and v6). Now I would like to restrict this to a few interfaces. But in dual stack mode an IPv4 adress in local causes the server to crash: [openvpn.log] Mon May 18 12:02:48 2015 us=69753 OpenVPN 2.3.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Dec 1 2014 Mon May 18 12:02:48 2015 us=69765 library versions: OpenSSL 1.0.1k 8 Jan 2015, LZO 2.08 Mon May 18 12:02:48 2015 us=73425 Diffie-Hellman initialized with 2048 bit key Mon May 18 12:02:48 2015 us=73603 TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ] Mon May 18 12:02:48 2015 us=73614 Socket Buffers: R=[212992->131072] S=[212992->131072] Mon May 18 12:02:48 2015 us=73619 RESOLVE: Cannot resolve host address: 10.20.30.40: Address family for hostname not supported Mon May 18 12:02:48 2015 us=73623 Exiting due to fatal error Either the option should support both or there should be a specific option like this: local 10.20.30.40 local6 fe80::fc54:ff:fe54:7933" crane 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 1336 AUTH_FAILED is not DDOS resilient Generic / unclassified OpenVPN 2.5.0 (Community Ed) release 2.6 Bug / Defect nobody assigned 2020-10-11T19:53:56Z 2023-01-10T10:50:51Z "Using a default client config: {{{ dev tun windows-driver wintun nobind client config easytls.conf # Certs/keys remote-cert-tls server verb 4 remote 10.10.101.101 34571 # One with and one without the user/pass auth-user-pass userpass.txt }}} == The client sends the wrong password: The server rejects this client on account of AUTH_FAILED. This is pushed back to the client and **the client restarts in 5 seconds**. (DDOS) `--connect-retry` does not effect this failure and the client always restarts in 5 seconds. == The client does not send user/pass If the client fails to push a username+password then the client fails to connect but the server does not respond AUTH_FAILED and the client waits for the expected TLS handshake time-out. Eventually, the client backs off as per `--connect-retry` defaults. Logs below (note: times): 1. Client sends wrong user/pass, recieves AUTH_FAILED (DDOS) 1. Continuation snip showing 5 second restart 1. Client does **not** send user/pass and receives nothing 1. Server log showing hammering 1. Server log when the client does not send user/pass **Client log - receives AUTH_FAILED** (DDOS) {{{ 2020-10-11 20:15:28 us=411379 OpenVPN 2.5_rc2 i686-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Sep 30 2020 2020-10-11 20:15:28 us=411379 Windows version 6.1 (Windows 7) 32bit 2020-10-11 20:15:28 us=411379 library versions: OpenSSL 1.1.1h 22 Sep 2020, LZO 2.10 Enter Management Password: 2020-10-11 20:15:28 us=411379 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340 2020-10-11 20:15:28 us=411379 Need hold release from management interface, waiting... 2020-10-11 20:15:28 us=880129 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340 2020-10-11 20:15:28 us=989504 MANAGEMENT: CMD 'state on' 2020-10-11 20:15:28 us=989504 MANAGEMENT: CMD 'log all on' 2020-10-11 20:15:29 us=286379 MANAGEMENT: CMD 'echo all on' 2020-10-11 20:15:29 us=302004 MANAGEMENT: CMD 'bytecount 5' 2020-10-11 20:15:29 us=302004 MANAGEMENT: CMD 'hold off' 2020-10-11 20:15:29 us=302004 MANAGEMENT: CMD 'hold release' 2020-10-11 20:15:29 us=317629 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key 2020-10-11 20:15:29 us=317629 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication 2020-10-11 20:15:29 us=317629 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key 2020-10-11 20:15:29 us=317629 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication 2020-10-11 20:15:29 us=317629 Control Channel MTU parms [ L:1621 D:1156 EF:94 EB:0 ET:0 EL:3 ] 2020-10-11 20:15:29 us=317629 Data Channel MTU parms [ L:1621 D:1450 EF:121 EB:406 ET:0 EL:3 ] 2020-10-11 20:15:29 us=317629 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,auth SHA1,keysize 128,key-method 2,tls-client' 2020-10-11 20:15:29 us=317629 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,auth SHA1,keysize 128,key-method 2,tls-server' 2020-10-11 20:15:29 us=317629 TCP/UDP: Preserving recently used remote address: [AF_INET]10.10.101.101:34571 2020-10-11 20:15:29 us=317629 Socket Buffers: R=[8192->8192] S=[8192->8192] 2020-10-11 20:15:29 us=317629 UDP link local: (not bound) 2020-10-11 20:15:29 us=317629 UDP link remote: [AF_INET]10.10.101.101:34571 2020-10-11 20:15:29 us=317629 MANAGEMENT: >STATE:1602443729,WAIT,,,,,, 2020-10-11 20:15:29 us=380129 MANAGEMENT: >STATE:1602443729,AUTH,,,,,, 2020-10-11 20:15:29 us=380129 TLS: Initial packet from [AF_INET]10.10.101.101:34571, sid=cb26395e ef50663f 2020-10-11 20:15:29 us=380129 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this 2020-10-11 20:15:29 us=395754 VERIFY KU OK 2020-10-11 20:15:29 us=395754 Validating certificate extended key usage 2020-10-11 20:15:29 us=395754 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication 2020-10-11 20:15:29 us=395754 VERIFY EKU OK 2020-10-11 20:15:29 us=395754 VERIFY OK: depth=0, CN=s01 2020-10-11 20:15:29 us=427004 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bit RSA 2020-10-11 20:15:29 us=427004 [s01] Peer Connection Initiated with [AF_INET]10.10.101.101:34571 2020-10-11 20:15:30 us=583254 MANAGEMENT: >STATE:1602443730,GET_CONFIG,,,,,, 2020-10-11 20:15:30 us=583254 SENT CONTROL [s01]: 'PUSH_REQUEST' (status=1) 2020-10-11 20:15:30 us=583254 AUTH: Received control message: AUTH_FAILED 2020-10-11 20:15:30 us=583254 TCP/UDP: Closing socket 2020-10-11 20:15:30 us=583254 SIGUSR1[soft,auth-failure] received, process restarting 2020-10-11 20:15:30 us=583254 MANAGEMENT: >STATE:1602443730,RECONNECTING,auth-failure,,,,, 2020-10-11 20:15:30 us=583254 Restart pause, 5 second(s) }}} **This goes on and on**: {{{ 2020-10-11 20:17:22 us=520754 Restart pause, 5 second(s) 2020-10-11 20:17:27 us=520754 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key 2020-10-11 20:17:27 us=520754 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication 2020-10-11 20:17:27 us=520754 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key 2020-10-11 20:17:27 us=520754 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication 2020-10-11 20:17:27 us=520754 Control Channel MTU parms [ L:1621 D:1156 EF:94 EB:0 ET:0 EL:3 ] 2020-10-11 20:17:27 us=520754 Data Channel MTU parms [ L:1621 D:1450 EF:121 EB:406 ET:0 EL:3 ] 2020-10-11 20:17:27 us=520754 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,auth SHA1,keysize 128,key-method 2,tls-client' 2020-10-11 20:17:27 us=520754 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,auth SHA1,keysize 128,key-method 2,tls-server' 2020-10-11 20:17:27 us=520754 TCP/UDP: Preserving recently used remote address: [AF_INET]10.10.101.101:34571 2020-10-11 20:17:27 us=520754 Socket Buffers: R=[8192->8192] S=[8192->8192] 2020-10-11 20:17:27 us=520754 UDP link local: (not bound) 2020-10-11 20:17:27 us=520754 UDP link remote: [AF_INET]10.10.101.101:34571 2020-10-11 20:17:27 us=520754 MANAGEMENT: >STATE:1602443847,WAIT,,,,,, 2020-10-11 20:17:27 us=614504 MANAGEMENT: >STATE:1602443847,AUTH,,,,,, 2020-10-11 20:17:27 us=614504 TLS: Initial packet from [AF_INET]10.10.101.101:34571, sid=bb537965 8ff299f1 2020-10-11 20:17:27 us=630129 VERIFY KU OK 2020-10-11 20:17:27 us=630129 Validating certificate extended key usage 2020-10-11 20:17:27 us=630129 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication 2020-10-11 20:17:27 us=630129 VERIFY EKU OK 2020-10-11 20:17:27 us=630129 VERIFY OK: depth=0, CN=s01 2020-10-11 20:17:27 us=692629 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bit RSA 2020-10-11 20:17:27 us=692629 [s01] Peer Connection Initiated with [AF_INET]10.10.101.101:34571 2020-10-11 20:17:28 us=723879 MANAGEMENT: >STATE:1602443848,GET_CONFIG,,,,,, 2020-10-11 20:17:28 us=723879 SENT CONTROL [s01]: 'PUSH_REQUEST' (status=1) 2020-10-11 20:17:28 us=723879 AUTH: Received control message: AUTH_FAILED 2020-10-11 20:17:28 us=723879 TCP/UDP: Closing socket 2020-10-11 20:17:28 us=723879 SIGUSR1[soft,auth-failure] received, process restarting 2020-10-11 20:17:28 us=723879 MANAGEMENT: >STATE:1602443848,RECONNECTING,auth-failure,,,,, 2020-10-11 20:17:28 us=723879 Restart pause, 5 second(s) 2020-10-11 20:17:32 us=723879 SIGTERM[hard,init_instance] received, process exiting 2020-10-11 20:17:32 us=723879 MANAGEMENT: >STATE:1602443852,EXITING,init_instance,,,,, }}} **Client log waits for TLS handshake**: {{{ Sun Oct 11 20:07:00 2020 OpenVPN 2.5_rc2 i686-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Sep 30 2020 Sun Oct 11 20:07:00 2020 Windows version 6.1 (Windows 7) 32bit Sun Oct 11 20:07:00 2020 library versions: OpenSSL 1.1.1h 22 Sep 2020, LZO 2.10 Sun Oct 11 20:07:00 2020 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340 Sun Oct 11 20:07:00 2020 Need hold release from management interface, waiting... Sun Oct 11 20:07:01 2020 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340 Sun Oct 11 20:07:01 2020 MANAGEMENT: CMD 'state on' Sun Oct 11 20:07:01 2020 MANAGEMENT: CMD 'log all on' Sun Oct 11 20:07:01 2020 MANAGEMENT: CMD 'echo all on' Sun Oct 11 20:07:01 2020 MANAGEMENT: CMD 'bytecount 5' Sun Oct 11 20:07:01 2020 MANAGEMENT: CMD 'hold off' Sun Oct 11 20:07:01 2020 MANAGEMENT: CMD 'hold release' Sun Oct 11 20:07:01 2020 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key Sun Oct 11 20:07:01 2020 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication Sun Oct 11 20:07:01 2020 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key Sun Oct 11 20:07:01 2020 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication Sun Oct 11 20:07:01 2020 Control Channel MTU parms [ L:1621 D:1156 EF:94 EB:0 ET:0 EL:3 ] Sun Oct 11 20:07:01 2020 Data Channel MTU parms [ L:1621 D:1450 EF:121 EB:406 ET:0 EL:3 ] Sun Oct 11 20:07:01 2020 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,auth SHA1,keysize 128,key-method 2,tls-client' Sun Oct 11 20:07:01 2020 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,auth SHA1,keysize 128,key-method 2,tls-server' Sun Oct 11 20:07:01 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]10.10.101.101:34571 Sun Oct 11 20:07:01 2020 Socket Buffers: R=[8192->8192] S=[8192->8192] Sun Oct 11 20:07:01 2020 UDP link local: (not bound) Sun Oct 11 20:07:01 2020 UDP link remote: [AF_INET]10.10.101.101:34571 Sun Oct 11 20:07:01 2020 MANAGEMENT: >STATE:1602443221,WAIT,,,,,, Sun Oct 11 20:07:01 2020 MANAGEMENT: >STATE:1602443221,AUTH,,,,,, Sun Oct 11 20:07:01 2020 TLS: Initial packet from [AF_INET]10.10.101.101:34571, sid=acd4374d 3676ee51 Sun Oct 11 20:07:01 2020 VERIFY KU OK Sun Oct 11 20:07:01 2020 Validating certificate extended key usage Sun Oct 11 20:07:01 2020 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication Sun Oct 11 20:07:01 2020 VERIFY EKU OK Sun Oct 11 20:07:01 2020 VERIFY OK: depth=0, CN=s01 Sun Oct 11 20:08:01 2020 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Sun Oct 11 20:08:01 2020 TLS Error: TLS handshake failed Sun Oct 11 20:08:01 2020 TCP/UDP: Closing socket Sun Oct 11 20:08:01 2020 SIGUSR1[soft,tls-error] received, process restarting Sun Oct 11 20:08:01 2020 MANAGEMENT: >STATE:1602443281,RECONNECTING,tls-error,,,,, Sun Oct 11 20:08:01 2020 Restart pause, 5 second(s) Sun Oct 11 20:08:06 2020 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key }}} **Server log showing hammering, also note the client was able to send** `--explicit-exit-notify` (looks like it did): {{{ 2020-10-11 20:17:27 us=470623 MULTI: multi_create_instance called 2020-10-11 20:17:27 us=470859 10.10.201.107:51782 Re-using SSL/TLS context 2020-10-11 20:17:27 us=471068 10.10.201.107:51782 tls-crypt-v2 server key: Cipher 'AES-256-CTR' initialized with 256 bit key 2020-10-11 20:17:27 us=471447 10.10.201.107:51782 tls-crypt-v2 server key: Using 256 bit message hash 'SHA256' for HMAC authentication 2020-10-11 20:17:27 us=471788 10.10.201.107:51782 Control Channel MTU parms [ L:1621 D:1212 EF:38 EB:0 ET:0 EL:3 ] 2020-10-11 20:17:27 us=472055 10.10.201.107:51782 Data Channel MTU parms [ L:1621 D:1450 EF:121 EB:406 ET:0 EL:3 ] 2020-10-11 20:17:27 us=472246 10.10.201.107:51782 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,auth SHA1,keysize 128,key-method 2,tls-server' 2020-10-11 20:17:27 us=472452 10.10.201.107:51782 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,auth SHA1,keysize 128,key-method 2,tls-client' 2020-10-11 20:17:27 us=472631 10.10.201.107:51782 TLS: Initial packet from [AF_INET]10.10.201.107:51782, sid=99dfa143 100c9c53 2020-10-11 20:17:27 us=472734 10.10.201.107:51782 Control Channel: using tls-crypt-v2 key 2020-10-11 20:17:27 us=472852 10.10.201.107:51782 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key 2020-10-11 20:17:27 us=472950 10.10.201.107:51782 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication 2020-10-11 20:17:27 us=473037 10.10.201.107:51782 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key 2020-10-11 20:17:27 us=473073 10.10.201.107:51782 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 recognised and Valid: 5E80D99E6EBB48C8C7E7FB5987AD1EF3 cw01 2020-10-11 20:17:27 us=557125 10.10.201.107:51782 TLS CRYPT V2 VERIFY SCRIPT OK 2020-10-11 20:17:27 us=623270 10.10.201.107:51782 VERIFY OK: depth=1, CN=easytls 2020-10-11 20:17:27 us=624391 10.10.201.107:51782 VERIFY OK: depth=0, CN=cw01 2020-10-11 20:17:27 us=624828 10.10.201.107:51782 peer info: IV_VER=2.5_rc2 2020-10-11 20:17:27 us=624876 10.10.201.107:51782 peer info: IV_PLAT=win 2020-10-11 20:17:27 us=624909 10.10.201.107:51782 peer info: IV_PROTO=6 2020-10-11 20:17:27 us=624934 10.10.201.107:51782 peer info: IV_NCP=2 2020-10-11 20:17:27 us=624959 10.10.201.107:51782 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM 2020-10-11 20:17:27 us=624977 10.10.201.107:51782 peer info: IV_LZ4=1 2020-10-11 20:17:27 us=624997 10.10.201.107:51782 peer info: IV_LZ4v2=1 2020-10-11 20:17:27 us=625013 10.10.201.107:51782 peer info: IV_LZO=1 2020-10-11 20:17:27 us=625029 10.10.201.107:51782 peer info: IV_COMP_STUB=1 2020-10-11 20:17:27 us=625045 10.10.201.107:51782 peer info: IV_COMP_STUBv2=1 2020-10-11 20:17:27 us=625061 10.10.201.107:51782 peer info: IV_TCPNL=1 2020-10-11 20:17:27 us=625076 10.10.201.107:51782 peer info: IV_HWADDR=08:00:27:10:b8:d0 2020-10-11 20:17:27 us=625094 10.10.201.107:51782 peer info: IV_SSL=OpenSSL_1.1.1h__22_Sep_2020 2020-10-11 20:17:27 us=625110 10.10.201.107:51782 peer info: IV_PLAT_VER=6.1_32bit 2020-10-11 20:17:27 us=625125 10.10.201.107:51782 peer info: IV_GUI_VER=OpenVPN_GUI_11 NO-NO-NO 2020-10-11 20:17:27 us=636464 10.10.201.107:51782 WARNING: Failed running command (--auth-user-pass-verify): external program exited with error status: 1 2020-10-11 20:17:27 us=636561 10.10.201.107:51782 TLS Auth Error: Auth Username/Password verification failed for peer 2020-10-11 20:17:27 us=650336 10.10.201.107:51782 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bit RSA 2020-10-11 20:17:27 us=650482 10.10.201.107:51782 [cw01] Peer Connection Initiated with [AF_INET]10.10.201.107:51782 2020-10-11 20:17:27 us=895839 10.10.201.107:51781 SIGTERM[soft,delayed-exit] received, client-instance exiting 2020-10-11 20:17:28 us=672267 10.10.201.107:51782 PUSH: Received control message: 'PUSH_REQUEST' 2020-10-11 20:17:28 us=672308 10.10.201.107:51782 Delayed exit in 5 seconds 2020-10-11 20:17:28 us=672424 10.10.201.107:51782 SENT CONTROL [cw01]: 'AUTH_FAILED' (status=1) 2020-10-11 20:17:33 us=877372 10.10.201.107:51782 SIGTERM[soft,delayed-exit] received, client-instance exiting }}} **Server log when the client does not send user/pass**: {{{ 2020-10-11 20:07:01 us=409459 MULTI: multi_create_instance called 2020-10-11 20:07:01 us=409499 10.10.201.107:57110 Re-using SSL/TLS context 2020-10-11 20:07:01 us=409536 10.10.201.107:57110 tls-crypt-v2 server key: Cipher 'AES-256-CTR' initialized with 256 bit key 2020-10-11 20:07:01 us=409558 10.10.201.107:57110 tls-crypt-v2 server key: Using 256 bit message hash 'SHA256' for HMAC authentication 2020-10-11 20:07:01 us=409624 10.10.201.107:57110 Control Channel MTU parms [ L:1621 D:1212 EF:38 EB:0 ET:0 EL:3 ] 2020-10-11 20:07:01 us=409642 10.10.201.107:57110 Data Channel MTU parms [ L:1621 D:1450 EF:121 EB:406 ET:0 EL:3 ] 2020-10-11 20:07:01 us=409687 10.10.201.107:57110 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,auth SHA1,keysize 128,key-method 2,tls-server' 2020-10-11 20:07:01 us=409705 10.10.201.107:57110 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,auth SHA1,keysize 128,key-method 2,tls-client' 2020-10-11 20:07:01 us=409744 10.10.201.107:57110 TLS: Initial packet from [AF_INET]10.10.201.107:57110, sid=5cda270d 0cb021ad 2020-10-11 20:07:01 us=409758 10.10.201.107:57110 Control Channel: using tls-crypt-v2 key 2020-10-11 20:07:01 us=409788 10.10.201.107:57110 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key 2020-10-11 20:07:01 us=409805 10.10.201.107:57110 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication 2020-10-11 20:07:01 us=409818 10.10.201.107:57110 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key 2020-10-11 20:07:01 us=409836 10.10.201.107:57110 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 recognised and Valid: 5E80D99E6EBB48C8C7E7FB5987AD1EF3 cw01 2020-10-11 20:07:01 us=431426 10.10.201.107:57110 TLS CRYPT V2 VERIFY SCRIPT OK 2020-10-11 20:07:01 us=461498 10.10.201.107:57110 VERIFY OK: depth=1, CN=easytls 2020-10-11 20:07:01 us=461646 10.10.201.107:57110 VERIFY OK: depth=0, CN=cw01 2020-10-11 20:07:01 us=462062 10.10.201.107:57110 peer info: IV_VER=2.5_rc2 2020-10-11 20:07:01 us=462117 10.10.201.107:57110 peer info: IV_PLAT=win 2020-10-11 20:07:01 us=462141 10.10.201.107:57110 peer info: IV_PROTO=6 2020-10-11 20:07:01 us=462164 10.10.201.107:57110 peer info: IV_NCP=2 2020-10-11 20:07:01 us=462187 10.10.201.107:57110 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM 2020-10-11 20:07:01 us=462208 10.10.201.107:57110 peer info: IV_LZ4=1 2020-10-11 20:07:01 us=462224 10.10.201.107:57110 peer info: IV_LZ4v2=1 2020-10-11 20:07:01 us=462239 10.10.201.107:57110 peer info: IV_LZO=1 2020-10-11 20:07:01 us=462251 10.10.201.107:57110 peer info: IV_COMP_STUB=1 2020-10-11 20:07:01 us=462263 10.10.201.107:57110 peer info: IV_COMP_STUBv2=1 2020-10-11 20:07:01 us=462285 10.10.201.107:57110 peer info: IV_TCPNL=1 2020-10-11 20:07:01 us=462313 10.10.201.107:57110 peer info: IV_HWADDR=08:00:27:10:b8:d0 2020-10-11 20:07:01 us=462343 10.10.201.107:57110 peer info: IV_SSL=OpenSSL_1.1.1h__22_Sep_2020 2020-10-11 20:07:01 us=462357 10.10.201.107:57110 peer info: IV_PLAT_VER=6.1_32bit 2020-10-11 20:07:01 us=462369 10.10.201.107:57110 peer info: IV_GUI_VER=OpenVPN_GUI_11 2020-10-11 20:07:01 us=462384 10.10.201.107:57110 TLS Error: Auth Username/Password was not provided by peer 2020-10-11 20:07:01 us=462396 10.10.201.107:57110 TLS Error: TLS handshake failed 2020-10-11 20:07:01 us=462497 10.10.201.107:57110 SIGUSR1[soft,tls-error] received, client-instance restarting 2020-10-11 20:08:06 us=519418 Control Channel: using tls-crypt-v2 key 2020-10-11 20:08:06 us=519513 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key 2020-10-11 20:08:06 us=519553 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication 2020-10-11 20:08:06 us=519578 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key 2020-10-11 20:08:06 us=519605 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication 2020-10-11 20:08:06 us=519659 MULTI: multi_create_instance called }}}" tct 1356 State reported as RECONNECTING when trying second remote after first one fails Generic / unclassified OpenVPN 2.5.0 (Community Ed) release 2.6 Bug / Defect plaisthos assigned 2020-11-25T19:41:56Z 2020-12-06T19:44:08Z "Ad suggested by @selvanair on GitHub in https://github.com/OpenVPN/openvpn-gui/issues/177: We have two remotes in our .ovpn config file. When the first fails (for instance when that server/line is down), it tries the second remote. The second remote connects, but it sets the state of the connection to ""reconnecting"" instead of ""connecting"". @selvanair responded to that bug report: If connecting to a second remote after failed attempts with another is reported as reconnecting, it looks like a bug in OpenVPN core. This bug will have quite a big impact for our users when they need to connect via the second remote. The connect script of the openvpn-gui is not started as a result of this and the average user will think the connection has failed to be established." ffes 403 Adding routes with gateways that have the same IP address Networking OpenVPN git master branch (Community Ed) release 2.6 Feature Wish Gert Döring assigned 2014-05-12T02:45:15Z 2020-09-09T15:27:25Z "If there are multiple gateways where the IP address on the remote side of the VPN connection are the same, adding routes might point the route to the wrong logical gateway. In src/openvpn/route.c ""add_route"", it only specifies ""via %s"" and not ""dev %s"" to ensure it's routing to the interface that OpenVPN just brought up. I'm not sure if there is a downside to specifying the device explicitly. It seems to only do this if you don't have ENABLE_IPROUTE set and ""is_local_route"" is true. It might be worth eliminating some complexity here by always specifying it." kruton 769 windows binaries auto-updater Generic / unclassified OpenVPN git master branch (Community Ed) release 2.6 Feature Wish Samuli Seppänen assigned 2016-11-15T19:48:46Z 2023-01-10T14:13:31Z "Hi, I think we should have an auto-update function the binaries we provide, namely, ""windows installers"". I've spent a bit of thinking, and it should not be THAT hard to do - in regular intervals (at every startup, once per day, once per week?) the GUI fetches an https URL that has a well-defined format that is easy to parse on windows - xml, json, whatever - in there, there's and tags that specify version numbers and URLs 2.4.1.601https://community.openvpn.net/...I601.exe ... ... (or something that makes sense, is human-understandable, and easy to machine-parse) - when the GUI finds a version number mismatch, present a ""new version available (X), download y/n"" window that will open a browser instance pointing to if confirmed - the URL checked for updates defaults to our community download server, but can be stored in the registry so site admins can control their local update policy Of course I'm not going to code it - lazy me, just throwing ideas at people :-)" Gert Döring 269 "Port SVN r8219 (""Minor fix to process_ipv4_header"") to Git master" Generic / unclassified OpenVPN git master branch (Community Ed) release 2.6 TODO (General task list) Gert Döring assigned 2013-03-21T15:00:00Z 2022-12-21T16:36:15Z Samuli Seppänen 1078 opensolaris fails on tun restart Networking OpenVPN git master branch (Community Ed) release 2.7 Bug / Defect Gert Döring assigned 2018-07-12T08:18:09Z 2023-01-10T10:46:57Z "Jul 12 10:13:05 osol10 openvpn[2435]: [ID 583609 daemon.notice] PUSH: Received control message: 'PUSH_REPLY,route 10.7.38.0 255.255.255.0,route 10.7.39.0 255.255.255.0,route 10.177.36.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 10.177.36.6 10.177.36.5' Jul 12 10:13:05 osol10 openvpn[2435]: [ID 583609 daemon.notice] OPTIONS IMPORT: timers and/or timeouts modified Jul 12 10:13:05 osol10 openvpn[2435]: [ID 583609 daemon.notice] OPTIONS IMPORT: --ifconfig/up options modified Jul 12 10:13:05 osol10 openvpn[2435]: [ID 583609 daemon.notice] OPTIONS IMPORT: route options modified Jul 12 10:13:05 osol10 openvpn[2435]: [ID 583609 daemon.notice] ROUTE: default_gateway=UNDEF Jul 12 10:13:05 osol10 openvpn[2435]: [ID 583609 daemon.error] Can't set PPA 0: File exists (errno=17) Jul 12 10:13:05 osol10 openvpn[2435]: [ID 583609 daemon.notice] Exiting due to fatal error with this config file {{{ client dev tun proto udp remote $host 1194 resolv-retry infinite nobind ping 10 ping-restart 300 persist-key }}}" Gert Döring 1221 SOCKS proxy not working with UDP+IPv6 Networking OpenVPN git master branch (Community Ed) release 2.7 Bug / Defect Gert Döring assigned 2019-10-20T08:25:40Z 2022-12-22T07:52:14Z "The combination of ""use IPv6 to talk to socks proxy *and* {{{proto udp}}}"" does not work today. What happens is that the openvpn client properly opens an IPv6 TCP connection (control) to the SOCKS proxy, but then requests an IPv4 socket. The v4 address returned is then put into the destination for an IPv6 socket, which leads to {{{ Thu Oct 17 16:19:59 2019 write UDPv6: Invalid argument (code=22) Thu Oct 17 16:20:01 2019 write UDPv6: Invalid argument (code=22) }}} looking into socks.c, there's a somewhat easy bugfix - return a v4-mapped v6 address in this case (""if the control connection is v6, a v4 address won't work""). This will still not be the **proper** fix, because OpenVPN will fail in an ipv6-only network. For a proper fix, the socks support needs to be extended to deal with UDPv6 - which is actually twofold: - the UDP socket towards the SOCKS proxy (address requested and returned in {{{establish_socks_proxy_udpassoc()}}} and {{{recv_socks_reply()}}}) - sending the actual packet with an embedded target address ({{{socks_process_outgoing_udp()}}} only does v4 today) - receiving the actual packet with an embedded from address ({{{socks_process_incoming_udp()}}} only does v4 today) Writing this I have the nagging suspicion that {{{--proto udp6 --socks-proxy ...}}} will still fail even if using v4-mapped v6 addresses... as the code would need to understand that the target machine ""behind the socks proxy"" can only be reached by v4 today. This affects 2.4, git master (and very likely 2.3 as well, if explicitly requesting {{{proto udp6}}})." Gert Döring 1397 Fix OCC, get rid of OCC string rewriting Generic / unclassified OpenVPN git master branch (Community Ed) release 2.7 Bug / Defect plaisthos assigned 2021-04-02T12:56:01Z 2022-12-07T14:21:03Z "Related to {{{compress migrate}}} this is the reminder ticket that we want to eventually get rid of the OCC rewriting code, when we can. So, first, fix OCC to become ""useful again"" for options that can be server-pushed. Setting ""milestone 2.6"" as a reminder, but more likely this will happen in the pre-2.7 timeframe." Gert Döring 1457 removing incorrect route on exit Networking release 2.7 Bug / Defect Antonio Quartulli assigned 2022-02-27T23:59:24Z 2023-01-21T18:05:55Z "I have only the following static routes set (before OpenVPN is started): `192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.10` `192.0.2.146 via 192.168.0.1 dev eth0` The OpenVPN config has `redirect-gateway def1` set and the Server has the IP 192.0.2.146. Now when OpenVPN connects it adds the route for the default gateway through the VPN tunnel as it should. It also tries set `/sbin/ip route add 192.0.2.146/32 via 0.0.0.0` which throws a warning with `RTNETLINK answers: No such device`. This is not an issue. But once OpenVPN exits it tries to cleanup the routes and thereby deletes the wrong one. It deletes the one previously existed and that points towards the OpenVPN server. And therefore it won't be able to be restarted. Routing table after OpenVPN exited: `192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.10`" agowa338 243 Allow IPV6 addresses in dhcp-options IPv6 OpenVPN git master branch (Community Ed) release 2.7 Feature Wish Gert Döring assigned 2012-12-07T16:47:43Z 2022-12-21T16:30:20Z "It looks like the check in options.c ""if (ip_addr_dotted_quad_safe (parm)) /* FQDN -- IP address only */"" stops IPv6 addresses used in dhcp-options from being set up on the client. The PUSH seems to be working ok. Fri Dec 07 11:36:31 2012 OpenVPN 2.3_rc1 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [eurephia] [IPv6] built on Nov 6 2012 Fri Dec 07 11:36:36 2012 Options error: dhcp-option parameter DNS '2001:470:xxxx:xxxx::1' must be an IP address Fri Dec 07 11:36:36 2012 Options error: dhcp-option parameter NTP '2001:470:xxxx:xxxx::1' must be an IP address " dennisd 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 647 Cannot connect to 2.3.4 server using client version >= 2.3.9 (TLS Error - handshake failed) Generic / unclassified OpenVPN 2.3.9 (Community Ed) release 2.6 Bug / Defect Gert Döring assigned 2016-01-11T22:38:25Z 2020-09-01T12:58:30Z "Using a 2.3.8 client on Fedora 23 with the following config works fine to connect to a Debian based 2.3.4 server: {{{ client remote openvpn.example.com ca /home/peter/.pki/nssdb/server.ca cert /home/peter/.pki/nssdb/client.crt key /home/peter/.pki/nssdb/client.key dev tun proto udp nobind auth-nocache script-security 2 persist-key persist-tun user openvpn group openvpn }}} (Config exported through NetworkManager). However, after upgrading to 2.3.9 or even 2.3.10 on the client (std. fedora updates) connecting to the Debian based 2.3.4 Server (std. config) does not work anymore. Opening the connection simply times out on the client side, however on the server I can see the following logs: {{{ Jan 11 23:24:17 server systemd[1]: Started OpenVPN connection to server. Jan 11 23:24:50 server ovpn-server[24767]: X:X:X:X:36210 TLS_ERROR: BIO read tls_read_plaintext error: error:0D07207B:asn1 encoding routines:ASN1_get_object:header too long: error:0D068066:asn1 encoding routines:ASN1_CHECK_TLEN:bad object header: error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error: error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error: error:0D08403A:asn1 encoding routines:ASN1_TEMPLATE_EX_D2I:nested asn1 error: error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error: error:1408900D:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:ASN1 lib Jan 11 23:24:50 server ovpn-server[24767]: X.X.X.X:36210 TLS Error: TLS object -> incoming plaintext read error Jan 11 23:24:50 server ovpn-server[24767]: X.X.X.X:36210 TLS Error: TLS handshake failed }}} Downgrading only the openvpn package on the client makes things working again. There doesn't really seem to be a difference in the 2 openvpn versions on the client: {{{ $ openvpn --show-ciphers --show-digests --show-engines; openvpn --version >> 2.3.8 $ sudo dnf update openvpn $ openvpn --show-ciphers --show-digests --show-engines; openvpn --version >> 2.3.10 $ diff -Naur 2.3.8 2.3.10 --- 2.3.8 2016-01-11 23:11:01.773698483 +0100 +++ 2.3.10 2016-01-11 23:11:11.605720665 +0100 @@ -105,7 +105,7 @@ Intel RDRAND engine [rdrand] Dynamic engine loading support [dynamic] -OpenVPN 2.3.8 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Aug 4 2015 +OpenVPN 2.3.10 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Jan 4 2016 library versions: OpenSSL 1.0.2e-fips 3 Dec 2015, LZO 2.08 Originally developed by James Yonan Copyright (C) 2002-2010 OpenVPN Technologies, Inc. }}} The error is 100% reproducible for 2 different Fedora Users, as well as for an Arch Manjaro user. Downgrading below 2.3.9 always solves the issue. Server Config {{{ $ grep '^[a-z]' /etc/openvpn/server.conf port 1194 proto udp dev tun ca ca.crt cert server.crt key server.key # This file should be kept secret dh dh.pem keepalive 10 120 max-clients 100 user nobody group nogroup persist-key persist-tun status openvpn-status.log verb 1 client-config-dir clients tun-mtu 1100 }}}" peter.meier 1396 option restoration on SIGUSR1 is incomplete Generic / unclassified OpenVPN git master branch (Community Ed) release 2.6 Bug / Defect plaisthos assigned 2021-03-31T14:33:56Z 2021-04-17T09:47:43Z "Moin, during review/testing of commit 5a2ed714d14a and commit 7064ccb9f it was found that there are more options that need restoration on SIGUSR1: {{{ compress lz4 route-gateway }}} (if connection A pushes them and B doesn't, and we change from A to B by means of a SIGUSR1 restart, the old values get stuck in the config). There might be more, but this is the ticket to not forget." Gert Döring 1486 "IPv6 Servers do not support ""nopool""" IPv6 OpenVPN 2.5.7 (Community Ed) release 2.6 Bug / Defect Gert Döring assigned 2022-11-22T18:10:10Z 2022-12-03T23:32:02Z "The doc string actually suggests that it maybe should work: https://github.com/OpenVPN/openvpn/blob/15ba808503113f685d254e9007b8e9937e01532d/src/openvpn/helper.c#L158-L172 But the code prevents it: https://github.com/OpenVPN/openvpn/blob/15ba808503113f685d254e9007b8e9937e01532d/src/openvpn/helper.c#L182 Is there any reason why nopool could not be supported for ´server-ipv6´ just like with `server`?" apollo13 1037 client-connect or similar does not fire when OpenVPN client floated Management OpenVPN 2.4.4 (Community Ed) release 2.6 Feature Wish stipa assigned 2018-03-09T15:43:51Z 2020-09-09T15:09:16Z "Hello, I'm using a client-connect script to export all env variables from the connecting clients to temporary files so my management GUI can use them. This works pretty well but not for floating clients. When I look into the man page I see the ipchange cmd. I thought to use that but there's a hint ""Don't use --ipchange in --mode server mode. Use a --client-connect script instead."" but I tried it anyway w/o success because OpenVPN does not start anymore with that parameter active in an OpenVPN server config. The problem is, when a client floats, --client-connect is not fired, nothing is fired so a new IP or a new port is not known from any env variable because it's not there so the temp file cannot get updated so my management GUI does not see the changes. I think this is a bug, at least something should fire when a client floats. I mean these events: Float requested for peer 40 to 1.2.3.4:62487 peer 40 (Common.Name) floated from 1.2.3.4:62487 to [AF_INET]5.6.7.8:62487 Float requested for peer 7 to 2.4.6.8:1025 peer 7 (Other.CommonName) floated from 2.4.6.8:62018 to [AF_INET]2.4.6.8:1025 I'm using OpenvPN 2.4.4 on Debian Linux. Thank you!" mcp 282 Preserve client's default route if networks conflict Networking OpenVPN git master branch (Community Ed) release 2.7 Feature Wish Gert Döring assigned 2013-04-19T18:30:29Z 2022-12-21T16:37:59Z "In case of networks conflict when server pushes a route to client that overlaps client's default route path client's Internet connection becomes useless untill OpenVPN link drops by timeout (if any). That'd be best an option like 'route-protect def1' for clients' config that'd mean: add the metric 1 most specific path route to current default gateway through current device of client's network stack to preserve Internet connectivity in case server pushes any route that overlaps current default gateway route (if not present yet)' That could solve an uncommon but unresolvable configuration where: - client's local net IF is 172.16.86.167/22 - client's default route is 172.16.84.1 - server pushes a route '172.16.84.0 255.255.255.0' on successful connect I guess people'd better optionally sacrifice 172.16.84.1 on remote tunneled network than total internet connectivity if random hotel network's administrator made BINGO of one's private address space." santjago 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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@… 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 554 Add support for partial TLS record reads (i.e. support 1/n-1 record splitting) Crypto OpenVPN git master branch (Community Ed) release 2.7 Bug / Defect new 2015-05-16T10:15:45Z 2023-01-10T10:39:44Z "This ticket is a follow-up for #524. OpenVPN assumes that its control channel messages are sent and received unfragmented, which is actually not conforming to the TLS spec. See RFC5246, section 6.2.1: Client message boundaries are not preserved in the record layer (i.e., multiple client messages of the same ContentType MAY be coalesced into a single TLSPlaintext record, or a single message MAY be fragmented across several records). In practice, this assumption only becomes invalid if 1/n-1 record splitting is enabled in PolarSSL/mbed TLS. As a quick fix for #524, record splitting is explicitly disabled. (That should be fine for openvpn. Record splitting is a counter measure against the BEAST attack, which requires an attacker to influence the data in the records to obtain other data in the same record. But unlike browsers, openvpn does not give an attacker control over the transmitted data.) Still, I think we should adhere to the spec to be able to support tricks like 1/n-1 splitting. It will make OpenVPN more robust against future changes in SSL libraries." Steffan Karger 755 --ifconfig-push should warn on topology Generic / unclassified OpenVPN git master branch (Community Ed) release 2.7 Bug / Defect Gert Döring new 2016-10-27T16:59:43Z 2023-01-10T10:40:37Z "if people have ccd/ configs containing {{{ --ifconfig-push 10.0.0.8 10.0.0.1 }}} and move to {{{ --topology subnet }}}, this will explode as the client needs to see {{{ --ifconfig-push 10.0.0.8 255.255.255.0 }}} (or the like) instead. We currently just pass on the option, and not issue a warning - and then the client dies on ifconfig. We should at least warn..." Gert Döring 765 cleanup tun.c and route.c wrt operating system variants Networking OpenVPN git master branch (Community Ed) release 2.7 Bug / Defect Gert Döring new 2016-11-10T21:08:54Z 2022-12-22T09:07:32Z "as promised: cleanup tun.c and route.c to get rid of the massive repetition of ""nearly the same"" argv_print() etc. calls to call ifconfig/ip/route (By, for example, having a describing structure for each operating system that is then parsed by a more general ""interpreter"" - ""need $local/$bits and $gateway"" - plus flags ""need arbitrary remote"", etc.)" Gert Döring 1297 feature wish: IPv6 subnet delegation Installation OpenVPN git master branch (Community Ed) release 2.7 Bug / Defect new 2020-06-27T19:40:10Z 2023-01-10T11:09:35Z "Delegate not only single IPv6 addresses (""ifconfig-ipv6-pool"" today) to clients, but whole subnets. Inspired by a question on twitter, ""how can I give each of my OpenVPN clients a /64"". You can, by means of {{{--client-config-dir}}} or {{{--client-connect}}}, but having this built-in would be nice. It needs pool handling on the server, and some sort of ""what to do with that /64"" logic on the client side - the client doesn't need it for its tun/tap interface (single IP from the transit network is sufficient), so it would need to be handed over towards ""something"" which does ""something"" to it (like: pass it to docker clients, use it to configure LAN interface for PCs behind routers, whatever). https://twitter.com/GeherRetep/status/1276924676082671617" Gert Döring 1301 Route: Waiting for TUN / TAP interface to come up ... Generic / unclassified OpenVPN 2.4.8 (Community Ed) release 2.7 Bug / Defect new 2020-07-13T16:31:59Z 2023-01-10T10:49:05Z "Greetings. I observe the following problem when connecting to OpenVPN 2.4.9-I601-win10: If on the local interface the gateway address is on a different subnet, then when I try to connect to OpenVPN, I get the following: TEST ROUTES: 18/38 succeeded len = 38 ret = 0 a = 0 u / d = up Route: Waiting for TUN / TAP interface to come up ... If you enable more detailed logging (verb 7), then the log contains the following lines with the addition of routes with a negative index and a large metric: Fri Jul 10 13:31:09 2020 us = 361160 DEBUG: IP Locate: ip = 192.168.1.1 nm = 0.0.0.0 index = -1 count = 0 metric = 2147483647 I understand that the problem is the lack of the correct route, but I saw similar connection configurations at airports and the metro. ipconfig: IPv4-адрес. . . . . . . : 192.168.1.200 Netmask . . . . . . . . : 255.255.255.128 Gateway. . . . . . . . . : 192.168.1.1 DNS. . . . . . . . . . . : 8.8.8.8 " lozhkinalexey 1340 UDP reflection amplification attack Generic / unclassified release 2.7 Bug / Defect new 2020-10-19T23:38:21Z 2023-01-10T10:38:55Z "I run a server that was subject to a DDoS attack today that appears to be a UDP reflection amplification attack coming from openvpn. I have searched the bug tracker, forums, CVEs, source, etc and could not find any mention of such a vulnerability, so I am asking here. Apologies if this is already solved or not an issue, but I was unable to determine so maybe at least it would help to document things. What I am seeing is floods of P_CONTROL_HARD_RESET_SERVER_V2 packets coming from port 1194 on hundreds of source IPs. I searched around and found some things that might be related: * Maybe the original vulnerability description https://www.freebuf.com/vuls/215171.html * Maybe related articles: * https://www.netscout.com/sites/default/files/2020-02/SECR_001_EN-2001_Web.pdf * https://govcyberhub.com/2020/03/26/new-vectors-new-techniques-the-evolution-of-ddos-attacks/ * https://nsfocusglobal.com/what-you-should-know-about-openvpn-reflection-attacks/ * Bug in SoftEtherVPN (maybe based on openvpn? source looks different) with a good description and a python script POC https://github.com/SoftEtherVPN/SoftEtherVPN/issues/1001 I plan to contact the network admins of the IPs used in the attack and I would like to include information on what course of action they should take. Thanks " mtaggart 415 IPv6 link-local address handling in tun mode IPv6 OpenVPN git master branch (Community Ed) release 2.7 Feature Wish Gert Döring new 2014-06-08T10:56:59Z 2022-12-21T17:07:47Z "Right now, IPv6 link-local addresses (source fe80:xxx) are not handled ""as the standards require"" - which is usually not a problem as the tun interfaces are seen as point-to-point, needing no neighbour discovery, etc. If we ever want to support things like DHCPv6 over multipoint tun, or more dynamic routing, etc., the p2pm server needs to support source address learning for fe80:: addresses (configurable?). Commit 70f1864188ad00451683cabf51e56b7730250c40 at least silences the quite annoying warning about invalid source addresses for fe80:: but leaves open the actual handling. For 2.4..." Gert Döring 552 check that ip forwarding is enabled Networking OpenVPN git master branch (Community Ed) release 2.7 Feature Wish new 2015-05-12T09:32:30Z 2023-01-10T10:52:04Z "11:24 [sjms(~sander@resolver2.steffann.nl)] when adding IPv6 to a linux box VPN server, do not forget to enable IPv6 forwarding..... 11:29 [msg(sjms)] hrhr, maybe we should add a sysctl check to see whether forwarding is actually on :) (on Linux, FreeBSD, windows?) no idea on whether this is doable with small effort, reasonable, etc..." Gert Döring 795 Add --port-share logging Generic / unclassified OpenVPN git master branch (Community Ed) release 2.7 Feature Wish new 2016-12-19T17:35:38Z 2023-01-01T14:38:00Z Currently, port-share has the optional parameter dir to store the source IP:port of the client connection and the source IP:port of the connection to the proxy receiver. However, it's not persistent. Can we also have the option to send these mappings to a log file? One use case is web server log can work with this log file to find all the original client IP and port. wliang 1043 "decouple IPv4 and IPv6 pool persistence so ""static IPv6 in ipp.txt"" works" Configuration OpenVPN git master branch (Community Ed) release 2.7 Feature Wish new 2018-03-17T15:02:10Z 2023-01-10T11:02:18Z "Hello, I've noticed a bug that specified ipv6 addresses for given clients are not loaded from file upon ovpn server start. So, there is no way to configure static IPv6 mappings for clients :( In log file there is a string with ""TODO: IPV6"", but it seems like it's never been implemented. Thanks." eshieldx 1061 Client cannot reconnect because of pushed routes Networking OpenVPN git master branch (Community Ed) release 2.7 Feature Wish new 2018-05-03T12:04:31Z 2023-01-10T11:04:22Z "Hey, I have checked currently reported bugs and I am pretty sure this one wasn`t in there. If I have missed it - then I would like to apologize and you can remove this ticket by pointing me to the appropriate issue. The issue is described in the following steps which can also be used to recreate it: 1. Connect to VPN server 2. Remove eth cable from the PC 3. Wait till you get Inactivity timeout error 4. Put the cable back in and wait for the client to reconnect (it cannot) 5. Check routing table: {{{ 0.0.0.0/1 via 10.7.7.1 dev tun0 default via 192.168.2.1 dev enp1s0 proto dhcp metric 20100 10.7.7.0/24 dev tun0 proto kernel scope link src 10.7.7.2 128.0.0.0/1 via 10.7.7.1 dev tun0 169.254.0.0/16 dev enp1s0 scope link metric 1000 192.168.2.0/24 dev enp1s0 proto kernel scope link src 192.168.2.51 metric 100 }}} 6. Remove these routes: {{{ 0.0.0.0/1 via 10.7.7.1 dev tun0 10.7.7.0/24 dev tun0 proto kernel scope link src 10.7.7.2 128.0.0.0/1 via 10.7.7.1 dev tun0 }}} 7. Successfully reconnect I guess you can already see where the issue is. The routes aren`t removed, and the client tries to initiate the connection via the tunnel which no longer exists. Same with TCP and UDP. Log: {{{ Thu May 3 14:21:25 2018 Initialization Sequence Completed Thu May 3 14:26:58 2018 [185.245.86.157] Inactivity timeout (--ping-restart), restarting Thu May 3 14:26:58 2018 SIGUSR1[soft,ping-restart] received, process restarting Thu May 3 14:26:58 2018 Restart pause, 5 second(s) Thu May 3 14:27:03 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]185.245.86.157:443 Thu May 3 14:27:03 2018 Socket Buffers: R=[87380->425984] S=[16384->425984] Thu May 3 14:27:03 2018 Attempting to establish TCP connection with [AF_INET]185.245.86.157:443 [nonblock] Thu May 3 14:29:03 2018 TCP: connect to [AF_INET]185.245.86.157:443 failed: Connection timed out Thu May 3 14:29:03 2018 SIGUSR1[connection failed(soft),init_instance] received, process restarting Thu May 3 14:29:03 2018 Restart pause, 5 second(s) }}} Relevant client configs: {{{ client dev tun proto tcp resolv-retry infinite remote-random nobind persist-key persist-tun reneg-sec 0 remote-cert-tls server pull fast-io }}} Client version: OpenVPN 2.4.4 Relevant server configs: {{{ push ""redirect-gateway def1"" topology subnet }}} Server version: OpenVPN 2.4.5 ---- If you need further information from me - please let me know. " ar4chn0 1084 net_gateway is only working for IPv4 IPv6 OpenVPN git master branch (Community Ed) release 2.7 Feature Wish Gert Döring new 2018-08-12T11:14:31Z 2023-01-10T11:05:13Z "Related to conversation on #openvpn with ordex, net_gateway is not converting to IPv6 gateway when used in 'route-ipv6 A:A:A:A/64 net_gateway' This is not a bug but a feature request. Usecase: using stunnel on top of OpenVPN, I have to add the OpenVPN IPv6/64 to the client side for maintening the stunnel and not passsing the stunel into OpenVPN as this break it." belette2B 1161 --route-ipv6 does not recognize net_gateway or net_gateway-ipv6 IPv6 OpenVPN git master branch (Community Ed) release 2.7 Feature Wish Gert Döring new 2019-02-24T19:19:17Z 2023-01-10T11:06:45Z "On a client with the following entries in the configuration file {{{ route 8.8.8.8 255.255.255.255 net_gateway route-ipv6 2001:4860:4860::8888/128 net_gateway }}} The first one (IPv4) works like a charm, but the second one (IPv6) causes the following log error: {{{ OpenVPNROUTE6: cannot parse gateway spec 'net_gateway' }}} Following convention and replacing net_gateway with net_gateway-ipv6 yields the following error: {{{ OpenVPNROUTE6: cannot parse gateway spec 'net_gateway-ipv6' }}} The documented functionality that a route is added with the pre-existing IP default gateway as its gateway (with the effect of routing this traffic outside of the tunnel) only works for IPv4 but not for IPv6. Version information: {{{ OpenVPN 2.4.7 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Feb 21 2019 Windows version 6.2 (Windows 8 or greater) 64bit library versions: OpenSSL 1.1.0j 20 Nov 2018, LZO 2.10 }}} " mike_SF 1192 review CONFIGURE_DEFINES in config Building / Compiling OpenVPN git master branch (Community Ed) release 2.7 Feature Wish new 2019-06-05T09:00:35Z 2022-12-22T08:00:17Z "right now, config.h has something like this: {{{ /* config.h.in. Generated from configure.ac by autoheader. */ /* Configuration settings */ #define CONFIGURE_DEFINES ""enable_async_push=no enable_comp_stub=no 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=yes 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=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_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"" }}} we should investigate before 2.5 whether these are the **relevant** things to have there - like, do we want {{{enable_sitnl}}}? Does that {{{with_aix_soname}}} thing make any sense? What is all the rest?" Gert Döring 1327 "revisit msg() messagelevels, go away from ""M_INFO for everything""" Generic / unclassified OpenVPN git master branch (Community Ed) release 2.7 Feature Wish new 2020-09-15T08:01:39Z 2023-01-10T11:08:11Z "errlevel.h has a nice collection of D_ flags for ""log this only for --verb 3 or higher, and rate-limit"" etc. (D_IFCONFIG_POOL()) - so stuff like pool.c shouldn't do {{{ msg(M_INFO, ""ifconfig_pool_read(), in='%s'"", BSTR(&in)); }}} for ""we read this lengthy file, here's line-by-line output"" - M_INFO is ""1"", so nearly always printed... But we have very many of these, so - come to agreement what we want to use - document this - go through the files one-by-one and use ""the right"" code" Gert Döring 1408 Error on client built with --disable-lzo: write to TUN/TAP : Unknown error (fd=-1,code=122) Generic / unclassified OpenVPN git master branch (Community Ed) release 2.7 Feature Wish new 2021-05-25T14:43:54Z 2022-12-07T13:40:09Z "Connection stays up but no traffic seems to flow. Server: 2.4.4-2ubuntu1.5 Windows 10 Client: 2.6 master built with --disable-lzo --disable-lz4 Sever pushes compress-stub-v2 if it reports IV_COMP_STUBv2 (and compress lzo to older clients). {{{PUSH: Received control message: 'PUSH_REPLY,route-gateway 10.178.11.1,topology subnet,ping 30,ping-restart 180,compress stub-v2, route xxx 255.255.255.255,route xxx 255.255.255.255,dhcp-option DOMAIN xxx,dhcp-option DNS xxx,dhcp-option DNS xxx,register-dns,ifconfig 10.178.11.2 255.255.255.0,peer-id 0,cipher AES-256-GCM'}}} {{{openvpn.exe --version reports}}} {{{ OpenVPN 2.6_git x86_64-w64-mingw32 [SSL (OpenSSL)] [PKCS11] [AEAD] built on May 25 2021 library versions: OpenSSL 1.1.1j 16 Feb 2021 Windows version 10.0 (Windows 10 or greater) 64bit Originally developed by James Yonan Copyright (C) 2002-2018 OpenVPN Inc Compile time defines: enable_async_push=no enable_comp_stub=no enable_crypto_ofb_cfb=yes enable_debug=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=no enable_lzo=no enable_management=yes enable_pam_dlopen=no enable_pedantic=no enable_pf=yes enable_pkcs11=yes enable_plugin_auth_pam=no enable_plugin_down_root=no enable_plugins=yes enable_port_share=yes enable_selinux=no enable_shared=yes enable_shared_with_static_runtimes=yes enable_small=no enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=no enable_werror=no enable_win32_dll=yes enable_wolfssl_options_h=yes enable_x509_alt_username=no with_aix_soname=aix with_crypto_library=openssl with_gnu_ld=yes with_mem_check=no with_special_build= with_sysroot=no }}}" kitsune1 1419 Could you add groups of clients with different ranges of ip addresses Generic / unclassified OpenVPN 2.5.1 (Community Ed) release 2.7 Feature Wish new 2021-07-19T03:57:56Z 2022-12-22T09:15:15Z "Could you add groups of clients with different ranges of ip addresses? For instance: Admins group with range of ip addresses 192.168.10.1-192.168.10.10. Users group with range of ip addresses 192.168.10.11-192.168.10.20. It give opportunity connecnt from multuple device in the same time with correct range of ip addresses. " maxim4 1451 handle packets from [::] and [fe80:...] in tun-p2mp IPv6 release 2.7 Feature Wish Gert Döring new 2022-02-07T15:50:25Z 2022-12-22T07:33:51Z "As originally reported in TODO.IPv6: > (most likely those are DAD packets) > silently ignore DAD? > Or accept-and-forward iff (multicast && client2client)? > handle NS/NA" Antonio Quartulli 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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@… 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 226 '--auth-user-pass-verify