Messages

Ciao,

Eh, come scusa?

Questa guida é su un altro aspetto specifico ovvero come creare una VPN IPsec con Nat Before IPsec.
Gli alias servono per creare appunto degli alias, sia per singoli oggetti di rete sia per ragrupparne alcuni e rendere più leggibile e più semplice l'aggregazione di risorse con una stessa peculiarità nelle varie configurazioni.

Perdonami ma non ho capito quale sia il punto che intendi. Se ti spieghi meglio si può estendere e/o correggere alcuni aspetti di questo mio post.

Grazie.

Ciao

Ciao a tutti,
Più che una richiesta di aiuto volevo condividere un HowTo e contribuire alla community italiana di questo fantastico prodotto nella speranza che possa semplificare il lavoro e spingere anche nuova gente ad adottare questo firewall.
Sulla documentazione ufficiale si trova tutto, ma online non ho trovato una guida passo a passo for dummies (per chi ad esempio viene dal mondo pfsense, ce ne sono moltissime) e volevo semplificare l'operazione per coloro che non sono espertissimi, visto che, per capire il meccanismo è necessario conosce in maniera un po' più approfondita le fasi dell'IPsec.
Entriamo nel dettaglio: parto prima con lo spiegone ma in coda metto tutti gli screenshot con i vari passaggi step by step per chi fosse pigro.

Come suggerisce l'oggetto mi rivolgo a chi usa l'opnsense soprattutto come vpn concentrator poiché riguarda  il setup di una VPN ipsec policy based con una sovrapposizione delle due reti locali e quindi che necessita di un NAT/BINAT (in questo caso la sovrapposizione  della 10.0.0.0/24)



Quindi bisogna scegliere due reti di servizio da impostare nel tunnel ( la 10.10.10.0/24 e  la 10.10.11.0/24)
Per chi viene dal mondo pfsense è una operazione semplice, quasi banale che si fa durante il setup delle varie fasi 2.



Su Opnsense come anticipato va conosciuto più nel dettaglio il meccanismo in cui funziona L'IPsec e come instaura i tunnel e sceglie i pacchetti da convogliare  dentro di essi. Ma una volta capito il metodo risulta molto più chiaro, lineare e granulare.

Il concetto principale è quello di Security Policy Database (SPD). Una volta che arriva un pacchetto sull'interfaccia di lan, per decidere dove ruotarlo il firewall controlla il suo SPD, se è presente una policy allora viene girato nel tunnel VPN utilizzando le informazioni delle Security Association Database (SAD).
Il SPD viene generato in automatico sulla base delle regole settate nelle Children Security Association (Fasi 2) settate nelle varie ipsec configurate in Connections

Il punto è che il traffico che deve essere intercettato e ruotato è quello proveniente dalla 10.0.0.0/24. Ma se si imposta la 10.0.0.0/24 nelle Child_SA del tunnel, nell'handshaking viene negoziata questa rete e fallisce. Quindi vanno messe la 10.10.10.0/24(10.10.11.0/24) e di conseguenza vengono generate in automatico le policy corrispondenti nell'SPD.
Per permettere al firewall di ruotare anche i pacchetti provenienti della 10.0.0.0/24 bisogna creare una policy manuale nel spd e associarla alla corrispettiva Child_SA.
Una volta fatto va detto al Firewall di tradurre gli ip della 10.0.0.0/24 in 10.10.10.0/24(10.10.11.0/24) altrimenti vengono rigettati dall'apparato remoto.

Vanno create poi tutte le regole Firewall sia per mettere in sicurezza l'apparato dalla WAN permettendogli di comunicare solo ed esclusivamente con gli ip pubblici che vogliamo, sia per sbloccare le reti o meglio ancora i singoli host sulle singole porte che vogliamo che comunichino con la rete remota tramite la VPN.
Non ho preso in considerazione l'elemento di routing, ma se necessario vanno anche aggiunte rotte statiche per il raggiungimento delle reti locali e remote, e la configurazione va anche ripetuta speculare per l'apparato remoto.

Ovviamente se ci sono imprecisioni o inesattezze liberi di correggerle e qualsiasi arricchimento e aggiunta è ben accetta.

Spero che possa esservi utile.

Ecco di seguito i vari screenshot.