Konfigurera och kontrollera BGP i Sophos Firewall

BGP utbyter utvalda routes mellan routrar. I en Sophos Firewall är det särskilt användbart vid flera platser, redundanta anslutningar samt VPN till AWS eller Azure. För ett enskilt målnät med en fast Next Hop är en statisk route oftast enklare.

I följande exempel upprättar två Sophos Firewalls en eBGP-session via ett transitnät. Till slut står Neighbor i Established, Firewall A känner till LAN-nätet bakom Firewall B och omvänt.

⚠️ Dynamic Routing ska endast vara åtkomligt för den avsedda motparten. En ändring av Router ID avbryter alla BGP-sessioner; en ändring av Local AS tar dessutom bort alla konfigurerade Neighbors och Networks. Båda ändringarna hör därför hemma i ett planerat underhållsfönster med en aktuell backup.

BGP i sju steg

För en enkel IPv4-konfiguration krävs följande steg:

Fastställ transit-IP-adresser, lokalt och fjärranslutet ASN samt de nät som ska annonseras.
Kontrollera direkt IP-nåbarhet mellan de två BGP-peererna.
Tillåt under Administration > Device access Dynamic Routing endast för peer-zonen eller via en snäv Local Service ACL Exception.
Ange Router ID och Local AS under Routing > BGP.
Lägg till peer-IP-adressen som Neighbor med Remote AS.
Ange endast de lokala prefix som behövs under Networks.
Kontrollera under Routing > Information > BGP-IPv4 State Established, den inlärda routen och därefter verklig trafik.

Vad BGP avgör i brandväggen

BGP besvarar frågan vilka nät som kan nås via vilken router. Varje deltagare behöver därför några tydligt åtskilda värden:

Local AS betecknar det egna autonoma systemet. Två olika ASN bildar en eBGP-anslutning; samma ASN på båda sidor skulle vara iBGP.
Remote AS är motpartens ASN.
Router ID identifierar BGP-routern i BGP-topologin. Det ser ut som en IPv4-adress, men behöver inte vara en interfaceadress och ska förbli unikt och stabilt.
En Neighbor är den direkt nåbara peer-IP-adress som BGP-sessionen byggs mot.
Ett Network är ett lokalt prefix som brandväggen ska annonsera till motparten.

BGP tillåter ingen nyttotrafik och krypterar den inte. Själva BGP-sessionen upprättas över TCP 179 och tillåts till brandväggen via Device Access eller en Local Service ACL. Nyttotrafiken över en inlärd route kräver fortfarande lämpliga brandväggsregler, en fungerande returväg och, beroende på designen, en medveten NAT-konfiguration.

För dynamisk routing inom en sammanhängande intern routingdomän är OSPF ofta mer naturligt. BGP passar bättre mellan olika autonoma system, mot molnleverantörer eller när routes måste påverkas selektivt med policyer.

Planera exempeltopologin

Exemplet använder två platser:

Firewall A: Local AS 65010, Router ID 192.0.2.10, transit-IP 198.51.100.1/30, LAN 10.10.10.0/24
Firewall B: Local AS 65020, Router ID 192.0.2.20, transit-IP 198.51.100.2/30, LAN 10.20.20.0/24
Transitnät: 198.51.100.0/30

Intervallen 192.0.2.0/24 och 198.51.100.0/24 är dokumentationsnät. De ersätts med miljöns faktiska värden. De två privata ASN-värdena passar ett internt exempel; vid en anslutning till AWS, Azure eller en leverantör används de ASN- och peer-värden som motparten anger.

Router ID ska väljas medvetet och vara unikt och stabilt. Med Automatic använder SFOS den högsta interface-IP-adressen. Om den ändras senare kan även routerns identitet ändras oväntat. Ett manuellt värde undviker detta beroende.

Förbered BGP säkert

Följande ska vara uppfyllt före konfigurationen:

