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

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

cron2 (10 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).


ecrist (1 match)

Ticket Summary Component Milestone Type Created
Description
#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

samuli (7 matches)

Ticket Summary Component Milestone Type Created
Description
#52 No routing after restart of Win 2003 Server on 2.1 Networking release 2.4 Bug / Defect 09/09/10

I have installed OpenVPN 2.1rc4 on a Windows 2003 Server (SBS)

Everytime the Server is restarted, I *can* connect to the OpenVPN daemon but could not ping anything, neither internal net nor the Tunnel Endpoint itself which is 192.168.254.1 in my case.

Then, if I simply restart the OpenVPN service, everything works as expected e.g ping to internal machines on the network works and the routing as well.

Tell me what Information you need in addition


#153 Add "RequestExecutionLevel admin" to tapinstall.exe manifest file Installation RC 2.4 Bug / Defect 08/12/11

Currently standalone tapinstall.exe does not automatically raise privileges on Windows Vista/7 as it should. This should be trivial to fix by modifying it's manifest file.


#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


#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 (1 match)

Ticket Summary Component Milestone Type Created
Description
#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.


syzzer (2 matches)

Ticket Summary Component Milestone Type Created
Description
#764 --management-external-key sometimes requests signatures for too long data Generic / unclassified release 2.3.15 Bug / Defect 11/09/16

According to https://openvpn.net/index.php/open-source/documentation/miscellaneous/79-management-interface.html, the ">RSA_SIGN" notification should be responded with "rsa-sig" command where the signature should be a "Base64 encoded output of RSA_sign(NID_md5_sha1,... ".

The normal case is that OpenVPN requests signatures for 36 bytes of data, but with some clients we see a notification requesting a signature for 83 bytes:

>RSA_SIGN:MFEwDQYJYIZIAWUDBAIDBQAEQGOZtLwchpQ0BVWxcSizpYpAEoVi/B8tGMYuj374VsmPQ1GUMiIbggdX7apKK7+x5FgVTqCCi+T/1EGZU1zIYn4=

OpenSSL RSA_sign with NID_md5_sha1 expects that the data is exactly 36 bytes and will refuse to sign this and gives an error about invalid message length: https://github.com/openssl/openssl/blob/608a026/crypto/rsa/rsa_sign.c#L88

Either the documentation is wrong and the signature should be generated in another way or the request for signing 83 bytes is a bug.

This seems to happen only with certain clients/versions (Android) and is reproducible always with those.

OpenSSL version is 1.0.2d and OpenVPN version:

OpenVPN 2.3.12 arm-poky-linux-gnueabi [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Nov  9 2016
library versions: OpenSSL 1.0.2d 9 Jul 2015, LZO 2.09
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_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=yes enable_fragment=yes enable_http_proxy=yes enable_iproute2=no 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=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=no with_crypto_library=openssl with_gnu_ld=yes with_lzo_headers=/include with_lzo_lib=/lib with_mem_check=no with_plugindir='$(libdir)/openvpn/plugins' with_ssl_headers=/include with_ssl_lib=/lib with_sysroot=no

#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


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