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?
And I think the TAP-adapter version is the same as before.
Or maybe you guys and girls see some relationship between high port number and 
2.3.10.
What would be the next step to test?
 
Novice thinking loud :)
Thanks,
Pippin

 
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

Reply via email to