Sophos Firewall BGP configureren en controleren

BGP wisselt geselecteerde routes tussen routers uit. Op een Sophos Firewall is dit vooral zinvol bij meerdere locaties, redundante verbindingen en AWS- of Azure-VPN’s. Voor één doelnetwerk met een vaste Next Hop blijft een statische route meestal eenvoudiger.

In het volgende voorbeeld bouwen twee Sophos Firewalls via een transitnetwerk een eBGP-sessie op. Aan het einde staat de Neighbor op Established, kent Firewall A het LAN achter Firewall B en omgekeerd.

⚠️ Dynamic Routing mag alleen voor de bedoelde tegenpartij bereikbaar zijn. Een wijziging van de Router ID onderbreekt alle BGP-sessies; een wijziging van de Local AS verwijdert bovendien alle geconfigureerde Neighbors en Networks. Beide wijzigingen horen daarom in een gepland onderhoudsvenster met een actuele back-up.

BGP in zeven stappen

Voor een eenvoudige IPv4-opstelling zijn de volgende stappen nodig:

1. Transit-IP’s, lokale en externe ASN’s en de te adverteren netwerken vastleggen.
2. De directe IP-bereikbaarheid tussen beide BGP-peers controleren.
3. Onder Administration > Device access Dynamic Routing alleen voor de peerzone of via een strikte Local Service ACL Exception toestaan; controleer de benodigde firewallregels afzonderlijk.
4. Onder Routing > BGP Router ID en Local AS instellen.
5. Het peer-IP als Neighbor met de Remote AS toevoegen.
6. Alleen de benodigde lokale prefixen onder Networks invoeren.
7. Onder Routing > Information > BGP-IPv4 de State Established, de geleerde route en vervolgens echt verkeer controleren.

Wat BGP op de firewall beslist

BGP beantwoordt de vraag welke netwerken via welke router bereikbaar zijn. Daarvoor heeft elke deelnemer enkele duidelijk gescheiden waarden nodig:

• De Local AS duidt het eigen autonome systeem aan. Twee verschillende ASN’s vormen een eBGP-verbinding; dezelfde ASN aan beide kanten zou iBGP zijn.
• De Remote AS is de ASN van de tegenpartij.
• De Router ID identificeert de BGP-router binnen de BGP-topologie. Deze ziet eruit als een IPv4-adres, maar hoeft geen interfaceadres te zijn en moet uniek en stabiel blijven.
• Een Neighbor is het IPv4- of IPv6-adres van de tegenpartij waarmee de BGP-sessie wordt opgebouwd. In het voorbeeld is dit het transit-IP.
• Een Network is een lokaal prefix dat de firewall aan de tegenpartij moet adverteren.

BGP staat geen gegevensverkeer toe en versleutelt dit niet. Dynamic Routing onder Device Access of een Local Service ACL regelt de lokale BGP-service. Verkeer dat de firewall via geleerde routes doorstuurt, vereist daarnaast passende firewallregels, een werkend retourpad en, afhankelijk van het ontwerp, een bewuste NAT-configuratie.

Voor dynamische routing binnen één samenhangend intern routingdomein ligt OSPF vaak meer voor de hand. BGP past beter tussen verschillende autonome systemen, naar cloudproviders of wanneer routes gericht met beleid moeten worden beïnvloed.

Voorbeeldtopologie plannen

Het voorbeeld gebruikt twee locaties:

• 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
• Transitnetwerk: 198.51.100.0/30

De reeksen 192.0.2.0/24 en 198.51.100.0/24 zijn documentatienetwerken. Ze worden vervangen door de werkelijke waarden van de omgeving. De twee private ASN’s zijn geschikt voor een intern voorbeeld; bij een verbinding met AWS, Azure of een provider worden de ASN- en peerwaarden gebruikt die de tegenpartij opgeeft.

De Router ID moet bewust worden gekozen, uniek en stabiel zijn. Bij Automatic gebruikt SFOS het hoogste interface-IP. Als dit later verandert, kan ook de identiteit van de router onverwacht wijzigen. Een handmatig ingestelde waarde voorkomt deze afhankelijkheid.

BGP veilig voorbereiden

Vóór de configuratie moet aan de volgende punten zijn voldaan:

