Guida al dimensionamento dei firewall hardware

Prima di cominciare

La seguente guida al dimensionamento dell’hardware è stata scritta inizialmente e principalmente per il sistemi operativi pfSense® CE e OPNsense®.
Chi fosse interessato ad approfondire le differenze, troverà una comparativa tecnica pfSense® CE VS OPNsense® a questo link.
Tuttavia è possibile estendere questi concetti anche per Zeroshell, ipFire.

Strumenti utili: dimensionamento veloce degli apparati

Di seguito ci dilungheremo su alcuni concetti tecnici per spiegare e motivare le nostre conclusioni riportate nella tabella Dimensionamento istantaneo.
Qualora il navigatore non avesse voglia di leggere tutta la parte tecnica può saltare immediatamente a: Dimensionamento istantaneo.

Qui potete trovare il link al NUOVO CONFIGURATORE HARDWARE dei nostri apparati: con pochi click vi permetterà di capire quale apparato acquistare.
Configuratore hardware apparati
N.B. Alla voce “Select product category“: selezionare “Firewall“.

Premessa

Per dimensionare un firewall hardware basato su pfSense® CE / OPNsense® dalla 2.4.X / 18.X in poi è necessario tenere presente 3 fattori principali:

1. Throughput richiesto
2. Features o pacchetti aggiuntivi di pfSense^®/OPNsense^® utilizzati
3. Numero e tipologia di NIC (Network Interface Card) richieste
   

Questi 3 fattori influenzano principalmente su RAM, CPU, Memoria di massa e ovviamente quantità di NIC. Nella parte sottostante metteremo a disposizione la nostra esperienza nel dimensionamento dell’hardware.

Da tenere presente anche che pfSense^® dalla versione 2.4 NON SUPPORTA più i sistemi su CF (in particolare non supporta più le immagini i386), cosa che OPNsense^® continua a fare.

1. Considerazioni sul Throughput richiesto

Per definizione si intende per throughput di un canale di comunicazione la sua capacità di trasmissione effettivamente utilizzata.
Il throughput non è da confondersi con la capacità del link. Sia la capacità che il throughput si esprimono in bit/s, ma mentre la prima esprime la frequenza trasmissiva massima alla quale i dati possono viaggiare, il throughput è un indice dell’effettivo utilizzo della capacità del link. Il throughput è la quantità di dati trasmessi in una unità di tempo e dipende esclusivamente da quanta informazione è immessa sul canale della trasmissione.
Prima di fare delle considerazioni sul troughput occorre considerare il fatto che sia pfSense^® che OPNsense^® possono operare sia come firewall che come router oppure entrambi. Sarà necessario quindi considerare per la scelta dell’apparato, il throughput complessivo del sistema che vogliamo realizzare.
Per esempio, se dobbiamo realizzare un firewall, possiamo considerare come throughput la somma dei throughput delle WAN.
Se dobbiamo invece realizzare un Router che unisce tra loro delle reti dobbiamo sommare il throughput di tutte le interfacce, sia WAN che LAN.

Tipo di CPU

È importante determinare il throughput di una rete prima dell’installazione di un firewall/router pfSense^®/OPNsense^® in quanto esso determina il tipo di CPU da utilizzare ed in certi casi il tipo di NIC.
Se sono richiesti meno di 10 Mbps allora è possibile utilizzare i requisiti minimi hardware. Per throughput superiori consigliamo caldamente di seguire il dimensionamento suggerito dalla tabella che segue, basata su test effettivamente eseguiti sul campo. La tabella qui sotto è pensata per evitare di raggiungere il massimo livello di carico dell’hardware, così da non incorrere in problemi.
Se per esempio devo realizzare un Router o un Firewall con delle porte a 10 Gbit, non potrò utilizzare una CPU meno potente di uno XEON Quad Core. Infatti, quando le NIC raggiungono i 10 Gbit di traffico i Core dell’appliance vanno al 100% e la macchina va in crisi.

Per questi usi si consigliano A2-Server o A3-Server.

