My OpenVPN configuration

[sinshiva]

Hi all,

Been playing with my RT-N66R. So, i got OpenVPN working for the first time. Always had trouble getting things to accept certificates before and ended up blowing it off.

Anyway, i did lots of testing of the performance variety. I am running the service on 443/tcp. So for my tests, i'm possibly losing out on any benefits offered for UDP streams.

The final result is thus;

4096bit RSA keys (should be strong enough?)
6144bit DH 'modulus'
192bit AES CBC

with the below added to the 'Custom configuration' field.

tls-cipher DHE-RSA-AES256-SHA  //this whole field is outdated, read on
auth sha512

For the 4096bit RSA keys, this is good enough? For the Diffie Hellman modulus, i started out low and worked up to generating this 8192bit modulus (single core (can this be multithreaded for a single modulus?), about 6 hours on an Athlon 2 x4 645), obviously now free to the public domain.

-----BEGIN DH PARAMETERS-----
MIIECAKCBAEA7Qk27H7hBvDdQESs+CDS5OKNqxjovkTgFmgPKX/jYBeqn1m+IF/z
yF85kU0VIMqR1W9xLGsCbUdQmZ110IXKzizjIGwTmEetoGfOFZp6cCyEcRuokt1H
9fk+KFw989L49PMa8Y4bK+LQlsWLmFZnWNtzRGQmX9xMSJi9ae3hHJIhD3mTLWQd
p2VYLOlpzySsxXKMlq4NZrqCJ+5b3HpqD90MWgL0f1Dn+wnL3/bqvrtSsNeICxZw
GBuXal2bfCrUZUrrskbdwReS9isrrW06oyjd8/0nnK/ryP+LdKTlY5Vokr8ncqia
7hxtUm1A1myZJqd4JJ2rJVJsuKIbgqKIKtukcSvqjDvxLpINNuke7WwA8OEPDOAq
T33cj5e6AUHwErFemFE7mLZb40XFppcBTluRxOtCBDUHE3IJitmbNWF85nOc5uK7
VNL1upx7rnwT94qcRNLyUzIT+3F/Gw5YR8lRryyaEjFoRlWkFVz3yO5VXluZeAsz
dYjkSrLi5eUHYBdUpRWraSSr6l6YTZjdxp4UUWwB/ulxA9Lneij+YJmdsThneQkp
2mmh7bxVi04uvzmrl6Mye3rUz0D9v7z6xIAz9IzTtRhrC2r5agQuyS16B17LvgwM
OMNecsuiscWARmN6HOouTqSz6+S5HPBBn6p0a177Ye0woKNTfzmdZsZDPcRad1R0
SUKLsWbtKcCODcY/LCisjfscrqM7uS3UZL26bDcYO4+GD3RgDo6unfFRlsB7UBSc
/aatIV3BuOJfCiBROAt6utAZscSi+5eby9+JPIDaAED0IOISgA6AKxbQdo8fjMxa
q9Wpp23kqQdpBKEO4tKOi+3yZc/8P3dHUXtOiSZzESB0WNG3yx2gGWd4+6DWCN2g
+QnBDzS0cHLihwUudcezbh1AinGaa0Eg8W+m0JyOQDgphVHaxYpf+9Gi7lDQZfqN
vPIFxeRsOv9B06YK/LweqaqafvF9yS4i9jZF7QfWA3JBswzl9Olh4CEzRUQw1Rw+
giSnu5hHKkk01hS6kJiRskJkHs8+agZe77po9W5+oJo/FViaL4oObpymSjsdz/PI
TYp0d3FqPGlQWCH9W18Rcggl8hCuUVLoh3VAKlpCB2ovS2c6nsiC7vqGZ9GRgO8W
pZWcBMnn2thUtSY0p4mJyeGdBxA+5gKoYvKznNljcpu5f4BgKGCYygrBRix3tEZv
Jcv0H4VoObAE5CjtXt23J/Aj0zKRSCLFX9TyuWVKUOY0YgE7dxt6TKjHCKY2ZYsx
v0NOJRORkuSXkdd2HvPR/WlGvIxSlvCOW/QSCfW4GGusRfQi5Ok9LDe7sVy1oqEK
wuxBCa1HWoDpXarRLtHVVgc1XW3SHVOUQwIBAg==
-----END DH PARAMETERS-----