• De firewall draait in Gateway Mode. In Transparent Mode is BGP niet beschikbaar.
• Beide transit-IP’s kunnen elkaar direct bereiken. Bij een XFRM-tunnel moet ook de tunnelinterface up zijn.
• Local AS, Remote AS, peer-IP’s en toegestane prefixen zijn met de tegenpartij afgestemd.
• De lokale routingtabel en de geplande Networks zijn gedocumenteerd, zodat elke aankondiging na de configuratie gericht kan worden gecontroleerd.
• Er zijn een actuele configuratieback-up en een onafhankelijke managementtoegang beschikbaar.
• Firewallregels en retourroutes voor het latere gegevensverkeer zijn gepland.

De basis voor transitinterface en zone wordt uitgelegd in Sophos Firewall zones en interfaces configureren. Vóór een wijziging in een productieve routingomgeving moet bovendien een actuele firewallback-up buiten de appliance beschikbaar zijn.

Dynamic Routing gericht toestaan

Onder Administration > Device access is Dynamic Routing standaard voor alle zones uitgeschakeld. Voor een afzonderlijk netwerk dat uitsluitend als transitnetwerk wordt gebruikt, kan de service in die zone worden geactiveerd.

Deelt de peerinterface zijn LAN- of WAN-zone met andere netwerken, dan is een Local Service ACL Exception voor het concrete peer-IP of het transitnetwerk strikter dan brede toestemming voor de zone. Maak hiervoor onder Administration > Device access > Local service ACL exception rule > Add een Accept-regel met IP version, Source zone, Source networks and hosts, Destination hosts, de service Dynamic Routing en de passende Rule position. Test daarna de toegang vanaf het toegestane peer-IP en vanaf een niet-toegestane bron.

De Sophos BGP-help vraagt bovendien om firewallregels voor inkomend en uitgaand BGP-verkeer. Tegelijkertijd stelt de Device Access-help dat lokale services niet worden beheerd door firewallregels. Deze stellingen zijn niet eenduidig op elkaar afgestemd. Behandel daarom afzonderlijk de Local Service ACL voor de lokale BGP-service, de regels die vereist zijn door het tunnel- of providerontwerp en de normale regels voor gerouteerd gebruikersverkeer. Hieruit volgt geen algemene Any-to-Any-regel voor TCP 179. Device Access op Sophos Firewall beveiligen legt de lokale toegangslaag uitgebreider uit.

BGP in WebAdmin configureren

De volgende stappen worden op beide firewalls uitgevoerd. Alleen de lokale en externe waarden worden omgewisseld.

1. Router ID en Local AS instellen

Voer onder Routing > BGP in Global configuration op Firewall A de volgende waarden in:

Als er al een BGP-configuratie bestaat, moet de actuele stand vóór het toepassen worden gedocumenteerd: een gewijzigde Router ID reset alle BGP-sessies; een gewijzigde Local AS verwijdert alle Neighbors en Networks. Pas zulke wijzigingen alleen in een gepland onderhoudsvenster toe.

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

Op Firewall B worden eveneens Manual, 192.0.2.20 en 65020 gebruikt. Pas daarna de globale configuratie toe.

De Local AS accepteert waarden van 1 tot 4294967295. Voor interne omgevingen zonder openbare ASN noemt Sophos het private bereik 64512 tot 65535.

2. Tegenpartij als Neighbor toevoegen

Klik onder Routing > BGP > Neighbors op Add en voer op Firewall A het volgende in:

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

Firewall B gebruikt 198.51.100.1 als Neighbor en 65010 als Remote AS. Sla beide configuraties daarna op met Save.

Het Neighbor-adres is niet het externe LAN en niet de Router ID, maar het direct bereikbare transit-IP van de tegenpartij. Als dit IP niet bereikbaar is of de ASN’s zijn verwisseld, kan de sessie de status Established niet bereiken.

3. Lokaal LAN adverteren

Klik onder Routing > BGP > Networks op Add. Firewall A adverteert:

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

Op Firewall B worden in plaats daarvan 10.20.20.0 en 255.255.255.0 (/24) ingevoerd.

Een Network-vermelding bepaalt welke prefix BGP adverteert; deze vervangt noch de lokale route, noch een firewallregel. Controleer na het opslaan daarom zowel de sessie als de geadverteerde en op de peer ontvangen prefix. Alleen benodigde prefixen horen in deze lijst.

IPv6-Neighbors en -netwerken begrijpen