Brandväggen körs i Gateway Mode. BGP är inte tillgängligt i Transparent Mode.
De båda transit-IP-adresserna når varandra direkt. Med en XFRM-tunnel måste även tunnelinterfacet vara uppe.
Local AS, Remote AS, peer-IP-adresser och tillåtna prefix har stämts av med motparten.
De nät som ska annonseras finns redan som motsvarande routes i den lokala routningstabellen.
En aktuell konfigurationsbackup och en oberoende managementåtkomst finns tillgängliga.
Brandväggsregler och returvägar för den senare nyttotrafiken är planerade.

Grunderna för transitinterface och zon förklaras i Konfigurera zoner och interface i Sophos Firewall. Före en ändring i en produktiv routingmiljö ska det dessutom finnas en aktuell brandväggsbackup utanför appliance-enheten.

Tillåt Dynamic Routing selektivt

Under Administration > Device access är Dynamic Routing som standard avstängt för alla zoner. För ett separat nät som endast används som transit kan tjänsten aktiveras i dess zon.

Om peer-interfacet delar sin LAN- eller WAN-zon med andra nät är en Local Service ACL Exception för den konkreta peer-IP-adressen eller det snäva transitnätet säkrare än att tillåta hela zonen. Under Administration > Device access > Local service ACL exception rule > Add skapas en Accept-regel för peer-zonen, den konkreta peer-IP-adressen eller det snäva transitnätet, den brandväggsadress som behövs och tjänsten Dynamic Routing. Testa därefter åtkomst från den tillåtna peer-IP-adressen och från en otillåten källa.

Device Access styr endast BGP-anslutningen till brandväggen. De produktiva anslutningarna mellan de två LAN-näten behöver därefter vanliga brandväggsregler. Skillnaden förklaras i Säkra Device Access i Sophos Firewall.

Konfigurera BGP i WebAdmin

Följande steg utförs på båda brandväggarna. Endast lokala och fjärranslutna värden byter plats.

1. Ange Router ID och Local AS

Ange följande värden på Firewall A i Global configuration under Routing > BGP:

Om det redan finns en BGP-konfiguration måste det aktuella läget dokumenteras innan ändringen tillämpas: ett ändrat Router ID återställer alla BGP-sessioner; ett ändrat Local AS tar bort alla Neighbors och Networks. Sådana ändringar tillämpas endast i ett planerat underhållsfönster.

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

På Firewall B används också Manual samt 192.0.2.20 och 65020. Tillämpa därefter den globala konfigurationen.

Local AS accepterar värden från 1 till 4294967295. För interna miljöer utan publikt ASN anger Sophos det privata intervallet 64512 till 65535.

2. Lägg till motparten som Neighbor

Klicka på Add under Routing > BGP > Neighbors och ange följande på Firewall A:

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

Firewall B använder 198.51.100.1 som Neighbor och 65010 som Remote AS. Spara därefter på respektive brandvägg med Save.

Neighbor-adressen är inte det fjärranslutna LAN-nätet eller Router ID, utan motpartens direkt nåbara transit-IP-adress. Om IP-adressen inte kan nås eller ASN-värdena har förväxlats kan sessionen inte nå Established.

3. Annonsera lokalt LAN

Klicka på Add under Routing > BGP > Networks. Firewall A annonserar:

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

På Firewall B anges i stället 10.20.20.0 och 255.255.255.0 (/24).

Ett Network skapar ingen route. Prefixet måste redan finnas exakt i den lokala routningstabellen, till exempel som ett direktanslutet nät eller en statisk route. Om det saknas eller nätmasken inte stämmer kan BGP-sessionen ändå vara Established, men Network annonseras inte.

Endast prefix som faktiskt behövs ska anges. En generell redistribution av direktanslutna eller statiska routes kan även omfatta WAN-, management- eller Blackhole-nät och hör endast hemma i produktion med verifierad filtrering.

Kontrollera och verifiera BGP

En upprättad session bekräftar inte ensam ett fungerande paketflöde. Verifieringen sker därför på flera nivåer:

