Hi Pippin,
On 22-Jan-16 14:34, Dreetjeh D wrote:
Hallo Jan Just and the rest,
Thank you,
Lowering mtu did not help. I`ve tried 1200, 1300 and 1400.
On Android the log also shows 1602 and works flawlessly.
But this morning I had some time and tested the following with my
config as I always used it:
Laptop-->Android-hotspot-->4G-->port 11194 = Fail
Laptop-->Android-hotspot-->4G-->port 443 = Succes
Laptop-->Android-hotspot-->4G-->port 53 = Succes
Laptop-->Public-hotspot-->port 11194 = Fail
Laptop-->Public-hotspot-->port 443 = Succes
Laptop-->Public-hotspot-->port 53 = Succes
The log shows the exact same TLS Warning for port 11194.
I`ve tried three "4G locations" about 10 KM apart from each other and
one Public hotspot.
The three ports 11194, 443, 53 point to the NAS and even though
Android can connect
on all three, I still checked portforwarding.
Disabling the Firewall on laptop also makes no difference.
The next what I want to try is another laptop but I don`t have, so
that will take some time.
Even I reverted back to 2.3.9, it still could be that some settings
remained in registry?
not really
And I think the TAP-adapter version is the same as before.
yup
Or maybe you guys and girls see some relationship between high port
number and 2.3.10.
nope, should "just work"
What would be the next step to test?
hmmm this log line bothers me:
crypto_adjust_frame_parameters: Adjusting frame parameters for crypto by
zu bytes
"by zu bytes" ?!?!?!? Can you try it without compression?
HTH,
JJK
------------------------------------------------------------------------
Date: Fri, 22 Jan 2016 10:42:20 +0100
From: janj...@nikhef.nl
To: dreet...@hotmail.com; openvpn-users@lists.sourceforge.net
Subject: Re: [Openvpn-users] TLS Warning: no data channel send key
available
Hi,
On 21/01/16 16:51, Dreetjeh D wrote:
Hello,
Since yesterday I`m having problems connecting to my home VPN on a
NAS.
First i thought it was because i updated to 2.3.10 so i reverted
back to 2.3.9 but the client log is the same.
This is a laptop W7 Home Premium.
It connects to the Android hotspot and then i start OpenVPN on the
laptop as i always do.
I`m not sure if I already connected after the update to 2.3.10 or
if this was the first time.
Connecting directly from Android works as before.
Connecting with the laptop in the LAN also works.
Configurations on server and client did not change which lead me
to think that maybe the 4G provider (KPN) changed something.
But that seems not logical because I can connect with Android
directly.
There was no update on Android either, everything is still the
same as it was as far as I know so I'm puzzled as to what happened.
The server log shows nothing.
The client log at verb 7:
################
Enter Management Password:
us=462416 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
us=462416 Need hold release from management interface, waiting...
us=930417 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
us=39617 MANAGEMENT: CMD 'state on'
us=39617 MANAGEMENT: CMD 'log all on'
us=117618 MANAGEMENT: CMD 'hold off'
us=117618 MANAGEMENT: CMD 'hold release'
us=515227 MANAGEMENT: CMD 'username "Auth" "admin"'
us=515227 MANAGEMENT: CMD 'password [...]'
us=655627 PRNG init md=SHA1 size=36
us=655627 Control Channel Authentication: using 'ta.key' as a
OpenVPN static key file
us=655627 Outgoing Control Channel Authentication: Using 512 bit
message hash 'SHA512' for HMAC authentication
us=655627 Outgoing Control Channel Authentication: HMAC KEY:
XXXXXXXXXX
us=655627 Outgoing Control Channel Authentication: HMAC size=64
block_size=64
us=655627 Incoming Control Channel Authentication: Using 512 bit
message hash 'SHA512' for HMAC authentication
us=655627 Incoming Control Channel Authentication: HMAC KEY:
XXXXXXXXXX
us=655627 Incoming Control Channel Authentication: HMAC size=64
block_size=64
us=655627 crypto_adjust_frame_parameters: Adjusting frame
parameters for crypto by zu bytes
us=655627 crypto_adjust_frame_parameters: Adjusting frame
parameters for crypto by zu bytes
us=655627 LZO compression initialized
us=655627 PID packet_id_init tcp_mode=0 seq_backtrack=64
time_backtrack=15
us=655627 PID packet_id_init tcp_mode=0 seq_backtrack=64
time_backtrack=15
us=655627 PID packet_id_init tcp_mode=0 seq_backtrack=64
time_backtrack=15
us=655627 PID packet_id_init tcp_mode=0 seq_backtrack=64
time_backtrack=15
us=655627 Control Channel MTU parms [ L:1602 D:1140 EF:110 EB:0
ET:0 EL:3 ]
us=655627 MTU DYNAMIC mtu=1450, flags=2, 1602 -> 1450
us=655627 Socket Buffers: R=[8192->8192] S=[8192->8192]
us=655627 MANAGEMENT: >STATE:1453372063,RESOLVE,,,
us=655627 GETADDRINFO flags=0x0101 ai_family=2 ai_socktype=1
us=780428 RESOLVE_REMOTE flags=0x0101 phase=1 rrs=0 sig=-1 status=0
us=780428 Data Channel MTU parms [ L:1602 D:1450 EF:102 EB:143
ET:0 EL:3 AF:3/1 ]
us=780428 Local Options String: 'V4,dev-type tun,link-mtu
1602,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 1,cipher
AES-256-CBC,auth SHA512,keysize 256,tls-auth,key-method 2,tls-client'
us=780428 Expected Remote Options String: 'V4,dev-type
tun,link-mtu 1602,tun-mtu 1500,proto UDPv4,comp-lzo,keydir
0,cipher AES-256-CBC,auth SHA512,keysize 256,tls-auth,key-method
2,tls-server'
us=780428 Local Options hash (VER=V4): 'XXXXXXXX'
us=780428 Expected Remote Options hash (VER=V4): 'XXXXXXXX'
us=780428 UDPv4 link local (bound): [undef]
us=780428 UDPv4 link remote: [AF_INET]XXXXXXXXXX:1194
us=780428 TLS Warning: no data channel send key available: [key#0
state=S_INITIAL id=0 sid=00000000 00000000] [key#1 state=S_UNDEF
id=0 sid=00000000 00000000] [key#2 state=S_UNDEF id=0 sid=00000000
00000000]
us=780428 SENT PING
us=780428 MANAGEMENT: >STATE:1453372063,WAIT,,,
us=780428 UDPv4 WRITE [86] to [AF_INET]XXXXXXXXXX:1194:
P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #1 ] [ ] pid=0 DATA len=0
us=120432 UDPv4 WRITE [86] to [AF_INET]XXXXXXXXXX:1194:
P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #2 ] [ ] pid=0 DATA len=0
us=800440 UDPv4 WRITE [86] to [AF_INET]XXXXXXXXXX:1194:
P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #3 ] [ ] pid=0 DATA len=0
us=444453 UDPv4 WRITE [86] to [AF_INET]XXXXXXXXXX:1194:
P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #4 ] [ ] pid=0 DATA len=0
us=358080 TLS Warning: no data channel send key available: [key#0
state=S_PRE_START id=0 sid=00000000 00000000] [key#1 state=S_UNDEF
id=0 sid=00000000 00000000] [key#2 state=S_UNDEF id=0 sid=00000000
00000000]
us=358080 SENT PING
us=590482 UDPv4 WRITE [86] to [AF_INET]XXXXXXXXXX:1194:
P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #5 ] [ ] pid=0 DATA len=0
us=223307 TLS Warning: no data channel send key available: [key#0
state=S_PRE_START id=0 sid=00000000 00000000] [key#1 state=S_UNDEF
id=0 sid=00000000 00000000] [key#2 state=S_UNDEF id=0 sid=00000000
00000000]
us=223307 SENT PING
us=388132 TLS Error: TLS key negotiation failed to occur within 60
seconds (check your network connectivity)
######################
I found a post from Mr. Yonan that somewhat explains this error:
http://sourceforge.net/p/openvpn/mailman/message/5886350/
can you try lowering the MTU size by adding
tun-mtu 1400
to the server and client configs? the logs show a link-mtu of 1602
bytes, which exceeds a regular ethernet frame by quite a bit. And yes
, this could be a change in the 4G network, where fragmented packets
are no longer allowed.
HTH,
JJK
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