Unfortunately, this was too slow/whatever for the router, i think. nothing would handshake, just time out. I generated a 6144bit DH mod and while a little slow handshaking, once connected everything operates very quick.

I ended up with using the cipher aes-192-cbc because on my single core devices, i saw great bandwidth improvements testing over my wifi compared to 256bit, and according to this guy, it looks like it would require a 16384-bit DH mod for aes-256-cbc.

Sorry for the lack of pretty graphics, but my primary method of testing was using a netbook with a single core hyperthreaded Atom processor (running winxp) and a 1ghz single core Android phone. Only the Android was connected over wifi and bandwidth was tested using the Speed Test application by ping-test.net with 10mbit/768kbit DSL.

My vpn throughput over both devices was higher with aes-192-cbc than aes-256-cbc and bf-cbc. At less than half wifi strength, i was getting 1-3mbit with bf-cbc, 1-2mbit with aes-256-cbc, but with aes-192-cbc, i am getting 7-8mbit.

Anyway, remember, this all was with using the RT-N66R for my OpenVPN server.

comments appreciated

 

[Dreamslacker]

A 2048 or 4096 DH key should suffice for most purposes. There's no real need to go any higher especially if these are ad-hoc connections rather than site to site permanent links with data being transmitted all the time.

Funny that you get worse rates on Blowfish-128 compared to AES-192 though. Without any specific crypto hardware to offload AES, you should be getting better performance with BF-CBC-128.

 

[sinshiva]

i think on one of my devices, blowfish ended up performing better, the old acer atom netbook. however, my 1ghz samsung epic downclocked didn't really make a whole lot of difference, and it likely what i'll be typically be using the vpn for.

i added to my configurations and downgraded the DH key because a friend's iphone4 was having trouble with higher than 2048. even 3074bits or whatever was slow. additionally, i realized i forgot to add the tls-client line to my client configurations; duh. i also reduced hmac to 256 for the iphones, just in case.

also, i discovered that while leaving the MTU untouched worked fine for linux and windows, apple users get problems if i don't at least set the link-mtu. which amuses me, everywhere online it seems to typically suggest using the tun-mtu for setting the tunnel's inside MTU rather than the outside. i'd have figured that in most cases, what's going on with the outside of the tunnel would be most volatile. the only cases i really saw setting the inside MTU to be important is with various kinds of PPP links. i considered running the MTU at 1492 incase any of the wifi hotspots i go to are running their connection over PPPoE. i think that most of them in town from at&t might be, but i have to test their MTU next time i go to one to find out. in the end, i've just set the link-mtu to 1500 leaving the tun-mtu undefined rather than setting the tun-mtu to 1428, because the openvpn server wouldn't start with both.

For the Windows TAP driver, on both a windows xp and a windows 7 machine i had to edit the TAP interface's MTU to 1428, otherwise it would get DF errors.

Server config;

[edit15dec] reupped photos; as i'm using the tun-mtu parameter set at 1384, i've altered the below accordingly to reflect MY configuration based on a WAN MTU of 1456.

tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA
auth sha256
tun-mtu 1384  //use link-mtu 1500 or tun-mtu 1428 for most people
mssfix 0

as with below, this is based on the configuration page of what is now a legacy firmware.

and the top of my ovpn configs;

client
tls-client
remote-cert-tls server
mssfix 0
tun-mtu 1384 //if you have 1500 MTU, use link-mtu 1500 or tun-mtu 1428
comp-lzo
verb 3
dev tun
remote blahblahblah.net 443 tcp-client
nobind
auth sha256
float
cipher aes-128-cbc
verify-x509-name changeme name
persist-tun
persist-remote-ip