SFOS ondersteunt ook IPv6 onder Neighbors en Networks. Het voorgaande voorbeeld blijft bewust bij IPv4; voor IPv6 worden de IP-versie, een direct bereikbaar IPv6-adres van de peer en het IPv6-prefix afzonderlijk ingevoerd.

WebAdmin voegt de vereiste scheiding automatisch toe. In een CLI-only configuratie zijn de defaults asymmetrisch: IPv4 Networks worden aanvankelijk voor alle Neighbors geactiveerd, ook IPv6-Neighbors. IPv6 Networks worden voor geen enkele Neighbor geactiveerd. Stel voor een IPv6-Neighbor expliciet deze waarden in:

address-family ipv4 unicast
no neighbor <ipv6-neighbor> activate
exit
address-family ipv6 unicast
neighbor <ipv6-neighbor> activate

Om de WebAdmin-defaults via CLI te reproduceren noemt Sophos ook no bgp ebgp-requires-policy en bgp log-neighbor-changes. show running-config toont alleen afwijkende waarden; een automatisch gekozen Router ID en bijvoorbeeld maximum-paths ibgp 16 verschijnen mogelijk niet. Valideer IPv4 en IPv6 apart onder Routing > Information > BGP-IPv4 en BGP-IPv6, met eigen IPv6-regels en retourpaden.

BGP controleren en valideren

Een opgebouwde sessie alleen bevestigt nog geen werkende pakketstroom. De validatie vindt daarom op meerdere niveaus plaats:

1. Onder Routing > Information > BGP-IPv4 > Neighbors moet de tegenpartij in de State Established verschijnen.
2. Onder Routes verwacht Firewall A het prefix 10.20.20.0/24; Firewall B verwacht 10.10.10.0/24.
3. Onder Summary worden de sessie en het aantal ontvangen prefixen gecontroleerd.
4. Onder Diagnostics > Tools > Route lookup wordt op Firewall A bijvoorbeeld het doel 10.20.20.10 gecontroleerd.
5. Daarna volgt een test met een echte service tussen een host uit elk LAN. Log Viewer en Packet Capture moeten de verwachte regel, de juiste transitinterface en het retourverkeer tonen.

Een Neighbor met de status Established bewijst alleen dat de BGP-uitwisseling werkt. Pas de geleerde route, de correcte Route Lookup en een echte verbinding bevestigen de volledige opstelling. Voor het controleren van de pakketstroom helpt Sophos Firewall-regels met Log Viewer en Packet Capture testen.

Hetzelfde voorbeeld via de CLI

Als alternatief voor WebAdmin kan dezelfde basisconfiguratie na aanmelding via SSH in de routing-CLI worden ingevoerd. Voer de volgende opdrachten niet uit in een al geconfigureerde voorbeeldomgeving. Sla vóór wijzigingen de huidige toestand op; een ASN-wijziging verwijdert Neighbors en Networks en vereist een back-up en onderhoudsvenster. De toegang hangt af van de SFOS-versie.

SFOS 22: het volgende menupad opent bgp>. Alleen deze toegang begint met enable:

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

Op Firewall A waar nog geen ASN is toegewezen:

enable
configure terminal
router bgp 65010

SFOS 23: 3. Route Configuration > 1. Configure Unicast Routing opent direct router#; de derde menukeuze en enable horen niet bij deze toegang. Voor de eerste ASN-toewijzing op Firewall A:

configure terminal
router bgp 65010

Als de ASN in SFOS 23 al is toegewezen, gebruik dan na configure terminal in plaats daarvan router bgp zonder ASN om de bestaande configuratie te selecteren. router bgp 65010 is bedoeld voor de eerste toewijzing of een bewust geplande ASN-wijziging, niet voor een ongecontroleerde nieuwe toewijzing.

Ga na precies één van deze toegangsreeksen verder in de BGP-configuratiemodus:

no bgp ebgp-requires-policy
bgp log-neighbor-changes
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
end
show running-config
write

Op Firewall B worden Local AS, Router ID, Neighbor, Remote AS en Network vervangen door respectievelijk 65020, 192.0.2.20, 198.51.100.1, 65010 en 10.20.20.0/24.

show running-config dient ter controle. write slaat de CLI-configuratie permanent op, maakt de vermeldingen zichtbaar in WebAdmin en behoudt ze na een herstart. Zonder write is de wijziging niet volledig afgerond.

