{5} Accepted, Active Tickets by Owner (Full Description) (29 matches)

List tickets accepted, group by ticket owner. This report demonstrates the use of full-row display.

cron2 (11 matches)

Ticket Summary Component Milestone Type Created
Description
#336 --port-share doesn't work from 2.3.0 release Generic / unclassified Bug / Defect 09/25/13

When I use --port-share in my config and try to load web page firefox returns “SSL received a record that exceeded the maximum permissible length.”

2.2.2: $ telnet localhost 443 Trying ::1... Connected to localhost. Escape character is ']'.

2.3.x: $ telnet localhost 443 Trying ::1... Connected to localhost. Escape character is ']'. *@R?0 C%H?RB??*@R?0?(?%? ?K5?y?S???? ???jҷ?RB??*@R?0 ?K5?@??&?X?Qp???F?g.???RB??*@R?0 ?K5???w??g????e?? ?w??RB??*@R?0 ?K5?6??f?qB-H???JۅtZRB??Connection closed by foreign host.

I mean I don't press any key but server sends some data


#745 1 byte overread in mss_fixup_dowork Generic / unclassified release 2.3.14 Bug / Defect 09/30/16

make openvpn-2.3.12 like this:

CFLAGS="-fsanitize=address" ./configure && make

Call mss_fixup_ipv4 directly:

    unsigned char payload[] = {
        0x3e, 0x28, 0x00, 0x54, 0x3a, 0x51, 0x60, 0x00, 0x21, 0x06, 0x89, 0x27,
        0xde, 0x21, 0x27, 0xf1, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x09, 0x01,
        0x01, 0x01, 0x01, 0x01, 0x11, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
        0x01, 0x01, 0x01, 0x01, 0x01, 0x7e, 0x7e, 0x7e, 0x7e, 0x7e, 0x7e, 0x7e,
        0x7e, 0x7e, 0x7e, 0x7e, 0x7e, 0x7e, 0x7e, 0x7e, 0x7e, 0x7e, 0x7e, 0x7e,
        0x7e, 0x7e, 0x7e, 0x7e, 0x7e, 0x7e, 0x7e, 0x7e, 0x7e, 0x7e, 0x7e, 0x7e,
        0x7e, 0x7e, 0x7e, 0x7e, 0x7e, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x33
    };
    unsigned int payload_len = 84;
    struct gc_arena gc = gc_new ();
    struct buffer b = alloc_buf_gc (payload_len, &gc);
    memcpy(b.data, payload, payload_len);
    b.len += payload_len;
    mss_fixup_ipv4(&b, 100);
    gc_free (&gc);

This should trigger ASAN. I haven't attempted to trigger this remotely with an actual OpenVPN instance, but it's probably possible?

Proposed patch:

diff --git a/mss.c b/mss.c
index 7298c7b..715d837 100644
--- a/mss.c
+++ b/mss.c
@@ -153,6 +153,9 @@ mss_fixup_dowork (struct buffer *buf, uint16_t maxmss)
     else if (*opt == OPENVPN_TCPOPT_NOP)
       optlen = 1;
     else {
+        if ( optlen == 1 ) {
+            break;
+        }
       optlen = *(opt + 1);
       if (optlen <= 0 || optlen > olen)
         break;

#29 push-reset should not reset topology and route-gateway from global config Documentation release 2.4 Feature Wish 07/21/10

When using push-reset, all "push" option are reset (this also include topology and route-gateway).

Considering this server conf:

route 192.168.34.0 255.255.255.0
server 10.9.0.0 255.255.255.0

Considering a client with this part of the conf in his ccd's file:

push-reset
route 192.168.33.0 255.255.255.0
route 192.168.32.0 255.255.255.0

I expect client to get an IP in 10.9.0.0/24 range and get route added for 192.168.33.0/24 and 192.168.32.0/24 (but not 192.168.34.0/24)

In topology net30 (default topology) it works perfectly, but does not in topology subnet. The reason is that in topology subnet, the following options MUST to be pushed:

  • topology subnet
  • route-gateway 10.9.0.1

Whithout these, the client will fail to set itself up with the following message:

Wed Jul 21 21:00:01 2010 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Jul 21 21:00:01 2010 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Wed Jul 21 21:00:01 2010 [server] Peer Connection Initiated with [AF_INET]192.168.51.128:1195
Wed Jul 21 21:00:03 2010 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Wed Jul 21 21:00:03 2010 PUSH: Received control message: 'PUSH_REPLY,route 192.168.33.0 255.255.255.0,route 192.168.32.0 255.255.255.0,ifconfig 10.9.0.2 255.255.255.0'
Wed Jul 21 21:00:03 2010 OPTIONS IMPORT: --ifconfig/up options modified
Wed Jul 21 21:00:03 2010 OPTIONS IMPORT: route options modified
Wed Jul 21 21:00:03 2010 WARNING: Since you are using --dev tun with a point-to-point topology, the second argument to --ifconfig must be an IP address.  You are using something (255.255.255.0) that looks more like a netmask. (silence this warning with --ifconfig-nowarn)
Wed Jul 21 21:00:03 2010 ROUTE default_gateway=192.168.2.1
Wed Jul 21 21:00:03 2010 TUN/TAP device tun0 opened
Wed Jul 21 21:00:03 2010 TUN/TAP TX queue length set to 100
Wed Jul 21 21:00:03 2010 /sbin/ifconfig tun0 10.9.0.2 pointopoint 255.255.255.0 mtu 1500
SIOCSIFDSTADDR: Invalid argument

It seems to me that overriding topology and route-gateway from ccd can only break things and make the connection unusable. Also they become compulsary and redundant when using push-rest in topology subnet .

Even though it can be worked-around by adding them to the ccd's file, it become a bit more complexed to handle these when the push options of the user are store remotely as this would involve to have a specific route-gateway set up for each openvpn server that will get users config from that remote backend.

What do you guys think? should those opeions (topology/route-gateway) be reset from push list ? or just overriden when provided by ccd's file.

Tks


#662 NetBSD: topology subnet tun setup causes quagga routing to ignore interface Generic / unclassified Patch submission 02/24/16

configuring openvpn using subnet topology usin dev tun initializes the tun dev as point-to-point device and issues an ifconfig setting a specific end-point address (consistent with p2p).

Such setup however, causes routing software (quagga ripd in my case) to detect a p2p if and therefore not to forward any other address of the configured subnet to the if in use.

On netbesd setting up tun dev may use IFF_BROADCAST in place of IFF_POINTTOPOINT to create a broadcast capable tun dev that will allow configuring a true subnet.

Applying the attached patch will change the NetBSD specific part of tun.c to use IFF_BROADCAST oand use the proper ifconfig command line for fitting with if semantic detection from other programs (like ripd).


#495 src/plugins/down-root/down-root.c should not include <err.h> directly Generic / unclassified Bug / Defect 12/29/14

configure script will detect the existence of <err.h> , if <err.h> 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.


#496 src/plugins/down-root/down-root.c should use src/compat/compat-daemon.c when daemon() not exist plug-ins / plug-in API Bug / Defect 12/29/14

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.


#587 Add sanity checks, replace deprecated calls in OpenVPN 2.3.x Generic / unclassified release 2.3.14 Bug / Defect 08/03/15

Hello All,

In reviewing source files in OpenVPN 2.3.x, I found some

missing checks for return values for library function calls in C. In directory 'openvpn-2.3.x/src/openvpn', file 'route.c' there is a call to socket() which is not checked for a return value of < 0, indicating error. Additionally, there are a number of instances where the deprecated function bzero() is called in route.c, which should be replaced by memset() (which is used everywhere else in OpenVPN-2.3.x).

The patch file below should address these issues:

--- route.c.orig 2015-08-01 16:54:22.478831925 -0400 +++ route.c 2015-08-02 11:41:50.451396086 -0400 @@ -2644,9 +2644,9 @@

seq = 0; rtm_addrs = RTA_DST | RTA_NETMASK;

  • bzero(&so_dst, sizeof(so_dst));
  • bzero(&so_mask, sizeof(so_mask));
  • bzero(&rtm, sizeof(struct rt_msghdr));

+ memset(&so_dst, 0, sizeof(so_dst)); + memset(&so_mask, 0, sizeof(so_mask)); + memset(&rtm, 0, sizeof(struct rt_msghdr));

rtm.rtm_type = RTM_GET; rtm.rtm_flags = RTF_UP | RTF_GATEWAY;

@@ -2665,6 +2665,13 @@

rtm.rtm_msglen = l = cp - (char *)&m_rtmsg;

s = socket(PF_ROUTE, SOCK_RAW, 0);

+ if (s < 0) + { + msg(M_WARN|M_ERRNO, "Unable to open default gateway from route socket:"); + gc_free (&gc); + close(s); + return; + }

if (write(s, (char *)&m_rtmsg, l) < 0)

{

@@ -2758,10 +2765,10 @@

seq = 0; rtm_addrs = RTA_DST | RTA_NETMASK | RTA_IFP;

  • bzero(&m_rtmsg, sizeof(m_rtmsg));
  • bzero(&so_dst, sizeof(so_dst));
  • bzero(&so_mask, sizeof(so_mask));
  • bzero(&rtm, sizeof(struct rt_msghdr));

+ memset(&m_rtmsg, 0, sizeof(m_rtmsg)); + memset(&so_dst, 0, sizeof(so_dst)); + memset(&so_mask, 0, sizeof(so_mask)); + memset(&rtm, 0, sizeof(struct rt_msghdr));

rtm.rtm_type = RTM_GET; rtm.rtm_flags = RTF_UP | RTF_GATEWAY;

@@ -2965,9 +2972,9 @@

seq = 0; rtm_addrs = RTA_DST | RTA_NETMASK;

  • bzero(&so_dst, sizeof(so_dst));
  • bzero(&so_mask, sizeof(so_mask));
  • bzero(&rtm, sizeof(struct rt_msghdr));

+ memset(&so_dat, 0, sizeof(so_dat)); + memset(&so_mask, 0, sizeof(so_mask)); + memset(&rtm, 0, sizeof(struct rt_msghdr));

rtm.rtm_type = RTM_GET; rtm.rtm_flags = RTF_UP | RTF_GATEWAY;

In directory 'openvpn-2.3.x/src/openvpn', file 'ssl_polarssl.c', there is a call to strdup() which is not checked for a return value of NULL, indicating failure. The patch file below should address this issue:

--- ssl_polarssl.c.orig 2015-08-01 16:44:03.777831925 -0400 +++ ssl_polarssl.c 2015-08-01 16:47:08.764831925 -0400 @@ -192,7 +192,10 @@

/* Parse allowed ciphers, getting IDs */ i = 0; tmp_ciphers_orig = tmp_ciphers = strdup(ciphers);

- + if (NULL == tmp_ciphers) { + msg(M_FATAL, "Unable to allocate memory for ciphers..."); + return; + }

token = strtok (tmp_ciphers, ":"); while(token)

{

In directory 'openvpn-2.3.x/sample/sample-plugins/defer', file 'simple.c', there is a call to calloc() which is not checked for a return value of NULL, indicating failure. The patch file below should address this issue:

--- simple.c.orig 2015-08-01 17:13:50.357831925 -0400 +++ simple.c 2015-08-01 17:15:27.551831925 -0400 @@ -132,6 +132,10 @@

  • Allocate our context */

context = (struct plugin_context *) calloc (1, sizeof (struct plugin_context));

+ if (NULL == context) { + printf ("MEMORY_ALLOCATION for context failed...\n"); + return NULL; + }

context->test_deferred_auth = atoi_null0 (get_env ("test_deferred_auth", envp)); printf ("TEST_DEFERRED_AUTH %d\n", context->test_deferred_auth);

In directory 'openvpn-2.3.x/sample/sample-plugins/log', file 'log.c', there is a call to calloc() which is not checked for a return value of NULL, indicating failure. The patch file below should address this issue:

--- log.c.orig 2015-08-01 17:21:06.813831925 -0400 +++ log.c 2015-08-01 17:22:13.086831925 -0400 @@ -77,6 +77,10 @@

  • Allocate our context */

context = (struct plugin_context *) calloc (1, sizeof (struct plugin_context));

+ if (NULL == context) { + printf("Unable to allocate memory for context\n"); + return NULL; + }

/*

  • Set the username/password we will require.

In file 'log_v3.c' in the above directory, there is a call to calloc() which is not checked for a return value of NULL, indicating failure. The patch file below should address this issue:

--- log_v3.c.orig 2015-08-01 17:17:36.741831925 -0400 +++ log_v3.c 2015-08-01 17:19:13.187831925 -0400 @@ -106,6 +106,10 @@

/* Allocate our context */ context = (struct plugin_context *) calloc (1, sizeof (struct plugin_context));

+ if (NULL == context) { + printf("Unable to allocate memory for context\n"); + return OPENVPN_PLUGIN_FUNC_ERROR; + }

/* Set the username/password we will require. */ context->username = "foo";

In directory 'openvpn-2.3.x/src/openvpn', file 'crypto.c', a call to memset() at approximately line 1022 is made with pointer variable 'output', but if memset() is called with a memory area which is set to NULL, a segmentation violation/fault will occur. The patch file below adds a check to test the value of 'output' for NULL:

--- crypto.c.orig 2015-08-01 17:27:21.039831925 -0400 +++ crypto.c 2015-08-01 17:38:39.031831925 -0400 @@ -1022,6 +1022,9 @@

md_ctx_t md;

ASSERT (len >= md_kt_size(digest));

+ if (NULL == output) + msg(M_FATAL, "memory area for variable 'output' is NULL"); +

memset (output, 0, len);

md_ctx_init(&md, digest);

Comments, Questions, Suggestions, Complaints :)

I am attaching the patch file(s) to this bug report...

Bill Parker (wp02855 at gmail dot com)


#626 Routing entry not deleted when MAC address moves from client to server Networking Bug / Defect 11/09/15

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. <sales@openvpn.net>
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?


#264 [PATCH] IPv6 p2p issues IPv6 release 2.4 Feature Wish 02/25/13

I had a couple problems adding IPv6 to an existing IPv6 p2p tunnel configuration. I want to use:

# server
 ifconfig-ipv6 2620:83:8000:3088::101/128 2620:83:3000:8088::445
# client
ifconfig-ipv6 2620:83:8000:3088::445/128 2620:83:3000:8088::101

First I ran into:

ifconfig-ipv6: /netbits must be between 64 and 124, not /128

Once I "fixed" that the ifconfig command issued was missing the remote end:

# server
openvpn_test[57456]: /sbin/ifconfig tun6 inet6 2620:83:3000:8088::101/128

Attached are patches for both changes I needed.


#498 Support dynamic IPv6 prefixes in server config rather than hardcoded prefixes. IPv6 release 2.5 Feature Wish 01/02/15

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 <prefix>::100. The <prefix> 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).


#808 ifconfig-push-ipv6 should behave like ifconfig-push (DNS names) IPv6 release 2.5 Feature Wish 12/30/16

Since ifconfig-push allows the use of dns names that will be resolved by the server and then pushed to the client, it should be possible to do the same with ipv6. Otherwise the dns names for client adresses in the custom client configs is semi useless.

p.ex. one might want to use: ifconfig-push name.example.com 255.255.255.0 # maybe even change to /24 to be more consistent with below... ifconfig-ipv6-push name.example.com /64

It is useful cause it allows address changes by changing dns zones which will have to be done either way when using dns names in the first place.

Another reason is consistency in my opinion ipv6 specific config options should behave as their counterparts (where possible)

It looks like the resolver part needs to go somewhere in between there: https://github.com/OpenVPN/openvpn/blob/master/src/openvpn/options.c#L1069

Since I'm not familiar with the ovpn source I'm not sure if there are routines/helper for resolving ipv6 addresses so before considering implementing this I thought I get some ideas/feedback first.


dazo (1 match)

Ticket Summary Component Milestone Type Created
Description
#840 Server --auth-gen-token and client --auth-nocache do not work together Configuration Bug / Defect 02/07/17

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


ecrist (2 matches)

Ticket Summary Component Milestone Type Created
Description
#818 easy-rsa package does not contain windows binaries easy-rsa Bug / Defect 01/08/17

This might have been reported more often. But the latest release on https://github.com/OpenVPN/easy-rsa/releases does not contain the binaries for windows need to run the script.

One can pluck most of the binaries from previous releases but i had to get mktemp.exe from somewhere else entirely.

Please include them into the package or make an extra package available that contains the required binaries.

Also in several places it is stated that easy-rsa is no longer part of the openvpn package and then you get forwarded to the 3.x github. However, easy-rsa is still an option to be installed in 2.4


#9 MacOSX making .dmg/.pkg Packaging Patch submission 05/19/10

http://thread.gmane.org/gmane.network.openvpn.devel/3589

A generic packaging script for OS X (pkg/dmg), and a basic binary Installer packages for PowerPC and Intel. It's meant only for distributing the generic binary distribution, analogous to any other UNIX binary package. A small addition is a script which installs an OS X launchd service, net.openvpn.


janjust (1 match)

Ticket Summary Component Milestone Type Created
Description
#160 openvpn sometimes doesn't provide 'common_name' env. var during client-disconnect execution. plug-ins / plug-in API release 2.4 Bug / Defect 09/12/11

Hi!

I have a client-disconnect script which gets executed when users disconnect. Although I'm push'ing "explicit-exit-notify" to clients, sometimes it happens that they disconnect abruptly (because of flaky internet connections). For a long time the client-disconnect script has never failed me, and it cleaned up after the user, but to be able to do this, it needs the 'common_name' environment variable, which provides me the username (I'm using username/password auth, not key files). Unfortunately, every now and then, there is a user, who loses her/his internet connection, and I'm starting to get these in the server logs:

read UDPv4 [ECONNREFUSED]: Connection refused (code=111)

Then after ten or so messages, the client-disconnect script's log entries:

client-disconnect: undefined username!

The code is simple which provides this: it simply checks for the 'common_name' env. var existence. I've gathered additional information from the time when this has happened. These informations are produced by the same client-disconnect script, which couldn't find the 'common_name' env. variable:

  • ENVIRONMENT VARIABLES:
    time_ascii=Sat Sep 10 15:35:02 2011
    daemon_start_time=1315566047
    ifconfig_local=10.x.x.x
    trusted_ip=7x.x.x.x
    remote_port_1=1194
    daemon_pid=1129
    daemon_log_redirect=0
    untrusted_port=1024
    verb=3
    time_duration=416
    bytes_sent=17018
    daemon=1
    local_1=9x.x.x.x
    trusted_port=1024
    ifconfig_broadcast=10.x.x.x
    dev=tap0
    ifconfig_pool_remote_ip=10.x.x.49
    untrusted_ip=7x.x.x.x
    bytes_received=10460
    tun_mtu=1500
    ifconfig_netmask=255.255.240.0
    ifconfig_pool_netmask=255.255.240.0
    time_unix=1315661702
    proto_1=udp
    link_mtu=1574
    local_port_1=1194
    config=/etc/openvpn/openvpn-fw.conf
    script_type=client-disconnect
    script_context=init
    

You can see that the 'common_name' is missing from it. Every other information is present and correct.

  • ARP TABLE:
    Address       HWtype HWaddress          Flags Mask Iface
    [...]
    10.x.x.49 ether  00:ff:x:x:x:x  C          tap0
    [...]
    

The "offending" user's information is available in the arp table.

  • OPENVPN STATUS FILE:
    OpenVPN CLIENT LIST
    Updated,Sat Sep 10 15:41:58 2011
    Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
    [...]
    UNDEF,7x.x.x.x:1024,10460,17018,Sat Sep 10 15:35:02 2011
    [...]
    ROUTING TABLE
    Virtual Address,Common Name,Real Address,Last Ref
    [...]
    00:ff:x:x:x:x,UNDEF,7x.x.x.x:1024,Sat Sep 10 15:41:21 2011
    [...]
    GLOBAL STATS
    Max bcast/mcast queue length,49
    END
    

As you can see, the username is UNDEF, probably that is why the client-disconnect script won't get the env. var. The other informations (ip, mac) are present and correct.

OpenVPN server version is 2.2.1, and has been configured and compiled like this:

./configure --enable-password-save --enable-iproute2 --disable-selinux --prefix=/usr/local && make

The server config:

daemon          openvpn-fw

mode            server
tls-server
dh              /etc/openvpn/dh1024.pem
ca              /etc/ssl/certs/ca.crt
cert            /etc/ssl/certs/cert.crt
key             /etc/ssl/private/key.key

user            openvpn
group           openvpn

local           9x.x.x.x
port            1194
proto           udp

dev-type        tap
dev             tap0
ifconfig        10.x.x.1 255.255.240.0

ifconfig-pool   10.x.x.10 10.x.x.255 255.255.240.0
push            "route-gateway 10.x.x.1"

persist-key
persist-tun

replay-persist  /var/run/openvpn/openvpn-replay

comp-lzo        adaptive
push            "comp-lzo adaptive"

max-clients     150
keepalive       3 30
push            "explicit-exit-notify 3"

status          /var/run/openvpn/openvpn-fw_status 1
status-version  1

syslog          openvpn
verb            3

management      /var/run/openvpn/openvpn-fw_management unix /etc/openvpn/management_passwd
management-client-user  root
management-client-group root

client-cert-not-required
username-as-common-name

script-security 2

client-connect          /usr/local/libexec/openvpn/client-connect.pl
client-disconnect       /usr/local/libexec/openvpn/client-disconnect.pl
tmp-dir                 /dev/shm

auth-user-pass-verify   /usr/local/libexec/openvpn/auth-user-pass-verify.pl     via-file

ordex (1 match)

Ticket Summary Component Milestone Type Created
Description
#834 remote-random-hostname changes http-proxy url Configuration Bug / Defect 01/30/17

The remote-random-hostname option is prepending the address from http-proxy option, therefore is impossible to use both at same time.

Tested on OpenVPN 2.4 on Windows 10 x64

Mon Jan 30 09:33:29 2017 OpenVPN 2.4.0 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Dec 27 2016
Mon Jan 30 09:33:29 2017 Windows version 6.2 (Windows 8 or greater) 64bit
Mon Jan 30 09:33:29 2017 library versions: OpenSSL 1.0.2i  22 Sep 2016, LZO 2.09
Enter Management Password:
Mon Jan 30 09:33:29 2017 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Mon Jan 30 09:33:29 2017 Need hold release from management interface, waiting...
Mon Jan 30 09:33:29 2017 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Mon Jan 30 09:33:29 2017 MANAGEMENT: CMD 'state on'
Mon Jan 30 09:33:29 2017 MANAGEMENT: CMD 'log all on'
Mon Jan 30 09:33:29 2017 MANAGEMENT: CMD 'hold off'
Mon Jan 30 09:33:29 2017 MANAGEMENT: CMD 'hold release'
Mon Jan 30 09:33:31 2017 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Mon Jan 30 09:33:31 2017 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Mon Jan 30 09:33:31 2017 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Mon Jan 30 09:33:31 2017 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Mon Jan 30 09:33:31 2017 MANAGEMENT: >STATE:1485776011,RESOLVE,,,,,,
Mon Jan 30 09:33:31 2017 RESOLVE: Cannot resolve host address: 17dcf03d8978.10.236.68.10:3128 (No such host is known. )
Mon Jan 30 09:33:31 2017 MANAGEMENT: >STATE:1485776011,RESOLVE,,,,,,
Mon Jan 30 09:33:31 2017 RESOLVE: Cannot resolve host address: 5628fefd7756.10.236.68.10:3128 (No such host is known. )
Mon Jan 30 09:34:00 2017 RESOLVE: signal received during DNS resolution attempt
Mon Jan 30 09:34:00 2017 Could not determine IPv4/IPv6 protocol
Mon Jan 30 09:34:00 2017 SIGHUP[hard,close_context usr1 to hup] received, process restarting
Mon Jan 30 09:34:00 2017 MANAGEMENT: >STATE:1485776040,RECONNECTING,close_context usr1 to hup,,,,,
Mon Jan 30 09:34:00 2017 OpenVPN 2.4.0 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Dec 27 2016
Mon Jan 30 09:34:00 2017 Windows version 6.2 (Windows 8 or greater) 64bit
Mon Jan 30 09:34:00 2017 library versions: OpenSSL 1.0.2i  22 Sep 2016, LZO 2.09
Mon Jan 30 09:34:00 2017 MANAGEMENT: Client disconnected
Mon Jan 30 09:34:00 2017 ERROR: Exit Event ('98400002a70') is signaled
Mon Jan 30 09:34:00 2017 Exiting due to fatal error

samuli (6 matches)

Ticket Summary Component Milestone Type Created
Description
#161 GET INST BY VIRT error is too obscure quiet Generic / unclassified release 2.4 Bug / Defect 09/20/11

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.


#325 Windows: Lacking ASLR and DEP support Building / Compiling release 2.4 Bug / Defect 08/27/13

All exe's and dll's from OpenVPN Windows client 2.3.2 64 bit lack ASLR and DEP support, I haven't checked other versions.


#592 Tap-Windows Adapter not work Windows 10 tap-windows6 Bug / Defect 08/06/15

No work Windows 10 Tap-Windows Adapter Add ComponentId?: tap0901 not fix the problem


#798 certificate for tap-windows driver is outdated tap-windows Bug / Defect 12/27/16

Silent install on windows 10 fails/hangs as there is always the confirmation-dialog for the device-driver. Output from Powershell:

PS C:\Users\Hakan.Kocaman> Get-AuthenticodeSignature "C:\Program Files (x86)\LANDesk\LDClient\sdmcache\swd\OpenVPN\tap-windows-9.21.2.exe"


    Verzeichnis: C:\Program Files (x86)\LANDesk\LDClient\sdmcache\swd\OpenVPN


SignerCertificate                         Status                                                         Path
-----------------                         ------                                                         ----
5E66E0CA2367757E800E65B770629026E131A7DC  Valid                                                          tap-windows-9.21.2.exe


PS C:\Users\Hakan.Kocaman> Get-AuthenticodeSignature "C:\Program Files (x86)\LANDesk\LDClient\sdmcache\swd\OpenVPN\tap-windows-9.21.2.exe"|fl


SignerCertificate      : [Subject]
                           CN="OpenVPN Technologies, Inc.", O="OpenVPN Technologies, Inc.", L=Pleasanton, S=California, C=US

                         [Issuer]
                           CN=DigiCert Assured ID Code Signing CA-1, OU=www.digicert.com, O=DigiCert Inc, C=US

                         [Serial Number]
                           04D54DC0A2016B263EEEB255D321056E

                         [Not Before]
                           13.08.2013 02:00:00

                         [Not After]
                           02.09.2016 14:00:00

                         [Thumbprint]
                           5E66E0CA2367757E800E65B770629026E131A7DC

TimeStamperCertificate :
Status                 : Valid
StatusMessage          : Signatur wurde überprüft.
Path                   : C:\Program Files (x86)\LANDesk\LDClient\sdmcache\swd\OpenVPN\tap-windows-9.21.2.exe
SignatureType          : Authenticode
IsOSBinary             : False



PS C:\Users\Hakan.Kocaman> Get-AuthenticodeSignature "C:\Users\Hakan.Kocaman\Downloads\tap-windows-9.21.2\driver\tap0901.cat"


    Verzeichnis: C:\Users\Hakan.Kocaman\Downloads\tap-windows-9.21.2\driver


SignerCertificate                         Status                                                         Path
-----------------                         ------                                                         ----
5E66E0CA2367757E800E65B770629026E131A7DC  Valid                                                          tap0901.cat


PS C:\Users\Hakan.Kocaman> Get-AuthenticodeSignature "C:\Users\Hakan.Kocaman\Downloads\tap-windows-9.21.2\driver\tap0901.cat"|fl


SignerCertificate      : [Subject]
                           CN="OpenVPN Technologies, Inc.", O="OpenVPN Technologies, Inc.", L=Pleasanton, S=California, C=US

                         [Issuer]
                           CN=DigiCert Assured ID Code Signing CA-1, OU=www.digicert.com, O=DigiCert Inc, C=US

                         [Serial Number]
                           04D54DC0A2016B263EEEB255D321056E

                         [Not Before]
                           13.08.2013 02:00:00

                         [Not After]
                           02.09.2016 14:00:00

                         [Thumbprint]
                           5E66E0CA2367757E800E65B770629026E131A7DC

TimeStamperCertificate :
Status                 : Valid
StatusMessage          : Signatur wurde überprüft.
Path                   : C:\Users\Hakan.Kocaman\Downloads\tap-windows-9.21.2\driver\tap0901.cat
SignatureType          : Authenticode
IsOSBinary             : False


Staus for the Certificate is valid, but it wss only valid till 2016-09-02. Kind regards hkocam


#213 OpenVPN GUI on 64-bit Windows (registry issue) Generic / unclassified release 2.4 Bug / Defect 06/07/12

Hello. My name is Kirill and I apologize for my English.

Creating an installer for my own VPN, based on OpenVPN, I found a bug with 64-bit Windows systems. The registry in 64-bit versions of Windows is divided into 32-bit and 64-bit keys. (http://support.microsoft.com/kb/305097/) So, OpenVPN registry keys are creating in HKLM/Software/Wow6432node/OpenVPN instead of HKLM/Software/OpenVPN. And OpenVPN GUI application does not take this into account. If OpenVPN was installed in default location (C:\Program Files (x86)\OpenVPN), I guess, GUI does not find registry keys, and it uses default values. Otherwise, it causes an error in CreateProcess? system call, because openvpn.exe does not exist in default folder.

If you have additional questions, I am ready to answer.

Thanks in advance.


#23 Integrate code security analysis tools into Buildbot Generic / unclassified TODO (General task list) 07/16/10

In the 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.


selvanair (3 matches)

Ticket Summary Component Milestone Type Created
Description
#810 OpenVPN 2.4 Interactive Service Cannot access user folder Generic / unclassified release 2.4.1 Bug / Defect 01/03/17

The new GUI suggests to store config files in c:\users\<user>\openvpn\config

However, the IService cannot reach that without impersonating the user first (which it doesn't) Which results in the following error:

You specified a config file location (...) relative to (...) which requires administrator access. add your account to "OpenVPN Administrators" group

The error is hard to read and not logged to the logfile.


#740 No PIN prompt with PKCS11 in Windows GUI mode Windows GUI release 2.4 Bug / Defect 09/24/16

The OpenVPN GUI for Windows is unable to query a PIN for smartcards (tested with Yubikey 4). The GUI queries username and password (if needed), but it fails to query the PIN. The problem seems to be similar to bug #538.

The source code shows that OpenVPN has at least three options for querying the PIN:

  1. script/file (not tested)
  2. management console (tested manually with telnet)
  3. console input

1) and 2) may be good options, but I haven't found no good and secure standard solutions for it. So only 3) can be easily setup.

Solution 3) does not work in OpenVPN GUI. It works, if OpenVPN is started in console.

I suggest, that PIN entry is handled the same way like username/passwords.


#833 openvpn-gui.exe --help shows a truncated help message Windows GUI release 2.4.1 Bug / Defect 01/29/17

Like this

https://ibin.co/3AagqStclchj.png

The help message defined in the resource file has many more options such as --log_viewer --editor --allow_edit --allow_service --allow_password --allow_proxy --show_balloon --service_only --silent_connection --show_script_window --passphrase_attempts --connectscript_timeout --disconnectscript_timeout --preconnectscript_timeout


syzzer (4 matches)

Ticket Summary Component Milestone Type Created
Description
#845 set cipher for client in ccd Generic / unclassified Feature Wish 02/17/17

Hello!

This was discussed in user's mail list, and there was info that such fetaure was already planned , but we really need it, so I decided to create feature wish.

In 2.4 it is possible for server to get cipher info from pre-2.4 client , but some clients (let's say in home routers) can't send info about cipher to server, because they are compiled without support for this feature, so server will always use default cipher. This makes migration from one default cipher to another , at least, very hard task, because we need to change default cipher on all such clients and on server at the same time. This is major issue for us, because we are using OpenVPN for long time and aour default cipher is blowfish :-(

I'd like to have an ability to set default cipher on per-client basis in ccd.

Thank you!


#835 OpenVPN exits on fatal error with large tun-mtu Networking Bug / Defect 01/30/17

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.


#720 Add tls-auth to <connection> profiles. Configuration release 2.5 Feature Wish 08/16/16

I would like to take advantage of multiple remote statements for connection redundancy but cannot because my current provider has different tls-auth keys for every server.

Please enable the tls-auth directive for use with a connection profile.

Ideally, certs would be accepted there as well.

https://forums.openvpn.net/viewtopic.php?f=10&p=63746


#814 Display cipher negotiated in NCP in status output Crypto release 2.4.1 Feature Wish 01/05/17

NCP in 2.4 is an excellent addition, but it is sometimes important to know *which* cipher the client / server negotiated. This information is not currently (I believe) displayed in the status output.

Is it possible to echo this information to console or log?

Thanks


Note: See TracReports for help on using and creating reports.