Re: [Openvpn-users] ssl pre share mode

[Blaise <blaise@op...>]

Hello,

Thanks for your mail.

It's clear that in preshare mode, the OpenSSL cryptogrpahy library is used. b=
ut it seems

  that the SSL cryptography library is not used in this mode.

So i still have the same question, is the  SSL protocol  used in the preshare=
 key mode too ?

Thanks=20

 	----- Message d'origine -----=09
De: Timothy Madden <terminatorul@...>=09
Date: Sun, 26 Aug 2007 17:16:38 +0300=09
Sujet: Re: [Openvpn-users] ssl pre share=09
=C0: Blaise <blaise@...>=09
Cc: openvpn-users@...=09

As you can see in the man page, chipher and and keysize parameters are used i=
n Static key mode also,=20
and they both refer to the OpenSSL ciphers (that you can list with --show-cip=
hers)


Blaise wrote:=20


 	----- Message d'origine -----=09
De: Blaise <blaise@...>=09
Hello,=20

I try to know if, when using OpenVPN in preshare mode, SSL is used or not ?=
=20


Thanks=20


=09

=09

Re: [Openvpn-users] speed - OPENVPN STATS

[Markus Feilner <lists@fe...>]

Am Sonntag 26 August 2007 02:10:43 schrieb Timothy Madden:
> Mira Suk wrote:
> >> Have you been careful enough when you took the transfer times ? To have
> >> no other
> >> downloads in the background, like maybe Windows update ? Or maybe your
> >> ISP allows high transfer rates to you for some time, after which it will
> >> impose your
> >> traffic limit. Or maybe somewhere in between your endpoints the bandwith
> >> may vary.
> >>
> >> To check if you get overhead measure bandwidth at the interface level.
(...)


Maybe this is helpful for pinning down traffic questions...
If you are on linux: Add a line "status <logfile-name> " to your openvpn 
config .Example:
(...)
status /var/log/openvpn_status.log
(...)

Restart your tunnel software (the init.d-skript) and have a look in the 
logfile. Openvpn frequently updates the values here, and you can easily 
control the traffic on the tunnel. I once had a cacti script that would read 
this file and display the user's or tunnel's traffic statistics in  the 
webgui.

Here is an example output in this file, (on a client!)

:/var/log# cat openvpn_status.log
OpenVPN STATISTICS
Updated,Sun Aug 26 16:44:34 2007
TUN/TAP read bytes,29168
TUN/TAP write bytes,79276
TCP/UDP read bytes,112784
TCP/UDP write bytes,56758
Auth read bytes,79604
pre-compress bytes,5996
post-compress bytes,6232
pre-decompress bytes,0
post-decompress bytes,0
END
:/var/log#  

As you can see, you may also control the effects of compression here.

Here is an example output on a server:

# cat /var/log/openvpn/openvpn-status-test.log
OpenVPN CLIENT LIST
Updated,Sun Aug 26 16:55:05 2007
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
hostname0,11.22.33.44:61335,8994328,15756022,Sat Aug 25 15:14:43 2007
hostname1,55.66.77.88:39776,770283,1704572,Sun Aug 26 16:47:52 2007
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
1.1.1.2,hostname0,11.22.33.44:61335,Sun Aug 26 16:55:04 2007
1.1.1.6,hostname1,55.66.77.88:39776,Sun Aug 26 16:55:04 2007
GLOBAL STATS
Max bcast/mcast queue length,0
END
#
#
-- 

Best Regards - Mit freundlichen Gruessen
Markus Feilner

-------------------------
Feilner IT Linux & GIS
Linux Solutions, Training, Seminare und Workshops - auch Inhouse
Koetztingerstr 6c                93057 Regensburg
fon regensburg                  +49 941 8107989
mobil                           +49 170 3027092=20
www: http://www.feilner-it.net mail: mfeilner@...
--------------------------------------
My new book - Out now: http://www.packtpub.com/openvpn/book
OPENVPN : Building and Integrating Virtual Private Networks

