Client won't connect and repeatedly closes tcp sockets

capisani

Dear Collegues,
we are trying to make OpenVPN 2.2.2 arm-linux client connect with OpenVPN 2.3.14 x86_64-w64-mingw32 server.

This is the client configuration:
# cat /etc/openvpn/openvpn.conf
dev tap
ifconfig 10.0.4.1 255.255.255.0
ca /etc/openvpn/ca.crt
verb 1
mute 5
persist-key
persist-tun
keepalive 10 120
tls-client
remote 10.0.100.58
cert /etc/openvpn/client.crt
key /etc/openvpn/client.key
port 1194
proto tcp-client

This is the server configuration:
local 10.0.100.58
port 1194
proto tcp-server
dev tap
ifconfig 10.0.4.254 255.255.255.0
tls-server
ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"
cert "C:\\Program Files\\OpenVPN\\config\\sv-tds-ovpn.crt"
key "C:\\Program Files\\OpenVPN\\config\\sv-tds-ovpn.key"
dh "C:\\Program Files\\OpenVPN\\config\\dh1024.pem"
verb 7
persist-key
persist-tun
mode server

However, when client tries to connect after few seconds unespectedly, it closes the connection, then it retries to connect in few seconds.

From server logs, these are the relevant messages:
Tue Jan 03 15:48:38 2017 us=916953 MULTI: REAP range 48 -> 64
Tue Jan 03 15:48:38 2017 us=916953 MULTI: multi_create_instance called
Tue Jan 03 15:48:38 2017 us=916953 Re-using SSL/TLS context
Tue Jan 03 15:48:38 2017 us=916953 crypto_adjust_frame_parameters: Adjusting frame parameters for crypto by zu bytes
Tue Jan 03 15:48:38 2017 us=916953 PID packet_id_init tcp_mode=1 seq_backtrack=64 time_backtrack=15
Tue Jan 03 15:48:38 2017 us=916953 Control Channel MTU parms [ L:1539 D:1210 EF:40 EB:0 ET:0 EL:3 ]
Tue Jan 03 15:48:38 2017 us=916953 MTU DYNAMIC mtu=1450, flags=2, 1539 -> 1450
Tue Jan 03 15:48:38 2017 us=916953 Data Channel MTU parms [ L:1539 D:1450 EF:7 EB:12 ET:32 EL:3 AF:14/7 ]
Tue Jan 03 15:48:38 2017 us=916953 Local Options String: 'V4,dev-type tap,link-mtu 1539,tun-mtu 1532,proto TCPv4_SERVER,cipher [null-cipher],auth [null-digest],keysize 0,key-method 2,tls-server'
Tue Jan 03 15:48:38 2017 us=916953 Expected Remote Options String: 'V4,dev-type tap,link-mtu 1539,tun-mtu 1532,proto TCPv4_CLIENT,cipher [null-cipher],auth [null-digest],keysize 0,key-method 2,tls-client'
Tue Jan 03 15:48:38 2017 us=916953 Local Options hash (VER=V4): '1593dd0f'
Tue Jan 03 15:48:38 2017 us=916953 Expected Remote Options hash (VER=V4): 'c5dad6f3'
Tue Jan 03 15:48:38 2017 us=916953 TCP connection established with [AF_INET]10.74.0.55:42238
Tue Jan 03 15:48:38 2017 us=916953 TCPv4_SERVER link local: [undef]
Tue Jan 03 15:48:38 2017 us=916953 TCPv4_SERVER link remote: [AF_INET]10.74.0.55:42238
Tue Jan 03 15:48:38 2017 us=916953 10.74.0.55:42238 MULTI TCP: instance added: 10.74.0.55:42238
Tue Jan 03 15:48:38 2017 us=916953 10.74.0.55:42238 MULTI TCP: multi_tcp_action a=TA_INITIAL p=0
Tue Jan 03 15:48:38 2017 us=916953 10.74.0.55:42238 MULTI TCP: multi_tcp_dispatch a=TA_INITIAL mi=0x1e41640
Tue Jan 03 15:48:38 2017 us=916953 10.74.0.55:42238 MULTI TCP: multi_tcp_post TA_INITIAL -> TA_UNDEF
Tue Jan 03 15:48:39 2017 us=760714 10.74.0.55:42238 MULTI: REAP range 64 -> 80
Tue Jan 03 15:48:39 2017 us=760714 10.74.0.55:42238 MULTI TCP: multi_tcp_action a=TA_SOCKET_READ p=0
Tue Jan 03 15:48:39 2017 us=760714 10.74.0.55:42238 MULTI TCP: multi_tcp_dispatch a=TA_SOCKET_READ mi=0x1e41640
Tue Jan 03 15:48:39 2017 us=760714 10.74.0.55:42238 TCPv4_SERVER READ [14] from [AF_INET]10.74.0.55:42238: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Tue Jan 03 15:48:39 2017 us=760714 10.74.0.55:42238 TLS: Initial packet from [AF_INET]10.74.0.55:42238, sid=227abe37 f65284a8
Tue Jan 03 15:48:39 2017 us=760714 MULTI TCP: multi_tcp_post TA_SOCKET_READ -> TA_SOCKET_WRITE
Tue Jan 03 15:48:39 2017 us=760714 MULTI TCP: multi_tcp_action a=TA_SOCKET_WRITE p=1
Tue Jan 03 15:48:39 2017 us=760714 MULTI TCP: multi_tcp_wait_lite a=TA_SOCKET_WRITE mi=0x1e41640
Tue Jan 03 15:48:39 2017 us=760714 MULTI TCP: multi_tcp_dispatch a=TA_SOCKET_WRITE mi=0x1e41640
Tue Jan 03 15:48:39 2017 us=760714 10.74.0.55:42238 TCPv4_SERVER WRITE [26] to [AF_INET]10.74.0.55:42238: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ 0 ] pid=0 DATA len=0
Tue Jan 03 15:48:39 2017 us=760714 MULTI TCP: multi_tcp_post TA_SOCKET_WRITE -> TA_UNDEF
Tue Jan 03 15:48:39 2017 us=963831 MULTI TCP: multi_tcp_action a=TA_SOCKET_READ p=0
Tue Jan 03 15:48:39 2017 us=963831 MULTI TCP: multi_tcp_dispatch a=TA_SOCKET_READ mi=0x1e41640
Tue Jan 03 15:48:39 2017 us=963831 10.74.0.55:42238 TCPv4_SERVER READ [22] from [AF_INET]10.74.0.55:42238: P_ACK_V1 kid=0 [ 0 ]
Tue Jan 03 15:48:39 2017 us=963831 MULTI TCP: multi_tcp_post TA_SOCKET_READ -> TA_UNDEF
Tue Jan 03 15:48:40 2017 us=276340 MULTI: REAP range 80 -> 96
Tue Jan 03 15:48:40 2017 us=276340 MULTI TCP: multi_tcp_action a=TA_SOCKET_READ p=0
Tue Jan 03 15:48:40 2017 us=276340 MULTI TCP: multi_tcp_dispatch a=TA_SOCKET_READ mi=0x1e41640
Tue Jan 03 15:48:40 2017 us=276340 10.74.0.55:42238 TCPv4_SERVER READ [100] from [AF_INET]10.74.0.55:42238: P_CONTROL_V1 kid=0 [ ] pid=1 DATA len=86
Tue Jan 03 15:48:40 2017 us=276340 MULTI TCP: multi_tcp_post TA_SOCKET_READ -> TA_SOCKET_WRITE
Tue Jan 03 15:48:40 2017 us=276340 MULTI TCP: multi_tcp_action a=TA_SOCKET_WRITE p=1
Tue Jan 03 15:48:40 2017 us=276340 MULTI TCP: multi_tcp_wait_lite a=TA_SOCKET_WRITE mi=0x1e41640
Tue Jan 03 15:48:40 2017 us=276340 MULTI TCP: multi_tcp_dispatch a=TA_SOCKET_WRITE mi=0x1e41640
Tue Jan 03 15:48:40 2017 us=276340 10.74.0.55:42238 TCPv4_SERVER WRITE [1196] to [AF_INET]10.74.0.55:42238: P_CONTROL_V1 kid=0 [ 1 ] pid=1 DATA len=1170
Tue Jan 03 15:48:40 2017 us=276340 MULTI TCP: multi_tcp_post TA_SOCKET_WRITE -> TA_SOCKET_WRITE
Tue Jan 03 15:48:40 2017 us=276340 MULTI TCP: multi_tcp_action a=TA_SOCKET_WRITE p=1
Tue Jan 03 15:48:40 2017 us=276340 MULTI TCP: multi_tcp_wait_lite a=TA_SOCKET_WRITE mi=0x1e41640
Tue Jan 03 15:48:40 2017 us=276340 MULTI TCP: multi_tcp_dispatch a=TA_SOCKET_WRITE mi=0x1e41640
Tue Jan 03 15:48:40 2017 us=276340 10.74.0.55:42238 TCPv4_SERVER WRITE [1184] to [AF_INET]10.74.0.55:42238: P_CONTROL_V1 kid=0 [ ] pid=2 DATA len=1170
Tue Jan 03 15:48:40 2017 us=276340 MULTI TCP: multi_tcp_post TA_SOCKET_WRITE -> TA_SOCKET_WRITE
Tue Jan 03 15:48:40 2017 us=276340 MULTI TCP: multi_tcp_action a=TA_SOCKET_WRITE p=1
Tue Jan 03 15:48:40 2017 us=276340 MULTI TCP: multi_tcp_wait_lite a=TA_SOCKET_WRITE mi=0x1e41640
Tue Jan 03 15:48:40 2017 us=276340 MULTI TCP: multi_tcp_dispatch a=TA_SOCKET_WRITE mi=0x1e41640
Tue Jan 03 15:48:40 2017 us=276340 10.74.0.55:42238 TCPv4_SERVER WRITE [308] to [AF_INET]10.74.0.55:42238: P_CONTROL_V1 kid=0 [ ] pid=3 DATA len=294
Tue Jan 03 15:48:40 2017 us=276340 MULTI TCP: multi_tcp_post TA_SOCKET_WRITE -> TA_UNDEF
Tue Jan 03 15:48:40 2017 us=432589 MULTI TCP: multi_tcp_action a=TA_SOCKET_READ p=0
Tue Jan 03 15:48:40 2017 us=432589 MULTI TCP: multi_tcp_dispatch a=TA_SOCKET_READ mi=0x1e41640
Tue Jan 03 15:48:40 2017 us=432589 10.74.0.55:42238 TCPv4_SERVER READ [22] from [AF_INET]10.74.0.55:42238: P_ACK_V1 kid=0 [ 1 ]
Tue Jan 03 15:48:40 2017 us=432589 MULTI TCP: multi_tcp_post TA_SOCKET_READ -> TA_UNDEF
Tue Jan 03 15:48:40 2017 us=526339 MULTI TCP: multi_tcp_action a=TA_SOCKET_READ p=0
Tue Jan 03 15:48:40 2017 us=526339 MULTI TCP: multi_tcp_dispatch a=TA_SOCKET_READ mi=0x1e41640
Tue Jan 03 15:48:40 2017 us=526339 10.74.0.55:42238 Connection reset, restarting [0]
Tue Jan 03 15:48:40 2017 us=526339 10.74.0.55:42238 SIGUSR1[soft,connection-reset] received, client-instance restarting
Tue Jan 03 15:48:40 2017 us=526339 MULTI: multi_close_instance called
Tue Jan 03 15:48:40 2017 us=526339 PID packet_id_free
Tue Jan 03 15:48:40 2017 us=526339 TCP/UDP: Closing socket
Tue Jan 03 15:48:40 2017 us=526339 PID packet_id_free
Tue Jan 03 15:48:40 2017 us=526339 MULTI TCP: multi_tcp_post TA_SOCKET_READ -> TA_UNDEF