Occorre tenere presente che il team di sviluppo di pfSense, ha annunciato che dalla versione 2.5 NON SARA’ PIU’ POSSIBILE installare e tantomeno aggiornare le versioni di pfSense su hardware sprovvisto di  CPU dotate di istruzioni AES-IN. La ragione (sempre dichiarata da pfSense) è che per supportare l’aumento dei carichi della CPU derivanti dalla crittografia si è reso necessario l’uso del set di istruzioni AES-NI che vengono utilizzate per ottimizzare gli algoritmi di crittografia e decrittografia su determinati processori Intel e AMD.

La cosa non riguarda invece gli sviluppatori di OPNsense che dichiarano che l’esecuzione delle istruzioni AES-IN può essere fatta sia via hardware (con CPU aventi istruzioni AES-IN) che via software, come per altro avviene sulle versioni attuali di entrambe le distribuzioni senza particolari problemi.

Requisiti minimi di sistema per pfSense^® fino alla versione 2.4.X:

Requisiti minimi di sistema per pfSense® CE versione 2.5.X:

Dimensionamento pfSense® CE/OPNsense® basato sul Throughput

Dimensionamento pfSense® CE/OPNsense® basato sul Throughput versione Cluster

(*) I modelli Power Cluster e APUTM con CPU Intel I7 presentano un livello di rumorosità Medio solo se sottoposti a forti e continuativi carichi di lavoro.

2. Features o pacchetti aggiuntivi di pfSense^®/OPNsense^® utilizzati

Molte features di pfSense^®/OPNsense^® influenzano notevolmente il dimensionamento dell’hardware.

VPN: l’utilizzo pesante del servizio VPN fa crescere molto i requisiti della CPU. La cifratura e decifratura dei pacchetti accresce il carico sulla CPU. Il numero di connessioni è un fattore meno preoccupante del throughput.

• CPU di 266 MHz supporta circa 4 Mbps di traffico IPsec
• CPU di 500 MHz supporta circa 10-15 Mbps di traffico IPsec
• CPU I7 o I3 di nuova generazione supportano quasi fino a 200 Mbps di traffico IPsec
• CPU XEON di nuova generazione per carichi superiori a 400 Mbps

Squid – Squidguard – controllo del traffico in uscita mediante proxy: entrambi i pacchetti utilizzano molto sia la CPU che le scritture su disco. È pertanto fortemente sconsigliato l’utilizzo con la fascia Entry level, Entry level APU1 ed Entry Level APU2.
Per questo tipo di lavoro è fortemente consigliato l’utilizzo di Compact Small UTM 3, Appliance Small UTM 3, A2SUTM, A1-Server, A2-Server, A3-Server o APUTM con SSD o dischi Classici.
Tuttavia è altresì possibile l’utilizzo ottimizzato con il solo pacchetto squid sulla fascia Entry level APU1 e Entry Level APU2 a patto che si utilizzi la scrittura sul supporto disco con parsimonia ed in ogni caso a forte discapito delle prestazioni.

pfBlockerNg: pfBlockerNG è un pacchetto per pfSense^® che permette di estendere le funzionalità del firewall oltre il tradizionale firewall L2 / L3 / L4.
pfBlockerNG permette di configurare il firewall per consentire/negare traffico basandosi su elementi come la geo localizzazione di un indirizzo IP, il nome di dominio (per esempio per bloccare Facebook e simili) o le valutazioni di Alexa di determinati siti web.

Questo pacchetto richiede un aumento di CPU e RAM dal 15% al 25%.
Per approfondire il funzionamento di questo pacchetto, potete consultare la guida che abbiamo realizzato e pubblicato nella nostra area guide.

Captive Portal: Ambienti con centinaia di connessioni richiedono molta CPU. Con riferimento alla tabella del throughput sarà necessario aumentare gli utenti di un 15-20% per ottenere la piattaforma raccomandata.

Grandi tabelle di Stato: Ogni voce della tabella di stato richiede 1 KB. La tabella di stato, quando è piena ha 10.000 voci, quindi circa 10 MB di RAM. Per tabelle di stato più grandi, con centinaia di migliaia di connessioni sarà necessario dimensionare adeguatamente la RAM.

