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

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

cron2 (4 matches)

Ticket Summary Component Milestone Type Created
Description
#461 Change default sndbuf and rcvbuf values Networking Bug / Defect 10/11/14

Default value of 64K for sndbuf and rcvbuf can be speed limiter for, for example, wifi. With default values, I get 25 mbit/s for download and 30 mbit/s for upload over wifi, but with 512K values I get 80/80 mbit/s (maximum for my internet connection).

I suggest removing default values and use OS default values for rcvbuf and sndbuf, or increasing default values up to 256K for example.


#481 FreeBSD topo subnet self-route not via loopback interface? Networking release 2.3.7 Bug / Defect 11/18/14

Anton Sayetsky reported FreeBSD bug #194745 where apparently there is no loopback route added for the hosts' own interface, such that it gets routed through the tunnel. For details, please see the FreeBSD bug report.


#264 [PATCH] IPv6 p2p issues IPv6 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


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 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 (4 matches)

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


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


#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 (2 matches)

Ticket Summary Component Milestone Type Created
Description
#473 cipher none causes "Assertion failed at crypto_openssl.c:523" Crypto release 2.3.7 Bug / Defect 11/03/14

I'm using OpenVPN on Ubuntu 12.04, using the OpenVPN repository.

After upgrading to 2.3.5, using "cipher none" throws an assertion the VPN fails to start. Downgrading to OpenVPN 2.3.4 fixes the issue. See the attached log for details.


#301 Support AEAD cipher modes Crypto release 2.4 Patch submission 06/03/13

Add support for AEAD (Authenticated Encryption with Additional Data) that obviate the need for a separate MAC step. Modes such as AES-GCM, AES-CCM, and AES-XTS are examples. Combining the encryption and authentication steps leads to a speed-up since the library can use optimizations since it is doing both operations concurrently.


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