Pfsense/OpenVPN performance

[joriz]

Op een remote locatie draai ik een Pfsense server met OpenVPN. De Pfsense server connecteert met het internet via een dd-wrt router op een VDSL lijn.
Pfsense draait op een dedicated server (Intel(R) Xeon(R) CPU X3210 @ 2.13GHz, 4GB memory). Deze hardware zou normaal gezien snel genoeg moeten zijn om een OpenVPN verbinding vol te duwen, echter is de snelheid nogal aan de lage kant, ook al kunnen de VDSL lijnen aan beide kanten meer aan.

De volgende snelheden heb ik kunnen meten.
- Het uploaden van een ISO bestand naar een Vmware datastore.
-> Maximum uploadsnelheid gemeten met trafficgraph in Pfsense: 1.68Mbit/sec

- Het downloaden van een ISO bestand van een Vmware datastore.
-> Maximum downloadsnelheid gemeten met trafficgraph in Pfsense: 5,63Mbit/sec

De downloadsnelheid lijkt mij OK, de upload zou sneller mogen.

Wat ik getest heb om het probleem proberen op te lossen maar zonder resultaat.
- Encryption algorithm op none ipv BF-CBC
- tun-mtu 1500 en mssfix 1400 opgegeven in de advanced configuration van de OpenVPN server
- Andere poort 1194 TCP naar 5555 TCP

Wat kan ik nog doen om de uploadsnelheid te verbeteren?

[Petervanakelyen]

- Andere poort 1194 TCP naar 5555 TCP

UDP gebruiken in plaats van TCP zou performanter moeten zijn. Daarnaast kan je best zoeken naar de bottleneck. Wat is de cpu load op de server op het moment dat de OpenVPN verbinding belast wordt?

[joriz]

