Any OpenSolaris "dladm create-iptun" support for OpenVPN?

jimklimov

Hello all,

I'm using OpenVPN on OpenSolaris (SXCE b129) as a router for a few years now, and it works reliably for a number of remote clients (staff from home, etc.) The setup uses Kazuyoshi's TUN/TAP driver for Solaris: http://www.whiteboard.ne.jp/~admin2/tuntap/ which in turn is a modification of the "Universal TUN/TAP driver": http://vtun.sourceforge.net/tun/ .

One noted problem of our setup is the abysmal performance. For example, I can rsync at about 800-900KBps from a server behind this router's firewall without OpenVPN, but over the tunnel speeds drop to 100-300KBps. Worse limitations - down to 60-100KBps (though expected after reading the forums, blogs and docs) happen for CIFS over OpenVPN. We've tried playing with MTU and stuff, but to no avail. Besides, it would be cumbersome to require all our partners and employees to change their OpenVPN client configurations (RFE hint: some config options should be pushed by server and link establishment).

In some sources it was implied that while some performance degradation may be due to OpenSSL operating on small packets, or TCP/UDP flow control mismatches, or MTU and fragmentations, much of the rest can be blamed on the TUN/TAP interface software - which is made differently for different OSes, often by different authors, and performs - well - differently.

I wanted to try using OpenVPN with OpenSolaris ClearView/CrossBow tunneling interfaces, which are around for a while now (since OpenSolaris build 125, that's about 3 years now). These interfaces present IP-in-IP tunnels, they require knowledge of endpoints' IP addresses, and are configured by commands like this:
# dladm create-iptun -t -T ipv4 -s $LocalIP -d $RemoteIP
It is possible to separately configure IPSec security for the tunnel.

I don't yet know any further details, like requirements for the second side of the tunnel (what software should implement it) or transport protocols used.

Question is: is it known whether these tunnels are compatible with TUN/TAP interfaces used by OpenVPN (on windows, linux, solaris, etc.) and/or if they provide better performance? 😉

Another question is how would I go about integrating support for these OpenSolaris interfaces, if they are not yet directly useable by OpenVPN - should I conjure up some "up" and "down" scripts, or modify "tun.c" of OpenVPN?

Thanks for any hints,
//Jim

kaizawa

Hi,

I've modified tun/tap driver for solaris to improve a performance, and I could found almost tenfold increase in performance. (using netperf tools)
Please try development build below.

https://nodeload.github.com/kaizawa/tuntap/zipball/develop

I'm not sure what actually caused decrease in performance in your environment, but I hope it could solve your performance problem too.
If I won't see any issues, I intend to merge this fix into main branch of my repository.
Then, you will see it at my site.

http://www.whiteboard.ne.jp/~admin2/tuntap/

Thanks,

Kazuyoshi

jimklimov

YES! 🙂
Seems just what was needed.

I ran a few tests, loading the one and the other version of the tun/tap drivers and restarting the OpenSolaris-based OpenVPN server in the process. For a rough test, I copied over CIFS from a Windows box inside the LAN to a Windows laptop on the internet, using FAR file manager to measure reported speeds. OpenVPN tunnel uses UDP.

The 10Mbit/s internet uplink used (from corp LAN to internet) was clogged by a webcam streaming server for part of the test duration, leaving 1.5-2 Mbit/s available. Then the server was put offline for a couple of minutes, leaving the full channel available for the test.

While the older drivers were loaded (TUN/TAP driver 1.1 04/24/2009), CIFS transfers peaked at 64-70Kbyte/sec with or without interference from the webcam streaming.

With the new driver (reported as TUN/TAP driver 1.3.0 08/22/2012) the transfers averaged 140Kbyte/s at least, even with the roughly 1.5Mbit/s of the link available. Speeds varied during transfers of longer files (tens of mbytes in the test), sometimes flatlining at 200-220Kbyte/s, and sometimes reaching 430Kbyte/s or more.

I guess this depended on other intermediate network conditions, but at least the baseline performance was twice that of the tests with the old driver, and reached about 6x improvements from what I've seen. I can not confirm or deny if more is possible in practice - this was a relatively short test, and a relatively unpredictably clogged link 😉

I did not yet get to test my other usecase, with scp/rsync as the very visible example of noticeable performance drop with the old driver.

Overall: Merge it and ship it! 🙂
Thanks, you're our hero!
//Jim Klimov

jimklimov

Unfortunately, the notification from the forums only got to me today. The "Current Source" on site is nearly identical to the one I tested (one difference in pointer cast), so I think my findings do translate to this as well.
And it has been "shipped" a month ago 😉
Still, thanks-a-lot!

jimklimov

I've briefly run the rsync test as well. While the performance is not as bad as with CIFS, rsync over VPN (from the same windows laptop to a separate OpenSolaris fileserver in the LAN behind the OpenSolaris+OpenVPN gateway/router/firewall/NAT box) used to peak at about 300-400 Kbyte/s. With the new driver it reaches 850Kbyte/s in peaks, which is pretty close to what I get on this link without VPN in the way (max today was 950Kbyte/s with "raw" rsync; theoretical marketed BW is 10Mbit/s on both ends with half the globe in between).

Average performance with new drivers and rsync over OpenVPN hovers between 670-800Kbyte/s, which is also roughly twice as good as the 1.1.0 tun/tap driver was, and somewhat worse than what the "raw" link can offer - I guess OpenVPN overheads take its toll (hopefully negligible on server/client CPUs, but likely there are also some packet size and/or latency impacts from tunneling and VPNing itself).

//Jim