From: <ne...@sk...> - 2007-02-12 17:25:10
|
Hello folks, I am working on a research about OpenVPN and IPSec performance. I am doing an evaluation of bandwidth and delay performance on FreeBSD systems with OpenVPN and ipsec-tools software. I am writing to this list because so far I have got a bit strange results when testing their performance. Let me describe a little my first testbed: [Linux client] | | [Router1] ||| ||| [Router2] ||| ... ||| ||| [Router10] | | [FreeBSD server] So there are 10 FreeBSD 6.1 routers, a FreeBSD 6.1 server and a Linux Ubuntu 6.10 client. The topology was always the same, I was just changing the number of established VPNs between the server and the client and of course the type of VPN - OpenVPN and IPSec (ipsec-tools). The second testbed was not tested yet, I am planning to test scalability as a function of the number of simultaneously connected (and transferring) VPN clients to the VPN gateway. Of course for both IPSec and OpenVPN. But this situation is not what I am talking about here. I created a script which downloads 128MB file via HTTP, FTP, SMB and iperf ("pure" TCP) from the server to the client. I would like to draw conslusions about scalability of the number of VPN connections between the client and the server. I did the measurements for OpenVPN and got these results (each measurement was repeated 9 times and then the mean was computed): Number of VPNs SMB [kB/s] HTTP [B/s] FTP [B/s] iperf [kB/s] ping [ms] ------------------------------------------------------------------------ 0 (plaintext) 6669,57 9630588 10700136 9902,67 1,080 1 2946,14 3100290 3569819 5035,67 1,427 2 1923,77 2026082 2312693 3465,11 1,788 3 1650,19 1848989 2130939 3388,89 2,167 4 1472,79 1692140 1901855 3059,38 2,580 5 1398,39 1608982 1839668 2959 2,868 6 1324,77 1522765 1796560 2923,89 3,226 7 1247,46 1480822 1756947 2843,67 3,636 8 1192,31 1435238 1719665 2763,75 4,071 9 1158,36 1402470 1682964 2768,13 4,407 ------------------------------------------------------------------------ For me, the results are quite what I would expect. The plaintext data went through almost with nominal 100Mbit/s speed. The first VPN connection slowed things down drastically. The only thing which is interesting to me is, that the slowdown is not a linear function of the number of VPNs and that "iperf" went through VPNs much faster, I assume that is because of the compression. The files which I was transferring over SMB, FTP and HTTP were generated using /dev/random, which was not the case for iperf. Now the interesting part is IPSec performance: Number of VPNs SMB [kB/s] HTTP [B/s] FTP [B/s] iperf [kB/s] ping [ms] ------------------------------------------------------------------------ 0 (plaintext) 6669,57 9630588 10700136 9902,67 1,080 1 1621,5 1930545 1999285 1881,1 1,434 2 1001,5 1070713 1101005 1051,0 1,733 3 916,9 1069548 1101005 1045,0 2,161 4 868,0 1059062 1094014 1042,4 2,414 ------------------------------------------------------------------------ So this is what I get by using ipsec-tools (racoon). I think these values are unnormally small for IPSec (that's why I didn't finish testing it, so the maximum number of VPNs included in the test here is 4, not 9). As far as I understand, OpenVPN should be slower since there are many more context switches when a packet travels through the VPN connection. The config files are published here: http://nejc.skoberne.net/data/Faks/racoon.conf http://nejc.skoberne.net/data/Faks/ipsec.conf http://nejc.skoberne.net/data/Faks/openvpn-server.conf http://nejc.skoberne.net/data/Faks/openvpn-client.conf The current work-in-progress document (for more information on the experiment) can be found here: http://nejc.skoberne.net/data/Faks/VPN1.pdf The hardware is: - HP ProLiant ML110 G4 (Xeon 1.86 GHz with 512MB RAM for FreeBSD server) - Dell Inspiron 4150 (Pentium 4 1.6 GHz with 512MB RAM for Linux client) - VIA EPIA-PD machines (VIA C3 1 GHz with 256MB RAM for FreeBSD routers) Although VIA C3 processor supports VIA Padlock capability, it was not (at least not explicitly?) used during the tests. So my questions are: 1. Do you have any ideas what might cause the unusual slowdown when using IPSec? 2. Do you have any experience to estimate what the results *should* look like? 3. What would you be interested in if you had all this hardware and time to test the VPN connections? What kind/type of perfomance? Thanks a lot for your time. The results will be published on my blog when I finish the testing and process the results at http://nejc.skoberne.net. Bye, Nejc |
From: Mike T. <mi...@se...> - 2007-02-12 20:29:05
|
At 12:23 PM 2/12/2007, =?ISO-8859-2?Q?Nejc_=A9koberne?= wrote: >So my questions are: > >1. Do you have any ideas what might cause the unusual slowdown when >using IPSec? Try the OpenVPN tests with tls-auth as well as this will be a little more "fair" as you have hmac_sha1 on the ipsec side of things. I think pfs also adds overhead that is not present in OpenVPN, so try with it off. Also, what is the default encryption on openvpn ? Try changing it to 3des just like you are using in IPSEC. For the FreeBSD side make sure you use FAST_IPSEC as its faster (even without hardware acceleration) than the KAME version on FreeBSD which is the default. i.e. add in options FAST_IPSEC #new IPsec device crypto device cryptodev and take out INET6 and the other 2 ipsec defs >2. Do you have any experience to estimate what the results *should* look >like? > >3. What would you be interested in if you had all this hardware and time >to test the VPN connections? What kind/type of perfomance? We use both IPSEC and OpenVPN and personally, I prefer OpenVPN if I control both ends. Its much more flexible, especially in environments where NATing or dynamic IP addresses are involved or goofy MTU issues (e.g. PPPoE)... Its a LOT easier to deal with such environments with OpenVPN. Also, you can cram in many more connections than IPSEC (on FreeBSD at least). Once you add in more than a few hundred IPSEC policies you start to run into problems with the SADB structure hitting some hard limits. (At least on FreeBSD). For us, 250 was kind of the limit for total polices and associations and if you have a lot of tunnels re-keying at the same time, you could hit that limit sooner than later. Other than that, IPSEC on FreeBSD is quite stable especially using IPSEC Tools. The old version of raccoon had quite a few bugs that we would trip on, but these days its quite stable.... Then again, so is OpenVPN. If you are using C3 based boxes, try using AES as the default encryption and using engine padlock in your openvpn config file. On FreeBSD to use the Via padlock acceleration, load in device padlock to offload IPSEC AES crypto transformations. Use FreeBSD 6.2 as there are a number of bug fixes as well. ---Mike |
From: Muenz, M. <m....@sp...> - 2007-02-13 08:14:09
|
Nejc Škoberne schrieb: > So my questions are: > > 1. Do you have any ideas what might cause the unusual slowdown when > using IPSec? 3DES! Use AES, should be up to 10 times faster. > 3. What would you be interested in if you had all this hardware and time > to test the VPN connections? What kind/type of perfomance? I would like to see the results with blowfish encryption if available. :) Michael |
From: David B. <Dav...@he...> - 2007-02-13 08:31:46
|
iperf has the -F and -I options to use predefined data, so u can use the = same as for the other tests. =20 ________________________________ From: ope...@li... on behalf of Nejc = Skoberne Sent: Mon 12-Feb-07 18:23 To: ope...@li...; = ips...@li... Subject: [Openvpn-users] OpenVPN vs. IPSec performance Hello folks, I am working on a research about OpenVPN and IPSec performance. I am doing an evaluation of bandwidth and delay performance on FreeBSD systems with OpenVPN and ipsec-tools software. I am writing to this list because so far I have got a bit strange results when testing their performance. Let me describe a little my first testbed: [Linux client] | | [Router1] ||| ||| [Router2] ||| ... ||| ||| [Router10] | | [FreeBSD server] So there are 10 FreeBSD 6.1 routers, a FreeBSD 6.1 server and a Linux Ubuntu 6.10 client. The topology was always the same, I was just changing the number of established VPNs between the server and the client and of course the type of VPN - OpenVPN and IPSec (ipsec-tools). The second testbed was not tested yet, I am planning to test scalability as a function of the number of simultaneously connected (and transferring) VPN clients to the VPN gateway. Of course for both IPSec and OpenVPN. But this situation is not what I am talking about here. I created a script which downloads 128MB file via HTTP, FTP, SMB and iperf ("pure" TCP) from the server to the client. I would like to draw conslusions about scalability of the number of VPN connections between the client and the server. I did the measurements for OpenVPN and got these results (each measurement was repeated 9 times and then the mean was computed): Number of VPNs SMB [kB/s] HTTP [B/s] FTP [B/s] iperf [kB/s] ping [ms] ------------------------------------------------------------------------ 0 (plaintext) 6669,57 9630588 10700136 9902,67 1,080 1 2946,14 3100290 3569819 5035,67 1,427 2 1923,77 2026082 2312693 3465,11 1,788 3 1650,19 1848989 2130939 3388,89 2,167 4 1472,79 1692140 1901855 3059,38 2,580 5 1398,39 1608982 1839668 2959 2,868 6 1324,77 1522765 1796560 2923,89 3,226 7 1247,46 1480822 1756947 2843,67 3,636 8 1192,31 1435238 1719665 2763,75 4,071 9 1158,36 1402470 1682964 2768,13 4,407 ------------------------------------------------------------------------ For me, the results are quite what I would expect. The plaintext data went through almost with nominal 100Mbit/s speed. The first VPN connection slowed things down drastically. The only thing which is interesting to me is, that the slowdown is not a linear function of the number of VPNs and that "iperf" went through VPNs much faster, I assume that is because of the compression. The files which I was transferring over SMB, FTP and HTTP were generated using /dev/random, which was not the case for iperf. Now the interesting part is IPSec performance: Number of VPNs SMB [kB/s] HTTP [B/s] FTP [B/s] iperf [kB/s] ping [ms] ------------------------------------------------------------------------ 0 (plaintext) 6669,57 9630588 10700136 9902,67 1,080 1 1621,5 1930545 1999285 1881,1 1,434 2 1001,5 1070713 1101005 1051,0 1,733 3 916,9 1069548 1101005 1045,0 2,161 4 868,0 1059062 1094014 1042,4 2,414 ------------------------------------------------------------------------ So this is what I get by using ipsec-tools (racoon). I think these values are unnormally small for IPSec (that's why I didn't finish testing it, so the maximum number of VPNs included in the test here is 4, not 9). As far as I understand, OpenVPN should be slower since there are many more context switches when a packet travels through the VPN connection. The config files are published here: http://nejc.skoberne.net/data/Faks/racoon.conf http://nejc.skoberne.net/data/Faks/ipsec.conf http://nejc.skoberne.net/data/Faks/openvpn-server.conf http://nejc.skoberne.net/data/Faks/openvpn-client.conf The current work-in-progress document (for more information on the experiment) can be found here: http://nejc.skoberne.net/data/Faks/VPN1.pdf The hardware is: - HP ProLiant ML110 G4 (Xeon 1.86 GHz with 512MB RAM for FreeBSD server) - Dell Inspiron 4150 (Pentium 4 1.6 GHz with 512MB RAM for Linux client) - VIA EPIA-PD machines (VIA C3 1 GHz with 256MB RAM for FreeBSD routers) Although VIA C3 processor supports VIA Padlock capability, it was not (at least not explicitly?) used during the tests. So my questions are: 1. Do you have any ideas what might cause the unusual slowdown when using IPSec? 2. Do you have any experience to estimate what the results *should* look like? 3. What would you be interested in if you had all this hardware and time to test the VPN connections? What kind/type of perfomance? Thanks a lot for your time. The results will be published on my blog when I finish the testing and process the results at http://nejc.skoberne.net <http://nejc.skoberne.net/> . Bye, Nejc -------------------------------------------------------------------------= Using Tomcat but need to do more? Need to support web services, = security? Get stuff done quickly with pre-integrated technology to make your job = easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache = Geronimo http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D= 121642 _______________________________________________ Openvpn-users mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/openvpn-users |
From: VANHULLEBUS Y. <va...@fr...> - 2007-02-13 08:50:34
|
On Mon, Feb 12, 2007 at 06:23:44PM +0100, Nejc ?koberne wrote: > Hello folks, Hi. [....] > So my questions are: > > 1. Do you have any ideas what might cause the unusual slowdown when > using IPSec? Fragmentation. Lower your MTU on both FreeBSD server and Linux client (but of course NOT on routers on the way), let's say to 1400 or 1350, and try again. You can also try other things, such as using FAST_IPSEC (which should use your VIA padlock) instead of KAME's IPSec, check your router's CPU usage and other indicators to see where things slows down. Also check what algorithms are *really* used on both openvpn and ipsec (phase2, that is the really important part of the setup for such benchs). > 2. Do you have any experience to estimate what the results *should* look > like? Results really depends a lot on various parameters such as algorithms, traffic, etc... Yvan. |