end verlaat de configuratiemodus vóór deze twee opdrachten. Voor SFOS 23 documenteert Sophos de verwachte opslagbevestiging Integrated configuration saved to /conf/routing/frr.conf; dit is geen hier waargenomen appliance-uitvoer. Vergelijk daarna de configuratie en WebAdmin-vermeldingen met de bedoelde waarden.

De officieel gedocumenteerde aanvullende controle luidt:

show ip bgp

Deze opdracht toont de bekende BGP-prefixen en hun padinformatie. Neighbor-state en Summary worden betrouwbaar gecontroleerd onder Routing > Information > BGP-IPv4.

⚠️ Meng geavanceerde CLI-configuratie en WebAdmin niet ongecontroleerd. Als een Neighbor in WebAdmin wordt bewerkt, kunnen aanvullende CLI-waarden zoals een Neighbor-wachtwoord of Route Map worden verwijderd. Zodra dergelijke instellingen worden gebruikt, moet eerst show running-config worden opgeslagen en de BGP-configuratie verder via de CLI worden beheerd.

SFOS 23.0: experimentele BFD voor BGP

Bidirectional Forwarding Detection (BFD) bewaakt de bereikbaarheid van een BGP-Neighbor met eigen controlepakketten. Daardoor kan de firewall een uitval eerder detecteren dan met alleen de BGP-timers. Deze optionele procedure maakt geen deel uit van de voorgaande BGP-basisconfiguratie en is niet van toepassing op oudere SFOS-versies.

⚠️ In SFOS 23.0 is BFD experimenteel. De gedocumenteerde toepassing betreft BGP in Standalone-Deployments; dit betekent niet dat BFD is vrijgegeven voor HA-clusters of andere routingprotocollen. Voor andere protocollen moet Sophos Support worden betrokken. Avanet raadt aan om eerst een geïsoleerde testomgeving te gebruiken. Zonder een voor de geïnstalleerde build bevestigde rollbackprocedure wordt BFD niet in productie geactiveerd.

Toepassingsgebied en voorbereiding

Sophos noemt BGP-IPv4- en BGP-IPv6-Neighbors, evenals eBGP, iBGP, eBGP multihop en Route-Reflector-Neighbors als BFD-toepassingen. Het volgende voorbeeld blijft bij de al geconfigureerde IPv4-Neighbor 198.51.100.2 op Firewall A. Dit biedt geen aanvullende garantie voor een specifieke Cloud VPN-dienst of een specifieke multihop-topologie.

Voordat wordt begonnen, moeten de BGP-sessie, de verwachte prefixen en het applicatieverkeer zonder BFD werken. De tegenpartij moet op BFD zijn voorbereid; peeradressen, bereikbaarheid en timers worden met de beheerder daarvan afgestemd. Leg de actuele SFOS-build, show running-config, Neighbor-status en Route Lookup vast en zorg voor een back-up, een onderhoudsvenster en onafhankelijke managementtoegang. Stem vooraf met Sophos Support voor deze build af hoe de BFD-koppeling aan de Neighbor, een aanvullend peerprofiel en de service volledig worden verwijderd. De BFD-handleiding documenteert hiervoor geen volledige verwijder- of stopopdrachten.

Als de bewaakte Neighbor onbereikbaar wordt, verwijdert de firewall alle daarvan geleerde routes onmiddellijk uit de routingtabel. Alleen als er een alternatief pad beschikbaar is, kan het verkeer daarop overschakelen; zonder alternatief verliezen de betrokken netwerken hun route. Bij terugkeer van de Neighbor beschrijft Sophos het herstel van de routes en de terugschakeling naar het oorspronkelijke pad. Daarom worden zowel uitval als herstel gecontroleerd, inclusief de daadwerkelijk gekozen route.

Service starten en Neighbor bewaken

De BFD-service is standaard uitgeschakeld. De volgende opdrachten wijzigen de werking van routing; vóór uitvoering moeten de vastgelegde uitgangssituatie en de bevestigde rollbackprocedure beschikbaar zijn. Meld u via de CLI aan onder 5. Device Management > 3. Advanced shell en start daar de service:

service -ds nosync bfdd:start

Schakel daarna in dezelfde Advanced Shell met vtysh over naar de routing-CLI:

vtysh

