Redes · Firewall · Fortinet · FortiGate · IPsec · VPN · NAT · FortiClient

Duarte Spínola · 25 de Junho de 2026

FortiGate 2026: Firewall Policies, NAT e VPN IPsec — Guia Prático para PME

O FortiGate é uma das firewalls de próxima geração mais usadas em PME portuguesas, mas a configuração inicial de policies, NAT e VPNs continua a gerar dúvidas. A documentação oficial da Fortinet é extensa (mais de 1500 páginas no administration guide do FortiOS 8.0), mas dispersa por dezenas de páginas. Este guia consolida os quatro temas que um sysadmin de PME precisa de dominar: firewall policies, NAT (source e destination), VPN IPsec site-to-site e VPN SSL/remote access com FortiClient. Todos os comandos CLI foram extraídos directamente da documentação oficial (Fortinet Administration Guide 8.0), validada em Junho de 2026. A informação sobre SSL VPN foi recolhida na versão 7.4 (a última com a nomenclatura clássica), uma vez que no FortiOS 8.0 a SSL VPN foi renomeada para “Agentless VPN”.

Neste artigo

  1. Entender o Modelo de Políticas do FortiGate
  2. Pré-requisitos e Conceitos Essenciais
  3. Passo 1 — Criar Firewall Policies e Address Objects
  4. Passo 2 — Configurar NAT (Source e Destination)
  5. Passo 3 — VPN IPsec Site-to-Site com Pre-Shared Key
  6. Passo 4 — Configurar VPN SSL com FortiClient (Split Tunnel)
  7. Passo 5 — Verificar e Diagnosticar com CLI
  8. FortiOS 8.0: O que Mudou em VPN SSL
  9. Erros Comuns de Configuração
  10. Checklist Rápido de Verificação

1. Entender o Modelo de Políticas do FortiGate

O FortiGate funciona com um modelo de políticas baseado em fluxo: cada pacote que entra numa interface é avaliado contra uma lista ordenada de firewall policies, da primeira para a última. A primeira policy que corresponde ao tráfego (interface de origem, interface de destino, endereços, serviços, horário) determina a acção: ACCEPT (permitir) ou DENY (bloquear). Se nenhuma policy corresponder, o tráfego é bloqueado por defeito (Fortinet — Firewall Policy).

No FortiOS 8.0 existem dois modos de policy:

Modo Descrição Quando usar
NGFW Policy Combina regras de tráfego com perfis de segurança (AV, IPS, Web Filter, Application Control) numa única policy Recomendado para PME — simplifica a gestão
Legacy Policy Regras de tráfego separadas dos perfis de segurança Ambientes complexos com policies específicas por perfil

A ordem das policies é crítica. O FortiGate avalia de cima para baixo, pelo que policies mais específicas devem estar acima de policies mais permissivas. Por exemplo, uma policy que bloqueia um IP específico deve aparecer antes de uma policy que permite “all” para a mesma interface (Fortinet — NGFW Policy).

⚠ Atenção

Nunca usar set srcaddr "all" e set dstaddr "all" em conjunto com set service "ALL" numa policy de WAN para LAN, a menos que seja um cenário controlado. Esta configuração é o equivalente a abrir tudo, e é a causa nº1 de compromissos em PME.

O NAT (Network Address Translation) é integrado nas firewall policies no FortiGate. Por defeito, quando se cria uma policy entre interfaces com redes diferentes, o NAT está activo (set nat enable), traduzindo o IP de origem para o IP da interface de saída. Para cenários mais complexos (IP pools, VIPs, central NAT), o NAT pode ser separado das policies (Fortinet — Source NAT).

2. Pré-requisitos e Conceitos Essenciais

Antes de configurar policies, NAT e VPNs, é necessário entender os objectos base do FortiGate:

Address Objects — Endereços IP ou subnets nomeadas que podem ser reutilizadas em múltiplas policies. Em vez de colocar IPs directamente nas policies, criam-se objectos (ex.: LAN_subnet = 192.168.1.0/24) e referenciam-nos nas regras. Isto torna a configuração legível e fácil de manter.

Address Groups — Agrupamentos de address objects. Útil para criar grupos como Internal_Networks que incluem LAN_subnet, DMZ_subnet, VPN_subnet.

