Módulo 7 — VPN: IPsec e SSL

Módulo 7 — VPN: IPsec e SSL

Objetivos de aprendizagem

• Explicar o papel do IPsec site-to-site no FortiGate e distinguir as fases IKE phase 1 e phase 2.


• Comparar IKEv1 e IKEv2, e túneis route-based vs policy-based.


• Configurar um túnel IPsec route-based com PSK, incluindo proposals, rotas e firewall policies.


• Aplicar mecanismos de robustez do túnel: DPD, NAT-T e keepalives.


• Configurar uma SSL-VPN de acesso remoto, distinguindo tunnel mode e web mode, portais e split tunneling.


• Diagnosticar túneis IPsec e sessões SSL-VPN com comandos diagnose do FortiOS 7.6.

IPsec site-to-site: para que serve

Uma VPN IPsec site-to-site liga duas redes privadas (por exemplo, a sede e uma filial) através da Internet, cifrando todo o tráfego entre elas. No FortiGate, o túnel é negociado pelo protocolo IKE (Internet Key Exchange) em duas fases: a phase 1 estabelece um canal seguro de gestão entre os dois gateways; a phase 2 negocia as Security Associations (SA) que cifram o tráfego de dados real.

IKEv1 vs IKEv2

IKEv1 é o protocolo mais antigo: a phase 1 pode correr em main mode (6 mensagens, mais seguro) ou aggressive mode (3 mensagens, mais rápido mas expõe identidades). IKEv2 é o mais recente e recomendado: menos trocas de mensagens, suporte nativo a NAT traversal, EAP e re-keying mais eficiente, e melhor resiliência. Para túneis novos, escolhe IKEv2 sempre que ambos os lados o suportarem.

Route-based vs policy-based

No FortiOS, o modo recomendado é route-based (também chamado interface mode): cria-se uma interface virtual de túnel (ex.: to_branch) e o tráfego entra no túnel por routing — basta uma rota que aponte o destino remoto para a interface do túnel, mais firewall policies normais. É mais flexível: permite routing dinâmico (OSPF/BGP) sobre o túnel e múltiplas phase 2.

O modo policy-based (legacy) define o tráfego a cifrar dentro de uma firewall policy especial do tipo IPsec, sem interface dedicada. É menos flexível e está em desuso. No exame, assume route-based salvo indicação em contrário.

Configurar a phase 1 (route-based, IKEv2, PSK)

A phase 1 define o peer remoto, a versão do IKE, a chave pré-partilhada (PSK), os proposals (cifra + autenticação + grupo DH) e parâmetros de robustez como DPD e NAT-T. Numa interface-mode, o tipo é static (peer com IP fixo) ou dynamic (peer com IP variável, ex.: filial atrás de DSL).

config vpn ipsec phase1-interface

    edit "to_branch"

        set interface "wan1"

        set ike-version 2

        set peer-type any

        set net-device disable

        set proposal aes256-sha256 aes128-sha256

        set dhgrp 14

        set remote-gw 203.0.113.20

        set psksecret SuperSegreda_2026!

        set dpd on-idle

        set dpd-retryinterval 60

        set nattraversal enable

    next

end

Notas: proposal lista os algoritmos de cifra/hash; dhgrp 14 é o grupo Diffie-Hellman (2048 bits). DPD (Dead Peer Detection) deteta um peer morto e derruba o túnel para forçar renegociação — on-idle só sonda quando não há tráfego; on-demand sonda quando há tráfego de saída sem resposta. NAT-T (NAT Traversal) encapsula ESP em UDP/4500 para o túnel atravessar dispositivos NAT no caminho.

Configurar a phase 2

A phase 2 liga-se à phase 1 e define os selectors (src/dst subnets), os proposals de dados e o tempo de vida (keylife). Com PFS (Perfect Forward Secrecy) ativo, cada renegociação de chave usa um novo DH, isolando as chaves anteriores.