Packages: molti pacchetti aumentano significativamente la quantità di RAM utilizzata. Per esempio snort e ntop non dovrebbero essere installati su piattaforme hardware con meno di 512 MB di ram ed almeno 32 GB di disco.

Versione di pfSense^®/OPNsense^® da installare

È da sottolineare la differenza tra i due tipi di installazioni che è possibile effettuare con pfSense^®/OPNsense^® sui diversi dispositivi.

Ricordiamo che per quanto riguarda pfSense^®, l’ultima versione installabile su CF (cioè la versione embedded) è la 2.3.5, mentre per OPNsense^® non è prevista la cessazione del supporto.

• La soluzione Embedded (firewall Entry Level) NON permette la scrittura dei file di log sulla memoria (C.F. o DOM) ed in ogni caso è fortemente sconsigliato farlo. Su questa versione non è possibile installare alcuni dei pacchetti aggiuntivi di pfSense^®/OPNsense^®.
• La soluzione che si installa su hard disk (normalmente sulle soluzioni Appliance UTM o superiori) ha la possibilità di salvare i log al suo interno. Su questa versione è possibile installare tutti i pacchetti aggiuntivi forniti per pfSense^®/OPNsense^®.
• Ricordiamo che pfSense 2.5.X sarà installabile solo su hardware avente CPU con il supporto AES-IN

3. Approfondimento sui chipset delle schede di rete

La scelta di una scheda di rete è fondamentale per chi sta progettando un sistema per medie/grandi dimensioni.
Come potete notare dalle descrizioni dei prodotti, specifichiamo sempre molto bene se gli apparati integrano al proprio interno dei chipset Intel oppure Realtek.

Da circa metà 2016 in avanti praticamente tutti i nostri devices sono dotati di chipset Intel.
Il chipset Realtek è meno performante del chipset Intel ed è adatto principalmente per carichi di lavoro meno intensi. Tuttavia, per un’azienda che non richiede throughput elevati (come l’85% delle aziende Italiane) rimane sempre la scelta ideale.

Il chipset Intel invece offre maggiori performances in caso di traffico intenso: offre infatti parecchie features avanzate come la gestione delle code e dalla versione di pfSense^® 2.2 in poi anche un supporto migliorato al multi-core. Questo si traduce in un throughput più elevato e minore carico sulle CPU.
Per essere precisi, il pieno supporto al multicore è stato introdotto su FreeBSD, cioè dal S.O. padre di pfSense^® e OPNsense^®, quindi lo stesso discorso fatto per pfSense^® vale e varrà in futuro anche per OPNsense^®.
Se state ancora utilizzando pfSense^® 2.1.x, a questo proposito abbiamo pubblicato un approfondimento sull’ottimizzazione delle NIC Intel attraverso il tuning del driver e delle impostazioni. Specifichiamo comunque che fino ad oggi le nostre appliances non hanno bisogno di tale ottimizzazione. Noi la inseriamo comunque per completezza.

Sulle attuali versioni di pfSense^®/OPNsense^® non sembra essere necessario apportare modifiche.
Qualora pensiate che il vostro appliances abbia problemi di performances derivanti dalle NIC potete utilizzare questa guida per la diagnosi del problema.

4. Dimensionamento secondo la rumorosità degli apparati

Per fornire il prodotto adeguato è necessario pensare a dove verrà collocato il firewall.
Se l’apparato verrà collocato nelle vicinanze di persone che lavorano, sarà necessario scegliere una macchina con un basso livello di rumore o sarà necessario l’acquisto di apposito kit silent!

Ultimamente, per effetto della nuova tecnologia a 25 nanometri di Intel, le potenze assorbite si sono ridotte moltissimo e di conseguenza anche il calore dissipato è diminuito.

Dal punto di vista progettuale, abbiamo preferito mantenere nei modelli di fascia alta (tipicamente impiegati in datacenter o CED) la ventola. Questo perché, qualora la board o la CPU rilevassero alte temperature, l’ausilio della ventola riporterebbe in pochi secondi la temperatura a livelli accettabili.