Virtual IPs (VIPs) — Usados para destination NAT. Um VIP mapeia um IP público e porta para um IP interno e porta. É o mecanismo para expor servidores internos (web, email, RDP) à internet sem expor a rede interna.

IP Pools — Range de IPs usados para source NAT dinâmico. Em vez de traduzir todos os clientes para o IP da interface de saída, pode-se usar um pool de IPs públicos.

Zones — Agrupamento lógico de interfaces. Em vez de aplicar policies a interfaces individuais, pode-se criar uma zona (ex.: LAN) que inclui múltiplas interfaces (ex.: port1, port2, port3) e aplicar policies à zona inteira.

VDOM (Virtual Domains) — Permite dividir um FortiGate em múltiplas instâncias virtuais, cada uma com as suas próprias interfaces, policies e routing. Para a maioria das PME, um único VDOM (root) é suficiente.

💡 Nota

Para gestores de PME que gerem múltiplos clientes (MSP), os VDOMs permitem isolar cada cliente num domínio virtual separado, com as suas próprias policies e configurações de VPN. Isto é diferente de múltiplas instâncias FortiGate — é um único hardware a servir múltiplos tenants.

3. Passo 1 — Criar Firewall Policies e Address Objects

O primeiro passo é criar os address objects que representam as redes internas e externas, e depois as firewall policies que controlam o tráfego entre elas. Os comandos abaixo são extraídos da documentação oficial do FortiOS 8.0 (Configuring a firewall policy) e do CLI Reference.

O seguinte script CLI cria os address objects base e uma policy LAN → WAN com NAT activado:

# — Criar address objects para as redes internas —
config firewall address
edit “LAN_subnet”
set subnet 192.168.1.0 255.255.255.0
next
edit “DMZ_subnet”
set subnet 192.168.10.0 255.255.255.0
next
edit “VPN_subnet”
set subnet 10.10.10.0 255.255.255.0
next
end

# — Criar address group para redes internas —
config firewall addrgrp
edit “Internal_networks”
set member “LAN_subnet” “DMZ_subnet” “VPN_subnet”
next
end

# — Policy: LAN → WAN (internet access com NAT) —
config firewall policy
edit 1
set name “LAN_to_WAN”
set srcintf “port1”
set dstintf “wan1”
set action accept
set srcaddr “LAN_subnet”
set dstaddr “all”
set schedule “always”
set service “ALL”
set nat enable
set logtraffic all
next
end

# — Policy: Deny tráfego de gestao para WAN —
config firewall policy
edit 2
set name “Block_mgmt_to_WAN”
set srcintf “port1”
set dstintf “wan1”
set action deny
set srcaddr “MGMT_subnet”
set dstaddr “all”
set schedule “always”
set service “ALL”
set logtraffic all
next
end

Parâmetros-chave explicados:

  • srcintf / dstintf — interface de origem e destino. Pode ser uma interface física (port1), uma zona (LAN), ou uma interface virtual de VPN (remote_vpn)
  • srcaddr / dstaddr — address objects ou groups. "all" equivale a 0.0.0.0/0
  • action — accept (permitir) ou deny (bloquear)
  • nat enable — activa source NAT (traduz o IP de origem para o IP da interface de saída)
  • logtraffic all — regista todo o tráfego que corresponde à policy. Sem isto, não há logs para auditoria
  • schedule — "always" para permanente, ou um objecto de horário customizado

Nota: A ordem do edit define a posição da policy. A policy edit 1 é avaliada primeiro. Para inserir uma policy entre duas existentes, usar um ID livre entre elas ou usar move após criar.

Para verificar qual policy está a corresponder a um determinado tráfego, o FortiGate tem o comando diagnose debug flow que mostra o caminho exacto do pacote:

# Verificar qual policy corresponde ao tráfego de 192.168.1.50
diagnose debug enable
diagnose debug flow filter addr 192.168.1.50
diagnose debug flow show function-name enable
diagnose debug flow trace start 10
# … gerar tráfego …
diagnose debug flow trace stop
diagnose debug disable

Este comando é essencial para troubleshooting — mostra exactamente qual policy faz match, se o NAT foi aplicado, e se o pacote foi aceite ou bloqueado (Fortinet — Verifying the correct firewall policy).

4. Passo 2 — Configurar NAT (Source e Destination)

