{5} Accepted, Active Tickets by Owner (Full Description) (27 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


#562 FreeBSD 9.3-RELEASE-p16 - OpenVPN 2.3.7 :: Only the first Dialin-IP-Traffic forwarded Networking release 2.3.10 Bug / Defect 06/15/15

Since version 2.3.7 was installed over FreBSD Port-Build (see below) method the TUN-Interface setup is different to 2.3.6 and only the first IP address in this pool was forwarded to the internet. All other IP addresses are unreachable from external networks. After I have copied the old binary (without any changes to the configuration) with version 2.3.6 the forwarding seems OK. What's the issue?

NOTICE: I can't select version 2.3.7 on field "Version" in this form.

Network: xx.xx.32.240/28 (Non-RFC1918) Clients: Ubuntu 14, iPhone 5-Client

[2.3.6-Output (TUN-I/F)] tun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500

options=80000<LINKSTATE> inet6 fe80::xxxxxxf%tun1 prefixlen 64 scopeid 0x12 inet xx.xx.x2.241 --> xx.xx.x2.241 netmask 0xfffffff0 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> Opened by PID 1145

[netstat -rnfinet] xx.xx.x2.240/28 xx.xx.x2.241 UGS 0 5048 tun1 xx.xx.x2.241 link#18 UH 0 0 tun1

---

[2.3.7-Output (TUN-I/F)] tun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500

options=80000<LINKSTATE> inet6 fe80::xxxxxxf%tun1 prefixlen 64 scopeid 0x12 inet xx.xx.x2.241 --> xx.xx.x2.242 netmask 0xfffffff0 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> Opened by PID 1146

[netstat -rnfinet] xx.xx.x2.240/28 xx.xx.x2.241 UGS 0 5048 tun1 xx.xx.x2.241 link#18 UH 0 0 lo0

---

[Port-Build] ./configure --enable-pkcs11 --enable-password-save --enable-x509-alt-username --with-crypto-library=openssl --prefix=/usr/local --localstatedir=/var --mandir=/usr/local/man --infodir=/usr/local/info/ --build=amd64-portbld-freebsd9.3

[Configuration] daemon dev tun1 proto udp port 500 bind xx.xx.1.38 local xx.xx.1.38 topology subnet float tun-mtu 1500 mssfix mute-replay-warnings management localhost 7500

# certs ..

# TLS tls-auth /usr/local/etc/openvpn500/server.key 0 verify-x509-name xxxxxxxxxxxxx name cipher AES-256-CBC tls-version-min 1.0

comp-lzo yes keepalive 30 600

status /var/log/openvpn500-status.log 1 log-append /var/log/openvpn500.log user root group daemon

persist-key persist-tun duplicate-cn

tls-server server xx.xx.x2.240 255.255.255.240

push "redirect-gateway" push "dhcp-option DNS xx.xx.x2.196" push "dhcp-option DNS xx.1xx.xx.196" push "dhcp-option DNS xx.xx.86.xx"

plugin /usr/local/lib/radiusplugin.so

client-to-client tmp-dir /etc/openvpn client-config-dir /usr/local/etc/openvpn500/ccd

username-as-common-name verb 3 script-security 2


#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.9 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)


#613 OpenVPN crashes with SIGSEGV when no certificate available Generic / unclassified release 2.3.10 Bug / Defect 09/29/15
# /usr/local/openvpn/sbin/openvpn --version
OpenVPN 2.3.6 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Dec  4 2014
library versions: OpenSSL 1.0.1k 8 Jan 2015, LZO 2.06

If I try to start openvpn from the command line, it crashes with SIGSEGV, see the output from strace:

access("/usr/local/openvpn/conf/keys/dh2048.pem", R_OK) = 0
access("/usr/local/openvpn/conf/keys-new/cert.cabundle", R_OK) = 0
access("/usr/local/openvpn/conf/keys-new/wildcard.crt", R_OK) = -1 ENOENT (No such file or directory)
fstat(1, {st_mode=S_IFREG|0600, st_size=2169, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f5b24d80000
write(1, "Options error: --cert fails with"..., 108) = 108
access("/usr/local/openvpn/conf/keys-new/wildcard.key", R_OK) = -1 ENOENT (No such file or directory)
write(1, "Options error: --key fails with "..., 107) = 107
access("/usr/local/openvpn/run", R_OK|W_OK|X_OK) = 0
access("/usr/local/openvpn/run/openvpn-ish.tcp.new.pid", F_OK) = -1 ENOENT (No such file or directory)
access("/var/log/openvpn", R_OK|W_OK|X_OK) = 0
access("/var/log/openvpn/status.new.tcp", F_OK) = -1 ENOENT (No such file or directory)
access("/tmp", R_OK|W_OK|X_OK)          = 0
write(1, "Options error: Please correct th"..., 44) = 44
write(1, "Use --help for more information."..., 33) = 33
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} ---
+++ killed by SIGSEGV +++

Obviously, it is my fault since I have wrong file names in the config. Nevertheless, openvpn should complain and not just crash.


#616 Compilation error with --enable-pedantic Building / Compiling release 2.4 Bug / Defect 10/07/15

With --enable-pedantic option enabled, compilation fails in compat-lz4.c:

compat-lz4.c:154:1: error: expected identifier or '(' before '/' token
 //**************************************
 ^

 compat-lz4.c:154:2: error: unterminated comment
 //**************************************
  ^

#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 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).


dazo (1 match)

Ticket Summary Component Milestone Type Created
Description
#29 push-reset should not reset topology and route-gateway from global config Configuration 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


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 (12 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 alpha 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.


#252 OpenVPN-GUI (64-bit) fails after installation Windows GUI release 2.4 Bug / Defect 01/25/13

I installed OpenVPN-2.3.0 on my 64-bit Windows 7 install without uninstalling my older OpenVPN install. I install OpenVPN in a custom path. After installing, opening OpenVPN-GUI errors out with this error:

Error while creating HKLM\SOFTWARE\OpenVPN-GUI key.

I tried to remove any old OpenVPN-GUI keys I found in the Registry, but it doesn't appear to work.


#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.


#249 Installer script bugs Installation release 2.4 Bug / Defect 01/11/13

I found two problems with the v2.3 installer:

1) '\OpenVPN' is not appended to path when install dir is changed on MUI_PAGE_INSTFILES (dir selection).

2) specifying the install dir on the command line (/D=) has no consequence, making it impossible to silently install OpenVPN to a non-default directory.

The cause of problem No.1 is that the InstallDir? attribute was omitted from the script. Current script uses the following code to set default install dir with regard to architecture:

	Function .onInit

	...

	${If} "${ARCH}" == "x86_64"
		SetRegView 64
		StrCpy $INSTDIR "$PROGRAMFILES64\${PACKAGE_NAME}"
	${Else}
		StrCpy $INSTDIR "$PROGRAMFILES\${PACKAGE_NAME}"
	${EndIf}

	...

	FunctionEnd

This works fine but it doesn't make the InstallDir? attribute redundant. InstallDir? shouldn't have been removed because it serves another purpose - the part of the string after the last '\' is what gets appended when the user changes the install dir.

Problem No.2 is directly tied to the above code. The current script always sets $INSTDIR to default in .onInit and thus overwrites the value possibly set by the /D switch.

And the solution to both problems is:

	InstallDir "$PROGRAMFILES\${PACKAGE_NAME}"

	...

	Function .onInit

	...

	${If} "${ARCH}" == "x86_64"
		SetRegView 64
		StrCmp $INSTDIR "$PROGRAMFILES\${PACKAGE_NAME}" 0 +2
		StrCpy $INSTDIR "$PROGRAMFILES64\${PACKAGE_NAME}"
	${EndIf}

	...

	FunctionEnd

Sorry if my report doesn't conform to standards, but better to report bugs some way than no way I suppose. Anyway, I know my NSIS and what I wrote is definitely correct.


#323 http://openvpn.net/faq.html#dhcpclientserv not working anymore Documentation release 2.3.9 Bug / Defect 08/22/13

When the initialization sequence fails, the last line of the log says:

Thu Aug 22 16:07:44 2013 Initialization Sequence Completed With Errors ( see http://openvpn.net/faq.html#dhcpclientserv )

That link isn't really working as it should. It should point to http://openvpn.net/index.php/open-source/faq/community-software-client/259-tap-win32-adapter-is-not-coming-up-qinitialization-sequence-completed-with-errorsq.html now


#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.


#494 OpenVPN GUI does not use file association handlers for log viewing & config editing Windows GUI Bug / Defect 12/29/14

With default file association handlers registered for .log and .ovpn set to Notepad++ when right-clicking the OpenVPN GUI system tray icon and selecting either "View Log" or "Edit Config" the standard Windows Notepad application is launched.


#219 man page could need improvements in the --keepalive section Documentation release 2.4 Feature Wish 07/12/12

I guess there's a small bug in the man page of openvpn regarding the "keepalive" example:

--keepalive n m

A helper directive designed to simplify the expression of --ping and --ping-restart in server mode configurations.

For example, --keepalive 10 60 expands as follows:

if mode server:

ping 10 ping-restart 120 push "ping 10" push "ping-restart 60"

else

ping 10 ping-restart 60

Would openvpn really double the value for "ping-restart" in server mode, or shouldn't that read "ping-restart 60" instead "ping-restart 120"?


syzzer (1 match)

Ticket Summary Component Milestone Type Created
Description
#633 tls-enc - symmetric protection of TLS handshake Crypto Feature Wish 11/27/15

Currently, users have to choose between static key encryption or TLS.

If you choose static key, you have no forward secrecy - if the key gets compromised, anyone can read your past traffic. Also, just connecting to a server is enough to make it divulge some of your network traffic in encrypted form, no authentication needed. However, if your key does not get compromised, even a quantum attacker will be unable to read your traffic.

If you choose TLS, you have forward secrecy against regular adversaries if your key gets leaked, but you also have the guarantee that all your traffic will eventually be readable by anyone who is willing to store the encrypted form until they get a quantum computer. There is tls-auth, which will protect against attacks like Heartbleed by authenticating the TLS packets with HMAC, but it doesn't stop this attack (as the hardening page correctly points out).

To protect against this, I would like to propose tls-enc, which would encrypt the TLS traffic with a static key, just like tls-auth authenticates it. I think this idea was shot down as unnecessary in the past, but given the Snowden disclosures, the NSA announcing a soon-to-come push for quantum safe crypto, and the fact that this issue will disclose past traffic, I think this would be a valuable addition now.

Like tls-auth, an implementation should not require replay protection, as this would be covered by the TLS layer, but there may be a risk that an attacker could use the server as an oracle to decrypt captured packets if there is a way for an attacker to reorder/replay packets that get fed into the TLS layer and elicit distinct responses depending on the content. I'm not sure if the OpenVPN protocol would allow that though.

The overhead should be minimal - since this only affects connection establishment, adding 8-16 bytes for an IV to each packet won't be too expensive, and tls-enc with AES-GCM could replace the HMAC in tls-auth, making it no more expensive than the status quo in terms of CPU.

Would this be something that OpenVPN would like to implement, or at least something that OpenVPN would accept a patch for?


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