We have double-checked the certificates.
We cannot understand where can be the issue.
Thanks for any comments,
Luca Capisani

capisani

Edit:
we got also the client logs, and it seems that client does not accept the certificate, however, we have verified the keys with "openssl verify" command.

# openvpn /etc/openvpn/openvpn.conf
Tue Jan 3 15:01:55 2017 us=356421 OpenVPN 2.2.2 arm-linux [SSL] [LZO1] [EPOLL] built on Jan 24 2014
Tue Jan 3 15:01:55 2017 us=360084 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Tue Jan 3 15:01:55 2017 us=361138 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Tue Jan 3 15:01:55 2017 us=401894 Control Channel MTU parms [ L:1575 D:140 EF:40 EB:0 ET:0 EL:0 ]
Tue Jan 3 15:01:55 2017 us=403898 Socket Buffers: R=[87380->131072] S=[16384->131072]
Tue Jan 3 15:01:55 2017 us=427147 TUN/TAP device tap0 opened
Tue Jan 3 15:01:55 2017 us=428413 TUN/TAP TX queue length set to 100
Tue Jan 3 15:01:55 2017 us=430615 /sbin/ifconfig tap0 10.0.4.1 netmask 255.255.255.0 mtu 1500 broadcast 10.0.4.255
Tue Jan 3 15:01:55 2017 us=470391 Data Channel MTU parms [ L:1575 D:1450 EF:43 EB:4 ET:32 EL:0 ]
Tue Jan 3 15:01:55 2017 us=471432 Attempting to establish TCP connection with 10.0.100.58:1194 [nonblock]
Tue Jan 3 15:01:56 2017 us=476763 TCP connection established with 10.0.100.58:1194
Tue Jan 3 15:01:56 2017 us=477541 TCPv4_CLIENT link local: [undef]
Tue Jan 3 15:01:56 2017 us=478352 TCPv4_CLIENT link remote: 10.0.100.58:1194
Tue Jan 3 15:01:56 2017 us=480511 TCPv4_CLIENT WRITE [14] to 10.0.100.58:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Tue Jan 3 15:01:56 2017 us=607973 TCPv4_CLIENT READ [26] from 10.0.100.58:1194: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ 0 ] pid=0 DATA len=0
Tue Jan 3 15:01:56 2017 us=609148 TLS: Initial packet from 10.0.100.58:1194, sid=5f22721a 0c5fd691
Tue Jan 3 15:01:56 2017 us=611133 TCPv4_CLIENT WRITE [22] to 10.0.100.58:1194: P_ACK_V1 kid=0 [ 0 ]
Tue Jan 3 15:01:56 2017 us=614760 TCPv4_CLIENT WRITE [100] to 10.0.100.58:1194: P_CONTROL_V1 kid=0 [ ] pid=1 DATA len=86
Tue Jan 3 15:01:56 2017 us=900656 TCPv4_CLIENT READ [1196] from 10.0.100.58:1194: P_CONTROL_V1 kid=0 [ 1 ] pid=1 DATA len=1170
Tue Jan 3 15:01:56 2017 us=903917 TCPv4_CLIENT WRITE [22] to 10.0.100.58:1194: P_ACK_V1 kid=0 [ 1 ]
Tue Jan 3 15:01:56 2017 us=911540 TCPv4_CLIENT READ [1184] from 10.0.100.58:1194: P_CONTROL_V1 kid=0 [ ] pid=2 DATA len=1170
Tue Jan 3 15:01:56 2017 us=932274 VERIFY ERROR: depth=1, error=certificate signature failure: /C=IT/ST=XX/L=XXX/O=XXX/OU=ICT/CN=xx/name=xxx/emailAddress=mail@host.domain
Tue Jan 3 15:01:56 2017 us=935398 TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Tue Jan 3 15:01:56 2017 us=946369 TLS Error: TLS object -> incoming plaintext read error
Tue Jan 3 15:01:56 2017 us=947026 TLS Error: TLS handshake failed
Tue Jan 3 15:01:56 2017 us=949095 Fatal TLS error (check_tls_errors_co), restarting
Tue Jan 3 15:01:56 2017 us=950468 TCP/UDP: Closing socket
Tue Jan 3 15:01:56 2017 us=951822 SIGUSR1[soft,tls-error] received, process restarting
Tue Jan 3 15:01:56 2017 us=966594 Restart pause, 5 second(s)