Di seguito è riportata una tabella nella quale vengono forniti dati indicativi sulla rumorosità degli apparati:

Note sul rumore:
un dispositivo che dissipa bene il calore, sicuramente durerà più a lungo e sarà più stabile e affidabile!
Ecco perché i nostri dispositivi di fascia alta sono progettati in modo tale che il flusso d’aria “investa” i componenti interni raffreddandoli.

5. Funzione RAID

Una delle funzioni maggiormente apprezzate da pfSense^®/OPNsense^® in termini di affidabilità hardware è la funzionalità Raid direttamente implementata dal sistema operativo FreeBSD.
Questa funzione garantisce un livello di affidabilità superiore dell’applicane in quanto in caso di rottura di un disco l’applicazione continuerà a funzionare come se nulla fosse.
Questa funzione è supportata da: Compact Small UTM 3, Appliance Small UTM 3, A2SUTM, A1-Server, APUTM, A2-Server, A3-Server ed in tutte le versioni Cluster dei nostri apparati tranne che il NanoCluster.
Per chi volesse approfondire l’argomento, abbiamo pubblicato una guida che spiega come funziona e come intervenire sugli apparati in caso di guasto. La trovate sotto il menù guide.

6. Quando dovrei usare un sistema Cluster?

Un sistema Cluster è una soluzione composta da un sistema avente due apparati hardware completamente indipendenti. Esistono 3 versioni di soluzioni Cluster, una per piccoli uffici e l’altra per traffico intenso e/o per strutture medio/grandi.

• NANOCluster: soluzione 1U compatta, studiata per piccoli uffici
• Small Cluster: soluzione 2U per le PMI e/o piccoli Datacenter che non vogliono rinunciare all’alta affidabilità
• Power Cluster: soluzione 2U per aziende e organizzazioni che necessitano dell’alta affidabilità
• A2-Server Cluster e A3-Server Cluster: soluzione 2U di livello Datacenter che fornisce l’alta affidabilità

Lo Small Cluster e il Power Cluster sono dispositivi 2U, composti da 2 cassetti indipendenti, mentre il NanoCluster è composto da due apparati Entry Level.
Mediante pfSense^® oppure OPNsense^® si può ottenere un vero e proprio Cluster attivo passivo configurato per ottenere l’alta affidabilità tra i 2 apparati che diventano a tutti gli effetti dei nodi del cluster.
Gli altri S.O. non hanno (speriamo solo per ora) una funzione come il CARP di pfSense^®/OPNsense^® ma possono essere comunque configurati in modo tale che l’utente possa spegnere manualmente uno dei due sistemi ed accendere l’altro. Possiamo dire quindi che si tratta di un sistema Cluster che nel caso di pfSense^® e OPNsense^® è automatico ed in caso di altri S.O. è manuale. Tale sistema dovrebbe essere utilizzato in ambienti dove l’alta affidabilità è obbligatoria.

7. Dimensionamento istantaneo

In base alle nostre esperienze abbiamo stilato una classificazione delle installazioni che abbiamo seguito negli anni. Tale classificazione non è solo frutto dell’esperienza fatta durante l’installazione del firewall, ma anche dell’evoluzione tecnologica che l’utilizzatore richiede al dispositivo durante gli anni di utilizzo.

I risultati sono legati per esempio all’evoluzione tecnologica che ogni azienda/ente subisce o richiede negli anni per esigenze diverse. Per esempio le piccole aziende richiedono inizialmente l’installazione di un semplice firewall. Normalmente non passa molto tempo dalla presentazione di richieste come la VPN, filtraggio dei contenuti o regole di navigazione.

Per questo in base al numero di “dispositivi attivi” (cioè di dispositivi connessi ad internet) abbiamo elaborato la seguente tabella che tiene anche conto dei concetti sopra riportati:

8. Analisi performance apparati

(*) Queste misure sono state effettuate utilizzando il modulo hardware di compressione.