Voeg in de routing-CLI de BFD-koppeling toe voor de al bestaande Neighbor op Firewall A. Router ID, Local AS, Remote AS en Networks blijven daarbij ongewijzigd:

configure terminal
router bgp
neighbor 198.51.100.2 bfd
end
write

Vervang 198.51.100.2 door het werkelijke Neighbor-adres, niet door het LAN of de Router ID daarvan. Op Firewall B is het bijbehorende adres in dit voorbeeld 198.51.100.1. De tegenpartij wordt volgens de eigen producthandleiding geconfigureerd. Als de BGP-Neighbor nog ontbreekt, voltooi dan eerst de BGP-basisconfiguratie uit dit artikel; BFD vervangt die niet. write slaat de routingconfiguratie op, maar bewijst niet dat de BFD-sessie werkt of dat de service na een herstart automatisch wordt gestart.

Timers alleen wijzigen als daar een goede reden voor is

Voor de eerste test raadt Avanet de gedocumenteerde defaults aan: Detect multiplier 3, Transmit interval 300 ms en Receive interval 300 ms. Zeer korte intervallen of een gevoelige multiplier kunnen de verwerkingsbelasting verhogen. Hieruit volgt geen garantie voor een vaste omschakeltijd.

Timers worden ingesteld in de BFD-configuratie, niet in de BGP-Neighbor-opdracht. Als een expliciet peerprofiel nodig is, toont dit blok in de routing-CLI de gedocumenteerde standaardwaarden voor dezelfde voorbeeldpeer:

configure terminal
bfd
peer 198.51.100.2
 detect-multiplier 3
 transmit-interval 300
 receive-interval 300
end
write

peer start de peerbewaking met de standaardtimers; dit aanvullende blok is niet nodig om alleen de BGP-koppeling te configureren. Voor detect-multiplier documenteert Sophos het bereik 1–155, voor beide intervallen 10–4294967 ms. De Transmit-waarde geeft het minimale verzendinterval zonder jitter aan, de Receive-waarde het verwachte minimale ontvangstinterval. De tegenpartij berekent haar detectietijd op basis van de lokale multiplier en de grootste waarde van het lokale verzendinterval en het externe ontvangstinterval. Stem daarom beide kanten af, in plaats van alleen een zo klein mogelijke lokale waarde te kiezen. Aanvullende timers direct achter neighbor … bfd zijn geen geldige syntaxis.

BFD, routes en applicatie samen valideren

In de routing-CLI zijn deze twee controles alleen-lezen:

show bfd peers
show bfd peers brief

Voor de bedoelde peer wordt Status: up verwacht. De gedetailleerde uitvoer moet passende lokale en externe timers tonen, evenals Diagnostics: ok en Remote diagnostics: ok; het beknopte overzicht koppelt het peeradres aan de status. Controleer vervolgens opnieuw de BGP-sessie onder Routing > Information > BGP-IPv4 of BGP-IPv6, de verwachte prefixen, Route Lookup en echt applicatieverkeer. Alleen BFD up bevestigt noch de juiste BGP-route, noch het gegevenspad.

Voer een uitvaltest alleen uit in een goedgekeurde testomgeving of een gepland onderhoudsvenster, zonder de onafhankelijke managementtoegang in gevaar te brengen. Leg vooraf de prefixen vast die van de bewaakte Neighbor zijn geleerd, evenals het geplande vervangende pad. Tijdens de gecontroleerde uitval van de peer moeten de betrokken routes verdwijnen en moeten, indien aanwezig, de vervangingsroute en het applicatieverkeer werken. Controleer na herstel opnieuw BFD up, BGP, de teruggekeerde prefixen, het gekozen pad en de applicatie. Hier wordt geen apparaatuitvoer of geslaagde omschakeling als al getest gepresenteerd.

Fouten afbakenen en de wijziging terugdraaien