Heb de VPN config eens op UDP gezet, geeft geen verschil. Cpu load is 1 a 2%.
Net ook eens vanuit de Pfsense CLI een 50MB file gedownload ( fetch -o /dev/null http://download.thinkbroadband.com/50MB.zip /dev/null ) , de download snelheid blijft daar ook vrij laag (1 a 2 Mbit/sec).
Beetje vreemd allemaal. Misschien komt het door de dubbele NAT. We zoeken verder

[didi79]

Misschien eens in context plaatsen:
Welke vdsl profielen heb je op beide locaties ? Maken er nog andere zaken gebruik van die internetverbindingen ?
Wat doe je allemaal in pfsense ? Kan zijn dat een pakket een hele weg aflegt (NAT, routing, firewall, content inspection...). Zou kunnen dat dat nauwelijks effect heeft op cpu load (tenslotte spreek je over een vrij zware cpu), maar heeft misschien wel tijd nodig.
Over hoeveel firewall rules spreken we ? Is de rule order optimaal voor je vpn traffic (dus niet helemaal als laatste) ?
Specs van de dd-wrt router ? Doe je daarmee meer dan routing alleen ?

[joriz]

Ok, even een schema gemaakt om alles te verduidelijken. (klikken voor grotere versie).
De lijnen worden voor niets anders gebruikt. Ben nog maar pas bezig met Pfsense. Het is uiteindelijk de bedoeling dat je vanuit het 192.168.5.0 netwerk niet aan het 10.128.1.0 netwerk kan, tenzij je aanmeldt via OpenVPN.

schema.jpg

- Remote locatie
--> BBOX2 in bridge mode, Proximus VDSLlijn op 30/6
--> Router (TP-link TL-WR1043ND) zet de PPPoe link op, DHCP voor subnet 192.168.5.0/24, Wifi
--> Aan de TP-link is nog 1 pc (DHCP) en 1 media converter aangesloten (utp naar fiber)
--> 200meter verder staat terug 1 media converter (utp naar fiber) aangesloten op een unmanaged switch
--> Op de switch is een Wifi Accespunt aangesloten (IP 192.168.5.4/24, GW 192.168.5.1)
--> Op dezelfde switch is de WAN nic aangesloten van de Pfsense server (IP 192.168.5.254/24, GW 192.168.5.1)
--> Een 2de nic (LAN) in de Pfsense server zorgt voor het 10.128.1.0/24 netwerk
--> Op de managed switch in het 10.128.1.24 netwerk staat nog alles default, geen vlans etc..

Details van Pfsense:
--> WAN IP 192.168.5.254/24 , gateway 192.168.5.1
--> LAN IP 10.128.1.254/24

--> DHCP server voor het 10.128.1.0/24 netwerk
--> OpenVPN server, UDP protocol, port 5555, tunnel netwerk 10.128.2.0/24, SSL/TLS + User AUTH

vpn1.JPG

vpn2.JPG

vpn3.JPG

vpn4.JPG

--> NAT staat actief om netwerk 10.128.2.0/24 en netwerk 10.128.1.0/24 van internet te voorzien


--> Voorlopig staat een Allow any/any rule actief voor elke interface




-Locatie home
--> VDSL modem/router (192.168.1.0/24 netwerk), Scarlet 70/10
--> OpenVPN client

[rpr]

Laat pfsense eens de PPPOE verbinding opmaken.

[didi79]

je pfsense server staat wel "ver" van internet:
internet - modem - router - conversie - conversie - switch - pfsense

Je moet rekening houden dat vpn wat overhead met zich meebrengt. Al die overhead én vpn traffic moet ook door al die tussenliggende toestellen verwerkt worden.
Kan perfect werken, maar dan moet je zekerheid hebben dat alle tussenliggende elementen het aankunnen.
Bijv. convertoren kunnen misschien wel conversie doen van 100Base-TX naar 100Base-FX (en dan spreken we puur over fysische conversie), maar misschien kunnen ze geen 100Mbps verwerken.

Idem voor routers en switchen: 't is niet omdat die FastEthernet (of Gigabit) poorten hebben, dat ze dat ook daadwerkelijk aan die snelheid kunnen verwerken (backplane). Daarin zit dikwijls het verschil tussen budget en professionele producten. Niets tegen TP-Link, maar 't is wel een budgetmerk. Merk van je convertoren heb je niet vermeld.

Misschien simpel te testen: welke snelheid haal je tussen (een pc aangesloten op) de router en de pfsense server ? Theorethisch zou je 100Mbps moeten halen. Alhoewel: is die fiber full duplex ?

[ubremoved_539]

je pfsense server staat wel "ver" van internet:

200m is natuurlijk enorm ver als je daarna een website bezoekt aan de andere kant van de wereld

Die dingen zijn gewoon verwaarloosbaar... en verklaren totaal niet snelheden van amper 1 a 5 Mbits.

[joriz]

Gaat inderdaad niets uitmaken De setup is ook maar om mee te spelen dus het zijn geen highend routers/switchen.
Het probleem is gevonden en zat in de media converter aan de kant van de pfsense server. Op deze converter zit buiten een collectie dip schakelaars ook nog een Nway schakelaar (on/off). Van Nway had ik nog nooit gehoord maar na wat googlen is dat blijkbaar hetzelfde als auto-negotiation. Deze stond in stand On, je zou denken dat is ok. Nadat ik deze in de Off stand plaatste draaide alles op fullspeed. In beide standen gaf de converter full duplex link aan, vreemd...

Uitleg van Cisco:
The auto-negotiation algorithm (known as NWay) allows two devices at either end of a 10 Mbps, 100 Mbps, or 1000 Mbps link to advertise and negotiate the link operational mode—such as the speed of the link and the duplex configuration of half or full duplex—to the highest common denominator.

In addition, for 1000BaseT, NWay determines the master-slave interlock between the PHYs at the ends of the link. This mode is necessary to establish the source of the timing control of each PHY. NWay is an enhancement of the 10BaseT link integrity test (LIT) signaling method and provides backward compatibility with link integrity.

Untitled.jpg