Il source NAT su FortiGate si fa in tre modi, e non sono varianti dello stesso comando: cambiano dove vive la configurazione, quanto è granulare e — nel caso del central NAT — escludono gli altri. La domanda ricorrente non è «come si abilita il NAT» ma «perché su questa policy l’opzione NAT non c’è più».

Static SNAT: l’indirizzo dell’interfaccia di uscita

È il caso base: abiliti il NAT sulla policy e la sorgente viene tradotta nell’indirizzo dell’interfaccia di uscita. In GUI è l’opzione «Use Outgoing Interface Address», in CLI basta set nat enable, che di default è disabilitato.

È a tutti gli effetti port address translation. Con 60.416 numeri di porta disponibili, un singolo IP pubblico regge 60.416 indirizzi interni verso lo stesso servizio, dove per servizio si intende la combinazione di protocollo, IP di destinazione e porta di destinazione: il limite è per destinazione, non assoluto.

Due parametri governano la porta sorgente e vengono confusi di continuo.

config firewall policy
    edit 1
        set nat enable
        set fixedport disable
        set port-preserve enable
    next
end

fixedport — la voce «Preserve Source Port» in GUI — impedisce al SNAT di cambiare la porta sorgente, e serve per i servizi che pretendono il traffico da una porta specifica. Il rovescio è che con la porta bloccata non puoi avere più di una connessione contemporanea verso quel servizio. Di default è disabilitato.

port-preserve è un’altra cosa ed è abilitato per default: il SNAT usa la porta originale se non è già occupata. Disabilitandolo la porta viene sempre cambiata, passando alla successiva libera e ricominciando dall’inizio del range quando arriva in fondo. Il limite da ricordare: solo le porte fra 5117 e 65533 vengono preservate, sotto la 5117 la traduzione sale comunque sopra quella soglia e serve l’explicit port mapping.

IP pool: quattro tipi, quattro comportamenti

Quando l’indirizzo dell’interfaccia non basta si usa un IP pool, che definisce l’indirizzo o il range usato come sorgente per la durata della sessione. In policy servono set nat enable, set ippool enable e set poolname.

I quattro tipi non sono intercambiabili. Overload è il default e si comporta come uno static SNAT esteso: gli indirizzi sono condivisi con PAT e la mappatura è deterministica, perché l’indice dell’indirizzo scelto è il resto della divisione dell’IP sorgente, in decimale, per il numero di indirizzi del pool. One-to-one disabilita la PAT: due indirizzi esterni servono esattamente due client interni, e il terzo resta fuori. Fixed port range è l’unico in cui definisci anche il range interno, così il blocco di porte di ogni combinazione è calcolabile in anticipo; nella 7.6 supporta il full cone NAT con permit-any-host, ma solo per UDP. Port block allocation assegna a ogni IP interno un numero fisso di blocchi di porte.

config firewall ippool
    edit "PBA-ippool"
        set type port-block-allocation
        set startip 172.16.200.1
        set endip 172.16.200.1
        set block-size 128
        set num-blocks-per-user 8
    next
end

Con questi numeri ogni utente dispone di 1024 porte e un singolo IP esterno copre 59 indirizzi interni: è il conto da rifare quando ti chiedono di dimensionare un pool.

La trappola grossa degli IP pool non riguarda il NAT ma il routing. Per default arp-reply è abilitato: il FortiGate risponde alle ARP request per gli indirizzi del pool e li considera locali. L’effetto collaterale è che un IP pool mai usato in nessuna policy rende comunque locali quegli indirizzi, e il traffico verso di essi non viene più instradato secondo la routing table. Pool e VIP inutilizzati vanno cancellati, non lasciati lì.

Central SNAT: quando il NAT esce dalla policy

Il central NAT non è attivo per default e si abilita per VDOM.

config system settings
    set central-nat enable
end

Da quel momento l’opzione NAT nelle policy IPv4 viene ignorata e il source NAT si configura esclusivamente in config firewall central-snat-map. È esattamente lo scenario della policy in cui «il NAT non c’è più». Vale anche l’implicazione inversa: in modalità NGFW policy-based il central NAT è implicitamente attivo, quindi se non esiste una regola di central SNAT devi crearla.

La tabella si legge dall’alto verso il basso fino alla prima corrispondenza e viene applicata dopo la security policy. La granularità è il motivo per usarla: scegli l’IP pool in base a interfacce, indirizzo sorgente e di destinazione, protocollo, porta di destinazione e porta sorgente originale. Il pattern corretto è una regola specifica seguita da una catch-all che traduce il resto sull’indirizzo dell’interfaccia.

Attenzione all’explicit port mapping: funziona solo con IP pool overload e, mappando porta originale su porta tradotta, esclude i protocolli senza porte. Una regola così non prenderà mai traffico ICMP, che finirà in quella successiva.

Verificare che il NAT sia quello che credi

Non fidarti della configurazione, guarda la sessione. Nella session table la riga hook=post dir=org act=snat mostra la traduzione applicata, con indirizzo e porta tradotti fra parentesi, mentre hook=pre dir=reply act=dnat mostra la de-traduzione del ritorno.

diagnose sys session filter dst 172.16.200.55
diagnose sys session list

In debug flow il SNAT compare in due momenti distinti, l’allocazione della porta e l’applicazione della traduzione, entrambi dopo che la route è stata risolta. Per un riscontro rapido, il traffic log della policy riporta gli stessi dati nei campi trandisp, transip e transport.