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

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

cron2 (1 match)

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


dazo (3 matches)

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


#128 Connection errors Configuration release 2.3.4 Bug / Defect 05/06/11

This is a well known and long-term bug in OpenVPN

After establishing of the connection you'll get error: "write to TUN/TAP : Invalid argument (code=22)". The reason for the error is, that the client do not adapt the "pushed" option 'comp-lzo'. After restart, because of inactivity timeout, the connection works.

The workaround is putting this option into the client configuration file.


#277 client-config-dir silently ignored if not readable Configuration release 2.3.4 Bug / Defect 04/02/13

OpenVPN 2.3.0 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [eurephia] [MH] [IPv6] built on Feb 9 2013

I spent a considerable amount of time wondering why an iroute setup (to export a client’s LAN to the VPN) stopped working after some configuration changes. The clearest symptom was that the server was pushing the route to the client even though the common name on its certificate was correct and a client-config-dir entry with that common name specified an iroute. After Peer Connection Initiated was printed in the server log, MULTI_sva: pool returned … immediately followed, with no intervening OPTIONS IMPORT: reading client specific options from: ….

It turns out that the problematic change was adding user nobody to the server configuration: the directory specified in client-config-dir was in someone’s home directory and was not world-readable. By the time this file was needed, the openvpn server process could no longer access it.

Fair enough, but why did the server fail to record the fact that it could not traverse one of the parent directories? Simply printing to the server log something like

WARNING: cannot look in … for client configurations; not readable

would have saved a lot of debugging time.

(Even better would be to read the files in this directory when the server starts, before switching users, though some people may be relying on being able to change these files without restarting the server.)

Off topic note: the new user registration for this site refuses legitimate email addresses of the form realname+token@something.com, which GMail and other services offer to let you create aliased addresses for tracking purposes.


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"?


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