• Peer ontbreekt of blijft down: Controleer de servicestart en de BFD-koppeling in show running-config en vergelijk daarna het werkelijke peeradres, de bereikbaarheid en de BFD-configuratie van de tegenpartij. Leg met show bfd peers de lokale en externe diagnose en de timers vast. Voeg geen brede Any-to-Any-toestemming toe als algemene oplossing; betrek Sophos Support als de toegangsvereisten onduidelijk zijn.
• BFD werkt na een wijziging niet meer: Wijzigingen aan bijbehorende instellingen, zoals het doeladres of de Remote Gateway, kunnen de BFD-instellingen verwijderen. Vergelijk de configuratie met de vastgelegde uitgangssituatie, configureer BFD opnieuw voor de betrokken Neighbor en voer de volledige validatie uit.
• Instabiele sessie of hogere belasting na een timerwijziging: Stel in dezelfde BFD-peercontext de eerder gedocumenteerde waarden opnieuw in en sla ze op met write. Als het standaardprofiel de uitgangssituatie was, toont het bovenstaande blok 3 en 300 ms. Controleer daarna beide peerdiagnoses, BGP-routes en verkeer voordat verdere waarden worden gewijzigd.
• Volledige rollback: Pas alleen het vooraf voor deze build bevestigde rollbackplan toe en vergelijk daarna de BGP-configuratie zonder BFD met de vastgelegde uitgangssituatie. Noch een verzonnen no-opdracht, noch het zonder meer stoppen van de service vervangt dit plan. Het verwijderen van de volledige BGP-Neighbor is geen gelijkwaardige BFD-rollback, omdat daardoor ook de routes van die Neighbor vervallen. Rond de rollback pas af wanneer de BGP-sessie, de benodigde prefixen, de managementtoegang en de applicatie weer in de bedoelde toestand zijn.

Weight, MED en globale Route Precedence

De globale Route Precedence rangschikt de categorieën static, sdwan_policyroute en vpn. Deze staat los van de attributen waarmee BGP zijn eigen paden selecteert. system route_precedence show toont de huidige globale waarde; wijzig deze alleen als deze drie categorieën daadwerkelijk concurreren. Routingprioriteit aanpassen op Sophos Firewall legt de volledige controle en rollback uit.

Tussen verschillende routingprotocollen beslist onder meer de Administrative Distance. Binnen BGP worden BGP-attributen geëvalueerd. Sophos noemt bijvoorbeeld een hogere Weight als voorkeur; bij verder vergelijkbare paden krijgt een lagere MED de voorkeur.

Dit is vooral belangrijk wanneer dezelfde prefix via redistribute ospf en daarnaast van een BGP-Neighbor wordt geleerd. De lokaal gegenereerde, geredistribueerde route heeft standaard Weight 32768; de van de Neighbor geleerde route heeft Weight 0. Zonder een bewuste aanpassing wint daarom de geredistribueerde route. Als het peerpad de voorkeur moet krijgen, moet de Weight daarvan hoger worden ingesteld en moet de resulterende route daarna worden gecontroleerd.

MED gebruiken voor meerdere ingangspaden

SFOS 23: namen vooraf controleren. Inventariseer vóór het maken of hergebruiken van Access Lists, Prefix Lists of Route Maps hun namen over alle dynamische routingprotocollen. Ze staan in één configuratiebestand en de namen moeten over de protocollen heen uniek zijn. Vermijd naamconflicten en controleer de bedoelde Neighbor-/policykoppelingen aan de hand van de huidige en opgeslagen configuratie. Deze voorwaarde vervangt niet het hieronder vereiste MED-rollbackplan dat voor de geïnstalleerde build is bevestigd; uitvoerbare MED-configuratie blijft opgeschort totdat dat plan is bevestigd.

Upgrade naar SFOS 23.0: Vanaf deze versie gebruiken alle dynamische routingprotocollen één geïntegreerde configuratie. Bij een upgrade vanaf een eerdere versie voegt de firewall automatisch protocolprefixen toe aan de namen van Route Maps, Prefix Lists en Access Lists, maar alleen bij een naamconflict. Ook alle verwijzingen naar de hernoemde configuraties worden automatisch bijgewerkt. Dit betekent niet dat elk object wordt hernoemd.

Vergelijk na de upgrade de vooraf opgeslagen objectnamen en verwijzingen met de huidige show running-config en leg de koppeling tussen oude en huidige namen vast. Controleer of de bedoelde Neighbor-/Route-Map-koppelingen nog naar de juiste policies verwijzen, inclusief bestaande MED-koppelingen. Herstel oude namen niet blind. Controleer onder Routing > Information > BGP-IPv4 > Routes en met show ip bgp op de peer of de verwachte netwerkprefixen aanwezig zijn, niet-toegestane netwerkprefixen ontbreken en het bedoelde pad wordt gekozen; controleer ook het daadwerkelijk gebruikte pad met Route Lookup. Deze controle vervangt niet het hieronder vereiste MED-rollbackplan voor de geïnstalleerde build en heft de opschorting van MED-configuratie niet op.

