Muitas vezes faz sentido usar uma NVA (Network Virtual Appliance) como firewall dentro do AVS, porque permite reaproveitar a solução de firewall já existente (Palo Alto, Check Point, etc..) e manter a proficiência do time de segurança, evita parte da complexidade de roteamento que pode surgir ao forçar o tráfego passar por um firewall “fora” do AVS . Além disso, administrar esse firewall dentro do AVS continua familiar para quem já opera VMware, e você ganha acesso a recursos avançados de inspeção do fabricante (como filtragem por aplicação em camada 7 e inspeção SSL/TLS), que são muito úteis para controle de tráfego outbound e políticas corporativas.
Neste artigo eu demonstro e um laboratório prático de inspeção de tráfego Norte-Sul e Leste-Oeste, fazendo isolamento por ambiente (DEV/PRD) dentro do Azure VMware Solution (AVS) usando NSX-T (Tier-0/Tier-1) e um Firewall NVA (pfSense) implantado no SDDC. Também serão demonstradas as principais configurações no NSX (criação/associação de segments, gateways T0/T1 e ajustes de roteamento necessários para forçar o tráfego a passar pela NVA).
Arquitetura
Informações do Laboratório
Segmentos de Trânsito
- Transit_Outside | CIDR: 192.168.30.0/24 | GW: 192.168.30.1
- Transit_PRD | CIDR: 192.168.21.0/24 | GW: 192.168.21.1
- Transit_DEV | CIDR: 192.168.22.0/24 | GW: 192.168.22.1
Segmentos de Workloads
- PRD_WEB | CIDR: 192.168.70.0/24 | GW: 192.168.70.1
- PRD_DATA | CIDR: 192.168.71.0/24 | GW: 192.168.71.1
- DEV_WEB | CIDR: 192.168.80.0/24 | GW: 192.168.80.1
- DEV_DATA | CIDR: 192.168.81.0/24 | GW: 192.168.81.1
Interfaces da NVA (pfSense)
- Transit_Outside: 192.168.30.5
- Transit_PRD: 192.168.21.5
- Transit_DEV: 192.168.22.5
Configuração do Azure VMware Solution
Na configuração Internet connectivity (egress/ingress) do Azure VMware Solution (AVS) irei utilizar a opção "Connect using Public IP down to the NSX Edge". Isso permite usar o NSX Data Center para criar regras de outbound e inbound (DNAT/SNAT) usando esses IPs públicos diretamente no Edge do AVS.
Configuração de SNAT e NoSnat no NSX
- Regras “No SNAT” : Define que não deve haver tradução de origem quando o tráfego vai para redes privadas RFC1918. Isso preserva o IP original de origem para comunicação interna (ex.: on-prem, Azure, spoke VNets/rotas privadas), evita quebra de roteamento/retorno.
- Regra “SNAT”: Aplica tradução de origem para o restante do tráfego (Internet). Ou seja, quando uma VM com IP privado sai para fora, o NSX troca o IP de origem pelo IP público configurado ( 20.20.138.0/32).
Criação dos Gateways TIER-1 (PRD e DEV).
Importante: Estes gateway são "Isolados", portando não serão conectados ao TIER-0
T1_PRD_Isolado
T1_DEV_Isolado
Resultado
Criação dos Segmentos de Trânsito PRD e DEV
Importante: Estes Segmentos estarão conectados ao Tier-1 Gateway PRD (T1_PRD_Isolado) e DEV ( T1_DEV_Isolado) respectivamente criados na etapa anterior
TRANSIT_PRD
TRANSIT_DEV
Criação do Segmento PRD WEB e DATA
Importante: Estes Segmentos estarão conectados ao Tier-1 Gateway PRD (T1_PRD_isolado) e DEV ( T1_DEV_Isolado) respectivamente criados na etapa anterior
PRD_WEB
PRD_DATA
DEV_WEB
DEV_DATA
Visão Geral dos Segmentos
Configuração de Rotas
Rotas no Gateway T1 Default
No Gateway T1 Default que está conectado ao T0 , irei configurar rotas para todos os segmentos com Next Hop ao ip da interface Outside do meu PFsense (192.168.30.5) .
obs: o nome do gateway T1 é diferente em cada AVS SDDC, no meu ambiente é "TNT13-T1"
Informei o CIDR da Rede , neste caso é para o segmento TRANSIT_PRD
Next Hop aqui é o ip da interface Outside do PFsense ( 192.168.30.5) , que está conectada diretamente a este GW T1.
Repeti os mesmos passos para todos os outros Segmentos, sempre com next hop para 192.168.30.5.
Interfaces Firewall Pfsense
Neste cenário o Firewall possui apenas três interfaces.
Deve ser configurada a rota default ( 0.0.0.0/0) para o gateway do Segmento Transit Outside ( 192.168.30.1)
Interfaces do Pfsense
Rotas no Gateways de Transito : T1_PRD_isolado
Estarei criado uma rota default ( 0.0.0.0/0 ) , com next hop para a interface do Inside do PFsense (192.168.21.5 ) conectada ao Gateway T1 PRD. Devido a limitações do NSX, é necessário "quebrar" em duas: 0.0.0.0/1 e 128.0.0.1/1
Configuração da Rodas default
Next Hop para ip da Interface Inside PFsense.
Rotas no Gateways de Transito : T1_DEV_Isolado
Estarei criado uma rota default ( 0.0.0.0/0 ) , com next hop para a interface do Inside do PFsense (192.168.22.5 ) conectada ao Gateway T1 PRD. Devido a limitações do NSX, é necessário "quebrar" em duas: 0.0.0.0/1 e 128.0.0.1/1
Configuração da Rodas default
Next Hop para ip da Interface Inside PFsense.
Teste de Acesso
Tráfego Norte-Sul ( Saída Internet)
Para comprovar que conseguimos agora ter o tráfego Norte-Sul, pelo NVA PFense , irei fazer um teste a partir da máquina no segmento PRD_WEB , com ip 192.168.70.1
É possivel observar que o ip públlico de saída é do AVS
Agora vou criar uma regra no Pfsense bloqueando a porta 443 , mas deixando liberada as outras portas.
Podemos comprovar que o tráfego está sendo inspersionado fazendo um teste de conexão na porta 53 e outro teste https.
No Pfsense podemos ver o bloqueio
Tráfego Leste-Oeste
Para testar o tráfego leste oeste entre os Segmentos PRD_WEB ( VM 192.168.70.10 ) e DEV_WEB ( VM 192.168.80.10) , irei deixar ICMP liberado e bloquear a porta 3389 ( RDP)
Fazendo o teste a partir da máquina 192.168.70.10
Verificando no PFsense o bloqueio da porta 3389
Resumo
Neste laboratório demonstrei como integrar uma NVA ao Azure VMware Solution usando NSX-T com Tier-0/Tier-1, criando T1s isolados para DEV e PRD, segments de trânsito e a configuração de SNAT/NoSNAT no NSX para controlar o egress. Também mostrei o ajuste de rotas para garantir que o tráfego siga pelo caminho de inspeção no firewall. Validei a arquitetura com testes práticos de tráfego Norte-Sul (saída para Internet com IP público do AVS) e Leste-Oeste (controle entre DEV e PRD), comprovando a inspeção via logs e bloqueios aplicados no pfSense. Como próximos passos para produção, recomenda-se padronizar regras, logging, e revisar resiliência/HA do firewall e rotas para reduzir pontos únicos de falha.
Referências
Microsoft