Under Routing > Information > BGP-IPv4 > Neighbors ska motparten visas med State Established.
Under Routes förväntar sig Firewall A prefixet 10.20.20.0/24; Firewall B förväntar sig 10.10.10.0/24.
Under Summary kontrolleras sessionen och antalet mottagna prefix.
Under Diagnostics > Tools > Route lookup kontrolleras till exempel målet 10.20.20.10 på Firewall A.
Därefter testas en verklig tjänst mellan en värd i respektive LAN. Log Viewer och Packet Capture ska visa förväntad regel, rätt transitinterface och returtrafik.

En Neighbor i Established bevisar endast att BGP-utbytet fungerar. Först den inlärda routen, korrekt Route Lookup och en verklig anslutning bekräftar hela konfigurationen. För kontroll av paketflödet hjälper Testa en Sophos Firewall-regel med Log Viewer och Packet Capture.

Samma exempel via CLI

Som ett alternativ till WebAdmin kan samma grundkonfiguration anges i BGP-CLI efter SSH-inloggning. Följande kommandon körs inte dessutom i en redan färdigkonfigurerad exempelmiljö. Menysökvägen är:

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

På Firewall A ser det fullständiga exemplet ut så här:

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

På Firewall B ersätts Local AS, Router ID, Neighbor, Remote AS och Network med 65020, 192.0.2.20, 198.51.100.1, 65010 respektive 10.20.20.0/24.

show running-config används för kontroll. write sparar CLI-konfigurationen permanent, gör posterna synliga i WebAdmin och bevarar dem efter en omstart. Utan write är ändringen inte fullständigt avslutad.

Den ytterligare officiellt dokumenterade kontrollen är:

show ip bgp

Den visar kända BGP-prefix och deras sökvägsinformation. Neighbor State och Summary kontrolleras tillförlitligt under Routing > Information > BGP-IPv4.

⚠️ Blanda inte avancerad CLI-konfiguration och WebAdmin utan kontroll. Om en Neighbor redigeras i WebAdmin kan ytterligare CLI-värden, till exempel ett Neighbor-lösenord eller en Route Map, tas bort. När sådana inställningar används ska först show running-config sparas och BGP-konfigurationen därefter hanteras vidare via CLI.

Route Precedence och BGP:s sökvägsval

system route_precedence avgör inte mellan BGP och en statisk route. Den globala inställningen ordnar endast kategorierna static, sdwan_policyroute och vpn; BGP och andra dynamiska routes hör då till kategorin static.

Mellan olika routingprotokoll avgör bland annat Administrative Distance. Inom BGP utvärderas BGP-attribut. Sophos anger exempelvis att en högre Weight föredras; för i övrigt jämförbara vägar föredras ett lägre MED.

Den aktuella globala ordningen kan visas i 4. Device Console:

system route_precedence show

Den ska endast ändras när olika routingkategorier faktiskt konkurrerar. Sambanden och säkra exempel förklaras i Justera routingprioritet i Sophos Firewall.

BGP över route-based IPsec och Cloud VPN

BGP kan köras över ett adresserat XFRM-interface i en route-based Site-to-Site IPsec-tunnel. Båda XFRM-interfacen får då lämpliga transit-IP-adresser. Dynamic Routing tillåts selektivt för VPN-zonen; regler för nyttotrafiken krävs ändå.

Vid molnanslutningar väljs värdena inte fritt:

För AWS Site-to-Site VPN kommer Inside Tunnel-adresser, Remote AS och andra tunnelvärden från AWS-konfigurationen. Båda AWS-tunnlarna kontrolleras separat.
Med Azure VPN Gateway måste den lokala XFRM-IP-adressen stämma med avsedd BGP-peer-IP; lokalt ASN och Azure-ASN måste vara olika.

En grön IPsec-tunnel och en BGP Neighbor i Established är två separata kontrollpunkter. Därefter måste förväntade prefix och verklig applikationstrafik fungera.

Avgränsa fel systematiskt

