Hi all,
I seem to have problem with my openvpn server - client connection.
It do not know if it is important, but i am stating for the record that it is located behind a dynamic DNS connection, so its external ip changes - so I have added the clause "float" in my client's openvpn.conf - to solve exactly this issue
now, the important information is in the log (verb3) of my client:
Mon Mar 30 17:09:59 2015 OpenVPN 2.2.2 x86_64-slackware-linux-gnu [SSL] [LZO2] [EPOLL] [eurephia] built on Jul 4 2012
Mon Mar 30 17:09:59 2015 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Mon Mar 30 17:09:59 2015 LZO compression initialized
Mon Mar 30 17:09:59 2015 Control Channel MTU parms [ L:1546 D:138 EF:38 EB:0 ET:0 EL:0 ]
Mon Mar 30 17:09:59 2015 Socket Buffers: R=[229376->131072] S=[229376->131072]
Mon Mar 30 17:10:00 2015 Data Channel MTU parms [ L:1546 D:1300 EF:46 EB:135 ET:0 EL:0 AF:3/1 ]
Mon Mar 30 17:10:00 2015 Fragmentation MTU parms [ L:1546 D:1300 EF:45 EB:135 ET:1 EL:0 AF:3/1 ]
Mon Mar 30 17:10:00 2015 Local Options hash (VER=V4): 'c086e1aa'
Mon Mar 30 17:10:00 2015 Expected Remote Options hash (VER=V4): '8e7959c7'
Mon Mar 30 17:10:00 2015 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Mon Mar 30 17:10:00 2015 UDPv4 link local: [undef]
Mon Mar 30 17:10:00 2015 UDPv4 link remote: 79.107.26.144:32386
after a while this appears
Mon Mar 30 17:12:04 2015 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Mar 30 17:12:04 2015 TLS Error: TLS handshake failed
Mon Mar 30 17:12:04 2015 TCP/UDP: Closing socket
Mon Mar 30 17:12:04 2015 SIGUSR1[soft,tls-error] received, process restarting
Mon Mar 30 17:12:04 2015 Restart pause, 2 second(s)
Now, if i disable the firewall of my client, and i restart the openvpn client, it connects fine:
Mon Mar 30 17:16:55 2015 TLS: Initial packet from 79.107.26.144:26382, sid=ea96d0a6 67c4a473
Mon Mar 30 17:16:55 2015 VERIFY OK: depth=x, /C=xx/ST=xx/L=xxxxx/O=xxxx/CN=xxxxx_CA/emailAddress=openvpn@xxxxxx.com
Mon Mar 30 17:16:55 2015 VERIFY OK: nsCertType=SERVER
Mon Mar 30 17:16:55 2015 VERIFY OK: depth=x, /C=xxx/ST=xx/L=xxxxxx/O=xxxxxx/CN=stardust/emailAddress=openvpn@xxxxxx.com
Mon Mar 30 17:16:55 2015 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Mar 30 17:16:55 2015 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Mar 30 17:16:55 2015 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Mar 30 17:16:55 2015 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Mar 30 17:16:55 2015 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Mon Mar 30 17:16:55 2015 [stardust] Peer Connection Initiated with 79.107.26.144:26382
Mon Mar 30 17:16:57 2015 SENT CONTROL [stardust]: 'PUSH_REQUEST' (status=1)
Mon Mar 30 17:16:57 2015 PUSH: Received control message: 'PUSH_REPLY,route 192.168.112.0 255.255.255.0 vpn_gateway,route 192.168.114.0 255.255.255.0,route 192.168.26.0 255.255.255.0,topology net30,ping 20,ping-restart 120,ifconfig 192.168.26.18 192.168.26.17'
Mon Mar 30 17:16:57 2015 OPTIONS IMPORT: timers and/or timeouts modified
Mon Mar 30 17:16:57 2015 OPTIONS IMPORT: --ifconfig/up options modified
Mon Mar 30 17:16:57 2015 OPTIONS IMPORT: route options modified
Mon Mar 30 17:16:57 2015 ROUTE default_gateway=192.168.201.162
Mon Mar 30 17:16:57 2015 TUN/TAP device tun1 opened
Mon Mar 30 17:16:57 2015 TUN/TAP TX queue length set to 100
Mon Mar 30 17:16:57 2015 /usr/sbin/ip link set dev tun1 up mtu 1500
Mon Mar 30 17:16:57 2015 /usr/sbin/ip addr add dev tun1 local 192.168.26.18 peer 192.168.26.17
Mon Mar 30 17:16:57 2015 /usr/sbin/ip route add 192.168.112.0/24 via 192.168.26.17
Mon Mar 30 17:16:57 2015 /usr/sbin/ip route add 192.168.114.0/24 via 192.168.26.17
Mon Mar 30 17:16:57 2015 /usr/sbin/ip route add 192.168.26.0/24 via 192.168.26.17
Mon Mar 30 17:16:57 2015 Initialization Sequence Completed
The reason why firewall creates a problem , is because port 26382 that the server uses to try and complete the TLS handshake is not allowed by my clients firewall.
shouldn't the client ALWAYS initiate connections to the server (and then the server to reply on the established channel)?
What can I do in this situation, because dropping the firewall on my client is not an option. How should I go about making sure that the client will always initiate a TLS handshake?
Thank you in advance for your help