O FortiGate suporta três modos de source NAT e destination NAT via Virtual IPs. A escolha do modo depende da topologia de rede e dos requisitos (Fortinet — Source NAT).

Source NAT — três modos

Modo Descrição Quando usar
Static SNAT Todos os IPs internos traduzidos para o IP da interface de saída Default — adequado para a maioria das PME
Dynamic SNAT (IP Pool) IPs internos traduzidos para um pool de IPs públicos Quando há múltiplos IPs públicos e se quer distribuir carga
Central SNAT Regras de NAT separadas das firewall policies Ambientes complexos com regras de NAT específicas

Static SNAT é o comportamento por defeito — quando set nat enable está activo numa policy, o IP de origem é traduzido para o IP da interface de saída. Não há configuração adicional necessária.

Dynamic SNAT com IP Pool cria um range de IPs para tradução:

# Criar IP Pool para SNAT dinamico
config firewall ippool
edit “Public_IP_Pool”
set type overload
set startip 203.0.113.201
set endip 203.0.113.210
next
end

# Aplicar o pool numa firewall policy
config firewall policy
edit 1
set name “LAN_to_WAN”
set srcintf “port1”
set dstintf “wan1”
set action accept
set srcaddr “LAN_subnet”
set dstaddr “all”
set schedule “always”
set service “ALL”
set nat enable
set ippool enable
set poolname “Public_IP_Pool”
set logtraffic all
next
end

O tipo overload permite múltiplos clientes a partilhar o mesmo IP público (com tradução de portas). O tipo one-to-one mapeia cada cliente para um IP único do pool.

Central SNAT separa as regras de NAT das firewall policies, útil quando se quer gerir NAT independentemente das policies de segurança. Para activar o modo central NAT:

# Activar central NAT mode
config system settings
set central-nat enable
end

# Criar regra de central SNAT
config firewall central-snat-map
edit 1
set srcintf “port1”
set dstintf “wan1”
set orig-addr “LAN_subnet”
set dst-addr “all”
set nat-ippool “Public_IP_Pool”
next
end

⚠ Atenção

Activar central-nat muda o comportamento de NAT de toda a firewall. As policies existentes com set nat enable deixam de funcionar — é necessário migrar todas as regras de NAT para config firewall central-snat-map. Fazer backup antes de activar.

Destination NAT — Virtual IPs

Para expor um servidor interno à internet (ex.: servidor web, servidor de email, RDP), usa-se uma Virtual IP (VIP) que mapeia um IP público e porta para um IP interno (Fortinet — Destination NAT):

# Criar Virtual IP para servidor web interno
config firewall vip
edit “web_server_vip”
set extip 203.0.113.10
set mappedip 192.168.1.100
set extport 80
set mappedport 80
next
end

# Policy para permitir tráfego externo para o servidor
config firewall policy
edit 10
set name “WAN_to_Web_Server”
set srcintf “wan1”
set dstintf “port1”
set action accept
set srcaddr “all”
set dstaddr “web_server_vip”
set schedule “always”
set service “HTTP”
set logtraffic all
next
end

Quando o dstaddr de uma policy é uma VIP, o FortiGate sabe que deve aplicar destination NAT automaticamente. O tráfego que chega ao IP público 203.0.113.10:80 é traduzido para 192.168.1.100:80.

Hairpin NAT (NAT loopback) permite que clientes internos acedam a um servidor interno usando o IP público. Sem hairpin NAT, um cliente em 192.168.1.50 que tente aceder a 203.0.113.10:80 tem o tráfego enviado para o gateway externo em vez do servidor interno. Com hairpin NAT, o FortiGate reconhece que o IP público é seu e redirecciona o tráfego internamente (Fortinet — Hairpin NAT).

5. Passo 3 — VPN IPsec Site-to-Site com Pre-Shared Key

A VPN IPsec site-to-site liga duas localizações físicas (ex.: escritório principal + escritório remoto) através de um túnel encriptado na internet. O FortiGate suporta tanto IKEv1 como IKEv2, sendo IKEv2 o recomendado pela Fortinet (Fortinet — IPsec VPN Best Practices).

