Guide

OpenVPN e pfSense®/OPNsense®: ottimizzazione della Crittografia e compressione del traffico per ottimizzare l’hardware e migliorare la sicurezza

Obiettivi della guida:

In questa guida faremo delle considerazioni sulla configurazione e ottimizzazioni del servizio OpenVPN, in funzione di test da noi effettuati su apparati hardware.
In particolar modo sulle impostazioni di crittografia e compressione del traffico, 2 parametri indispensabili per l’ottimizzazione di questo strumento.
Per la stesura della guida faremo riferimento ai OS pfSense® e OPNsense®, tuttavia lo stesso discorso può essere esteso a tutte le implementazioni di OpenVPN.
Tali considerazioni ci possono aiutare a capire come i protocolli utilizzati da OpenVPN, utilizzati per criptare e comprimere il traffico, posso influire sulle capacità di traffico del sistema utilizzato e quindi su come dimensionare il nostro apparato. Nelle conclusioni, faremo delle considerazioni sul tema sicurezza del protocollo di crittografia del traffico in relazione alle performances.

Ambiente hardware e software utilizzato

Abbiamo effettuato le prove in laboratorio con due apparati hardware differenti e con il sistema pfSense.
Gli hardware selezionati per le prove sono:

Firewall Entry Level:
Firewall APU 3 NIC

Firewall Datacenter testati:
Firewall A1 Server

Tutti gli hardware da noi testati e di nostra produzione hanno chipset delle NIC rigorosamente Intel.
Il software utilizzato sull’appliance è pfSense® versione 2.4.X

Introduzione

Dal momento che la reale capacità di traffico dipende da molteplici fattori, nelle nostre prove valutiamo le capacità teoriche degli apparati, in modo da poter capire se e quando l’apparato può essere un collo di bottiglia durante l’utilizzo di una VPN.

Le prove sono state effettuate su due appliance hardware diversi, con differente potenza di calcolo (diversa CPU), mentre RAM e schede di rete non sono molto diverse, pur tuttavia, avendo chipset delle NIC Intel.

Considerazioni preliminari sui protocolli e specifiche delle VPN:

Prima di iniziare facciamo una brevissima introduzione sui protocolli UDP e TCP nell’ottica di capire meglio il loro utilizzo in ambito VPN.

Il protocollo TCP è un protocollo con handshake (a 3 vie); tale sistema lo rende un protocollo “affidabile”. Questo significa che se esiste una connessione stabile fra due host, il protocollo TCP garantisce che tutti i pacchetti arriveranno a destinazione.

In particolare Il client manda un pacchetto con un identificativo univoco e con una richiesta syn, il server risponde con un pacchetto syn-ack, successivamente il client manda un pacchetto ack. Se la comunicazione non viene chiusa il pacchetto viene reinviato fino al successo oppure dopo un time out e tutta la comunicazione viene interrotta e definita chiusa.

Viceversa, il protocollo UDP è un protocollo connection less, ossia non ci sono richieste di verifica o di riordino dei pacchetti. Questo lo rende meno affidabile poichè alcuni pacchetti possono venire persi e non verranno ritrasmessi, tuttavia questo meccanismo lo rende anche molto più veloce.

Per l’implementazione delle VPN conviene usare il protocollo UDP in quanto più veloce. Non ci dobbiamo preoccupare dell’affidabilità in quanto la VPN incapsula i protocolli che viaggiano nel tunnel, e se per esempio, il protocollo incapsulato è il TCP, sarà lui a preoccuparsi di far arrivare tutti i pacchetti. Per implementare una VPN si può usare il protocollo TCP, ma normalmente lo si usa a causa di restrizioni o blocchi che impediscono l’uso del UDP.

Quando si implementa una VPN vengono effettuate alcune operazioni, la prima consiste nello stabilire un tunnel, successivamente i dati possono venir criptati e/o compressi

Ne abbiamo parlato in modo approfondito in questa guida: https://www.firewallhardware.it/pfsense-e-vpn-differenze-e-approfondimenti-sulla-sicurezza-di-ipsec-e-openvpn/

