Pubblicare un server interno verso Internet su FortiGate non si fa spuntando una casella: si fa creando un oggetto virtual IP e usandolo come destinazione. È una differenza che conta, perché quasi tutte le domande d’esame su questo argomento girano intorno a una sola cosa: quale indirizzo va scritto dove.

L’oggetto VIP: cosa traduce e quando

Un VIP si crea in Policy & Objects > Virtual IPs o con config firewall vip. I campi che contano sono extip, l’indirizzo su cui il FortiGate ascolta, mappedip, l’indirizzo reale del server, ed extintf.

extintf è il campo sottovalutato più spesso: non è l’interfaccia di uscita, è l’interfaccia esterna a cui la source interface della policy deve corrispondere. Se l’interfaccia esterna è port1, il VIP si può usare in una policy da port1 a port3, ma non da port2 a port3. Con any diventa utilizzabile in qualunque policy. Conviene impostarla esplicitamente: è un filtro gratuito contro l’esposizione accidentale da una WAN secondaria.

Quando extintf non è any, extip può valere 0.0.0.0: l’indirizzo esterno coincide con quello dell’interfaccia. È la scelta giusta su una WAN in DHCP o PPPoE.

config firewall vip
    edit "Internal_WebServer"
        set extip 10.1.100.199
        set extintf "wan1"
        set mappedip "172.16.200.55"
    next
end

La policy che accompagna il VIP

Il VIP da solo non fa passare niente: serve una policy che accetti il traffico, e la sua destinazione è l’oggetto VIP, non l’indirizzo privato del server.

config firewall policy
    edit 8
        set name "Pubblica_WebServer"
        set srcintf "wan1"
        set dstintf "internal"
        set srcaddr "all"
        set dstaddr "Internal_WebServer"
        set action accept
        set schedule "always"
        set service "HTTPS"
    next
end

Attenzione a set nat enable: quella è SNAT, non DNAT, perché la traduzione di destinazione l’ha già fatta il VIP. Abilitarla fa vedere al server l’indirizzo del FortiGate invece di quello del client vero, e i log applicativi diventano inutili: su un server pubblicato va lasciata disabilitata.

Un parametro che torna nelle catture è match-vip, abilitato di default: la policy corrisponde anche ai pacchetti la cui destinazione è stata cambiata da un VIP. Su una policy di deny serve esattamente a questo, loggare i tentativi verso il VIP che nessuna policy di accept ha raccolto. match-vip-only restringe la corrispondenza ai soli pacchetti già tradotti.

Port forwarding, servizi e gruppi

Con set portforward enable compaiono protocol, extport e mappedport. portmapping-type decide le regole: con 1-to-1 un intervallo è ammesso ma il numero di porte deve coincidere, con m-to-n non ci sono vincoli.

Ci sono due modi di portare più porte pubbliche sulla stessa porta interna. Il VIP con servizi usa un elenco di servizi e una sola mappedport: 8080, 8081 e 8082 finiscono tutte sulla 80 dello stesso server.

config firewall vip
    edit "WebServer_VIP_Services"
        set service "TCP_8080-8082"
        set extip 10.1.100.199
        set portforward enable
        set mappedip "172.16.200.55"
        set mappedport 80
    next
end

Il port forwarding classico fa l’opposto: un VIP per ogni porta esterna, ognuno con un mappedip diverso, così 8080, 8081 e 8082 raggiungono la porta 80 di tre server distinti. Conviene raccoglierli in un gruppo con config firewall vipgrp e mettere il gruppo nella policy: se cambia un membro, o il suo IP o il suo port mapping, le policy che usano il gruppo si aggiornano da sole. Nei gruppi IPv4 sono ammessi VIP static NAT, load balance, DNS translation e FQDN; restano fuori access proxy e server load balance.

Central NAT cambia le carte in tavola

Con config system settings e set central-nat enable la logica si ribalta. I VIP si configurano sotto Policy & Objects > DNAT & Virtual IPs, devono avere status enable, e la policy non referenzia più il VIP: la destinazione diventa l’indirizzo interno reale del server, e sparisce la sezione NAT perché la traduzione di sorgente la governano le central SNAT policy, lette dall’alto fino alla prima corrispondenza. Vale solo per VIP IPv4 e VIP46.

Trappola del passaggio fra le due modalità: un VIP già assegnato a una firewall policy in modalità non centrale va tolto prima di attivare central NAT.

ARP, SNAT inverso e VIP sovrapposti

Tre comportamenti che generano ticket veri. Primo: arp-reply è abilitato di default, quindi il FortiGate risponde alle richieste ARP per l’indirizzo esterno del VIP e lo considera locale. L’effetto collaterale è che, una volta creato un VIP o un IP pool, anche senza mai usarlo in una policy il FortiGate tratta quell’indirizzo come proprio e non instrada più quel traffico secondo la routing table. I VIP inutilizzati vanno cancellati, non lasciati lì per il futuro.

Secondo: l’indirizzo esterno del VIP viene usato anche per fare SNAT del traffico in uscita del server mappato, quando l’interfaccia di destinazione corrisponde a extintf e la policy ha NAT abilitato. È così che il server esce con lo stesso indirizzo pubblico con cui è raggiungibile; per forzarlo su tutto il traffico c’è set nat-source-vip enable.

Terzo: FortiOS non controlla le sovrapposizioni fra VIP. Due VIP con lo stesso extintf e lo stesso extip vengono accettati senza alcun errore, e l’unica segnalazione arriva dal report di security rating. Quando un mapping non funziona e la configurazione sembra corretta, cerca il gemello dimenticato prima di aprire diagnose debug flow filtrato sull’indirizzo pubblico.