A configuração completa tem três partes: Phase 1 (negociação IKE), Phase 2 (parâmetros IPsec) e firewall policies para permitir tráfego através do túnel. O exemplo abaixo liga dois FortiGate — HQ1 (escritório principal) e HQ2 (escritório remoto) — usando pre-shared key. Os comandos são executados no HQ1; o HQ2 tem a configuração espelhada (Fortinet — Basic site-to-site VPN with PSK).

# — Address objects para as redes remotas —
config firewall address
edit “HQ2_local_subnet”
set allow-routing enable
set subnet 10.100.77.0 255.255.255.0
next
edit “HQ2_remote_subnet”
set allow-routing enable
set subnet 10.2.0.0 255.255.255.0
next
end

# — Address groups para Phase 2 —
config firewall addrgrp
edit “HQ2_local”
set allow-routing enable
set member “HQ2_local_subnet”
next
edit “HQ2_remote”
set allow-routing enable
set member “HQ2_remote_subnet”
next
end

# — Phase 1: IKE Gateway —
config vpn ipsec phase1-interface
edit “HQ2”
set interface “wan1”
set ike-version 2
set peertype any
set net-device disable
set proposal aes128-sha256 aes256-sha256 aes256gcm-prfsha384
set dhgrp 20 21
set wizard-type static-fortigate
set remote-gw 198.51.100.5
set psksecret
next
end

# — Phase 2: IPsec SA —
config vpn ipsec phase2-interface
edit “HQ2”
set phase1name “HQ2”
set proposal aes128-sha256 aes256-sha256 aes256gcm
set dhgrp 20 21
set src-addrgrp “HQ2_local”
set dst-addrgrp “HQ2_remote”
next
end

# — Firewall policies para tráfego VPN —
# Outbound: HQ1 → HQ2
config firewall policy
edit 20
set name “vpn_outbound”
set srcintf “port1”
set dstintf “HQ2”
set action accept
set srcaddr “HQ2_local”
set dstaddr “HQ2_remote”
set schedule “always”
set service “ALL”
next
end

# Inbound: HQ2 → HQ1
config firewall policy
edit 21
set name “vpn_inbound”
set srcintf “HQ2”
set dstintf “port1”
set action accept
set srcaddr “HQ2_remote”
set dstaddr “HQ2_local”
set schedule “always”
set service “ALL”
next
end

Parâmetros-chave da Phase 1:

  • ike-version 2 — IKEv2, recomendado pela Fortinet (mais rápido e seguro que IKEv1)
  • proposal — algoritmos de encriptação e integridade. AES-256 com SHA-256 ou AES-GCM são as opções recomendadas
  • dhgrp 20 21 — Diffie-Hellman groups 20 (NIST P-384) e 21 (NIST P-521). Groups mais altos = mais segurança
  • peertype any — aceita qualquer peer (útil para PSK; para maior segurança, especificar o IP do peer)
  • psksecret — a pre-shared key. Deve ser uma string aleatória de pelo menos 32 caracteres

⚠ Atenção

Em produção, usar certificados digitais em vez de pre-shared key. PSK é aceitável para túneis entre sites da mesma organização, mas é vulnerável a ataques de força bruta se o IKEv1 estiver activo. IKEv2 com EAP e certificados é a configuração mais segura (Fortinet — Site-to-site VPN com certificados).

Subnets sobrepostas

Quando ambos os sites usam a mesma subnet (ex.: 192.168.1.0/24), o túnel IPsec não funciona porque o FortiGate não consegue distinguir entre tráfego local e remoto. A solução é usar VIPs com NAT para traduzir as subnets de um dos lados (Fortinet — Overlapping subnets). Esta situação é comum em fusões de empresas ou quando se liga a rede de um cliente que usa o mesmo range.

6. Passo 4 — Configurar VPN SSL com FortiClient (Split Tunnel)

A VPN SSL permite que utilizadores remotos (teletrabalho) liguem ao escritório através de um túnel encriptado. No FortiOS 7.4 (última versão com nomenclatura clássica), a configuração usa config vpn ssl settings e config vpn ssl web portal (Fortinet — SSL VPN split tunnel 7.4).

Em split tunnel, apenas o tráfego destinado à rede corporativa vai pelo túnel; o resto (internet browsing, streaming) vai directamente pela ligação do utilizador. Isto reduz a carga no FortiGate e melhora a experiência do utilizador.

# — Criar utilizador VPN —
config user local
edit “vpn_user1”
set type password
set passwd next
end