La creazione di un tunnel non fa parte di questa guida, diremo solo che è la parte fondamentale per far funzionare la VPN, permettendo la comunicazione diretta fra le due reti remote, anche private.
La crittografia è facoltativa, ma fortemente consigliata, e di fatto protegge i nostri dati mentre passano nel tunnel della VPN, tramite l’utilizzo di chiavi.
La compressione è facoltativa e si occupa di ottimizzare la velocità di comunicazione comprimendo i dati che passano nel tunnel.

Premessa sulle prove effettuate

Dovendo principalmente verificare l’impatto del sistema VPN sulle prestazioni dell’hardware e del traffico di rete, il parametro che ci interessa principalmente in questo momento è l’Encryption Algorithm e in parte la compression. Gli altri parametri sono di minor interesse

I parametri oggetto di questa guida sono impostabili su PFSenese e OPNSense tramite interfaccia grafica. In particolare:

  • Parametri per la crittografica dei dati con PFSense:
    Da VPN→OpenVPN→Server (si presuppone sia già stato creato almeno un server OpenVpn), editare il server OpenVpn desiderato, nella sezione Cryptographics setting, si seleziona il parametro di cryttografica dei dati dal menu a tendina Encryption algoritms e/o NCP Algoritm(sistema di negoziazione dall’algoritmo di cryttografia).
Openvpn Compression And Encryption R3
  • Parametri per la compressione dei dati con pfSense:
    Nella stessa pagina dove abbiamo configurato la crittografia, sotto tunnel settings, selezionare dal menu “compression”, la compressione desiderata.
Openvpn Compression And Encryption R3
  • Parametri per la compressione dei dati con OPNSenese:
    Da VPNOpenVpnServer (si assume sia già stato creato un server OpenVpn), editare il server OpenVpn desiderato
    Cercare il menu a tendina “Compression”, selezionare la compressione desiderata. Per le possibili scelte, dalla figura qui sotto vedi note informative.
Openvpn Compression And Encryption R3
  • Parametri per la cryttografia dei dati con OPNSense:
    Sempre da questa pagina web Utilizzare il menu “Encryption Algoritm” per selezionare il tipo di crittografia da utilizzare per i dati
Openvpn Compression And Encryption R3

Le prove effettuate:

I test sono stati effettuati utilizzando ed elaborando i risultati tramite l’utilizzo di una shell di PFSense e con i comandi:

[“openssl speed”] e [“OpenVPN”+”time”]

  1. openssl speed md5 sha1 ….
    openssl è il sistema (libreria) usato da OPENVPN per l’implementazione delle VPN, il comando di fatto fa un test sulla velocità di esecuzione del comando per la compressione e decompressione dei dati. Il risultato è la velocità massima che la libreria openssl può avere per la cryttografia dei dati.
    Letteralmente: This command is used to test the performance of cryptographic algorithms
  2. # OpenVPN –genkey –secret /tmp/secret
    # time OpenVPN –test-crypto –secret /tmp/secret –verb 0 –tun-mtu 20000 –cipher aes-256-cbc
    OpenVPN, utilizzato con time, effettua un test di velocità direttamente con gli strumenti di compressione e decompressione di OpenVPN tramite una chiave statica generata con OpenVPN stesso; quindi time genera un risultato che obbedisce alla seguente formula
    (3200/tempoDiEsecuzioneInSecondi) = Proiezione massima della performance di OpenVPN in Mbps

Nota: Abbiamo anche effettuato dei test modificando il parametro“Cryptographic Hardware”
Su PPSense lo potete trovare in: System→Advanced→Miscellaneous
La modifica di questo parametri però non ha dato alcuna differenza significativa.

1. Test Hardware: A1Server

Passiamo ora al test vero e proprio e all’analisi dei dati.

Intel(R) Atom(TM) CPU C2758 @ 2.40GHz

8 CPUs: 1 package(s) x 8 core(s)
AES-NI CPU Crypto: Yes (inactive)

Risultati teorici utilizzando i seguenti comandi
# OpenVPN — genkey — secret /tmp/secret
# time OpenVPN — test-crypto — secret/tmp/secret — verb 0 — tun-mtu 20000 — cipher aes-256-cbc

