Sophos Firewall ARP- en NDP-neighborcache controleren
Wanneer een apparaat ondanks een correct IP-adres niet bereikbaar is, hoeft niet meteen een firewallregel of route fout te zijn. In het lokale netwerk heeft Sophos Firewall ook het juiste MAC-adres van het doel nodig. Deze koppeling wordt opgeslagen in de neighborcache.
Onder Network > Neighbors (ARP–NDP) kan worden gecontroleerd welk IP-adres momenteel bij welk MAC-adres en welke interface hoort. Leg eerst de bestaande vermelding vast en vergelijk deze met de werkelijke netwerksituatie. Alleen wanneer de koppeling verouderd is, wordt de betreffende cache geleegd en opnieuw opgebouwd.
De labels en opdrachten in deze procedure gelden voor SFOS 22.0. Begin de diagnose in WebAdmin en gebruik de Device Console alleen voor de hieronder uitdrukkelijk beschreven aanvullende controles.
⚠️ Flush leegt de geselecteerde IPv4- of IPv6-cache, niet slechts één regel. Op een productief systeem moet de huidige vermelding daarom eerst worden vastgelegd, de test worden afgebakend en de cache niet tijdens een belastingspiek worden geleegd.
Wat ARP, NDP en de neighborcache doen
ARP koppelt binnen het lokale Layer 2-segment een IPv4-adres aan een MAC-adres. Hiermee wordt een direct bereikbaar apparaat bedoeld, doorgaans in hetzelfde VLAN. Voor IPv6 vervult Neighbor Discovery Protocol (NDP) deze taak met ICMPv6. De firewall heeft deze informatie nodig voordat een pakket via een direct aangesloten interface naar de volgende neighbor kan worden verzonden.
Bij IPv4 vraagt een apparaat met een ARP-verzoek naar het MAC-adres dat bij een IP-adres hoort. Het antwoord levert de koppeling waarmee de firewall zijn neighbor-cache bijwerkt. Eerder geleerde IP-MAC-koppelingen worden opnieuw gebruikt om broadcastverkeer te verminderen; bij IPv6 verzorgt NDP de overeenkomstige neighbor-resolutie.
Dynamische neighbor-vermeldingen worden geleerd en voortdurend bijgewerkt. De gedocumenteerde standaardtime-out voor ARP- en NDP-verzoeken bedraagt 600 seconden (10 minuten). Dit garandeert niet dat elke afzonderlijke vermelding precies na 600 seconden verdwijnt: de caches blijven bestaan totdat ze automatisch of handmatig worden geleegd. Daarna kan de firewall actuele koppelingen opnieuw leren. Een verouderde vermelding kan bijvoorbeeld ontstaan na een wijziging van apparaat, netwerkkaart of VM. Een dubbel toegewezen IP-adres kan er daarentegen toe leiden dat het zichtbare MAC-adres herhaaldelijk verandert.
Onder Neighbor cache entry timeout kan het automatische flush-interval worden gewijzigd en met Apply worden toegepast. Een kortere waarde dwingt vaker opnieuw leren af en verhelpt geen dubbele IP-adressen, onjuiste VLAN’s of verouderde statische koppelingen. Leg vóór een wijziging de uitgangswaarde vast. Levert de test niets op, voer dan exact die waarde opnieuw in, klik op Apply en test het werkelijke datapad opnieuw.
Voor XML-automatisering: De XML-referentie voor SFOS 22.0 en 23.0 beschrijft onder ARPConfiguration de parameter ARPCacheEntryTimeOut als cache-flush-interval: gedocumenteerde standaardwaarde 2 minuten, bereik 1–500; het voorbeeld vermeldt Minutes. Dit zijn referentiewaarden, geen bewijs van een actuele runtimewaarde of van dezelfde instelling als die in de UI-help voor ARP-/NDP-verzoeken met een time-out van 600 seconden. Deze IPv4-ARP-entiteit toont evenmin aan dat er een algemene configuratie voor alle IPv6-NDP-eigenschappen bestaat. Neem geen van deze documentatiewaarden over als automatische reset- of tuningwaarde: bepalend blijft de actuele waarde die vóór een wijziging is vastgelegd en bij het terugdraaien exact wordt hersteld; daarna wordt de oorspronkelijke dienst opnieuw gecontroleerd.
De neighborcache betreft alleen direct bereikbare neighbors in het betreffende Layer 2-segment. Voor een extern doel slaat de firewall niet het MAC-adres van de doelserver op, maar dat van de volgende router.
Dit is niet hetzelfde als Proxy ARP: daarbij beantwoordt de firewall op een interface een IPv4-ARP-verzoek voor een ander doeladres namens dat doel. Dit bijzondere geval wordt afzonderlijk behandeld in Proxy ARP configureren en controleren op Sophos Firewall.
ARP flux over meerdere interfaces herkennen
ARP flux kan optreden wanneer meerdere fysieke Ethernet-interfaces van Sophos Firewall met hetzelfde Layer 2-medium of dezelfde broadcast domain zijn verbonden. De firewall kan één ARP-verzoek dan via beide interfaces beantwoorden, waardoor het aanvragende apparaat wisselende of onverwachte MAC-koppelingen ziet. Twee afzonderlijke VLAN’s, een verkeerd geconfigureerde LAG of een gewoon dubbel IP-adres zijn niet automatisch ARP flux.
Gebruik een korte packet capture uitsluitend om het ARP-gedrag te controleren: ga na of hetzelfde verzoek beide fysieke poorten bereikt en of beide firewallinterfaces antwoorden. Een capture toont de geconfigureerde waarde van arp-flux niet.
De Device Console is bereikbaar via de lokale console of via SSH. De vereisten en SSH-toegang worden uitgelegd in Via SSH verbinding maken met Sophos Firewall. Selecteer na aanmelding Option 4: Device Console. Voer vóór iedere wijziging de gezaghebbende precheck voor SFOS 22.0 uit:
show arp-flux
Leg de exact weergegeven waarde on of off vast. De instelling is globaal en geldt niet voor slechts één interface. Wijzig deze alleen tijdelijk wanneer beide interfaces bewust dezelfde broadcast domain delen, de capture het problematische gedrag bevestigt en de huidige waarde een wijziging vereist. Als on is vastgelegd, test u de interfacespecifieke antwoordmodus binnen een onderhoudsvenster met:
set arp-flux off
Met off beantwoordt de firewall ARP-verzoeken via de bijbehorende Ethernet-interface. Controleer daarna via beide paden de bereikbaarheid, neighborvermeldingen, de oorspronkelijke service en het ARP-gedrag met een nieuwe capture.
Herstel na de test, ongeacht het resultaat, exact de met show arp-flux vastgelegde waarde. Als de uitgangswaarde on was, voert u uit:
set arp-flux on
Als de uitgangswaarde off was, voert u in plaats daarvan uit:
set arp-flux off
Voer show arp-flux opnieuw uit om de herstelde waarde te bevestigen en herhaal daarna de padtests. Gebruik packet capture uitsluitend om het resulterende gedrag te controleren.
Als er geen bewijs is voor een gedeelde broadcast domain of het probleem met off ongewijzigd blijft, mogen geen andere ARP-instellingen op basis van aannames worden gewijzigd. Onderzoek dan opnieuw de VLAN’s, bridges, LAG’s, MAC-tabel van de switch, bekabeling en dubbele IP-adressen.
Eerst de neighborcache controleren
- Network > Neighbors (ARP–NDP) openen.
- Onder Show de IPv4 neighbor cache of IPv6 neighbor cache selecteren.
- Naar het betreffende IP-adres zoeken.
- IP-adres, MAC-adres en interface noteren.
- Onder Static neighbor table uitsluiten dat voor hetzelfde IP-adres een vaste maar onjuiste koppeling bestaat.
- Het MAC-adres vergelijken met het eindapparaat, de hypervisor, de switch of de volgende router.
De interface is even belangrijk als het MAC-adres. Een correcte IP-MAC-koppeling op de verkeerde poort wijst vaak op een probleem met een VLAN, bridge, LAG of bekabeling. Het verwachte MAC-adres is bijvoorbeeld te vinden in de netwerkinformatie van het eindapparaat, in de MAC-tabel van de switch of bij de direct aangesloten router. Als de vermelding volledig ontbreekt, wordt vanaf de firewall een gerichte ping naar het betreffende IP-adres uitgevoerd en wordt de weergave daarna opnieuw gecontroleerd.
Voor IPv4 en IPv6 zijn de twee cacheweergaven in WebAdmin het gedocumenteerde controlepunt. Ze tonen naast het adres ook de interface en voorkomen dat een IPv4-waarneming per ongeluk op een IPv6-probleem wordt toegepast.
Afbakening van de XML-API: Get Dynamic Neighbour Entries leest vermeldingen voor controle; Flush All Dynamic Entries verwijdert dynamische cachevermeldingen, niet één statische vermelding. De referentie voor SFOS 22.0 en 23.0 vermeldt het optionele scalaire IPFamily met IPv4 en IPv6, maar geen standaardwaarde. Hieruit valt niet af te leiden of het weglaten ervan één van beide families, beide of een andere reikwijdte selecteert. Geen van beide versies bevat een verzoekpayload; de parametertabel levert daarom geen uitvoerbaar bewerkingsverzoek op. Gebruik voor controle en flush de bestaande GUI-procedure met een expliciete keuze van de IP-familie. De waarschuwing blijft gelden: Flush leegt de volledige geselecteerde cache.
Een verouderde koppeling gecontroleerd opnieuw opbouwen
Het legen van de cache is een diagnosestap, geen permanente reparatie. Een onjuiste statische koppeling wordt er evenmin door verwijderd. Voor verwijderde dynamische vermeldingen bestaat geen directe rollback; de firewall leert ze opnieuw uit nieuw verkeer. Wanneer dezelfde verkeerde koppeling terugkeert, ligt de oorzaak nog steeds in het netwerk.
- Het huidige IP-adres, MAC-adres en de interface vastleggen.
- De fout reproduceren met één ping of verbindingspoging.
- Bij een vermoeden van een dubbel IP-adres of manipulatie eerst de huidige toestand en een korte capture bewaren. Een onmiddellijke flush zou deze aanwijzing verwijderen.
- Onder Show de betreffende IPv4- of IPv6-cache selecteren.
- Op Flush klikken. Daarmee wordt de geselecteerde cache geleegd.
- Vanaf het betreffende apparaat opnieuw gericht verkeer genereren.
- Controleren welk MAC-adres en welke interface opnieuw zijn geleerd.
- De oorspronkelijke service opnieuw testen met dezelfde bron en hetzelfde doel.
Voor een gecontroleerde test vanuit de Device Console kunnen bijvoorbeeld vier pakketten naar een vastgelegd doeladres worden verzonden:
ping 192.0.2.10 count 4
ping6 2001:db8:10::10 count 4
De adressen zijn voorbeelden en worden vervangen door het werkelijke IPv4- of IPv6-doel. Een geslaagde ping bevestigt alleen de fundamentele bereikbaarheid; daarna moet nog steeds de oorspronkelijk verstoorde service worden getest.
Tijdens het opnieuw leren kunnen korte vertragingen optreden. De timeout sterk en algemeen verkorten is zelden de beste oplossing: de firewall moet neighbors dan vaker opnieuw omzetten, zonder dat daarmee een dubbel IP-adres of verkeerde switchpoort wordt verholpen.
Wanneer na de flush alleen een openbaar IP-adres nog steeds niet naar het nieuwe MAC-adres van de firewall wisselt, bevindt de verouderde vermelding zich waarschijnlijk bij de provider of een voorgeschakelde router. Daarvoor bestaat de aparte procedure ARP-problemen na een firewallmigratie oplossen.
Alleen voor vaste koppelingen een statische neighbor aanmaken
Een statische neighbor koppelt een IP-adres permanent aan een MAC-adres en een fysieke interface. Per IP-adres kan slechts één dergelijke koppeling bestaan. Bij een verzoek op de betreffende poort controleert de firewall eerst de statische neighbor-tabel en verwijdert hij bij het opslaan dynamische verwijzingen voor hetzelfde IP-adres. Als een statische vermelding ontbreekt, controleert hij de neighbor-caches en voegt hij zo nodig het MAC-adres toe. Voor een statisch gekoppeld IP-MAC-paar antwoordt de firewall op geen enkele andere poort. Wanneer het IP-adres, MAC-adres of de poort later niet meer klopt, kan de verbinding uitvallen terwijl het eindapparaat correct is geconfigureerd.
Statische vermeldingen passen daarom bij stabiele systemen, zoals een vast bekabeld infrastructuurapparaat met een vast IP-adres. Voor DHCP-clients, mobiele apparaten, HA- of VM-wijzigingen en wisselende switchpoorten zijn ze meestal ongeschikt.
Onder Network > Neighbors (ARP–NDP) de Static neighbor table weergeven en Add selecteren. Vervolgens worden de volgende waarden ingesteld:
- IP version: IPv4 of IPv6 selecteren.
- IPv4/IPv6 address: het vaste adres van het apparaat invoeren.
- MAC address: het werkelijke MAC-adres van dit apparaat invoeren.
- Interface: de fysieke interface selecteren waarlangs de neighbor bereikbaar is.
Een gedocumenteerd voorbeeld kan 192.0.2.10, 02:00:00:00:00:10 en Port1 gebruiken. Deze waarden zijn tijdelijke aanduidingen en moeten volledig worden vervangen door het werkelijke IP-adres, MAC-adres en de werkelijke poort.
Leg vóór het opslaan vast of Add as a trusted MAC address to prevent a spoofing attempt is geselecteerd. De optie voegt de IP-MAC-koppeling toe aan de lijst met vertrouwde MAC-adressen. Activeer deze optie alleen wanneer deze beveiligingsstrategie bewust wordt toegepast, omdat een latere wijziging van VM, NIC of poort dan als een legitiem conflict kan verschijnen. Hoe vertrouwde MAC-vermeldingen samenwerken met dynamische netwerken, DHCP en virtualisatie wordt uitgelegd in Sophos Firewall Spoof Protection en DoS Settings controleren.
Klik op Save om de koppeling aan te maken en test vervolgens precies het betreffende apparaat. Verwijder bij de rollback van de test de nieuwe vermelding uit de Static neighbor table, genereer gericht verkeer en controleer de dynamisch geleerde koppeling. Open daarna Intrusion prevention > DoS & spoof protection > Spoof protection trusted MAC. Als daar een bij deze test behorende vertrouwde MAC-vermelding achterblijft, verwijdert u deze afzonderlijk; neem niet aan dat het verwijderen van de statische neighbor die vermelding ook verwijdert. Leg daarnaast vast wie een behouden vermelding bij een wijziging van hardware, IP-adres of poort aanpast. Een statische koppeling zonder deze verantwoordelijkheid wordt later gemakkelijk een onzichtbare foutoorzaak.
Afbakening ten opzichte van de Add/Edit-API
De Add/Edit-referentie voor statische neighbors in SFOS 22.0 en 23.0 beschrijft een afzonderlijk API-contract, niet de hierboven toegelichte timeout-entiteit ARPConfiguration. Deze vereist neighname voor de opgeslagen of geselecteerde neighbor-identiteit; neighid is daarentegen optioneel. Beide moeten worden onderscheiden van IPAddress, MACAddress en Interface. De GUI-waarden voor IP-adres, MAC-adres en fysieke poort leveren noch deze identiteit, noch een uitvoerbaar JSON- of XML-verzoek op. De referentie beschrijft de bewerking als JSON, maar toont geen voorbeeld dat het formaat of de identiteitstoewijzing met zekerheid verduidelijkt; leid daarom geen identificatie af uit de GUI-waarden.
Ook de adresgegevens zijn tegenstrijdig: het vereiste IPFamily staat IPv4 en IPv6 toe, terwijl IPAddress wordt beperkt tot IPADDRESS met maximaal 15 tekens en op IPv4 gebaseerde adresklassen. Hieruit kan geen betrouwbare IPv6-codering worden afgeleid; het weerlegt evenmin de IPv6-ondersteuning van de hierboven beschreven GUI-procedure. Voor het optionele AddAsATrustedMACAddress vermeldt de referentie alleen Enable. Dit bewijst noch dat een waarde Disable bestaat, noch wat het effect is van het weglaten van de parameter. De keuze voor een vertrouwd MAC-adres blijft een bewuste beslissing, en een achterblijvende vertrouwde MAC-vermelding wordt zoals hierboven beschreven afzonderlijk verwijderd. Zolang de identiteit, het verzoekformaat en het IPv6-adresschema voor de specifieke SFOS-versie onduidelijk zijn, gebruikt u voor het aanmaken of bewerken de bestaande GUI in plaats van een API-verzoek op basis van aannames.
Delete Static ARP Entry is een afzonderlijke bewerking: de referentie voor SFOS 22.0 en 23.0 vereist IPAddress om de vermelding te identificeren, niet het Add/Edit-contract met neighname en neighid. De beperking tot IPADDRESS, maximaal 15 tekens en op IPv4 gebaseerde adresklassen biedt geen betrouwbare representatie voor IPv6-verwijdering. Geen van beide versies bevat een voorbeeld van een verwijderverzoek of een statustabel; er worden dus geen verzoekformaat, verwijderpayload of resultaatcontract uit afgeleid. Gebruik in plaats van een API-verwijderverzoek te raden de bestaande GUI om uitsluitend de bedoelde opgeslagen statische vermelding te selecteren en te verwijderen. Controleer en verwijder een eventuele bijbehorende achtergebleven vertrouwde MAC-vermelding nog steeds afzonderlijk, zoals hierboven beschreven; verwijdering in cascade is niet gegarandeerd.
Mogelijke pogingen tot neighbor poisoning controleren
Een statische koppeling definieert de verwachte combinatie van IP-adres, MAC-adres en interface. Wanneer hetzelfde IP-adres met een ander MAC-adres verschijnt of dezelfde IP-MAC-combinatie op een andere gekoppelde poort verschijnt, behandelt de firewall dit als mogelijke manipulatie en werkt de cache niet bij met de afwijkende koppeling.
Eén koppeling per IP-adres betekent niet dat een MAC-adres bij slechts één IP-adres mag horen. In het IPv4-ARP-voorbeeld zijn IP1 en IP2 elk gekoppeld aan MAC1 en poort A. Als elk IP-adres met MAC1 op poort A verschijnt, is dat geen poging tot neighbor poisoning. Het gaat erom dat elke IP-MAC-poortcombinatie overeenkomt met de eigen statische koppeling.
In hetzelfde voorbeeld wordt ook IP3 met MAC1 zonder statische ARP-vermelding voor IP3 niet als een poging tot neighbor poisoning aangemerkt. Alleen het delen van het MAC-adres veroorzaakt dus geen conflict met de koppelingen van IP1 of IP2. Deze voorbeelden leggen de controle van statische ARP-koppelingen uit; ze vormen geen algemene veiligheidsgoedkeuring voor het verkeer.
Onder Network > Neighbors (ARP–NDP) kan Log possible neighbor poisoning attempts worden ingeschakeld en met Apply worden opgeslagen. Leg vóór een tijdelijke test vast of het selectievakje is aangevinkt en herstel die zichtbare status achteraf. De optie helpt bij de diagnose, maar betekent niet dat elke afwijking onmiddellijk als aanval moet worden beoordeeld. Ook een dubbel IP-adres, een vervangen netwerkadapter, een verplaatste VM of een poortwijziging veroorzaakt een conflict.
Verworpen IPv4-ARP-pakketten kunnen tijdens een korte test in de Device Console worden weergegeven:
drop-packet-capture 'arp'
Bij veel interfaces kan de uitvoer worden beperkt tot één fysieke poort:
drop-packet-capture interface Port1 'arp'
Port1 is een voorbeeld en wordt vervangen door de betreffende interface. Reproduceer de fout daarna eenmaal en beëindig de doorlopende uitvoer met Ctrl+C. Het filter toont alleen verworpen ARP-pakketten en is geen permanent logarchief. Voor IPv6-NDP of een algemene pakketanalyse wordt Packet Capture in WebAdmin gebruikt, waarbij bron, doel, protocol en interface gericht worden afgebakend.
Typische foutbeelden beoordelen
- Na vervanging van een apparaat of NIC blijft het doel onbereikbaar: de oude en opnieuw geleerde MAC-waarde vergelijken, de cache beheerst legen en opnieuw testen.
- Het MAC-adres verandert herhaaldelijk: controleren op een dubbel IP-adres, DHCP-lease, VM-kloon of HA-gedrag. Een statische vermelding zou het eigenlijke conflict alleen verbergen.
- De koppeling verschijnt op de verkeerde interface: VLAN, bridge, LAG, switchpoort en bekabeling controleren.
- Een statisch gekoppeld apparaat valt na een wijziging uit: IP-adres, MAC-adres en fysieke poort met de koppeling vergelijken en de vermelding bewust aanpassen of verwijderen.
- Alleen IPv6 is getroffen: IPv6 neighbor cache, Router Advertisements, VLAN en het ICMPv6-pad controleren. Een IPv4-ARP-opdracht levert hiervoor geen bewijs.
- Pakketten bereiken de firewall, maar de service werkt nog steeds niet: firewallregel, NAT, routing en retourpad afzonderlijk controleren. De neighborcache bewijst alleen de lokale Layer 2-aflevering.
Eindcontrole
- Betreffend IP-adres, verwacht MAC-adres en interface vastgelegd.
- IPv4- of IPv6-cache vóór een wijziging gecontroleerd.
- Indien nodig precies de geselecteerde cache geleegd en gericht verkeer gegenereerd.
- Opnieuw geleerde koppeling vergeleken met eindapparaat, switch, hypervisor of router.
- Statische koppeling alleen gebruikt bij een permanent stabiele combinatie van IP-adres, MAC-adres en poort.
- Poisoningmelding onderscheiden van een dubbel IP-adres, apparaatvervanging en netwerkwijzigingen.
- Oorspronkelijke service na de Layer 2-controle opnieuw getest.