I'm sure someone else, or a Google search will get you a more detailed
run-down - but the gist of the "problem" is this;
OpenVPN is run in user-space, not kernel space. IPSec runs in kernel
space, and the difference is vastly diminished throughput.
HTH
-Greg
On Jan 4, 2018 3:23 PM, "Tom Kunz" <tk...@solidrocktechnologies.com> wrote:
> Hi,
>
> I have been testing OVPN 2.4.4 vs StrongSwan IPSec, to be used as
> transport, and I have found something that I think might be a
> performance issue. I have 3 linux boxes, A, B, and C. All interfaces
> are 1Gbps. Each has an interface to the next one downstream:
>
> A - eth0=10.10.10.10/24 and eth1=172.16.0.10/24
>
> B - eth0=172.16.0.11/24 and eth1=172.30.0.11/24
>
> C - eth0=172.30.0.10/24 and eth1=192.168.168.10/24
>
> Packets route as usual through this with no encryption, and throughput
> from A to C is at wire speed. With IPSec between A&B, from
> 172.16.0.10-172.16.0.11, I can still get wire speed from A to C. Then I
> turn off IPSec, and I setup A as the server and B as the client, with
> A's config being:
>
> =====
>
> dev tun
>
> topology subnet
> server 172.17.0.0 255.255.255.0
> port 1194
> proto udp
> dh /etc/openvpn/keys/dh2048.pem
> ca /etc/openvpn/keys/ca.crt
> cert /etc/openvpn/keys/server.crt
> key /etc/openvpn/keys/server.key
> verb 3
> keepalive 10 45
> cipher aes-256-cbc
> comp-lzo
>
> tun-mtu 50000
>
> mssfix 0
>
> fragment 0
>
> client-config-dir ccd
>
> push "route 10.10.10.0 255.255.255.0"
>
> =====
>
> and the client B config file is
>
> =====
>
> verb 3
> client
> cipher AES-256-CBC
> comp-lzo
> tun-mtu 50000
> mssfix 0
> fragment 0
> remote 172.16.0.10 1194
>
> dev tun
> redirect-private local
> tls-client
>
> ca /etc/openvpn/keys/ca.crt
> cert /etc/openvpn/keys/client1.crt
> key /etc/openvpn/keys/client1.key
>
> =====
>
> and I setup static routes on each side so that traffic is going through
> the tunnel from A to C and vice versa.
>
> I can pass traffic over this link, however when I do tests for speed, I
> am only getting about 200Mbps instead of 1Gbps.
>
> The funny thing is, I know that each of these machines can easily do
> 1Gbps. If I do my performance test from A to B, over the above ovpn
> configs, I can get just over 1Gbps because of the MTU overhead being
> removed. But as soon as I have it make the leap downstream once more, I
> lose 80+% of the speed. And again, both non-encrypted traffic and IPSec
> do the exact same test at wire speed or just slightly under wire speed.
>
> The way I do a speed test is on A:
>
> # nc -l -p 5555 > /dev/null
>
> and over on C:
>
> # dd if=/dev/urandom of=blob.random.1G bs=10M count=100
>
> # time cat blob.random.1G | nc 10.10.10.10 5555
>
> tcpdumps over each interface confirm traffic is flowing in the expected
> fashion.
>
> Over unencrypted or IPSec, I am looking at about 4s to move 1G of data
> from one end to the other, and with ovpn, 15-22s. The machines involved
> are 2 Dell R720's with 8+G ram and a homebrew machine with several Xeons
> and 32G RAM. Network cards involved are a mix of BCM Tigon3 "tg3"
> driver and IGB driver gigabit NICs.
>
> Anyone have any suggestions or thoughts as to why the big perf decrease
> and what might be done to improve it?
>
> Thanks,
>
> Tom
>
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
