Configurar e verificar BGP na Sophos Firewall

O BGP troca rotas selecionadas entre routers. Numa Sophos Firewall, é especialmente útil com várias localizações, ligações redundantes e VPNs para AWS ou Azure. Para uma única rede de destino com um Next Hop fixo, uma rota estática continua normalmente a ser mais simples.

No exemplo seguinte, duas Sophos Firewalls estabelecem uma sessão eBGP através de uma rede de trânsito. No final, o Neighbor apresenta Established, a Firewall A conhece a LAN atrás da Firewall B e vice-versa.

⚠️ Dynamic Routing deve estar acessível apenas à contraparte prevista. Uma alteração ao Router ID interrompe todas as sessões BGP; uma alteração à Local AS elimina adicionalmente todos os Neighbors e Networks configurados. Ambas pertencem, por isso, a uma janela de manutenção planeada com um backup atual.

BGP em sete passos

Para uma configuração IPv4 simples, são necessários estes passos:

Definir IPs de trânsito, ASN local e remoto e redes a anunciar.
Verificar a acessibilidade IP direta entre os dois peers BGP.
Em Administration > Device access, permitir Dynamic Routing apenas para a zona do peer ou através de uma Local Service ACL Exception restrita.
Em Routing > BGP, definir Router ID e Local AS.
Adicionar o IP do peer como Neighbor com a Remote AS.
Introduzir em Networks apenas os prefixos locais necessários.
Em Routing > Information > BGP-IPv4, verificar o State Established, a rota aprendida e, em seguida, tráfego real.

O que o BGP decide na firewall

O BGP responde à pergunta sobre que redes são alcançáveis através de que router. Para isso, cada participante precisa de alguns valores claramente distintos:

A Local AS identifica o próprio sistema autónomo. Dois ASN diferentes formam uma ligação eBGP; o mesmo ASN em ambos os lados seria iBGP.
A Remote AS é o ASN da contraparte.
O Router ID identifica o router BGP na topologia BGP. Tem o formato de um endereço IPv4, mas não tem de ser um endereço de interface e deve permanecer único e estável.
Um Neighbor é o IP do peer diretamente alcançável com o qual se estabelece a sessão BGP.
Uma Network é um prefixo local que a firewall deve anunciar à contraparte.

O BGP não autoriza tráfego útil nem o encripta. A própria sessão BGP é estabelecida através de TCP 179 e autorizada para a firewall por Device Access ou por uma Local Service ACL. O tráfego útil através de uma rota aprendida continua a exigir regras firewall adequadas, um caminho de retorno funcional e, conforme o design, uma configuração NAT deliberada.

Para routing dinâmico dentro de um domínio de routing interno contínuo, OSPF é muitas vezes mais natural. O BGP é mais adequado entre sistemas autónomos diferentes, para fornecedores cloud ou quando as rotas precisam de ser influenciadas seletivamente por políticas.

Planear a topologia de exemplo

O exemplo utiliza duas localizações:

Firewall A: Local AS 65010, Router ID 192.0.2.10, IP de trânsito 198.51.100.1/30, LAN 10.10.10.0/24
Firewall B: Local AS 65020, Router ID 192.0.2.20, IP de trânsito 198.51.100.2/30, LAN 10.20.20.0/24
Rede de trânsito: 198.51.100.0/30

Os intervalos 192.0.2.0/24 e 198.51.100.0/24 são redes de documentação. Devem ser substituídos pelos valores reais do ambiente. Os dois ASN privados são adequados para um exemplo interno; numa ligação a AWS, Azure ou a um fornecedor, utilizam-se os valores de ASN e peer definidos pela contraparte.

O Router ID deve ser escolhido conscientemente, ser único e estável. Com Automatic, o SFOS utiliza o IP de interface mais elevado. Se este mudar mais tarde, a identidade do router também pode mudar inesperadamente. Um valor manual evita esta dependência.

Preparar o BGP com segurança

Antes da configuração, devem estar cumpridos os seguintes pontos:

