Ok I have been doing some experiments and I can connect using 10000 bit DH 
parameters.  Any bigger than that up to at least 13824 I get the following 
'modulus too large' error on the client log:

TLS_ERROR: BIO read tls_read_plaintext error: error:05066067:Diffie-Hellman 
routines:COMPUTE_KEY:modulus too large: error:14098005:SSL 
routines:SSL3_SEND_CLIENT_KEY_EXCHANGE:DH lib
Wed Apr 22 07:08:58 2015 TLS Error: TLS object -> incoming plaintext read error
Wed Apr 22 07:08:58 2015 TLS Error: TLS handshake failed

Something interesting/weird also happened.  I tried to test 10001, 10002, and 
10004 bit DH to find the exact place I would get the 'modulus too large' error. 
 But the server log reported the DH parameters being 10008 instead.  I did a 
test at 15104 that gave the same error but then I tried two more times and the 
client just sat at the 'initial packet point' like it does with the 16384 bit 
parameters.  So somewhere between 13824 and 16384 it switches between the error 
above and just sitting there 'frozen'.

Questions: 1. Can the modulus error be cured?  2. Do you think the same modulus 
error is going on when the client appears to freeze with parameters larger than 
13824 or is something else going (i.e. why does it freeze instead of giving the 
'modulus error')?  3. Why does the server log report 10001, 10002, 10004 bit DH 
as 10008?

________________________________
> From: bird_...@hotmail.com 
> To: xenoph...@godshell.com 
> CC: janj...@nikhef.nl; openvpn-users@lists.sourceforge.net 
> Subject: RE: [Openvpn-users] Testing with large keys 
> Date: Thu, 1 Jan 2015 23:28:32 -0600 
>  
> Well now it timed out in less than 3 minutes.  This is the server openvpn.log 
>  
> Thu Jan  1 23:15:04 2015 192.168.200.116:50290 TLS: Initial packet from  
> [AF_INET]192.168.200.116:50290 (via [AF_INET]192.168.200.1%br0),  
> sid=bfb37b79 340ac555 
> Thu Jan  1 23:17:32 2015 192.168.200.116:50290 [UNDEF] Inactivity  
> timeout (--ping-restart), restarting 
> Thu Jan  1 23:17:32 2015 192.168.200.116:50290  
> SIGUSR1[soft,ping-restart] received, client-instance restarting 
>  
> I can get it to work using a 8192 DH parameters but 16384 is a no go. 
>  
>  
>  
>  
> > Date: Thu, 1 Jan 2015 22:00:04 -0500 
> > From: xenoph...@godshell.com 
> > To: bird_...@hotmail.com 
> > CC: janj...@nikhef.nl; openvpn-users@lists.sourceforge.net 
> > Subject: Re: [Openvpn-users] Testing with large keys 
> > 
> > -----BEGIN PGP SIGNED MESSAGE----- 
> > Hash: SHA1 
> > 
> > jack seth wrote: 
> >> Could possibly be that. I ran your command below and I get 180 
> >> also. Is there a way to temporarily disable it? Does this happen on 
> >> TCP streams? 
> > 
> > That would be for UDP streams. There are a number of parameters for tcp 
> > connections .. Check out the /proc/sys/net/netfilter directory on your 
> > linux box. 
> > 
> > I wouldn't disable it, but you could determine if that's what the 
> > problem is by changing the value and verifying if the behavior changes. 
> > You can use sysctl to set a new value : 
> > 
> > $ sudo sysctl -w net.netfilter.nf_conntrack_udp_timeout_stream=240 
> > 
> > That would change the setting to 240 seconds. If this ends up being the 
> > problem, you can make these settings permanent via /etc/sysctl.conf. 
> > 
> > - -- 
> > - --------------------------- 
> > Jason 'XenoPhage' Frisvold 
> > xenoph...@godshell.com 
> > - --------------------------- 
> > 
> > "Any sufficiently advanced magic is indistinguishable from technology." 
> > - - Niven's Inverse of Clarke's Third Law 
> > -----BEGIN PGP SIGNATURE----- 
> > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) 
> > Comment: GPGTools - http://gpgtools.org 
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ 
> > 
> > iEYEARECAAYFAlSmCbQACgkQ8CjzPZyTUTTjYwCeJ1kdh3XFe3mOXsXHF1nGa2tn 
> > ehIAnjiX89HjsBPPHzgZCgcrkWbjrk0E 
> > =w6KA 
> > -----END PGP SIGNATURE----- 
                                          
------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Reply via email to