OpenVPN traag

[Tha Ra]

Beste Tweakers,

Ik heb voor het volgende nog geen oplossing kunnen vinden (wel mensen met hetzelfde probleem maar geen antwoord):
Ik zit op dit moment voor mijn studie in Finland en maak verbinding met mijn NAS server thuis in Nederland via een VPN, echter is de snelheid verre van optimaal. Het thuisnetwerk in Nederland is als volgt:

Ubee modemrouter met Ziggo 150/15 Mbit/s
Poort 1194 netjes geforward naar OpenVPN
Hierop zitten bekabeld aangesloten:

NAS met CIFS en FTP
Freenas 9
Intel Xeon E3, 16 GB
Intel 1 Gb/s NIC

Oude netbook met OpenVPN
Ubuntu 12.04 LTS
Intel Atom N270 (single core, 32 bit), 1 GB
Realtek 100 Mb/s NIC (gebridged met virtuele TAP adapter)

In Finland heb ik een Laptop met Windows 7 met Realtek GBit NIC en een razendsnelle glasvezelverbinding (Ik vermoed 1 Gbit/s, maar de online speedtesten kunnen het niet aan . In ieder geval boven de 500 Mb/s).

Als ik een bestand upload naar de NAS in Nederland over mijn VPN, of dit nou via CIFS (SMB) of FTP gaat, is de transfer snelheid niet hoger dan ongeveer 4 Mb/s terwijl de bottleneck 100 zou moeten zijn (NIC van VPN-server). Als ik tijdens de transfer de CPU load van de VPN-server bekijk, komt die niet boven de 10% (RAM rond de 15 %). OpenVPN is zo simpel mogelijk geconfigureerd en doet alleen briding dus geen NAT.

Het vreemde is echter, als ik anuit Finland direct over het internet verbinding maak via FTP met de NAS, dan haal ik wel gewoon bijna de maximum snelheid (135~140 van de 150 Mb/s van Ziggo).

Heeft VPN een enorme overhead? Is er iets niet in orde met mijn VPN-server? Heeft VPN-verkeer een lage prioriteit voor ISPs?
Hoe krijg ik deze snelheid in orde?

[Pakjebakmeel]

Post je config voor server en client eens (uiteraard gevoelige data weglaten). Misschien rare MTU size? Of iets met send/receive window scaling?


Die atom is niet zo snel maar meer dan 4Mb/s AES zou hij toch wel moeten kunnen?

Check:

code:

Processor                      AES-256-CTR+HMAC-SHA256     AES-256-GCM
----------------------------------------------------------------------
Intel Atom N270, 1.6 GHz                  59.48 Mbit/s    89.63 Mbit/s
Intel Atom 330, 1.6 GHz                   79.72 Mbit/s   238.11 Mbit/s
AMD Phenom II X4 965, 3.4 GHz            336.96 Mbit/s   478.66 Mbit/s
Intel Core i3-3220T, 2.8 GHz             543.64 Mbit/s     1.69 Gbit/s
Intel Core i7-3960X, 3.3 GHz             787.99 Mbit/s     5.60 Gbit/s

[ Voor 66% gewijzigd door Pakjebakmeel op 25-04-2014 07:07 ]

[Andre_J]

Ik weet dat in windows de TAP adapter een limiet heeft van 10 Mbit.
Of dat in Linux ook het geval is ?? wellicht kan je dat uitzoeken.

[Pakjebakmeel]

Andre_J schreef op vrijdag 25 april 2014 @ 11:06:
Ik weet dat in windows de TAP adapter een limiet heeft van 10 Mbit.
Of dat in Linux ook het geval is ?? wellicht kan je dat uitzoeken.

Maar dan nog.. 4mbit?

[Grootstyr]

Die 4Mbps klinkt vrij logisch als het om een upload gaat, van NAS naar Finland dus, maar andersom is het bijzonder weinig. Is er een specifieke reden waarom je een bridged VPN gebruik ipv een routed VPN?

edit: 4Mbps is nog steeds weinig met een upload van 15Mbps.

[ Voor 13% gewijzigd door Grootstyr op 25-04-2014 11:19 ]

[Orion84]

Waarom is 4mbit logisch, als er 15mbit aan bandbreedte ter beschikking staat?

Ik heb ook een ziggo 150/15 lijn en gebruik ook OpenVPN (vpn server draait op mijn NAS) en ik trek gewoon die 15mbit dicht (voor zover mijn verbinding hier in Frankfurt dat toelaat, want in tegenstelling tot TS is dat maar een brakke (gedeelde) lijn, ipv sexy gbit glas).