A firewall funciona em Gateway Mode. O BGP não está disponível em Transparent Mode.
Ambos os IPs de trânsito alcançam-se diretamente. Num túnel XFRM, a interface de túnel também deve estar up.
Local AS, Remote AS, IPs dos peers e prefixos permitidos estão coordenados com a contraparte.
As redes a anunciar já existem como rotas correspondentes na tabela de routing local.
Estão disponíveis um backup de configuração atual e um acesso de management independente.
Foram planeadas regras firewall e caminhos de retorno para o tráfego útil posterior.

Os fundamentos da interface de trânsito e da zona são explicados em Configurar zonas e interfaces da Sophos Firewall. Antes de uma alteração num ambiente de routing produtivo, também deve estar disponível fora da appliance um backup atual da firewall.

Autorizar Dynamic Routing de forma seletiva

Em Administration > Device access, Dynamic Routing está desativado por predefinição para todas as zonas. Numa rede própria utilizada exclusivamente como trânsito, o serviço pode ser ativado na respetiva zona.

Se a interface do peer partilhar a sua zona LAN ou WAN com outras redes, uma Local Service ACL Exception para o IP concreto do peer ou para a rede de trânsito restrita é mais segura do que a autorização ampla da zona. Em Administration > Device access > Local service ACL exception rule > Add, cria-se uma regra Accept para a zona do peer, o IP concreto do peer ou a rede de trânsito restrita, o endereço necessário da firewall e o serviço Dynamic Routing. Depois, testa-se o acesso a partir do IP do peer permitido e de uma origem não permitida.

Device Access controla apenas a ligação BGP à firewall. As ligações produtivas entre as duas LANs continuam a precisar de regras firewall normais. Esta separação é explicada em Proteger Device Access na Sophos Firewall.

Configurar BGP no WebAdmin

Os passos seguintes são executados em ambas as firewalls. Apenas se trocam os valores locais e remotos.

1. Definir Router ID e Local AS

Em Routing > BGP, introduzir em Global configuration na Firewall A os seguintes valores:

Se já existir uma configuração BGP, o estado atual deve ser documentado antes de aplicar a alteração: um Router ID alterado reinicia todas as sessões BGP; uma Local AS alterada elimina todos os Neighbors e Networks. Estas alterações só são aplicadas numa janela de manutenção planeada.

Router ID assignment: Manual
Router ID: 192.0.2.10
Local AS: 65010

Na Firewall B também se utiliza Manual, bem como 192.0.2.20 e 65020. Em seguida, aplica-se a configuração global.

A Local AS aceita valores de 1 a 4294967295. Para ambientes internos sem ASN público, a Sophos indica o intervalo privado de 64512 a 65535.

2. Adicionar a contraparte como Neighbor

Em Routing > BGP > Neighbors, selecionar Add e introduzir na Firewall A:

IP version: IPv4
IP address: 198.51.100.2
Remote AS: 65020

A Firewall B utiliza 198.51.100.1 como Neighbor e 65010 como Remote AS. Depois, guardar em cada firewall com Save.

O endereço do Neighbor não é a LAN remota nem o Router ID, mas sim o IP de trânsito diretamente alcançável da contraparte. Se este IP não estiver acessível ou os ASN estiverem trocados, a sessão não consegue alcançar Established.

3. Anunciar a LAN local

Em Routing > BGP > Networks, selecionar Add. A Firewall A anuncia:

IP version: IPv4
IP address: 10.10.10.0
Subnet mask: 255.255.255.0 (/24)

Na Firewall B, introduzem-se em vez disso 10.20.20.0 e 255.255.255.0 (/24).

Uma Network não cria uma rota. O prefixo tem de existir exatamente na tabela de routing local, por exemplo como rede diretamente ligada ou rota estática. Se faltar ou a máscara não corresponder, a sessão BGP pode ficar Established, mas a Network não é anunciada.

Só devem ser introduzidos os prefixos realmente necessários. Uma redistribution geral de rotas diretamente ligadas ou estáticas pode também incluir redes WAN, de management ou Blackhole e só deve ser usada em produção com filtragem verificada.

Verificar e validar o BGP

Uma sessão estabelecida não confirma por si só um fluxo de pacotes funcional. A validação é, por isso, feita em vários níveis:

Em Routing > Information > BGP-IPv4 > Neighbors, a contraparte deve aparecer com o State Established.
Em Routes, a Firewall A deve receber o prefixo 10.20.20.0/24; a Firewall B deve receber 10.10.10.0/24.
Em Summary, verificam-se a sessão e o número de prefixos recebidos.
Em Diagnostics > Tools > Route lookup, verifica-se na Firewall A, por exemplo, o destino 10.20.20.10.
Depois, testa-se um serviço real entre um host de cada LAN. Log Viewer e Packet Capture devem mostrar a regra esperada, a interface de trânsito correta e o tráfego de retorno.

Um Neighbor com Established prova apenas que a troca BGP funciona. Só a rota aprendida, o Route Lookup correto e uma ligação real confirmam toda a configuração. Para verificar o fluxo de pacotes, é útil testar uma regra da Sophos Firewall com Log Viewer e Packet Capture.

O mesmo exemplo através da CLI

Como alternativa ao WebAdmin, a mesma configuração base pode ser introduzida na CLI BGP depois da ligação SSH. Os comandos seguintes não são aplicados adicionalmente a um ambiente de exemplo já configurado. O caminho do menu é:

3. Route Configuration > 1. Configure Unicast Routing > 3. Configure BGP

Na Firewall A, o exemplo completo é o seguinte:

enable
configure terminal
router bgp 65010
bgp router-id 192.0.2.10
neighbor 198.51.100.2 remote-as 65020
address-family ipv4 unicast
network 10.10.10.0/24
exit
show running-config
write
end

Na Firewall B, Local AS, Router ID, Neighbor, Remote AS e Network são substituídos respetivamente por 65020, 192.0.2.20, 198.51.100.1, 65010 e 10.20.20.0/24.

show running-config serve para controlo. write guarda permanentemente a configuração CLI, torna as entradas visíveis no WebAdmin e conserva-as depois de um reinício. Sem write, a alteração não fica completamente concluída.

A verificação adicional oficialmente documentada é:

show ip bgp

Mostra os prefixos BGP conhecidos e as respetivas informações de caminho. O estado do Neighbor e Summary são verificados de forma fiável em Routing > Information > BGP-IPv4.

⚠️ Não misturar sem controlo configuração CLI avançada e WebAdmin. Editar um Neighbor no WebAdmin pode remover valores CLI adicionais, como uma palavra-passe do Neighbor ou uma Route Map. Assim que se utilizem estas definições, deve guardar-se primeiro show running-config e continuar a gerir a configuração BGP através da CLI.

Route Precedence e seleção de caminho BGP

system route_precedence não decide entre BGP e uma rota estática. A definição global ordena apenas as categorias static, sdwan_policyroute e vpn; BGP e outras rotas dinâmicas pertencem à categoria static.

Entre diferentes protocolos de routing, um dos fatores de decisão é a Administrative Distance. Dentro do BGP, são avaliados atributos BGP. A Sophos indica, por exemplo, que um Weight mais elevado é preferido; em caminhos de resto comparáveis, é preferido um MED mais baixo.

A ordem global atual pode ser apresentada em 4. Device Console:

system route_precedence show

Só deve ser alterada quando existirem realmente categorias de routing concorrentes. As relações e os exemplos seguros são explicados em Ajustar a prioridade de routing na Sophos Firewall.

BGP através de route-based IPsec e Cloud VPN

O BGP pode funcionar através de uma interface XFRM endereçada de um túnel Site-to-Site IPsec route-based. Para isso, ambas as interfaces XFRM recebem IPs de trânsito adequados. Dynamic Routing é permitido seletivamente para a zona VPN; as regras para o tráfego útil continuam a ser necessárias.

Nas ligações cloud, os valores não são escolhidos livremente:

Para AWS Site-to-Site VPN, os endereços Inside Tunnel, Remote AS e outros valores de túnel provêm da configuração AWS. Ambos os túneis AWS são verificados separadamente.
No Azure VPN Gateway, o IP XFRM local deve corresponder ao IP de peer BGP previsto; o ASN local e o ASN Azure têm de ser diferentes.

