Newsgroup: it.comp.reti.locali
Titolo: Parametri IPsec.

Secondo voi, quale delle configurazioni (cfg1 basata su 3des o cfg2
basata su aes), con rispettivamente il file di configurazione per un
FritzBox e gli screenshot della configurazione di un pfSense è migliore?
Suppongo la cfg2... tra l'altro non ho notato differenze di prestazioni.
 
https://www.dropbox.com/sh/f0o2sp1vimygnl7/AAAZ_yTWbOHlQA3y8Y-17y0Ja?dl=0
 
 
C'è la possibilità di migliorare le prestazioni del tunnel?
-- 
Per rispondere, togliere -NOSPAM- dall'indirizzo.

 C'è la possibilità di migliorare le prestazioni del tunnel?
 
A livello di prestazioni AES128/SHA1 e' da preferire, anche se qualche 
temperasupposte avra' da ridire sulla sicurezza, AES256 e' considerato 
sicuro (anche dai temperasupposte).
 
Se parliamo di una sola connessione probabilmente la differenza di 
prestazioni e' irrilevante.

 prestazioni e' irrilevante.
Facendo ulteriori prove, ho avuto l'impressione che la configurazione
3DES sia leggermente più reattiva, con dei ping che passano da una media
di 20ms ad una media di 18ms (prova ripetuta in più volte passando da
una configurazione all'altra).
Può essere un rischio? Meglio usare comunque AES, magari in versione a
128bit? C'è qualche altro parametro da provare a modificare per
migliorare le prestazioni (la VPN è tra 2 ADSL 20/1 Mbit teorici, con
velocità effettiva 14/1)?


 velocità effettiva 14/1)?
 
AES e' piu' sicuro quindi andrebbe scelto per questioni di sicurezza, ma 
se ti interessano piu' le prestazioni usa quello che sul tuo hardware 
fornisce quelle migliori.

 fornisce quelle migliori.
Mi interessa che funzioni, e lě ci siamo. Adesso volevo ottimizzare ;-)
(= miglior compromesso sicurezza/prestazioni).


 sicurezza/prestazioni).
 
Se non devi far passare chissà cosa sulla VPN, credo
che, ferme restando le due config, ti potrebbe essere
sufficiente ottimizzare le prestazioni; se invece vuoi
puntare sulla sicurezza, allora dovresti orientarti su 
una config AES-256/SHA-256, evitando SHA-1 che ormai è
vulnerabile
 
Per quanto riguarda la misurazione delle prestazioni,
tu hai mostrato i tempi di "ping" ossia praticamente la
latenza, dovresti però verificare anche il throughput;
allo scopo potresti usare questo
 
https://en.wikipedia.org/wiki/Ttcp
 
 
considera anche che l'hardware utilizzato influisce
sulle prestazioni della VPN, quindi se da un lato hai
un vecchio catorcio, non ti aspettare chissà cosa :)
 
 
per ulteriori info vedi anche
 
https://doc.pfsense.org/index.php/Routing_internet_traffic_through_a_site-to-site_IPsec_tunnel
 
 
https://wiki.openwrt.org/doc/howto/vpn.ipsec.performance
 
 

 ottimizzare le prestazioni
In che modo? Semplicemente testando le configurazioni, o hai qualche
suggerimento? SHA-256 non credo sia supportato dal FritzBox*, e salvo
problemi incombenti, al momento l'hardware non si cambia.
* anche se...:
ftp://ftp.avm.de/fritz.box/fritzbox.7490/firmware/english/info.txt
 
Chissà se "Increased security of FRITZ!Box's own certificate through
signature with SHA 256" vale anche per il 3270?!
-- 
Per contattarmi, togliere -NOSPAM- dall'indirizzo.
To contact me, remove -NOSPAM- from address.

 
 