config vpn ipsec phase2-interface

    edit "to_branch_p2"

        set phase1name "to_branch"

        set proposal aes256-sha256 aes128-sha256

        set pfs enable

        set dhgrp 14

        set keylifeseconds 43200

        set src-subnet 10.10.0.0 255.255.0.0

        set dst-subnet 10.20.0.0 255.255.0.0

    next

end

Rotas e firewall policies

Num túnel route-based, o túnel sozinho não encaminha tráfego: é preciso (1) uma rota estática que envie a sub-rede remota para a interface do túnel e (2) firewall policies bidirecionais entre a LAN local e a interface do túnel. Sem policies, o tráfego é negado mesmo com o túnel "up".

config router static

    edit 0

        set dst 10.20.0.0 255.255.0.0

        set device "to_branch"

    next

end



config firewall policy

    edit 0

        set name "LAN-to-Branch"

        set srcintf "internal"

        set dstintf "to_branch"

        set srcaddr "LAN_local"

        set dstaddr "Branch_subnet"

        set action accept

        set schedule "always"

        set service "ALL"

    next

end

SSL-VPN de acesso remoto

A SSL-VPN dá a utilizadores individuais (teletrabalho) acesso à rede interna a partir de qualquer lugar, sobre HTTPS. Há dois modos:

• Web mode (portal): o utilizador entra num portal web no browser e acede a recursos pré-publicados (bookmarks RDP, SSH, ficheiros, web interno). Não instala cliente, mas o acesso é limitado às aplicações publicadas.


• Tunnel mode: usa o cliente FortiClient que cria um adaptador virtual e recebe um IP do pool da SSL-VPN; o tráfego flui como numa VPN completa. Mais flexível, suporta qualquer aplicação.

O split tunneling controla que tráfego vai pelo túnel: desativado (full tunnel) envia todo o tráfego do cliente pela VPN (mais seguro, mais carga no FortiGate); ativado envia pelo túnel só as sub-redes corporativas e deixa o resto sair localmente (Internet do utilizador), poupando largura de banda.

Configurar SSL-VPN (settings + portal)

config vpn ssl settings

    set servercert "Fortinet_SSL"

    set tunnel-ip-pools "SSLVPN_TUNNEL_ADDR1"

    set port 10443

    set source-interface "wan1"

    set source-address "all"

    set default-portal "full-access"

    config authentication-rule

        edit 1

            set groups "SSLVPN_Users"

            set portal "full-access"

        next

    end

end



config vpn ssl web portal

    edit "full-access"

        set tunnel-mode enable

        set web-mode enable

        set ip-pools "SSLVPN_TUNNEL_ADDR1"

        set split-tunneling enable

        set split-tunneling-routing-address "Corp_subnets"

    next

end

Falta ainda uma firewall policy da interface virtual ssl.root para a LAN interna, com o grupo de utilizadores como origem, para autorizar o acesso. Sem ela, o login tem sucesso mas o utilizador não chega aos recursos. A porta 10443 evita conflito com a gestão HTTPS na 443.

Diagnóstico

Para inspecionar túneis IPsec ativos (estado, selectors, bytes cifrados/decifrados):

diagnose vpn tunnel list

diagnose vpn tunnel list name to_branch

diagnose vpn ike gateway list

Para ver as sessões SSL-VPN e os utilizadores ligados:

diagnose vpn ssl list

diagnose vpn ssl statistics

get vpn ssl monitor

Em diagnose vpn tunnel list, confirma que existem SAs de phase 2 e que os contadores de tráfego aumentam nos dois sentidos. Se vês a SA mas só sobe num sentido, suspeita de policy/rota em falta no lado oposto. Em diagnose vpn ssl list vês o utilizador, o IP atribuído do pool e o modo (web/tunnel).

Labs associados

• 🧪 Abrir este Lab na plataforma LAB
  Abre com sessão automática (SSO). Incluído no curso — sem custo de créditos.




• 🧪 Abrir este Lab na plataforma LAB
  Abre com sessão automática (SSO). Incluído no curso — sem custo de créditos.