Azure VPN Gateway: Site-to-Site, Point-to-Site, BGP e diagnósticos completos
azure · vpn-gateway · ipsec · bgp · site-to-site · point-to-site · ha · Diagnóstico · Cloud
Por Duarte Spínola · 27 junho 2026 · kbase.pt
Este artigo integra uma série sobre segurança e conectividade híbrida publicada no kbase.pt. Para enquadramento sobre firewalls on-premises que frequentemente servem de peer do lado do cliente numa VPN Site-to-Site com o Azure, consulte os artigos FortiGate: firewall, NAT e IPsec VPN — configuração prática e DrayTek Vigor: configuração de router empresarial. Para ambientes que privilegiam software livre, veja OPNsense: firewall open-source de produção. A abordagem Zero Trust para PMEs em 2026 complementa a VPN com segmentação e identidade, e a alternativa Cloudflare Tunnel + Zero Trust + WARP é relevante quando a VPN tradicional deixa de ser a melhor opção.
Índice
- Tipos de VPN: S2S, P2S e VNet-to-VNet
- SKUs do VPN Gateway
- Pré-requisitos e planeamento
- Configuração Site-to-Site com PowerShell e CLI
- Point-to-Site com IKEv2
- BGP sobre VPN Gateway
- Ligação on-premises: FortiGate, DrayTek e OPNsense
- High Availability: active/active e NAT-T
- NAT e UDR em ambientes híbridos
- Diagnóstico e resolução de problemas
- IPsec/IKE policies personalizadas
- Erros comuns (tabela)
- RFC, compatibilidade e limites técnicos
- Checklist final de implementação
1. Tipos de VPN: S2S, P2S e VNet-to-VNet
O Azure VPN Gateway é um serviço gerido que envia tráfego encriptado por IPsec entre uma rede virtual do Azure (VNet) e localizações externas — on-premises, outras clouds ou clientes individuais. Existem três modos principais, todos suportados pelo mesmo recurso VpnGateway ou VirtualNetworkGateway, dependendo do tipo de gateway implementado.
Site-to-Site (S2S)
A VPN S2S liga uma rede on-premises inteira a uma VNet do Azure através de um túnel IPsec entre dois dispositivos VPN — um do lado do cliente (FortiGate, DrayTek, OPNsense, Cisco, etc.) e o gateway do Azure. O tráfego entre as sub-redes é encaminhado de forma transparente, como se fossem parte da mesma rede. É o modo mais usado em cenários híbridos empresariais.
Point-to-Site (P2S)
A VPN P2S permite que clientes individuais (portáteis,workstations) se liguem à VNet sem necessidade de dispositivo VPN no lado do cliente. Cada cliente inicia um túnel IKEv2 (ou SSTP/OpenVPN) autenticado por certificado ou Entra ID. É ideal para teletrabalho e administradores que precisam de acesso seguro a recursos em Azure.
VNet-to-VNet
A ligação VNet-to-VNet cria um túnel IPsec entre duas VNets do Azure, eventualmente em regiões diferentes. Funciona de forma semelhante à S2S mas usa dois gateways do Azure como pontos finais. É útil para georeplicação, segregação de ambientes (produção vs DR) e contornar o peering quando se precisa de encriptação em trânsito entre VNets.
| Modo | Caso de uso | Autenticação | Protocolo | Dispositivo peer |
|---|---|---|---|---|
| S2S | Ligar site on-premises a VNet | PSK (pre-shared key) | IKEv2/IKEv1 | FortiGate, DrayTek, OPNsense, Cisco… |
| P2S | Teletrabalho, acesso administrador | Certificado ou Entra ID | IKEv2, SSTP, OpenVPN | Cliente nativo Windows/macOS/iOS/Android |
| VNet-to-VNet | Interligar VNets (geo-DR, multi-env) | PSK | IKEv2 | Outro VPN Gateway do Azure |
Uma única instância de VPN Gateway pode suportar S2S e P2S simultaneamente. O limite máximo de túneis S2S depende do SKU (por exemplo, VpnGw3 suporta até 30 túneis S2S). Planeie o SKU com folga para crescimento futuro.
Para uma visão oficial e detalhada de cada tipo, a Microsoft mantém a página About VPN Gateway no Microsoft Learn, que serve de referência base para todo este guia.
2. SKUs do VPN Gateway
A escolha do SKU determina a largura de banda agregada, o número máximo de túneis, o suporte para BGP e a capacidade de P2S. Existem duas famílias: legacy (Basic, VpnGw1–VpnGw5) baseadas em VirtualNetworkGateway e geridas (azuredesenhadas) baseadas em VpnGateway (VpnGw1AZ–VpnGw5AZ), que suportam zonas de disponibilidade.
| SKU | Largura de banda | Túneis S2S | Conexões P2S | BGP | Zonas |
|---|---|---|---|---|---|
| Basic | 100 Mbps | 10 | 128 | Não | Não |
| VpnGw1 | 650 Mbps | 30 | 250 | Sim | Não |
| VpnGw2 | 1 000 Mbps | 30 | 500 | Sim | Não |
| VpnGw3 | 1 250 Mbps | 30 | 1 000 | Sim | Não |
| VpnGw4 | 2 500 Mbps | 100 | 5 000 | Sim | Não |
| VpnGw5 | 10 000 Mbps | 100 | 10 000 | Sim | Não |
| VpnGw1AZ | 650 Mbps | 30 | 250 | Sim | Sim |
| VpnGw2AZ | 1 000 Mbps | 30 | 500 | Sim | Sim |
| VpnGw3AZ | 1 250 Mbps | 30 | 1 000 | Sim | Sim |
| VpnGw4AZ | 2 500 Mbps | 100 | 5 000 | Sim | Sim |
| VpnGw5AZ | 10 000 Mbps | 100 | 10 000 | Sim | Sim |
O SKU Basic não suporta BGP nem IKEv2 com políticas personalizadas e está limitado a 100 Mbps. Para produção recomenda-se no mínimo VpnGw1AZ ou superior. A mudança de SKU após criação é suportada entre SKUs da mesma família (legacy ou AZ), mas tem downtime durante o redimensionamento.
Os valores de largura de banda são agregados e baseados em tráfego simultâneo em todos os túneis. Para detalhes atualizados, consulte Gateway SKUs no Microsoft Learn.
3. Pré-requisitos e planeamento
Antes de implementar um VPN Gateway é essencial planejar o endereçamento, os gatewaysubnet e o SKU. Os pontos seguintes representam o conjunto mínimo de decisões técnicas.
3.1 Sub-rede GatewaySubnet
O VPN Gateway exige uma sub-rede dedicada com o nome exato GatewaySubnet. O tamanho mínimo recomendado é /27 (32 endereços), mas /26 ou /28 também funcionam. Esta sub-rede não deve conter outros recursos.
Nunca associe um NSG à
GatewaySubnet sem regras explícitas que permitam o tráfego IPsec (UDP 500, UDP 4500, ESP). Um NSG restritivo nesta sub-rede é uma causa frequente de túneis que não sobem.
3.2 Endereçamento sem sobreposição
O espaço de endereçamento on-premises e o da VNet do Azure não pode overlap. Por exemplo, se o site on-premises usa 192.168.1.0/24, a VNet deve usar uma range diferente como 10.20.0.0/16. Isto vale também para todas as redes remotas que vão ser announced via BGP.
3.3 IP público do gateway
O VPN Gateway precisa de pelo menos um IP público dinâmico (Standard para SKUs AZ). Em active/active são necessários dois IPs públicos. O IP público é atribuído automaticamente e não pode ser um IP Basic para SKUs AZ.
3.4 Dispositivo VPN on-premises
O dispositivo on-premises tem de suportar IKEv2 (preferencial) ou IKEv1 com IPsec. A Microsoft mantém uma lista de dispositivos validados em VPN devices. Mesmo dispositivos não listados funcionam se cumprirem os parâmetros padrão.
3.5 Lista de verificação de planeamento
- Definir espaço de endereçamento da VNet sem conflitos com on-premises.
- Criar
GatewaySubnetcom máscara /27 ou superior. - Reservar IP público Standard para o gateway.
- Confirmar que o dispositivo on-premises suporta IKEv2.
- Decidir se vai usar BGP (recomendado para multi-túnel).
- Verificar regras de firewall on-premises: UDP 500, UDP 4500 (NAT-T), ESP (protocolo 50).
- Planejar janelas de implementação — a criação do gateway demora 20–45 minutos.
A documentação oficial sobre o tutorial completo de S2S está em Tutorial: Create a Site-to-Site VPN connection.
4. Configuração Site-to-Site com PowerShell e CLI
Nesta secção vamos implementar uma VPN S2S completa entre uma VNet do Azure e um site on-premises com IP público 203.0.113.10. São mostrados dois caminhos: PowerShell (módulo Az) e Azure CLI.
4.1 PowerShell (módulo Az)
# Variáveis
$RG = "rg-vpn-prod"
$Location = "westeurope"
$VNetName = "vnet-prod"
$GWName = "gw-prod"
$GWIPName = "gwpip-prod"
$LNGName = "lng-onprem"
$ConnName = "cn-s2s-onprem"
$SharedKey = "UnaCh4v3F0rte!2026"
$OnPremIP = "203.0.113.10"
$OnPremPrefix= "192.168.10.0/24"
# 1. Grupo de recursos
New-AzResourceGroup -Name $RG -Location $Location
# 2. VNet com sub-redes
$gwSub = New-AzVirtualNetworkSubnetConfig -Name "GatewaySubnet" -AddressPrefix "10.20.0.0/27"
$workSub = New-AzVirtualNetworkSubnetConfig -Name "workload" -AddressPrefix "10.20.1.0/24"
$vnet = New-AzVirtualNetwork -Name $VNetName -ResourceGroupName $RG `
-Location $Location -AddressPrefix "10.20.0.0/16" `
-Subnet $gwSub,$workSub
# 3. IP público do gateway
$gwpip = New-AzPublicIpAddress -Name $GWIPName -ResourceGroupName $RG `
-Location $Location -AllocationMethod Dynamic -Sku Standard
# 4. Configuração IP do gateway
$gwipconfig = New-AzVirtualNetworkGatewayIpConfig -Name "gwipconfig" `
-SubnetId $vnet.Subnets[0].Id -PublicIpAddressId $gwpip.Id
# 5. Criar o gateway (VpnGw2AZ, ~30 min)
New-AzVirtualNetworkGateway -Name $GWName -ResourceGroupName $RG `
-Location $Location -IpConfigurations $gwipconfig `
-GatewayType Vpn -VpnType RouteBased -VpnGatewayGeneration Generation2 `
-GatewaySku VpnGw2AZ -EnableBgp $false
# 6. Local Network Gateway (peer on-premises)
New-AzLocalNetworkGateway -Name $LNGName -ResourceGroupName $RG `
-Location $Location -GatewayIpAddress $OnPremIP `
-AddressPrefix $OnPremPrefix
# 7. Ligação S2S
$vnetgw = Get-AzVirtualNetworkGateway -Name $GWName -ResourceGroupName $RG
$lng = Get-AzLocalNetworkGateway -Name $LNGName -ResourceGroupName $RG
New-AzVirtualNetworkGatewayConnection -Name $ConnName `
-ResourceGroupName $RG -Location $Location `
-VirtualNetworkGateway1 $vnetgw -LocalNetworkGateway2 $lng `
-ConnectionType IPsec -SharedKey $SharedKey `
-RoutingWeight 10 -ConnectionProtocol IKEv2
4.2 Azure CLI
RG="rg-vpn-prod"
LOC="westeurope"
VNET="vnet-prod"
GW="gw-prod"
GWPIP="gwpip-prod"
LNG="lng-onprem"
CONN="cn-s2s-onprem"
SHAREDKEY='UnaCh4v3F0rte!2026'
ONPREMIP="203.0.113.10"
# 1. Grupo de recursos
az group create --name $RG --location $LOC
# 2. VNet + GatewaySubnet
az network vnet create \
--name $VNET --resource-group $RG --location $LOC \
--address-prefixes 10.20.0.0/16 \
--subnet-name GatewaySubnet --subnet-prefixes 10.20.0.0/27
az network vnet subnet create \
--name workload --vnet-name $VNET --resource-group $RG \
--address-prefixes 10.20.1.0/24
# 3. IP público
az network public-ip create \
--name $GWPIP --resource-group $RG --location $LOC \
--allocation-method Dynamic --sku Standard
# 4. Gateway (VpnGw2AZ, ~30 min)
az network vnet-gateway create \
--name $GW --resource-group $RG --location $LOC \
--vnet $VNET --public-ip-addresses $GWPIP \
--gateway-type Vpn --vpn-type RouteBased \
--sku VpnGw2AZ --vpn-gateway-generation Generation2
# 5. Local Network Gateway
az network local-gateway create \
--name $LNG --resource-group $RG --location $LOC \
--gateway-ip-address $ONPREMIP \
--address-prefixes 192.168.10.0/24
# 6. Ligação S2S
az network vpn-connection create \
--name $CONN --resource-group $RG --location $LOC \
--vnet-gateway1 $GW --local-gateway2 $LNG \
--shared-key "$SHAREDKEY" --connection-type IPsec \
--routing-weight 10 --enable-bgp false
Use
--vpn-gateway-generation Generation2 sempre que possível. O Generation2 suporta IKEv2 em ambos os lados e tem melhor desempenho em SKUs VpnGw2 ou superior. O Generation1 só é necessário para compatibilidade com dispositivos antigos que só suportam IKEv1.
Ao executar estes comandos o gateway demora entre 20 e 45 minutos a ser criado — é uma operação pesada que envolve reservar capacidade de VMs geridas pela Microsoft. O progresso pode ser acompanhado no portal ou com az network vnet-gateway show.
5. Point-to-Site com IKEv2
A VPN P2S com IKEv2 é o método recomendado para teletrabalho em 2026. Comparado com o SSTP (apenas Windows, limitado a 200 Mbps) e o OpenVPN (requer cliente próprio), o IKEv2 é nativo em Windows, macOS, iOS e Android e oferece melhor desempenho e resiliência a mudanças de rede (por exemplo, passar de Wi-Fi para 4G sem cair o túnel).
5.1 Pré-requisitos P2S
- VPN Gateway RouteBased com SKU VpnGw1 ou superior.
- Certificado raiz auto-assinado ou emitido por CA interna (não pode ser público tipo Let’s Encrypt porque o Azure precisa do .cer em base64).
- Certificado cliente emitido pela mesma raiz.
- Pool de endereços P2S (por exemplo
172.16.0.0/24) que não se sobreponha com a VNet nem com on-premises.
5.2 Configuração CLI
# Pool P2S e tipo de túnel IKEv2
az network vnet-gateway update \
--name gw-prod --resource-group rg-vpn-prod \
--address-prefixes 172.16.0.0/24 \
--client-protocol Ike2v2
# Carregar certificado raiz (base64 do .cer)
CERT_B64=$(base64 -w0 rootCA.cer)
az network vpn-client-root-cert create \
--name rootCA --resource-group rg-vpn-prod \
--gateway-name gw-prod \
--public-cert-data $CERT_B64
# Revogar certificado cliente se necessário
az network vpn-client-revoke-cert \
--name revokedClient --resource-group rg-vpn-prod \
--gateway-name gw-prod \
--thumbprint ABCDEF1234567890
Para P2S com Entra ID (Azure AD) em vez de certificados, o tipo de túnel deve ser OpenVPN e é necessário registar a app
Azure VPN no tenant. O IKEv2 não suporta diretamente Entra ID — só certificados. Esta é a principal razão para muitos clientes mantiverem OpenVPN em paralelo com IKEv2.
5.3 Geração do certificado raiz (PowerShell)
# Certificado raiz auto-assinado
$rootcert = New-SelfSignedCertificate `
-Type Custom -KeySpec Signature `
-Subject "CN=P2SRootCA" -KeyExportPolicy Exportable `
-HashAlgorithm sha256 -KeyLength 2048 `
-CertStoreLocation "Cert:\CurrentUser\My" `
-KeyUsageProperty Sign -KeyUsage CertSign
# Exportar .cer para upload ao Azure
$certpath = "C:\certs\P2SRootCA.cer"
Export-Certificate -Cert $rootcert -FilePath $certpath -Type CERT
# Certificado cliente
$clientcert = New-SelfSignedCertificate `
-Type Custom -KeySpec Signature `
-Subject "CN=P2SClient1" -KeyExportPolicy Exportable `
-HashAlgorithm sha256 -KeyLength 2048 `
-CertStoreLocation "Cert:\CurrentUser\My" `
-Signer $rootcert -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.2")
O cliente VPN pode ser descarregado a partir do portal (VPN Gateway → Point-to-site configuration → Download VPN client) ou gerado via CLI com az network vnet-gateway generate-vpn-client. O cliente para Windows inclui os ficheiros .exe e .pbk pré-configurados.
Para a referência oficial completa de P2S, veja Configure a Point-to-Site VPN connection no Microsoft Learn.
6. BGP sobre VPN Gateway
O BGP (Border Gateway Protocol) sobre VPN Gateway permite que as rotas entre o Azure e o on-premises sejam trocadas dinamicamente, em vez de definidas estaticamente. Isto é essencial em cenários multi-túnel (várias filiais, multi-cloud) porque:
- Permite failover automático entre túneis sem reconfiguração manual.
- Evita problemas de rotas sobrepostas ou blackholes quando se adicionam novas redes on-premises.
- Limita o número de prefixos anunciados ao necessário (em vez de uma rota estática por cada sub-rede).
6.1 Parâmetros BGP do gateway
Cada VPN Gateway com BGP activo tem um ASN (Autonomous System Number) e um IP BGP (APIPA 169.254.x.x por defeito, ou um IP dentro da GatewaySubnet). O lado on-premises deve usar um ASN diferente (por exemplo 65010) e configurar o peer BGP com o IP do gateway do Azure.
| Parâmetro | Valor típico Azure | Valor típico on-premises |
|---|---|---|
| ASN | 65515 (default Azure) | 65010 (custom) |
| BGP Peer IP | 169.254.21.1 (APIPA) | 169.254.21.2 |
| Hold time | 180 s | 180 s |
| Keepalive | 60 s | 60 s |
6.2 Activar BGP na ligação (PowerShell)
# Gateway com BGP
New-AzVirtualNetworkGateway -Name gw-prod -ResourceGroupName rg-vpn-prod `
-Location westeurope -IpConfigurations $gwipconfig `
-GatewayType Vpn -VpnType RouteBased `
-VpnGatewayGeneration Generation2 -GatewaySku VpnGw2AZ `
-EnableBgp $true -Asn 65515 `
-BgpPeeringAddress "169.254.21.1"
# Local Network Gateway com BGP
New-AzLocalNetworkGateway -Name lng-onprem `
-ResourceGroupName rg-vpn-prod -Location westeurope `
-GatewayIpAddress "203.0.113.10" `
-AddressPrefix "192.168.10.0/24" `
-Asn 65010 -BgpPeeringAddress "169.254.21.2"
# Ligação com BGP
New-AzVirtualNetworkGatewayConnection -Name cn-s2s-bgp `
-ResourceGroupName rg-vpn-prod -Location westeurope `
-VirtualNetworkGateway1 $vnetgw -LocalNetworkGateway2 $lng `
-ConnectionType IPsec -SharedKey "UnaCh4v3!2026" `
-EnableBgp $true -ConnectionProtocol IKEv2
O range APIPA
169.254.21.0/24 é usado por defeito para BGP. Se o on-premises já usa APIPA noutro contexto, escolha um range diferente (por exemplo 169.254.22.0/24) e configure explicitamente no gateway. O BGP só funciona em SKUs VpnGw1 ou superior (não em Basic).
A documentação completa de BGP está em BGP overview e em Configure BGP no Microsoft Learn.
7. Ligação on-premises: FortiGate, DrayTek e OPNsense
O lado on-premises é tão importante quanto a configuração do Azure. Esta secção mostra os parâmetros IPsec essenciais para três dispositivos comuns em PMEs portuguesas. Para configuração detalhada de cada firewall, consulte os artigos dedicados no kbase.pt.
7.1 FortiGate (FortiOS 7.x)
O FortiGate é o dispositivo mais comum em ambientes enterprise e PME que precisam de integração robusta com o Azure. A configuração IPsec para uma S2S RouteBased com o Azure exige os parâmetros seguintes.
# FortiGate CLI
config vpn ipsec phase1-interface
edit "azure-p1"
set interface "wan1"
set ike-version 2
set keylife 28800
set peertype any
set proposal aes256-sha256
set remote-gw 20.115.45.67
set psksecret UnaCh4v3F0rte!2026
set dpd on-idle
next
end
config vpn ipsec phase2-interface
edit "azure-p2"
set phase1name "azure-p1"
set proposal aes256-sha256
set keylifeseconds 27000
set src-subnet 192.168.10.0/24
set dst-subnet 10.20.0.0/16
next
end
# Rota estática para a VNet via túnel
config router static
edit 100
set dst 10.20.0.0 255.255.0.0
set device "azure-p1"
next
end
Para uma explicação profunda de NAT, policies e troubleshooting IPsec no FortiGate, consulte o artigo FortiGate: firewall, NAT e IPsec VPN — configuração prática no kbase.pt.
7.2 DrayTek Vigor (firmware 4.x)
O DrayTek Vigor é popular em PME pequenas e filiais. A configuração faz-se via interface web em VPN and Remote Access → LAN-to-LAN.
| Parâmetro | Valor DrayTek |
|---|---|
| Call Direction | Outbound (Dial-Out) |
| Server IP/Host | 20.115.45.67 (IP público do gateway Azure) |
| VPN Type | IPsec Tunnel |
| Pre-Shared Key | UnaCh4v3F0rte!2026 |
| IKE Phase 1 | AES-256-CBC / SHA-256 / Group 14 / 28800s |
| IKE Phase 2 | AES-256-CBC / SHA-256 / Group 14 / 27000s |
| Local Network | 192.168.10.0/24 |
| Remote Network | 10.20.0.0/16 |
O DrayTek Vigor 2927/2865/3220 suporta IKEv2 nativamente. Para o DrayTek 2926 (firmware antigo) pode ser necessário usar IKEv1 e ajustar o gateway do Azure para
Generation1. Veja DrayTek Vigor: configuração de router empresarial para detalhes.
7.3 OPNsense (24.x)
O OPNsense, fork do pfSense, é uma opção open-source robusta. A configuração de IPsec para Azure S2S faz-se em VPN → IPsec → Tunnels com os parâmetros Phase 1 e Phase 2 seguintes.
# Phase 1
Key Exchange version: IKEv2
Internet Protocol: IPv4
Interface: WAN
Remote gateway: 20.115.45.67
Description: Azure S2S
Authentication method: Pre-Shared Key
Pre-Shared Key: UnaCh4v3F0rte!2026
My identifier: My IP address
Peer identifier: Peer IP address
Encryption algorithm: AES256-GCM
Hash algorithm: SHA256
DH key group: 14 (2048 bit)
Lifetime: 28800 seconds
DPD: enabled, 10s delay, 5s max failures
# Phase 2
Protocol: ESP
Encryption algorithms: AES256-GCM
Hash algorithms: SHA256
PFS key group: 14
Lifetime: 27000 seconds
Local Network: LAN subnet 192.168.10.0/24
Remote Network: Manual 10.20.0.0/16
Ping host: 10.20.1.1 (para monitorizar o túnel)
O OPNsense tem suporte nativo para BGP via plugin FRR, que pode ser activado em System → Firmware → Plugins. Para a configuração completa de OPNsense como firewall de produção, consulte OPNsense: firewall open-source de produção.
Em todos os três dispositivos é imprescindível garantir que NAT não é aplicado ao tráfego destinado à VNet do Azure. No FortiGate isto significa criar uma policy IPsec sem NAT (desactivar
set natip); no OPNsense, a regra de NAT Outbound deve ter uma exclusão para o prefixo da VNet; no DrayTek, o NAT-T deve ser desactivado se não houver NAT intermédio. Para diagnóstico de problemas de conectividade que afectam o túnel, consulte Diagnóstico de Conectividade Windows Server.
8. High Availability: Active/Active e NAT-T
VPNs Site-to-Site são ligações críticas. O Azure VPN Gateway suporta duas configurações de alta disponibilidade: Active/Passive (padrão, uma instância activa e outra em standby) e Active/Active (ambas as instâncias processam tráfego simultaneamente).
8.1 Activar Active/Active
# PowerShell: criar gateway em modo active/active
$gw = New-AzVirtualNetworkGateway `
-ResourceGroupName "rg-pme-hub" `
-Name "vpngw-hub-active-active" `
-Location "westeurope" `
-IpConfigurations @($ipconf1, $ipconf2) `
-GatewayType Vpn `
-VpnType RouteBased `
-VpnGatewayGeneration Generation2 `
-EnableActiveActiveFeature `
-GatewaySku VpnGw2AZ
# Confirmar modo
Get-AzVirtualNetworkGateway -Name "vpngw-hub-active-active" | `
Select-Object Name, EnableActiveActiveFeature, Sku
O modo Active/Active exige dois IP públicos (um por instância) e SKU
VpnGw1AZ ou superior. O SKU Basic não suporta Active/Active nem BGP.
8.2 NAT-T (NAT Traversal)
O NAT-T encapsula pacotes ESP em UDP 4500 para atravessar dispositivos NAT intermédios. O Azure VPN Gateway suporta NAT-T automaticamente quando detecta que o peer está atrás de NAT. Em dispositivos on-premises, garantir que a regra de firewall permite UDP 500 e UDP 4500 para o IP público do gateway.
| Porta | Protocolo | Função |
|---|---|---|
| UDP 500 | IKE | Negociação IKE Phase 1 |
| UDP 4500 | NAT-T | Tráfego ESP encapsulado quando há NAT |
| ESP (IP 50) | IPsec | Tráfego encriptado directo (sem NAT) |
| TCP 1701 | L2TP | Apenas para P2S com L2TP (legado) |
9. NAT e UDR em Ambientes Híbridos
Em cenários híbridos complexos, o tráfego entre on-premises e Azure pode necessitar de NAT (Network Address Translation) ou UDR (User Defined Routes) para garantir encaminhamento correcto.
9.1 NAT no VPN Gateway
O Azure VPN Gateway aplica NAT por defeito na configuração PolicyBased (NAT-T automático). Em RouteBased, o NAT pode ser configurado explicitamente via NatRules:
# Criar regra NAT no VPN Gateway
$natRule = New-AzVirtualNetworkGatewayNatRule `
-Name "nat-pme-internal" `
-Type "Static" `
-InternalMapping "10.20.0.0/16" `
-ExternalMapping "192.168.20.0/24"
# Aplicar ao gateway existente
$gw = Get-AzVirtualNetworkGateway -Name "vpngw-hub" -ResourceGroupName "rg-pme-hub"
$gw.NatRules.Add($natRule)
Set-AzVirtualNetworkGateway -VirtualNetworkGateway $gw
9.2 User Defined Routes (UDR)
Para forçar tráfego da VNet através do VPN Gateway (tunneling forçado) ou para encaminhar sub-redes específicas:
# Criar route table
$routeTable = New-AzRouteTable `
-ResourceGroupName "rg-pme-hub" `
-Name "rt-hybrid" `
-Location "westeurope"
# Adicionar rota para rede on-premises via VPN Gateway
Add-AzRouteConfig `
-RouteTable $routeTable `
-Name "route-onprem" `
-AddressPrefix "192.168.10.0/24" `
-NextHopType VirtualNetworkGateway | `
Set-AzRouteTable
# Associar a uma subnet
$vnet = Get-AzVirtualNetwork -Name "vnet-hub" -ResourceGroupName "rg-pme-hub"
Set-AzVirtualNetworkSubnetConfig `
-VirtualNetwork $vnet `
-Name "snet-apps" `
-AddressPrefix "10.20.1.0/24" `
-RouteTableId $routeTable.Id | `
Set-AzVirtualNetwork
O forced tunneling (0.0.0.0/0 → VPN Gateway) é útil quando toda a navegação de Internet da VNet deve passar pelo firewall on-premises. Configure o
NextHopType como VirtualNetworkGateway e adicione uma rota exempt para os serviços Azure (ex: storage, SQL).
10. Diagnóstico e Resolução de Problemas
O Azure fornece várias ferramentas para diagnosticar problemas de VPN Gateway. A mais potente é o VPN Troubleshooter (Network Watcher), que analisa a configuração e devolve um relatório detalhado.
10.1 VPN Troubleshooter (PowerShell)
# Verificar estado do túnel
Get-AzVirtualNetworkGatewayConnection `
-Name "conn-s2s-pme" `
-ResourceGroupName "rg-pme-hub" | `
Select-Object Name, ConnectionStatus, EgressBytesTransferred, IngressBytesTransferred
# Output esperado:
# Name : conn-s2s-pme
# ConnectionStatus : Connected
# EgressBytesTransferred : 1234567
# IngressBytesTransferred : 9876543
# Diagnóstico avançado com Network Watcher
$nw = Get-AzNetworkWatcher -Name "NetworkWatcher_westeurope" -ResourceGroupName "NetworkWatcherRG"
$gw = Get-AzVirtualNetworkGateway -Name "vpngw-hub" -ResourceGroupName "rg-pme-hub"
Start-AzNetworkWatcherResourceTroubleshooting `
-NetworkWatcher $nw `
-TargetResourceId $gw.Id `
-StorageId "/subscriptions/.../storageAccounts/diaglogs"
10.2 Logs de diagnóstico
Activar logs de diagnóstico para o VPN Gateway permite investigar problemas retrospectivamente:
# Activar diagnostic settings
$gw = Get-AzVirtualNetworkGateway -Name "vpngw-hub" -ResourceGroupName "rg-pme-hub"
$workspace = Get-AzOperationalInsightsWorkspace -Name "log-pme" -ResourceGroupName "rg-logs"
Set-AzDiagnosticSetting `
-ResourceId $gw.Id `
-WorkspaceId $workspace.ResourceId `
-Enabled $true `
-Category GatewayDiagnosticLog,IKEDiagnosticLog,P2SDiagnosticLog
| Log Category | Conteúdo | Quando consultar |
|---|---|---|
| GatewayDiagnosticLog | Estado do gateway, mudanças de SKU, reinícios | Gateway indisponível ou reiniciações inesperadas |
| IKEDiagnosticLog | Negociação IKE Phase 1 e 2, falhas de auth | Túnel não estabelece ou cai intermitentemente |
| P2SDiagnosticLog | Conexões P2S, atribuição de IPs, falhas IKEv2/SSTP | Clientes P2S não conseguem ligar |
| RouteDiagnosticLog | Rotas aprendidas via BGP, flaps | Rotas BGP em falta ou instáveis |
10.3 Packet Capture
O Azure Network Watcher permite capturar pacotes dentro da VNet para debug de tráfego pós-túnel:
# Configurar packet capture
$nw = Get-AzNetworkWatcher -Name "NetworkWatcher_westeurope"
$vm = Get-AzVM -Name "vm-app-01" -ResourceGroupName "rg-pme-hub"
$storage = "/subscriptions/.../storageAccounts/captures"
New-AzNetworkWatcherPacketCapture `
-NetworkWatcher $nw `
-TargetVirtualMachineId $vm.Id `
-PacketCaptureName "capture-vpn-debug" `
-CaptureLimitInBytes 100000000 `
-CaptureTimeLimitInSeconds 300 `
-StorageAccountId $storage
11. IPsec/IKE Policies Personalizadas
Por defeito, o Azure VPN Gateway negoceia IPsec com parâmetros predefinidos. Em alguns cenários — compatibilidade com dispositivos legados, requisitos de compliance, ou para forçar cifras mais fortes — é necessário definir uma policy IPsec/IKE personalizada.
11.1 Definir policy personalizada (PowerShell)
# Policy IPsec personalizada
$ipsecPolicy = New-AzIpsecPolicy `
-IkeEncryption AES256 `
-IkeIntegrity SHA384 `
-DhGroup ECP384 `
-IpsecEncryption GCMAES256 `
-IpsecIntegrity GCMAES256 `
-PfsGroup ECP384 `
-SaLifeTimeSeconds 27000 `
-SaDataSizeKilobytes 102400000
# Aplicar a uma conexão existente
$conn = Get-AzVirtualNetworkGatewayConnection `
-Name "conn-s2s-pme" -ResourceGroupName "rg-pme-hub"
Set-AzVirtualNetworkGatewayConnection `
-VirtualNetworkGatewayConnection $conn `
-IpsecPolicies $ipsecPolicy
Os parâmetros IPsec devem ser idênticos em ambos os lados do túnel. Uma mismatch em DH group, PFS, ou algoritmo de encriptação impede a negociação IKE. Use a documentação oficial em IPsec/IKE policy parameters para a lista completa de combinações suportadas.
11.2 Tabela de parâmetros suportados
| Parâmetro | Valores suportados | Recomendado (2026) |
|---|---|---|
| IKE Encryption | AES128, AES192, AES256, DES3, GCMAES256 | AES256 ou GCMAES256 |
| IKE Integrity | SHA1, SHA256, SHA384, MD5 | SHA256 ou SHA384 |
| DH Group | DHGroup1-24, ECP256, ECP384 | ECP384 (Group 20) |
| IPsec Encryption | AES128-256, DES3, GCMAES128-256 | GCMAES256 |
| IPsec Integrity | SHA1-384, MD5, GCMAES128-256 | GCMAES256 |
| PFS Group | None, DHGroup1-24, ECP256, ECP384 | ECP384 (PFS Group 20) |
| SA Lifetime (s) | 27000 (padrão) — 14400 a 36000 | 27000 |
12. Erros Comuns e Soluções
| Sintoma | Causa provável | Solução |
|---|---|---|
| Túnel não estabelece (IKE Phase 1 falha) | PSK mismatch, IP peer incorrecto, portas UDP 500/4500 bloqueadas | Verificar PSK em ambos os lados; confirmar IP público do gateway; abrir UDP 500/4500 no firewall on-premises |
| IKE Phase 1 OK mas Phase 2 falha | Parâmetros IPsec mismatch (encryption, integrity, PFS) | Comparar Get-AzIpsecPolicy com config do dispositivo; alinhar DH/PFS group |
| Túnel estabelece mas sem tráfego | Routes em falta, NAT aplicado ao tráfego do túnel, security policy bloqueia | Adicionar UDR para rede on-premises; desactivar NAT para prefixos da VNet; verificar NSG |
| Túnel cai intermitentemente | DPD desactivado, SA Lifetime mismatch, packet loss | Activar DPD (Dead Peer Detection); alinhar SA Lifetime; verificar latência e perda |
| BGP peer não estabelece | ASN incorrecto, BGP IP em uso, filtros de rota | Confirmar ASN em ambos os lados; verificar BGP IP único; usar Get-AzVirtualNetworkGatewayBGPPeerStatus |
| P2S cliente não obtém IP | Address pool esgotado, certificado expirado, IKEv2 não suportado no cliente | Expandir address pool; renovar certificado root; verificar suporte IKEv2 no OS cliente |
| Latência alta no túnel | SKU básico (Basic), tráfego através de região distante | Upgrade para VpnGw2+; usar Azure region mais próxima; considerar ExpressRoute |
| Throughput baixo | SKU insuficiente, PFS demasiado pesado, MTU/MSS | Upgrade SKU; ajustar PFS para DHGroup14; verificar MSS clamping |
13. RFC, Compatibilidade e Limites Técnicos
13.1 RFCs relevantes
| RFC | Título | Relevância para VPN Gateway |
|---|---|---|
| RFC 4301 | Security Architecture for IP | Arquitetura base IPsec |
| RFC 7296 | Internet Key Exchange (IKEv2) | Protocolo de negociação IKE |
| RFC 4106 | GCM for IPsec ESP | Encriptação GCMAES256 |
| RFC 7384 | ASN.1 for IKE | ASN de BGP |
| RFC 8229 | TCP Encapsulation of IKE and IPsec | NAT-T sobre TCP (não suportado no Azure) |
13.2 Limites técnicos
| Recurso | Limite | Notas |
|---|---|---|
| Conexões S2S por gateway | 30 (Basic) / 30 (VpnGw1-5) / 100 (VpnGw1-5AZ) | Inclui P2S + S2S |
| Conexões P2S por gateway | 128 (Basic) / 1000-10000 (VpnGw1-5) | Depende do SKU |
| BGP peers por gateway | 10 | Por instância |
| Rotas BGP por gateway | 1000 (Basic) / 4000 (VpnGw1-5) | Prefixos aprendidos |
| Throughput agregado | 100 Mbps (Basic) / 1.25 Gbps (VpnGw5) | Por túnel, não agregado |
Para a lista completa e actualizada de limites, consulte VPN Gateway limits — Microsoft Learn.
14. Checklist Final de Implementação
Planeamento
- ☐ Escolher SKU adequado (VpnGw2 para produção, VpnGw1 para dev/test)
- ☐ Reservar /28 para GatewaySubnet (necessário, não pode ser alterado)
- ☐ Confirmar que o IP público é Standard (não Basic) para Generation2
- ☐ Verificar que as prefixos on-prem e VNet não se sobrepõem
Configuração S2S
- ☐ Criar VNet e GatewaySubnet
- ☐ Criar IP público e VPN Gateway (RouteBased, Generation2)
- ☐ Criar Local Network Gateway com IP público on-prem e prefixos
- ☐ Criar Connection com PSK forte (32+ caracteres)
- ☐ Configurar dispositivo on-prem (FortiGate/DrayTek/OPNsense) com parâmetros idênticos
- ☐ Abrir UDP 500 e 4500 no firewall on-prem
BGP (opcional)
- ☐ Definir ASN único (65515 é o default Azure, usar outro se multi-site)
- ☐ Configurar BGP IP no gateway (ex: 10.20.0.254)
- ☐ Activar BGP na connection
- ☐ Configurar BGP no dispositivo on-prem (FRR no OPNsense, BGP no FortiGate)
Diagnóstico
- ☐ Activar diagnostic settings (IKE, Gateway, P2S logs) para Log Analytics
- ☐ Configurar alertas: ConnectionStatus != Connected → email/Teams
- ☐ Documentar parâmetros IPsec (PSK em cofre de passwords, ex: HashiCorp Vault)
P2S (se aplicável)
- ☐ Gerar certificado root e cliente (ou usar Entra ID)
- ☐ Configurar address pool (não sobreposto com VNet nem on-prem)
- ☐ Testar conexão com Microsoft VPN client
usão para o range 10.20.0.0/16; no DrayTek, o campo NAT Mode em VPN LAN-to-LAN deve estar em No NAT. Se o tráfego chegar ao Azure com IP traduzido, a ligação aparenta estar up mas nada comunica.