Dipende da cosa ci devi fare e dipende di che phase stiamo parlando. Ci 
sono algoritmi più portati alla leggerezza, e quindi alla gestione dei 
flussi stream (vedi ad esempio voip passante attraverso due sedi, 
l'agoritmo blowfish ne è un esempio), e algoritmi invece più robusti da 
un punto di vista di sicurezza.
 
Innanzitutto differenziamo le phasi e che impatto hanno.
 
La PH1 ha un impatto in fase di negoziazione del tunnel e per ogni 
lifetime che hai impostato, ma poi finisce lì.
 
La PH2 ha un impatto costante durante la generazione del traffico.
 
Poi ci sono parametri che hanno meno impatto (anche sulla PH2) quindi è 
utile incrementarli per incrementare la sicurezza del tunnel. E' il 
caso, ad esempio, del Diffie-Hellman (DH, a gruppi).
 
 
Un buon compromesso per tenere un tunnel leggero ma estremamente sicuro 
potrebbe essere:
 
- irrobustire la PH1 con AES256/SHA512 e magari con un DH2048bit MODP 
(mettendo un keep alive che quindi forzi la rinegoziazione continua allo 
scadere, riducendo i tempi quando arrivano richieste dei client)
(anche tenendo un SA life relativamente lungo, tipo 12h)
 
- tenere leggera la parte PH2 con Blowfish/SHA256 DH1024
 
Ovviamente tutto con certificati, tutto in main mode (sono documentati 
attacchi nella modalità aggressive, quella utilizzata in assenza di ip 
statici di entrambi i peer, per intenderci) personalmente se possibile 
evitare la PSK è meglio.
 
Così facendo si ha un tunnel estremamente robusto ma estremamente 
leggero allo stesso tempo.

 Dipende da cosa ci devi fare...
/cut
 
Grazie dell'esaustiva spiegazione.
Cosa ci devo fare: principalemente scambio di qualche file e sopratutto
qualche connessione in VNC, Apple o Microsoft Remote Desktop. Inoltre
ogni tanto mi capita di lanciare un po' di stampe da remoto.
Comunque, faro' qualche prova tenendo a mente quanto hai scritto.
Ma con alcuni limiti: i 2 IP sono dinamici, e intendo modificarli;
l'hardware quello č e quello resta (salvo provate esigenze che vanno
oltre al tunnel)... piuttosto tiro giů tutto e torno ad usare un
collegamento OpenVPN on demand dal singolo client al pfSense.


 
 
Tieni conto che sono considerazioni generiche (sviluppate in oltre un 
decennio di tunnel ipsec quasi tutti ancora in uso senza problemi, 
rivenditele bene! :-) ), poi che tu le applichi su due raspberry o su 
due vpn concentrator cisco o tra due routerini cinesi, l'effetto sulle 
performance (più o meno marcato) è, con le dovute proporzioni, il 
medesimo. Ovviamente hardware ottimizzato e accelerato ti darà esiti 
migliori, ma sempre un algoritmo "A" introdurrà una latenza e l'agoritmo 
"B" un'altra.
 
 
Nel tuo caso l'esempio di configurazione che ti ho fatto (ammesso che il 
tuo software consenti quelle applicazioni) è perfetto. Poi dovrai 
necessariamente andare in aggressive mode, pazienza.
 
 
Aggiungo un hint: Accertati che le sessioni VNC non ti restituiscano 
black screen (dopo aver correttamente fatto l'accesso). In tal caso e a 
prescindere dai protocolli utilizzati, dovrai lavorare sulla dimensione 
del pacchetto in quanto è facile che lo stream VNC in un tunnel IPSEC 
ecceda i 1500byte (di pochissimo) costringendo ad una frammentazione. 
Operazione, questa, che lo stream VNC non gradisce affatto restituendo 
schermata nera nel riquadro.
 
Buon divertimento,
CD


 
P.S. Per il momento non ho avuto problemi con VNC, sto ancora usando la
configurazione 1.