[Openvpn-users] Subject:, speed

[Peter Barwich <pbarwich@ba...>]

Mira,

I have to say I cannot repeat your results. I have two IP's at home so 
can experiment. Even better as far as I can tell they connect via the 
ISP router, not over the wider internet, so ping times are very low (2-3 
msec).. I have a Win2k machine set up as an OVPN server, and an XP 
laptop set up as an OVPN client. . Whichever way I route ftp (via OVPN 
or IP address) I get around the same speed (around 220kB which is around 
my ISP limit, up and down). I have confirmed the packets are actually 
going via VPN or not by looking at the Microsoft management consol for 
networks at each adaptor.

I use UDP also and WOULD NOT use TCP. Google 'TCP over TCP is a bad 
idea'. However I also use dev TAP (not TUN as you do). This means that 
remote machines do not come up in network neighbourhood as NETBIOS 
doesn't work, (and in any case I've turned off netbios over TCP for the 
OVPN adaptor), but I map remote disk drivers via the address (or via the 
machine name since I have my own DNS server). I have read that standard 
windows file sharing kills speed, mainly due to a large number of small 
packets, so I just wondered if by using TUN you are unknowingly invoking 
windows file sharing? Not sure about that, I admit, but worth your while 
remeasuring with dev TAP connections I would have thought.

Good luck,

Peter
> Subject:
> [Openvpn-users] speed
> From:
> "Mira Suk" <mira.suk@...>
> Date:
> Sat, 25 Aug 2007 21:29:06 +0200
> To:
> <openvpn-users@...>
>
> To:
> <openvpn-users@...>
>
>
> Hi,
>
> openVPN 2.0.9
> server Windows SBS 2003
> clients Window XP / Vista
>
> config
> TUN, UDP , blowfish / compression on
>
> Are following speeds normal (in that configuration) or should I look for something wrong ? Any recommendations ? (note I tried disabling compression but nothing changed - file was compressed and OpenVPN is smart ;)
>
> file download (one big file :)
> File sharing through VPN         62 minutes
> FTP through VPN                       53 minutes
> FTP without VPN                        32 minutes
> pings are great I would say.
> ping through VPN                      ~23 ms 
> ping without VPN                       ~19 ms
>
> I have never troubleshooted slowness with OpenVPN, but this link is slow (2MBit)... and I have not used win2K3 before (only linux and win2K)
>
> Oh, and I noticed option "nice" is not implemented for windows [SetPriorityClass, SetThreadPriority] can be used (If I haven't been too lazy to dig in source, I wouldn't have hardcoded it), also CPU affinity makes some small benefits under windows.
>
> Thanks for any hints.

Re: [Openvpn-users] ssl pre share

[Timothy Madden <terminatorul@gm...>]

As you can see in the man page, chipher and and keysize parameters are 
used in Static key mode also,
and they both refer to the OpenSSL ciphers (that you can list with 
--show-ciphers)


Blaise wrote:
>
>
>   	
> ----- Message d'origine -----
> *De:* Blaise <blaise@...>
>
> Hello,
>
> I try to know if, when using OpenVPN in preshare mode, SSL is used or 
> not ?
>
>
> Thanks
>
>

Re: [Openvpn-users] ssl pre share

[Blaise <blaise@qw...>]

Hello,

=20

CAn somebody help about this basic question ?

Thanks


 	----- Message d'origine -----=09
De: Blaise <blaise@...>=09
Date: Fri, 24 Aug 2007 18:04:14 +0200=09
Sujet: [Openvpn-users] ssl pre share=09
=C0: openvpn-users@...=09
Hello,=20

I try to know if, when using OpenVPN in preshare mode, SSL is used or not ?=
=20


Thanks=20

-------------------------------------------------------------------------=20
This SF.net email is sponsored by: Splunk Inc.=20
Still grepping through log files to find problems? Stop.=20
Now Search log events and configuration files using AJAX and a browser.=20
Download your FREE copy of Splunk now >> http://get.splunk.com/=20
_______________________________________________=20
Openvpn-users mailing list=20
Openvpn-users@...=20
https://lists.sourceforge.net/lists/listinfo/openvpn-users=20
=09