De Multi-Exit Discriminator (MED) vertelt een direct naburig AS welk van meerdere ingangspaden naar het lokale AS het moet verkiezen. Een lagere MED is beter en de standaard is 0. Adverteer daarom een hogere waarde op het minder gewenste pad. Standaard wordt MED alleen vergeleken wanneer hetzelfde prefix via meerdere links uit hetzelfde naburige AS wordt geleerd.

MED is niet-transitief. Als het ontvangende AS de route aan een ander AS doorgeeft, wordt de waarde teruggezet op 0. BGP beoordeelt eerst Weight, Local Preference, lokale oorsprong, AS Path-lengte en Origin Type. MED beslist alleen als deze attributen gelijk zijn. Een ingestelde waarde bewijst dus niet dat het gewenste pad wint.

Sophos stelt MED in via een uitgaande Route Map met een vast sequentienummer en koppelt deze in de IPv4 Address Family aan een specifieke Neighbor. out wijzigt de aankondiging aan die peer; het dwingt niet rechtstreeks het uitgaande gegevenspad van de Sophos Firewall af. De officiële SFOS 22-pagina documenteert de configuratie, maar geen volledige rollback. Voer de wijziging daarom pas uit nadat de exacte verwijdercommando’s voor de geïnstalleerde build afzonderlijk zijn bevestigd en samen met de eerder opgeslagen show running-config als herstelplan zijn vastgelegd.

Na een goedgekeurde wijziging moet show ip bgp op de ontvangende router de verwachte MED en het voorkeurspad tonen. Op een Sophos-peer staat de route bovendien onder Routing > Information > BGP-IPv4 > Routes. Zonder deze vergelijking voor en na blijft dit een beslissingshulp en geen uitvoerbare productiewijziging.

BGP via route-based IPsec en Cloud VPN

BGP kan over een geadresseerde XFRM-interface van een route-based Site-to-Site IPsec-tunnel lopen. Daarvoor krijgen beide XFRM-interfaces passende transit-IP’s. Dynamic Routing wordt gericht voor de VPN-zone toegestaan; regels voor het gegevensverkeer blijven desondanks noodzakelijk.

Bij cloudverbindingen worden de waarden niet vrij gekozen:

• Voor AWS Site-to-Site VPN komen Inside-Tunnel-adressen, Remote AS en andere tunnelwaarden uit de AWS-configuratie. Beide AWS-tunnels worden afzonderlijk gecontroleerd.
• Bij Azure VPN Gateway moet het lokale XFRM-IP overeenkomen met het bedoelde BGP-peer-IP; lokale en Azure-ASN moeten verschillend zijn.

Een groene IPsec-tunnel en een BGP Neighbor met de status Established zijn twee afzonderlijke controlepunten. Daarna moeten de verwachte prefixen en echt applicatieverkeer werken.

Fouten systematisch afbakenen

Neighbor blijft op Active of wordt niet weergegeven

Active betekent niet dat de sessie actief werkt. De firewall blijft proberen een BGP-verbinding op te bouwen. Controleer eerst de directe bereikbaarheid van het peer-IP, de interface- en tunnelstatus, Local AS, Remote AS en het Neighbor-IP. Controleer daarna of Dynamic Routing in de juiste zone of via een passende Local Service ACL Exception is toegestaan.

Controleer bij XFRM bovendien of beide tunneladressen correct zijn en de IPsec-tunnel up is. Controleer bij cloud- en XFRM-opstellingen ook de regels die in het betreffende VPN-ontwerp zijn voorzien. Als hun Services beperkt zijn, moet TCP 179 tussen beide peer-IP’s zijn opgenomen. Device Access of de Local Service ACL voor de lokale BGP-service blijft hiervan gescheiden.

Neighbor is Established, maar het externe netwerk ontbreekt

De sessie werkt, maar de prefix wordt niet geadverteerd of geaccepteerd. Controleer op de verzendende firewall de Network-vermelding, de IP-versie en het prefixmasker, en controleer show running-config. Kijk vervolgens op de peer onder Routes en Summary of de prefix aankomt of door een policy of filter wordt geweigerd.