Neighbor stannar i Active eller visas inte

Active betyder inte att sessionen fungerar aktivt. Brandväggen fortsätter att försöka upprätta en BGP-anslutning. Kontrollera först direkt nåbarhet till peer-IP-adressen, interface- och tunnelstatus, Local AS, Remote AS samt Neighbor-IP. Kontrollera därefter om Dynamic Routing är tillåtet i rätt zon eller via en lämplig Local Service ACL Exception.

Med XFRM ska det också säkerställas att båda tunneladresserna stämmer och att IPsec-tunneln är uppe. För moln- och XFRM-konfigurationer kontrolleras dessutom de regler som ingår i respektive VPN-design. Om deras Services är begränsade måste TCP 179 ingå mellan de två peer-IP-adresserna. Device Access eller Local Service ACL för den lokala BGP-tjänsten är fortfarande separat från detta.

Neighbor är Established, men fjärrnätet saknas

Sessionen fungerar då, men prefixet annonseras eller accepteras inte. På den sändande brandväggen måste Network med exakt samma nätmask finnas i den lokala routningstabellen. Kontrollera därefter Networks, filter och show running-config. En lokal route som saknas ska åtgärdas och inte döljas genom att BGP Network Import Check inaktiveras.

Om ett nät bakom en policybaserad IPsec-tunnel saknas efter en uppgradering till SFOS 22 kan det tidigare beroendet av redistribute kernel vara orsaken. BGP-sessionen kan ändå förbli Established; SFOS 22: IPsec-rutter och redistribute kernel förklarar versionsändringen och måldesignen med route-based XFRM.

BGP-routen är synlig, men används inte

Kontrollera först med Route Lookup vilken route som vinner för en konkret mål-IP-adress. En mer specifik route har företräde framför ett bredare prefix. Om flera källor konkurrerar ska Administrative Distance, BGP-attribut och först därefter den globala Route Precedence-kategorin bedömas separat.

Routen stämmer, men trafiken fungerar inte

BGP har slutfört sin uppgift när rätt route är installerad. Därefter finns felet oftast i brandväggsregeln, NAT, returvägen eller målsystemet. För normalt routade platsnät behövs ofta ingen SNAT eftersom båda sidor ska känna till de verkliga LAN-prefixen.

Avancerade inställningar försvann efter en ändring i WebAdmin

WebAdmin visar endast grundvärdena. Om en Neighbor sparades där efter en avancerad CLI-konfiguration kan lösenord, Route Map eller ändrade standardvärden ha tagits bort. Jämför med den sparade konfigurationen, återställ värdena via CLI och spara med write.

Kontrollera BGP- och routingloggar

I 5. Device Management > 3. Advanced Shell visar två loggfiler de olika nivåerna:

tail -f /log/bgpd.log

bgpd.log loggar BGP- och BGPv6-händelser. Den löpande utmatningen avslutas med Ctrl+C. Om BGP känner till en route, men den inte visas i systemet, används:

tail -f /log/zebra.log

Den som inte vill följa loggen live kan till exempel använda:

less /log/bgpd.log

Med route-based IPsec kan /log/xfrmi.log dessutom förklara XFRM-interfacets status. Tilldelningen av ytterligare filer finns i Sophos Firewall-tjänster och loggfiler.

Återställ ändringen säkert

Innan BGP tas bort måste det finnas en alternativ väg eller ett underhållsfönster för varje inlärt målnät. Först tas berörda Networks och Neighbors bort, därefter ändras den globala BGP-konfigurationen endast om inga andra peers är beroende av den. Dynamic Routing får inte avaktiveras förrän zonen inte längre behöver någon annan dynamisk routingtjänst.

Därefter kontrolleras Routing Information, Route Lookup, managementåtkomst och verklig trafik igen. En rollback är inte klar förrän inte bara BGP-sessionen har försvunnit, utan alla nödvändiga målnät fortfarande kan nås via den avsedda ersättningsvägen.