Re: [Openvpn-users] speed

[Timothy Madden <terminatorul@gm...>]

Mira Suk wrote:
>> Have you been careful enough when you took the transfer times ? To have 
>> no other
>> downloads in the background, like maybe Windows update ? Or maybe your
>> ISP allows high transfer rates to you for some time, after which it will 
>> impose your
>> traffic limit. Or maybe somewhere in between your endpoints the bandwith 
>> may vary.
>>
>> To check if you get overhead measure bandwidth at the interface level. 
>> In Windows
>> look at Connection properties to see the number of bytes or packets 
>> transferred.
>>
>> You will most likely see that the physical speed is also low when using 
>> VPN,
>> which would mean encryption takes too much time or you have a slow or
>>     
> busy
>   
>> computer. Or maybe the other end is slow or busy.
>>
>>
>>     
>
> Well, openvpn service sits at 0% CPU usage all the time - and I'm almost sure server wasn't busy, at least task manager says so (system idle 10:38, uptime 10:41). 
> Internet connection was unused (that says Firewall - only PC accessing internet was server with openVPN), openVPN and FTP shows only me in logs for today) Windows Update is disabled on server, and I have faster connection than openVPN server.
> measuring traffic on interface is good idea but I don't believe it will change anything (maybe only if my PC decided to slow down two of three tests with the fastest one last) - but I will try. well I will probably measure on firewall for server.
> benching, benching...
>
> 	        down server	up server      up client  down client     time/sec
> FTP	        1547	     103851	    1820	 104006	      476 
> FTP through VPN	5761		107354		5360	   108216	  704
> time is better than was previously, maybe something really happened. 3.5x upload ? lots of ACKs I guess.
> ok, seeing this, first thing I thought about is my connection upload - 4096/256 - however this should not be case for me, but maybe for users (they still sell connections like 2048/128 here). 
> Also note that this behavior is not only for me - I don't use this VPN regularily (just for server maintenance) I just set it up for friend's company, users were the ones noticing this behaviour - "much" slower than FTP.
> Anyway just to be sure I run bench of my and server connection and I got 22KiB while upload during transfer was 7,6KiB and download 417KiB while transfer was 153KiB, server have 242/238KiB. OpenVPN CPU usage 0% (both ends, I E6600@... server Dual Core Xeon@... x 2). oh well.
>
>   
Excellent stats !

Looks like OpenVPN only introduces overhead on the upload. Over all you 
have basically  no overhead.
Your download/upload ratio was almost 16:1, and a connection like 
2048/128 like you said means exactly 16:1
Your connection 4069/256 is also exactly 16:1.

This indicates that you are bound by your upload speed if you ask me :(

And I can not blame the encryption and encapsulation methods for 
introducing overhead on the reverse direction,
it is otherwise a good idea so that you have no overhead on the main 
direction.


This is exactly why I hate ADSL. Like consumer users must not be allowed 
to have some upload !

Especially when peer to peer download software (I use eMule) today trade 
download for upload.
Or maybe I just want to share music or some CD images with my friends. 
Today a photo camera can easily fill
two CDs with photos after a complete shooting session. How will I show 
the photos to my friends on the
internet if all I have is an ADSL connection ?

I for one have a bandwidth between 50/25 and 100/50 (kB/s) at home, with a
cable modem on a TV cable. I bought the line with 50/25, and my provider 
is trying to improve their service to
100/50, only they are not quite there yet.

Ok this is off-topic but I am just mad at what is happening.

I do not know what you could do to fix your problem. Maybe algorithms 
other than blowfish introduce overhead
on the main direction as opposed to overhead on the reverse direction. I 
don't know.

I also have some problems with UDP on my network card (but in my case it 
is because of a bug in the card's
hardware or driver). Maybe you can also try tcp-server/tcp-client 
instead of udp as protocol.

Hope that helps,

Timothy Madden,
Romania