Ontbreekt na een upgrade naar SFOS 22 een netwerk achter een policy-based IPsec-tunnel, dan kan de vroegere afhankelijkheid van redistribute kernel de oorzaak zijn. De BGP-sessie kan daarbij Established blijven; SFOS 22: IPsec-routes en redistribute kernel legt de versiewijziging en het route-based XFRM-doelontwerp uit.

De BGP-route is zichtbaar, maar wordt niet gebruikt

Controleer eerst met Route Lookup welke route voor een concrete doel-IP wint. Een specifiekere route heeft voorrang op een breder prefix. Als meerdere bronnen concurreren, moeten Administrative Distance, BGP-attributen en pas daarna de globale Route-Precedence-categorie afzonderlijk worden beoordeeld.

De route klopt, maar het verkeer werkt niet

BGP heeft zijn taak vervuld zodra de correcte route is geïnstalleerd. Daarna liggen fouten meestal bij de firewallregel, NAT, retourroute of het doelsysteem. Bij normaal gerouteerde locatienetwerken is vaak geen SNAT nodig, omdat beide kanten de echte LAN-prefixen moeten kennen.

Geavanceerde instellingen zijn na een WebAdmin-bewerking verdwenen

WebAdmin geeft alleen de basiswaarden weer. Als een Neighbor daar na een geavanceerde CLI-configuratie is opgeslagen, kunnen het wachtwoord, de Route Map of gewijzigde standaardwaarden zijn verwijderd. Ook het toepassen van Global configuration verwijdert wijzigingen aan bgp log-neighbor-changes en no bgp ebgp-requires-policy. Vergelijk de opgeslagen stand, herstel de waarden via de CLI en sla ze op met write.

BGP- en routinglogs toewijzen

De SFOS 22-logreferentie wijst BGP en BGPv6 toe aan bgpd.log. zebra.log betreft de installatie van dynamische IPv4- en IPv6-routes in de kernel; bij route-based IPsec hoort xfrmi.log bij de XFRM-tunnelinterface. Zo kunnen de foutcategorieën worden gescheiden: controleer eerst de BGP-sessie en de aankondiging, daarna de opname in de systeemroutingtabel en zo nodig de tunnelstatus. Sophos Firewall-services en logbestanden legt de toegang en andere bestanden uit. Voor deze validatie zijn geen ongedocumenteerde live-shell-opdrachten nodig.

Wijziging veilig terugdraaien

Voordat BGP wordt verwijderd, moet voor elk geleerd doelnetwerk een alternatief pad of een onderhoudsvenster beschikbaar zijn. Eerst worden de betrokken Networks en Neighbors verwijderd; daarna wordt de globale BGP-configuratie alleen gewijzigd als geen andere peers ervan afhankelijk zijn. Dynamic Routing mag pas worden uitgeschakeld wanneer de zone geen andere dynamische routingservice meer nodig heeft.

Verwijder in WebAdmin eerst de niet meer benodigde aankondigingen onder Routing > BGP > Networks en vervolgens de betreffende peers onder Neighbors. Controleer na elke stap of de verwachte vervangingsroutes actief zijn. Laat Router ID en Local AS ongewijzigd zolang andere BGP-verbindingen daarvan afhankelijk zijn; een wijziging van de Local AS zou alle resterende Neighbors en Networks verwijderen.

De beoordeelde BGP-overzichtspagina’s voor SFOS 22 en 23 tonen wel syntaxis om de BGP-routingconfiguratie uit te schakelen. Dit valideert echter niet de volledige uitvoeringscontext of een veilige rollback voor de geïnstalleerde build. De afwijkende bronsyntaxis wordt niet als uitvoerbare opdracht overgenomen of stilzwijgend gecorrigeerd; er wordt geen bevestigde daemonstop of procesverwijdering uit afgeleid. Er wordt geen destructieve CLI-opdracht aanbevolen. Wie geavanceerd CLI-beleid gebruikt, heeft vóór de rollback de voor de geïnstalleerde build bevestigde verwijdercommando’s en het opgeslagen eerdere configuratieblok nodig.

Daarna worden Routing Information, Route Lookup, managementtoegang en echt verkeer opnieuw gecontroleerd. Een rollback is pas voltooid wanneer niet alleen de BGP-sessie verdwenen is, maar alle benodigde doelnetwerken via het bedoelde vervangende pad bereikbaar blijven.