config user group
edit “sslvpn_group”
set member “vpn_user1”
next
end

# — Address object para a rede interna —
config firewall address
edit “Corp_LAN”
set subnet 192.168.1.0 255.255.255.0
next
end

# — Portal SSL VPN com split tunnel —
config vpn ssl web portal
edit “split_tunnel_portal”
set tunnel-mode enable
set split-tunneling enable
set split-tunneling-routing-address “Corp_LAN”
set ip-pools “SSLVPN_TUNNEL_ADDR1”
next
end

# — Settings globais SSL VPN —
config vpn ssl settings
set servercert “Fortinet_Factory”
set tunnel-ip-pools “SSLVPN_TUNNEL_ADDR1”
set source-address “all”
set source-address6 “all”
set default-portal “split_tunnel_portal”
end

# — Firewall policy para tráfego SSL VPN —
config firewall policy
edit 30
set name “sslvpn_access”
set srcintf “ssl.root”
set dstintf “port1”
set action accept
set srcaddr “SSLVPN_TUNNEL_ADDR1”
set dstaddr “Corp_LAN”
set schedule “always”
set service “ALL”
set logtraffic all
set nat enable
set groups “sslvpn_group”
next
end

A interface ssl.root é a interface virtual de SSL VPN no FortiGate. Todo o tráfego que chega pelo túnel SSL entra por essa interface. O SSLVPN_TUNNEL_ADDR1 é um IP pool pré-criado que atribui IPs aos clientes VPN (range predefinido: 10.212.134.200-210).

Nota: Para ambientes com Active Directory, a autenticação pode ser delegada para RADIUS via Windows NPS. O FortiGate suporta RADIUS, LDAP e SAML para autenticação SSL VPN. Ver Fortinet — SSL VPN com RADIUS/Windows NPS.

Para reforçar a segurança, recomenda-se activar FortiToken (MFA) para os utilizadores VPN. O FortiToken está incluído no FortiOS sem custo adicional (50 tokens gratuitos por FortiGate) e integra-se directamente com a autenticação SSL VPN. O utilizador introduz username + password + código OTP do FortiToken no FortiClient.

7. Passo 5 — Verificar e Diagnosticar com CLI

Depois de configurar policies, NAT e VPNs, é essencial verificar que tudo está a funcionar. O FortiOS tem comandos get e diagnose para inspecionar o estado de cada componente.

Verificar firewall policies

# Listar todas as policies com contadores de hit
get firewall policy 1
diagnose firewall iprope lookup policy 1

# Verificar contadores de tráfego por policy
get firewall policy | grep -i hit

Verificar NAT

# Verificar regras de central SNAT
get firewall central-snat-map

# Verificar VIPs configuradas
get firewall vip

# Verificar IP pools
get firewall ippool

Verificar VPN IPsec

# Estado do túnel (summary)
get vpn ipsec tunnel summary

# Detalhes completos das SAs
get vpn ipsec tunnel details

# Verificar rotas através do túnel
get router info routing-table

Debug de VPN IPsec

Se o túnel não se estabelece, o comando mais útil é o diagnose debug app ike -1 que mostra toda a negociação IKE em tempo real:

# Debug de negociação IKE para um peer especifico
diagnose vpn ike log filter dst-addr4 198.51.100.5
diagnose debug app ike -1
diagnose debug enable

# … tentar estabelecer o tunel …

# Parar o debug
diagnose debug disable
diagnose debug app ike 0
diagnose vpn ike log filter clear

Este comando mostra cada mensagem IKE trocada entre os dois peers, incluindo propostas, rejeições e erros. É a forma mais rápida de identificar mismatch de parâmetros (Fortinet — VPN IPsec troubleshooting).

Verificar SSL VPN

# Estado do SSL VPN
get vpn ssl stats

# Utilizadores conectados
get vpn ssl monitor

# Debug de SSL VPN
diagnose debug application fnbpalm -1
diagnose debug enable

8. FortiOS 8.0: O que Mudou em VPN SSL

No FortiOS 8.0, a nomenclatura de VPN SSL foi reestruturada de forma significativa (Fortinet — Agentless VPN):

