Re: [Openvpn-devel] Problem with client reconnect when using username-as-common-name and username is blank
Hi Jan, I added the two lines and recompiled. It did not seem to solve this problem. I think they are different problems as mine is that the client_disconnect script does not get called at all and yours just affect the environment variables when the script is called. I can do some more testing if you want before I change my scripts and drop the username-as-common-name option Carlos -Mensaje original- De: Jan Just Keijser [mailto:janj...@nikhef.nl] Enviado el: jueves, 04 de noviembre de 2010 10:07 Para: Carlos Soto CC: openvpn-devel@lists.sourceforge.net Asunto: Re: [Openvpn-devel] Problem with client reconnect when using username-as-common-name and username is blank Hi Carlos, this looks like a repeat of something reported on March 1st : in multi.c the function multi_client_connect_setenv contains 1410 /* setenv incoming cert common name for script */ 1411 setenv_str (mi->context.c2.es, "common_name", tls_common_name (mi->context.c2.tls_multi, true)); this is missing from the corresponding multi_client_disconnect_setenv function Unfortunately the openvpn-devel folks were unable to reproduce this error and hence no patch was not included. Can you try adding these two lines to "multi_client_disconnect_setenv" , rebuild openvpn and see if the problem goes away? HTH, JJK Carlos Soto wrote: > I have been having a very strange behavior with openvpn and I have finally > found the source. I do not know if it is a bug or not so I will explain it > and let the experts decide. > > I am using OpenVPN 2.1.3 in several openwrt routers connected with ADSL with > dynamic IPs. Every once in a client reconnects (normally because there is a > change in the IP). As I do not use the cn-duplicate, when the client > reconnects, it first calls the client-disconnect script and then the client > connect. See log: > > Thu Nov 4 07:55:16 2010 XX.148.40.117:42335 [javier] Peer Connection > Initiated with XX.148.40.117:42335 > Thu Nov 04 07:55:16 2010 XX.148.40.117:45483 openvpn_scripts: > (CN=javier/cn=javier) start client-disconnect > Thu Nov 4 07:55:16 2010 javier/XX.148.40.117:42335 TCP/UDP: Closing socket > Thu Nov 4 07:55:16 2010 MULTI: new connection by client 'javier' will cause > previous active sessions by this client to be dropped. Remember to use the > --duplicate-cn option if you want multiple clients using the same > certificate or username to concurrently connect. > Thu Nov 04 07:55:16 2010 XX.148.40.117:42335 openvpn_scripts: > (CN=javier/cn=javier) start client-connect > > openvpn_scripts are the log entries from my custom scripts that setup the > iptables and routes. This is all the expected behavior. > > The problem comes when I activate the username-as-common-name option. When > the client reconnects, the client-disconnect script does not get called and > only the client connect script gets called. The username is always blank for > this particular connection and CN. After the reconnection is done, there is > a timeout of the first connection because of the ping-restart option and the > client-disconnect script gets called. Here is the log > > Thu Nov 4 08:24:29 2010 XX.148.40.117:39056 TLS: Initial packet from > XX.148.40.117:39056, sid=2b306f61 c6c30e51 > Thu Nov 4 08:24:33 2010 XX.148.40.117:39056 VERIFY OK: depth=1, > /C=ES/ST=MAD/L=Madrid/O=CS/CN=CS_CA/emailAddress=xx@xxx > Thu Nov 4 08:24:33 2010 XX.148.40.117:39056 VERIFY OK: depth=0, > /C=ES/ST=MAD/L=Madrid/O=CS/CN=javier/emailAddress=xx@xxx > Thu Nov 04 08:24:34 2010 XX.148.40.117:39056 openvpn_scripts: > (CN=javier/cn=javier) start user-pass-verify > Thu Nov 4 08:24:34 2010 XX.148.40.117:39056 TLS: Username/Password > authentication succeeded for username '' [CN SET] > Thu Nov 4 08:24:34 2010 XX.148.40.117:39056 Data Channel Encrypt: Cipher > 'BF-CBC' initialized with 128 bit key > Thu Nov 4 08:24:34 2010 XX.148.40.117:39056 Data Channel Encrypt: Using 160 > bit message hash 'SHA1' for HMAC authentication > Thu Nov 4 08:24:34 2010 XX.148.40.117:39056 Data Channel Decrypt: Cipher > 'BF-CBC' initialized with 128 bit key > Thu Nov 4 08:24:34 2010 XX.148.40.117:39056 Data Channel Decrypt: Using 160 > bit message hash 'SHA1' for HMAC authentication > Thu Nov 4 08:24:35 2010 XX.148.40.117:39056 Control Channel: TLSv1, cipher > TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA > Thu Nov 4 08:24:35 2010 XX.148.40.117:39056 [] Peer Connection Initiated > with XX.148.40.117:39056 > Thu Nov 04 08:24:35 2010 XX.148.40.117:39056 openvpn_scripts: (CN=javier) > start client-connect > route: SIOCADDRT: File exists > Thu Nov 4 08:24:35 2010 XX.148.40.117:39056 OPTIONS IMPORT: reading client > specific options from: /tmp//openvpn_cc_9448a5143bd3e6786d2b8060da752fe5.t
Re: [Openvpn-devel] Problem with client reconnect when using username-as-common-name and username is blank
Hi Carlos, this looks like a repeat of something reported on March 1st : in multi.c the function multi_client_connect_setenv contains 1410 /* setenv incoming cert common name for script */ 1411 setenv_str (mi->context.c2.es, "common_name", tls_common_name (mi->context.c2.tls_multi, true)); this is missing from the corresponding multi_client_disconnect_setenv function Unfortunately the openvpn-devel folks were unable to reproduce this error and hence no patch was not included. Can you try adding these two lines to "multi_client_disconnect_setenv" , rebuild openvpn and see if the problem goes away? HTH, JJK Carlos Soto wrote: I have been having a very strange behavior with openvpn and I have finally found the source. I do not know if it is a bug or not so I will explain it and let the experts decide. I am using OpenVPN 2.1.3 in several openwrt routers connected with ADSL with dynamic IPs. Every once in a client reconnects (normally because there is a change in the IP). As I do not use the cn-duplicate, when the client reconnects, it first calls the client-disconnect script and then the client connect. See log: Thu Nov 4 07:55:16 2010 XX.148.40.117:42335 [javier] Peer Connection Initiated with XX.148.40.117:42335 Thu Nov 04 07:55:16 2010 XX.148.40.117:45483 openvpn_scripts: (CN=javier/cn=javier) start client-disconnect Thu Nov 4 07:55:16 2010 javier/XX.148.40.117:42335 TCP/UDP: Closing socket Thu Nov 4 07:55:16 2010 MULTI: new connection by client 'javier' will cause previous active sessions by this client to be dropped. Remember to use the --duplicate-cn option if you want multiple clients using the same certificate or username to concurrently connect. Thu Nov 04 07:55:16 2010 XX.148.40.117:42335 openvpn_scripts: (CN=javier/cn=javier) start client-connect openvpn_scripts are the log entries from my custom scripts that setup the iptables and routes. This is all the expected behavior. The problem comes when I activate the username-as-common-name option. When the client reconnects, the client-disconnect script does not get called and only the client connect script gets called. The username is always blank for this particular connection and CN. After the reconnection is done, there is a timeout of the first connection because of the ping-restart option and the client-disconnect script gets called. Here is the log Thu Nov 4 08:24:29 2010 XX.148.40.117:39056 TLS: Initial packet from XX.148.40.117:39056, sid=2b306f61 c6c30e51 Thu Nov 4 08:24:33 2010 XX.148.40.117:39056 VERIFY OK: depth=1, /C=ES/ST=MAD/L=Madrid/O=CS/CN=CS_CA/emailAddress=xx@xxx Thu Nov 4 08:24:33 2010 XX.148.40.117:39056 VERIFY OK: depth=0, /C=ES/ST=MAD/L=Madrid/O=CS/CN=javier/emailAddress=xx@xxx Thu Nov 04 08:24:34 2010 XX.148.40.117:39056 openvpn_scripts: (CN=javier/cn=javier) start user-pass-verify Thu Nov 4 08:24:34 2010 XX.148.40.117:39056 TLS: Username/Password authentication succeeded for username '' [CN SET] Thu Nov 4 08:24:34 2010 XX.148.40.117:39056 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key Thu Nov 4 08:24:34 2010 XX.148.40.117:39056 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Thu Nov 4 08:24:34 2010 XX.148.40.117:39056 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key Thu Nov 4 08:24:34 2010 XX.148.40.117:39056 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Thu Nov 4 08:24:35 2010 XX.148.40.117:39056 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA Thu Nov 4 08:24:35 2010 XX.148.40.117:39056 [] Peer Connection Initiated with XX.148.40.117:39056 Thu Nov 04 08:24:35 2010 XX.148.40.117:39056 openvpn_scripts: (CN=javier) start client-connect route: SIOCADDRT: File exists Thu Nov 4 08:24:35 2010 XX.148.40.117:39056 OPTIONS IMPORT: reading client specific options from: /tmp//openvpn_cc_9448a5143bd3e6786d2b8060da752fe5.tmp Thu Nov 4 08:24:35 2010 XX.148.40.117:39056 MULTI: Learn: 10.1.16.18 -> XX.148.40.117:39056 Thu Nov 4 08:24:35 2010 XX.148.40.117:39056 MULTI: primary virtual IP for XX.148.40.117:39056: 10.1.16.18 Thu Nov 4 08:24:35 2010 XX.148.40.117:39056 MULTI: internal route 10.2.0.0/16 -> XX.148.40.117:39056 Thu Nov 4 08:24:35 2010 XX.148.40.117:39056 MULTI: Learn: 10.2.0.0/16 -> XX.148.40.117:39056 Thu Nov 4 08:24:37 2010 XX.148.40.117:39056 PUSH: Received control message: 'PUSH_REQUEST' Thu Nov 4 08:24:37 2010 XX.148.40.117:39056 SENT CONTROL [UNDEF]: 'PUSH_REPLY,route 10.1.16.1,topology net30,ping 10,ping-restart 60,route 10.1.0.0 255.255.0.0,ifconfig 10.1.16.18 10.1.16.17' (status=1) Thu Nov 4 08:24:45 2010 MULTI: Learn: 10.2.0.2 -> XX.148.40.117:39056 Thu Nov 4 08:24:57 2010 XX.148.40.117:46554 [UNDEF] Inactivity timeout (--ping-restart), restarting Thu Nov 4 08:24:57 2010 XX.148.40.117:46554 SIGUSR1[soft,ping-restart] received, client-instance restarting Thu Nov 04 08:24:57 2010 XX.148.40.117:46554 openvpn_scripts: (CN=javier) start client-di
[Openvpn-devel] Problem with client reconnect when using username-as-common-name and username is blank
I have been having a very strange behavior with openvpn and I have finally found the source. I do not know if it is a bug or not so I will explain it and let the experts decide. I am using OpenVPN 2.1.3 in several openwrt routers connected with ADSL with dynamic IPs. Every once in a client reconnects (normally because there is a change in the IP). As I do not use the cn-duplicate, when the client reconnects, it first calls the client-disconnect script and then the client connect. See log: Thu Nov 4 07:55:16 2010 XX.148.40.117:42335 [javier] Peer Connection Initiated with XX.148.40.117:42335 Thu Nov 04 07:55:16 2010 XX.148.40.117:45483 openvpn_scripts: (CN=javier/cn=javier) start client-disconnect Thu Nov 4 07:55:16 2010 javier/XX.148.40.117:42335 TCP/UDP: Closing socket Thu Nov 4 07:55:16 2010 MULTI: new connection by client 'javier' will cause previous active sessions by this client to be dropped. Remember to use the --duplicate-cn option if you want multiple clients using the same certificate or username to concurrently connect. Thu Nov 04 07:55:16 2010 XX.148.40.117:42335 openvpn_scripts: (CN=javier/cn=javier) start client-connect openvpn_scripts are the log entries from my custom scripts that setup the iptables and routes. This is all the expected behavior. The problem comes when I activate the username-as-common-name option. When the client reconnects, the client-disconnect script does not get called and only the client connect script gets called. The username is always blank for this particular connection and CN. After the reconnection is done, there is a timeout of the first connection because of the ping-restart option and the client-disconnect script gets called. Here is the log Thu Nov 4 08:24:29 2010 XX.148.40.117:39056 TLS: Initial packet from XX.148.40.117:39056, sid=2b306f61 c6c30e51 Thu Nov 4 08:24:33 2010 XX.148.40.117:39056 VERIFY OK: depth=1, /C=ES/ST=MAD/L=Madrid/O=CS/CN=CS_CA/emailAddress=xx@xxx Thu Nov 4 08:24:33 2010 XX.148.40.117:39056 VERIFY OK: depth=0, /C=ES/ST=MAD/L=Madrid/O=CS/CN=javier/emailAddress=xx@xxx Thu Nov 04 08:24:34 2010 XX.148.40.117:39056 openvpn_scripts: (CN=javier/cn=javier) start user-pass-verify Thu Nov 4 08:24:34 2010 XX.148.40.117:39056 TLS: Username/Password authentication succeeded for username '' [CN SET] Thu Nov 4 08:24:34 2010 XX.148.40.117:39056 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key Thu Nov 4 08:24:34 2010 XX.148.40.117:39056 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Thu Nov 4 08:24:34 2010 XX.148.40.117:39056 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key Thu Nov 4 08:24:34 2010 XX.148.40.117:39056 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Thu Nov 4 08:24:35 2010 XX.148.40.117:39056 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA Thu Nov 4 08:24:35 2010 XX.148.40.117:39056 [] Peer Connection Initiated with XX.148.40.117:39056 Thu Nov 04 08:24:35 2010 XX.148.40.117:39056 openvpn_scripts: (CN=javier) start client-connect route: SIOCADDRT: File exists Thu Nov 4 08:24:35 2010 XX.148.40.117:39056 OPTIONS IMPORT: reading client specific options from: /tmp//openvpn_cc_9448a5143bd3e6786d2b8060da752fe5.tmp Thu Nov 4 08:24:35 2010 XX.148.40.117:39056 MULTI: Learn: 10.1.16.18 -> XX.148.40.117:39056 Thu Nov 4 08:24:35 2010 XX.148.40.117:39056 MULTI: primary virtual IP for XX.148.40.117:39056: 10.1.16.18 Thu Nov 4 08:24:35 2010 XX.148.40.117:39056 MULTI: internal route 10.2.0.0/16 -> XX.148.40.117:39056 Thu Nov 4 08:24:35 2010 XX.148.40.117:39056 MULTI: Learn: 10.2.0.0/16 -> XX.148.40.117:39056 Thu Nov 4 08:24:37 2010 XX.148.40.117:39056 PUSH: Received control message: 'PUSH_REQUEST' Thu Nov 4 08:24:37 2010 XX.148.40.117:39056 SENT CONTROL [UNDEF]: 'PUSH_REPLY,route 10.1.16.1,topology net30,ping 10,ping-restart 60,route 10.1.0.0 255.255.0.0,ifconfig 10.1.16.18 10.1.16.17' (status=1) Thu Nov 4 08:24:45 2010 MULTI: Learn: 10.2.0.2 -> XX.148.40.117:39056 Thu Nov 4 08:24:57 2010 XX.148.40.117:46554 [UNDEF] Inactivity timeout (--ping-restart), restarting Thu Nov 4 08:24:57 2010 XX.148.40.117:46554 SIGUSR1[soft,ping-restart] received, client-instance restarting Thu Nov 04 08:24:57 2010 XX.148.40.117:46554 openvpn_scripts: (CN=javier) start client-disconnect Thu Nov 4 08:24:57 2010 TCP/UDP: Closing socket Thu Nov 4 08:24:57 2010 XX.148.40.117:39056 MULTI: Learn: 10.2.0.2 -> XX.148.40.117:39056 After this happens the VPN is still up and working but because of the out of sequence call to the scripts the routes have been deleted and no traffic flows. Looking at the source code (but not having debugged it), I see that as the username is blank and that becomes the commonname, the call to tls_common_name in multi_delete_dup will returns NULL and the iteration to close the instances do not get executed. Changing the second parameter of the two tls_common_name call to false may do the trick but I d