@TS: is het geen optie voor jou om de VPN server op je NAS te draaien? Die machine ziet er een stukje capabeler uit dan dat laptopje?

[ Voor 16% gewijzigd door Orion84 op 25-04-2014 11:30 ]

[Tha Ra]

Bedankt voor de reacties tot zover

@Pakjebakmeel
Ik zal vanmiddag als ik weer thuis ben de configs posten

@AndreJ
Volgens mij is dit niet zozeer een limiet maar gewoon de aangeveven linksnelheid. Ik heb begrepen dat je daar gewoon overheen kunt komen

@Grootstyr
Omdat ik in de netbook geen mogelijkheid heb om een tweede NIC te installeren (afgezien van iets met USB) begreep ik dat mijn enige optie een bridge was. Ik kan het fout hebben, ik heb niet zoveel kaas gegeten van networking.

@Orion84
Er staat geen 15 maar 150 Mbit ter beschikking, het gat om uploaden naar Nederland. Ik heb vroeger tijdens het opzetten van de VPN inderdaard geprobeerd deze op de NAS te draaien, maar ik kreeg het niet voor elkaar. Kennelijk vindt FreeNAS het niet zo leuk als je zelf software gaat installeren buiten de jails om, het root fs is dan ook read only gemount standaard. Tevens kan ik op deze manier mijn (niet al te zuinige) NAS aanzetten via IPMI.

[Tha Ra]

Hier zijn mijn config files:

Server

code:

local 192.168.178.25

port 1194

proto udp

dev tap0

ca ca.crt
cert server.crt
key server.key

dh dh1024.pem

ifconfig-pool-persist ipp.txt

server-bridge 192.168.178.25 255.255.255.0 192.168.178.2 192.168.178.9

push "route 192.168.178.0 255.255.255.0"

push "dhcp-option DNS 192.168.178.1"

client-to-client

keepalive 10 120

tls-auth ta.key 0

comp-lzo

user nobody
group nogroup

persist-key
persist-tun

status openvpn-status.log

verb 6

up "/etc/openvpn/up.sh br0"
down "/etc/openvpn/down.sh br0"

Client

code:

client

dev tap

proto udp

remote xx.xx.xxx.xxx 1194

resolv-retry infinite

nobind

persist-key
persist-tun

ca ca.crt
cert Notebook_Ramon.crt
key Notebook_Ramon.key

ns-cert-type server

tls-auth ta.key 1

comp-lzo

verb 3

[_JGC_]

Je zou kunnen proberen de LZO compressie uit te schakelen. Verder zal CIFS nooit snel worden, ondanks je bandbreedte zorgt de latency tussen Ziggo en je verbinding in Finland ervoor dat bestanden extreem traag verstuurd worden.

Welke kernel draait je Ubuntu machine overigens? In 3.14 zit een regressie in de tun/tap driver waardoor OpenVPN extreem langzaam wordt.

[Tha Ra]

_JGC_ schreef op zaterdag 26 april 2014 @ 11:39:
Je zou kunnen proberen de LZO compressie uit te schakelen. Verder zal CIFS nooit snel worden, ondanks je bandbreedte zorgt de latency tussen Ziggo en je verbinding in Finland ervoor dat bestanden extreem traag verstuurd worden.

Welke kernel draait je Ubuntu machine overigens? In 3.14 zit een regressie in de tun/tap driver waardoor OpenVPN extreem langzaam wordt.

De compressie uitschakelen zou ik inderdaad kunnen proberen. Dat CIFS traag is kan ik me voorstellen, maar FTP is ook heel erg traag over de VPN tewijl het direct over het internet wel de volledige snelheid haal.

Ik draai kernel 3.8 btw

[Pakjebakmeel]

De latency over glas en kabel zal wel meevallen.. Iets met MTU sizes? Doe eens een ping testje van van WAN naar WAN adres. Je zet de do-not-fragment bit aan en maakt de payload groter.. De verwachting zou moeten zijn dat je maximaal 1472 per pakket door de lijn krijgt zonder fragmentatie. Voorbeeld hieronder.

code:

C:\Users\smeltekw>ping -l 1472 -f www.google.com

Pinging www.google.com [74.125.136.106] with 1472 bytes of data:
Reply from 74.125.136.106: bytes=64 (sent 1472) time=15ms TTL=49
Reply from 74.125.136.106: bytes=64 (sent 1472) time=14ms TTL=49
Reply from 74.125.136.106: bytes=64 (sent 1472) time=16ms TTL=49
Reply from 74.125.136.106: bytes=64 (sent 1472) time=17ms TTL=49

Ping statistics for 74.125.136.106:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 14ms, Maximum = 17ms, Average = 15ms