i switched to tun-mtu because it seems to be a more widely used parameter. i'd switch back to link-mtu if it weren't such a task redoing all the configs.

[/edit15dec]

with the above settings, everything connects; apple (except my friend's unrooted ipad), android or windows. yea, my server's x509 name thing is changeme. it was changed for the user keys lol.

[edit/] forgot to mention, the n66r is set to be the WINNS server/master browser via 'USB application > Miscellaneous setting' which i think is required to access samba shares over tun. I also added a spare 16gb sd card into the n66r for archival purposes. bye bye warranty.

 

[Dreamslacker]

You don't need a Master browser server to do SAMBA over TUN. You just need to access shares by IP rather than browsing the Local Network or using the hostnames.

 

[sinshiva]

so, i found my most efficient MTU to be 1456. therefore, i'm now using tun-mtu 1384 for my configurations.

I don't entirely know how my internet connection works, but here goes.

This is the information i got from my eq660 adsl modem.

[edit15dec] images gone, using a westell 7500 now, anyway. [/edit]

it sorta helped. i learned a bit about ATM googling around and it's 48byte payload, 48*31 = 1488 MTU to fit evenly in ATM cells, etc, etc.

What I ultimately ended up doing was working my way down speedtesting each MTU, dropping 2 bytes at a time from 1488. My maximum down bandwidth would perceptibly drop steadily as it got closer and closer to the ideal MTU. when i hit 1456, my max bandwidth shot up to a bit higher than what i was getting with a 1500 MTU. i then tested this by going back up to 1457 MTU and speedtesting, and it was right back where it was as it was scaling down with the MTU size.

And that's how i figured out my ideal MTU size to be 1456

This is on CenturyLink ADSL with 10mbit down, for the moment. seeing about bumping that up by tonight, actually.

[edit/]

[edit15dec/]image gone, sorry

 

[sinshiva]

Since merlin allows us to run two servers, i decided to setup a low latency udp server.

configuration below;

server;

[edit15dec]

tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA
auth sha256
fragment 1379    //1423 for most people
mssfix 1379     //1423 for most people
tun-mtu 1383   //1427 for most people

i think the pictures must have expired on postimg or something, sorry.
[/edit]

i apologize, but my firmware is outdated so this may or may not look like your configuration at the server page. however, as i understand it, the server will now let you drop in ovpn configurations, which is pretty cool.

top of client ovpn;

client
tls-client
remote-cert-tls server
tun-mtu 1383  //1427 for most people; with 1500 WAN MTU
fragment 1379 //this is why it makes more sense to use tun-mtu
mssfix 1379   //rather than link-mtu for a UDP vpn.  tunmtu less 4.
verb 3        
dev tun
remote blahblahblah.net 1194 udp
nobind
auth sha256
float
cipher aes-128-cbc
verify-x509-name nerieus name
persist-tun
persist-remote-ip

for this udp/1194 configuration, you must do a little math; with udp, you take your MTU, such as 1500 and subtract 73 to get a tun-mtu of 1427. after, you must specify the fragmentation and mssfix size, which needs to be 4 bytes less than the tun-mtu due to overhead, or 1423. this helps tcp data traversing the udp tunnel. (note: my configuration is based on a MTU of 1456)

also to note; i did disable comp-lzo compression for the udp server to further eliminate latency. i also spent some more time comparing bf-cbc and aes-128-cbc, and saw better performance from aes with the hardware I intend to use. i definitely suggest testing both via the devices you intend to utilize the tunnel with.

essentially, this gives us a more multipurpose tunnel than the tcp/443 server. with the lower latency, you can play LAN games, enjoy faster streaming, etc. whereas the tcp/443 server is more of an exfiltration/gtfo vpn.

thank you merlin for giving us the best of both worlds, eh?