FortiOS 7.4 (clássico) FortiOS 8.0 (novo) O que mudou
SSL VPN web mode Agentless VPN Renomeado; acesso via browser sem cliente
SSL VPN tunnel mode + FortiClient FortiClient como dialup client (IPsec) Migrou para IPsec em vez de SSL
ZTNA (existia mas separado) ZTNA (recomendado como substituto de SSL VPN tunnel) Zero Trust Network Access como moderno
config vpn ssl settings Ainda existe mas focado em Agentless VPN Para tunnel mode clássico, usar docs 7.4

Para PME que já têm SSL VPN tunnel mode configurado em FortiOS 7.x, a migração para 8.0 não é obrigatória imediatamente — as configurações existentes continuam a funcionar. No entanto, a Fortinet recomenda migrar gradualmente para:

  1. Agentless VPN para acesso browser-only (sem instalação de cliente)
  2. IPsec dial-up com FortiClient para tunnel mode (mais seguro que SSL)
  3. ZTNA para acesso granular por aplicação (zero trust)

⚠ Atenção

Se estão a planear um upgrade de FortiOS 7.x para 8.0, verificar a compatibilidade da configuração SSL VPN existente. As configs config vpn ssl settings e config vpn ssl web portal continuam suportadas mas podem mudar de comportamento. Fazer backup completo antes do upgrade e testar num ambiente de laboratório.

9. Erros Comuns de Configuração

Problema Causa Solução
Túnel IPsec não estabelece Mismatch de propostas entre Phase 1 dos dois peers Verificar que proposal e dhgrp são idênticos em ambos os lados. Usar diagnose debug app ike -1 para ver o mismatch exacto
Túnel estabelece mas tráfego não passa Falta de firewall policy para tráfego VPN Criar policies inbound e outbound com srcintf/dstintf = interface do túnel
Tráfego VPN passa numa direcção mas não na outra Asymmetric routing ou falta de route return Verificar rotas em ambos os FortiGate: get router info routing-table
Cliente SSL VPN liga mas não acede à LAN Split tunnel mal configurado ou falta de NAT Verificar split-tunneling-routing-address no portal e set nat enable na policy
Destination NAT não funciona VIP criada mas não referenciada na policy como dstaddr A VIP tem de ser o dstaddr da policy, não um address object
Hairpin NAT não funciona Falta de política intra-zone Criar policy com srcintf e dstintf na mesma interface (intra-zone)
Policy deny não bloqueia Policy deny está depois de uma policy accept que faz match primeiro Mover a policy deny para cima da accept com move
Central NAT não aplica central-nat não activado em config system settings Activar set central-nat enable e migrar todas as regras de NAT para central-snat-map
IP Pool esgota portas Muitos clientes para poucos IPs no pool Aumentar o range do IP pool ou usar type overload para partilha de portas
FortiClient não conecta Certificado SSL self-signed ou porta errada Verificar servercert em config vpn ssl settings e porta 443 aberta na WAN

10. Checklist Rápido de Verificação

  • [ ] Criar address objects para todas as redes internas (LAN, DMZ, VPN)
  • [ ] Agrupar redes relacionadas em address groups para policies reutilizáveis
  • [ ] Policy LAN → WAN com nat enable e logtraffic all
  • [ ] Verificar que policies deny estão acima de policies accept mais permissivas
  • [ ] Usar diagnose debug flow para confirmar qual policy corresponde ao tráfego
  • [ ] Para destination NAT: criar VIP com extip, mappedip, extport, mappedport
  • [ ] Referenciar a VIP como dstaddr na firewall policy (não usar address object)
  • [ ] VPN IPsec: IKEv2 com aes256-sha256 ou aes256gcm, dhgrp 20 21
  • [ ] VPN IPsec: criar policies inbound e outbound para a interface do túnel
  • [ ] Verificar túnel com get vpn ipsec tunnel summary
  • [ ] SSL VPN: split tunnel com split-tunneling-routing-address para a rede interna
  • [ ] SSL VPN: firewall policy com srcintf ssl.root e groups para autenticação
  • [ ] Activar FortiToken (MFA) para utilizadores VPN
  • [ ] Activar logtraffic all em todas as policies — sem logs não há auditoria
  • [ ] Backup da configuração antes de qualquer mudança: execute backup full-config

Artigos Relacionados

Este artigo foi útil?

Duarte Spínola

Artigos  

Deixe um Comentário