code:

C:\Users\smeltekw>ping -l 1473 -f www.google.com

Pinging www.google.com [74.125.136.106] with 1473 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 74.125.136.106:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Hoe is de snelheid van de lijn buiten VPN om? Als je even tijdelijk FTP naar het interwebz open zet en op die manier test? Daarnaast zou je ook eens een paar packets kunnen capturen en kijken wat de MTU size is?

Het lijkt me in ieder geval handig om eerst vast te stellen hoeveel je uberhaupt door die lijn heen krijgt.. Dan weten we of het aan de lijn of de VPN ligt.

[ Voor 7% gewijzigd door Pakjebakmeel op 26-04-2014 14:50 ]

[Tha Ra]

Pingen van Finland naa Ziggo lukt helaas niet. Omgekeerd werkt wel en levert ongeveer 200 ms latency op bij een packet size van 1472. Groter dan dan lukt het niet op te pingen. De snelheid buiten het VPN om (direct FTP naar internet) levert, zoals in de SP, ongeveer 135 á 140 Mbps op.

[Pakjebakmeel]

Ah, ik zie het nu. Had er schijnbaar overheen gelezen. MTU size is dus in orde blijkbaar. Er is een mechanisme om dynamisch de maximale MTU size vast te stellen, dat heet PMTU en het is afhankelijk van een specifiek ICMP type. Als je ping dropt kan dat protocol de mist in gaan en wellicht zet de tunnel een rare MTU size? Voeg eens een regel "mtu-test" toe aan je server config? Dan krijg je in je OpenVPN log file regeltjes met MTU test resultaten:

code:

Apr 28 08:26:51 localhost openvpn[20120]: client01/xx.xx.xx.xx:38665 NOTE: Beginning empirical MTU test -- results should be available in 3 to 4 minutes.
Apr 28 08:29:53 localhost openvpn[20120]: client01/xx.xx.xx.xx:38665 NOTE: Empirical MTU test completed [Tried,Actual] local->remote=[1557,1557] remote->local=[1557,1557]

Ik heb even gezocht en het lijkt erop alsof er meer mensen zijn met snelheids problemen over TAP. Je zou eens een 2e VPN instance kunnen opzetten op een andere poort met dezelfde config. Als deze ook traag is zal het geen throttleling of traffic shaping zijn van de ISP. Nu heb ik me er niet zo in verdiept maar volgens mij zijn het gewone SSL pakketjes toch dus dan doen ze hooguit traffic shaping op poort niveau lijkt me.

Probeer dan op die tweede instance eens voor de test een TUN adapter om te zien of die sneller is? Dit naar aanleiding van een topic op het OpenVPN forum, daar trekken ze de windows TAP adapter in twijfel.

Terzijde, ik zie dat je root privileges 'drop' met user en group nobody. Erg verstandig qua security maar werkt je ifdown script dan nog wel? ifup wordt gedaan onder root maar als de server draait gaat ie over op nobody/nobody. Je ifdown wordt dus uitgevoerd met 0 rechten.

Edit: Je zegt FTP direct naar internet is wel snel, is dat dan FTP naar een random FTP server of is dat dan Finland --> Ziggo? Dat laatste is namelijk interessant. Als beide lijnen namelijk snel zijn maar onderling niet en de MTU size is in orde zou je het moeten zoeken in TCP send/receive windows. Wellicht eens een poortje mappen voor iPerf en testen?

Stukje over window scaling: http://technet.microsoft....ine/2007.01.cableguy.aspx

[ Voor 11% gewijzigd door Pakjebakmeel op 28-04-2014 08:40 ]

[Grootstyr]

De makkelijkste manier op een OpenVPN op te zetten is volgens de documentatie een routed VPN (TUN adapter). In jou situatie zou dit volgens mij ook prima werken, ik zou hier eens naar kijken, de configuratie hiervan is simpel.

Bridged VPN's forwarden broadcast traffic, met verkeerd ingestelde routers kan dit leiden tot broadcast flooding, het broadcast traffic bounced dan heen en weer tussen de netwerken. Routed VPN's doen dit niet, en hiermee heb je dus minder onnodig verkeer.

[Pakjebakmeel]

Ik zou zelf ook gaan voor routed (dat heb ik ook) echter zou tap natuurlijk ook gewoon moeten werken. Bij mij werkt tun prima.

Daarom misschien eens testen met een tweede instance in tun modus. Latency is aan de hoge kant maar dat zou niet direct een oorzaak mogen zijn lijkt me, tenzij Windows anders omgaat met de adapter omdat hij denkt dat het lokaal verkeer is doordat het gebridged is?