Mbps teorici Algotitmo utilizzato
146,838022674072
140,765373449459
139,752030035798
138,90789131001
103,908045977011
91,1830408023706
69,338071197972
69,2795289227572
103,177714727882
116,2342002034
91,1596638655462
116,47534121929
91,1077580071174
no encryption
aes-128-cbc
AES-192-CBC
Aes-256-cbc
DES-CBC
RC2-CBC
DES-EDE-CBC
DES-EDE3-CBC
DESX-CBC
BF-CBC
RC2-40-CBC
CAST5-CBC
RC2-64-CBC

Risultati ottenuti col seguente comando
#openssl speed md5 sha1 sha256 sha512 des des-ede3 aes-128-cbc aes-192-cbc aes-256-cbc rsa2048
dsa2048
The ‘numbers’ are in 1000s of bytes per second processed.

type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
md5
sha1
des cbc
des ede3
aes-128 cbc
aes-192 cbc
aes-256 cbc
sha256
sha512
21190.45k
21710.91k
41221.46k
15988.63k
38312.81k
32731.46k
28285.92k
21627.88k
13847.41k
70594.55k
65473.75k
44227.26k
16365.97k
43219.39k
36044.84k
30700.84k
49864.17k
55176.02k
182172.84k
148563.20k
45445.11k
16509.70k
44714.80k
37102.34k
31754.84k
87007.91k
85171.11k
300125.18k
217115.81k
45549.91k
16545.79k
119669.42k
102306.47k
88846.97k
107239.77k
119439.36k
369085.06k
250563.24k
45544.79k
16599.26k
122071.72k
103322.97k
89260.03k
115149.48k
135876.83k

sign verify sign/s verify/s
rsa 2048 bits 0.005019s 0.000179s 199.3 5580.9

sign verify sign/s verify/s
dsa 2048 bits 0.001918s 0.001778s 521.3 562.3

2. Test effettuato con HardWare MINISERVER: AMD GX-412TC

4 CPUs: 1 package(s) x 4 core(s)
AES-NI CPU Crypto: Yes (inactive)

Risultati teorici utilizzando i seguenti comandi
# OpenVPN — genkey — secret /tmp/secret
# time OpenVPN — test-crypto — secret /tmp/secret — verb 0 — tun-mtu 20000 — cipher aes-256-cbc

Mbps teorici Algotitmo utilizzato
43,4804334247617
43,4804334247617
43,2800972841508
43,474532577135
32,3910582908885
none
aes-128-cbc
AES-192-CBC
Aes-256-cbc
DESX-CBC

Risultati ottenuti col seguente comando
# openssl speed md5 sha1 sha256 sha512 des des-ede3 aes-128-cbc aes-192-cbc aes-256-cbc rsa2048 dsa2048
The ‘numbers’ are in 1000s of bytes per second processed.

type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
md5
sha1
des cbc
des ede3
aes-128 cbc
aes-192 cbc
aes-256 cbc
sha256
sha512
6091.10k
6273.40k
14113.51k
5392.94k
15351.43k
12678.31k
11186.83k
7626.93k
5065.17k
20796.97k
20775.26k
14949.49k
5503.06k
16479.76k
13439.26k
11697.27k
18208.54k
20386.18k
55149.83k
49754.39k
15007.49k
5499.17k
16752.60k
13956.93k
11974.06k
31935.64k
32140.75k
102651.56k
75995.34k
15168.85k
5542.91k
42753.73k
36587.81k
31814.29k
39095.85k
46066.56k
135633.57k
90409.66k
15192.41k
5480.00k
43496.29k
36842.15k
31850.50k
41115.50k
51883.22k

sign verify sign/s verify/s
rsa 2048 bits 0.010064s 0.000284s 99.4 3517.3

sign verify sign/s verify/s
dsa 2048 bits 0.003835s 0.003517s 260.8 284.3

Guardando il risultato dei test effettuati salta subito all’occhio la grande differenza di velocità in Mbs, che si può notare dai due test a seconda delle CPU utilizzate.
i.e. con openssl e algoritmo di crittografia aes-128

  • Primo test: 140Mbps aes-128-cbc
  • Secondo test: 43Mbps aes-128-cbc