TinCanTech

capisani wroteOpenVPN 2.2.2 arm-linux client connect with OpenVPN 2.3.14

Can you not update this 2.2.2 ?

capisani

Dear TinCanTech,
we cannot update 2.2.2 because it is built up with a embedded Linux router. Moreover, we cannot understand why there are two possibilities:
the first is to launch "openvpn <config file>" from shell, and this is the object of the question,
while the second mode consists in using a bundled command of the embedded Linux router which loads a module named "tun.ko" inside the kernel.
This module *seems* to implement openvpn version 1.1.3; but, at the end, we have identical results from the connection viewpoint. We cannot find logs of this second launch mode.

Is there a way to make sure about compatibility of upper version (which server implements) and lower versions? We are wondering where can be issues in this.

Thank you again,
Luca

capisani

Edit:
we also installed the same version OpenVPN 2.2.2 on the server. The result is exactly the same. Now I figure out that client can miss some modules for authentication.

We are wondering if there is a way to be sure that the configuration is correct on both sides.

Thank you very much,
Luca

300000

Tue Jan 3 15:01:56 2017 us=932274 VERIFY ERROR: depth=1, error=certificate signature failure:

you need to use certificate which sign server certificate to sign client certificate so it must be the same .

it is wrong client certificate so you ll never can get connected

you can export ca certificate from server and use windows software to sign client certificate it is more easy than linux

capisani

Dear 300000,
we have generated certificates with Windows software as you suggest, and we have also validated the certificates by using "openssl verify" utility.

The same certificates have been tested on a Windows client and worked. I suspect that our actual OpenVPN client implementation on busybox lacks certain modules, however, we cannot find a way to understand what is missing.

We hope to find a solution,
thank you
Luca Capisani

300000

if it works on windows so something wrong with your client . make sue check the time must be the same on client and server

capisani

Yes, we have also verified the time setting of the two machines, and they are correct.

Is there a way to be sure about the condition which actually fails the check?

Thank you again and (late) season greetings!
Luca Capisani

TinCanTech

300000 wroteyou can export ca certificate from server and use windows software to sign client certificate it is more easy than linux

If you use Easy-RSA it makes no difference which OS you use.

capisani wrotewe have generated certificates with Windows software as you suggest

Did you use EasyRSA ?

Also, for testing setup a simple --dev tun --server subnet and assign default IP addresses not your strange manual IP addresses.

capisani

Dear TinCanTech,
we will try your suggestions.

Thank you for the assistance
Luca Capisani