Um túnel IPsec verde e um BGP Neighbor com Established são dois pontos de verificação separados. Depois, os prefixos esperados e o tráfego real da aplicação devem funcionar.

Diagnosticar erros sistematicamente

Neighbor permanece em Active ou não aparece

Active não significa que a sessão esteja ativamente funcional. A firewall continua a tentar estabelecer uma ligação BGP. Primeiro, verificar a acessibilidade direta do IP do peer, o estado da interface e do túnel, Local AS, Remote AS e o IP do Neighbor. Depois, confirmar se Dynamic Routing está permitido na zona correta ou através de uma Local Service ACL Exception adequada.

Com XFRM, confirmar também que ambos os endereços do túnel estão corretos e que o túnel IPsec está up. Em implementações cloud e XFRM, também se verificam as regras previstas no respetivo design VPN. Se os respetivos Services forem restritos, devem incluir TCP 179 entre os dois IPs dos peers. Device Access ou a Local Service ACL para o serviço BGP local continua separado destas regras.

Neighbor está Established, mas falta a rede remota

Nesse caso, a sessão funciona, mas o prefixo não é anunciado ou não é aceite. Na firewall emissora, a Network deve existir com exatamente a mesma máscara na tabela de routing local. Depois, verificar Networks, filtros e show running-config. Uma rota local em falta deve ser corrigida e não ocultada através da desativação de BGP Network Import Check.

Se, após uma atualização para o SFOS 22, faltar uma rede atrás de um túnel IPsec policy-based, a causa pode ser a dependência anterior de redistribute kernel. A sessão BGP pode continuar em Established; SFOS 22: rotas IPsec e redistribute kernel explica a alteração da versão e o design XFRM route-based de destino.

A rota BGP está visível, mas não é utilizada

Primeiro, utilizar Route Lookup para verificar que rota vence para um IP de destino concreto. Uma rota mais específica tem prioridade sobre um prefixo mais amplo. Quando várias origens concorrem, a Administrative Distance, os atributos BGP e só depois a categoria global de Route Precedence devem ser avaliados separadamente.

A rota está correta, mas o tráfego não funciona

O BGP cumpriu a sua função assim que a rota correta está instalada. Depois disso, os erros encontram-se normalmente na regra firewall, NAT, caminho de retorno ou sistema de destino. Em redes entre localizações com routing normal, muitas vezes não é necessário SNAT, porque ambos os lados devem conhecer os prefixos LAN reais.

Definições avançadas desapareceram após uma edição no WebAdmin

O WebAdmin representa apenas os valores básicos. Se um Neighbor tiver sido guardado no WebAdmin depois de uma configuração CLI avançada, podem ter sido removidos a palavra-passe, a Route Map ou valores predefinidos alterados. Comparar o estado guardado, restaurar os valores através da CLI e guardar com write.

Verificar logs de BGP e routing

Em 5. Device Management > 3. Advanced Shell, dois logs mostram os diferentes níveis:

tail -f /log/bgpd.log

bgpd.log regista eventos BGP e BGPv6. A saída contínua termina com Ctrl+C. Se o BGP conhecer uma rota, mas esta não aparecer no sistema, utilizar:

tail -f /log/zebra.log

Para não acompanhar em tempo real, utilizar por exemplo:

less /log/bgpd.log

Em route-based IPsec, /log/xfrmi.log pode explicar adicionalmente o estado da interface XFRM. A correspondência de outros ficheiros encontra-se em Serviços e ficheiros de log da Sophos Firewall.

Reverter a alteração com segurança

Antes de remover o BGP, deve existir um caminho alternativo ou uma janela de manutenção para cada rede de destino aprendida. Primeiro removem-se as Networks e os Neighbors afetados; depois, a configuração BGP global só é alterada se não dependerem dela outros peers. Dynamic Routing só pode ser desativado quando a zona já não precisar de outro serviço de routing dinâmico.

Em seguida, voltam a verificar-se Routing Information, Route Lookup, acesso de management e tráfego real. Um rollback só está concluído quando não apenas desapareceu a sessão BGP, mas também todas as redes de destino necessárias continuam alcançáveis através do caminho alternativo previsto.