Anche l’utilizzo di algoritmi diversi da dei risultati abbastanza diversi, tuttavia meno evidenti.
i.e. Dal primo test il risultato dell’algoritmo di crittografia fra aes-256 e DES-EDE

  • 138Mbps Aes-256-cbc
  • 69Mbps DES-EDE-CBC

Diversamente da quanto ci saremmo aspettati, utilizzando lo stesso algoritmo ma aumentando il numero bit di crittografia le differenze non sono poi molto grandi.
i.e. Dal primo test il risultato dell’algoritmo di crittografia a 128, 192 e 256 bit

  • 140Mbps aes-128-cbc
  • 139Mbs AES-192-CBC
  • 138Mbps Aes-256-cbc

Altro risultato da tenere in mente, sono le differenze che aumentano con l’aumentare della potenza della CPU, anche se a livello di percentuale sono simili, ovviamente cambia la quantità di Mbps. Questo può risultare poco interessante da un punto di vista teorico, cambia invece da un punto di vista pratico. Qui sotto un esempio.
Primo test:

  • 138Mbps Aes-256-cbc
  • 103Mbps DESX-CBC
  • differenza di circa il 30%
  • differenza di circa 25 Mbps

Secondo Test:

  • 43Mbps Aes-256-cbc
  • 32Mbps DESX-CBC
  • differenza di circa il 30%
  • differenza di circa 11 Mbps

Conclusioni e considerazioni.

Prima considerazione: il protocollo di crittografia non esclude l’overhead dovuto all’encapsulation della VPN, in quanto per poter far funzionare la VPN è necessario creare per prima cosa un tunnel che implica operazioni di modifica ed aggiunta di dati ai pacchetti TCP/IP (con ovvio impiego di potenza di calcolo e aggiunta di informazioni nei pacchetti TCP/IP) L’overhead  può cambiare a seconda della configurazione e dal software utilizzato (OpenVPN, IPSEC,L2TP,…), parametro che può influire sulle prestazioni, ma in modo molto minore rispetto alla crittografia. Quindi non usare la crittografia non corrisponde ad ottenere la massima di rete, ma potrebbe risultare poco influente.

Seconda considerazione: la maggiore sicurezza di un protocollo non significa minor velocità di esecuzione, pertanto la scelta di usare AES (più sicuro) rispetto DES (meno sicuro) è certamente migliore.

Terza considerazione: a meno di situazioni molto critiche, il vantaggio (in termini di velocità) di utilizzare un numero inferiore di bit con lo stesso algoritmo, per esempio la scelta fra AES-128 e AES-256 (algoritmo:AES numero di bit: 128 oppure 256), potrebbe non giustificare la minor sicurezza che si avrebbe. Pertanto, in questo caso, normalmente conviene usare AES-256

Considerazioni sul protocollo VPN/OpenVPN – TCP/UDP Compressione

Il protocollo standard di OpenVPN e delle vpn in generale è UDP, il motivo è che non è necessario caricare/appesantire la VPN di un protocollo con un sistema di handshake quale il TCP, infatti saranno gli applicativi che utilizzeranno la VPN a scegliere il protocollo piu’ adatto al loro scopo.
Il TCP su vpn viene scelto se non ci sono alternative dovute a protocolli di sicurezza o obbligo di uso di alcuni servizi per l’accesso alla rete esterna, quali proxy.

Considerazioni sul sistema di compressione del traffico VPN.

Anche in questo caso bisogna considerare il fatto che ormai la gran parte del traffico è già compressa, in ogni caso il default di compressione per OpenVPN è lzo, che ha un livello di compressione molto alto, ma impegna notevolmente le risorse del sistema, inoltre non è molto ottimizzato in caso di protocolli già compressi. Per questo motivo sono nati sistemi di compressione quali lz4 e lz4-v2 (espressamente pensato per OpenVPN).
Pertanto se il vostro sistema ha le risorse già molto impegnate, scegliete opportunamente il livello di compressione (per esempio evitate lzo), oppure valutate l’opzione di disabilitarla.
Inoltre il protocollo di compressione potrebbe creare problemi di compatibilità soprattutto nelle VPN P2P, quindi in caso di mal funzionamento delle VPN si consiglia come prima cosa di disabilitare la compressione.

  ti posso interessare anche