ARP-problemen oplossen na migratie van Sophos Firewall

Na een firewall-migratie kan het voorkomen dat de nieuwe Sophos Firewall in principe online is, maar dat bepaalde openbare IP-adressen of alias-IP-adressen toch niet bereikbaar zijn. Dit is vooral typisch na een overstap van een andere fabrikant naar Sophos Firewall of na een migratie van XG naar XGS hardware. De IP-adressen blijven hetzelfde, maar het MAC-adres op de WAN-interface verandert.

Als een voorgeschakelde router, een provider-CPE of een switch nog oude ARP-items in de cache heeft, stuurt hij pakketten nog steeds naar het eerdere MAC-adres. Dit lijkt dan alsof alleen bepaalde alias-IP-adressen, DNAT-doelen of ping-tests niet werken. Voor de algemene migratieplanning is daarnaast het artikel Wat is het verschil tussen een XG en XGS Firewall? nuttig.

Typische symptomen

ARP-problemen na een omschakeling komen meestal direct na de wissel of na een herstel op nieuwe hardware aan het licht.

Typische aanwijzingen:

De WAN-interface van de Sophos Firewall is online.
Het hoofd-IP-adres werkt, maar bepaalde alias-IP-adressen niet.
Ping naar bepaalde openbare IP’s mislukt, andere IP’s op dezelfde interface reageren wel.
DNAT- of WAF-regels lijken correct geconfigureerd, maar bereiken de interne server niet.
Een dienst is intern bereikbaar, maar extern alleen op bepaalde openbare IP’s verstoord.
Na enige tijd werkt het plotseling, omdat een ARP-cache automatisch verloopt.

Belangrijk is de afbakening: niet elk bereikbaarheidsprobleem na een migratie is een ARP-probleem. Firewall-regels, NAT-regels, zones, aliasconfiguratie, provider-routing en retourroutes moeten ook worden gecontroleerd.

Waarom ARP na een migratie kan storen

ARP vertaalt IPv4-adressen naar MAC-adressen. In een lokaal Layer-2-segment vraagt een apparaat: welk MAC-adres hoort bij dit IP-adres? Het antwoord wordt in de ARP-cache opgeslagen, zodat niet elk pakket een nieuwe ARP-aanvraag hoeft te veroorzaken.

Bij een firewall-migratie blijft het IP-adres vaak hetzelfde, maar verandert het MAC-adres. Precies dat kan problematisch zijn:

De provider-router kent het openbare IP nog met het oude MAC-adres.
Een voorgeschakelde switch of router houdt verouderde ARP-items vast.
Een alias-IP is correct aangemaakt op de nieuwe firewall, maar de buurman stuurt nog steeds naar de oude hardware.
Slechts een deel van de IP’s is al opnieuw geleerd, daarom werken sommige adressen wel en andere niet.

Bij afzonderlijke alias-IP-adressen is dit bijzonder verwarrend, omdat de basisverbinding schijnbaar werkt. Men kijkt dan snel naar NAT, firewall-regels of routing, terwijl de fout al eerder op Layer 2 ontstaat.

Voor de CLI-opdracht controleren

Voordat men ARP actief aanstuurt, moet de basisconfiguratie kloppen. Anders zal een ARP-ping alleen een ander probleem verhullen.

Controleren:

Onder Network > Interfaces controleren of het betreffende IP-adres of alias-IP-adres op de juiste interface ligt.
Zone van de interface controleren, bijvoorbeeld WAN.
Gateway, subnetmasker en alias-netwerklogica controleren.
Onder Rules and policies > NAT rules controleren of de DNAT-regel naar het juiste openbare IP wijst.
Onder Rules and policies > Firewall rules controleren of er een passende regel voor het verkeer bestaat.
In de Log Viewer kijken of pakketten überhaupt op de firewall aankomen.
Indien nodig met Sophos Firewall Packet Capture in WebAdmin controleren of inkomende pakketten op de WAN-interface zichtbaar zijn.

Als in de Packet Capture helemaal geen pakketten voor het betreffende openbare IP aankomen, ligt het probleem waarschijnlijk voor de firewall: provider-router, voorgeschakelde switch, ARP-cache of routing bij de provider. Als pakketten aankomen, maar worden verworpen, moet men eerst NAT, firewall-regels en zones controleren. Voor interface- en zonelogica helpt Sophos Firewall Zones en Interfaces configureren.

ARP-ping uitvoeren via de Device Console

Sophos Firewall kan via de Device Console een ARP-ping met gedefinieerde bron-IP en interface uitvoeren. Dit is nuttig wanneer een alias-IP na de migratie actief in het netwerk bekend moet worden gemaakt.

Belangrijk: De opdracht moet alleen worden uitgevoerd als duidelijk is welke bron-IP, welke interface en welk doel in het lokale segment wordt gebruikt. Verkeerde waarden helpen niet en kunnen de analyse vertekenen. Voor wijzigingen aan een productieve migratie moet een actueel Sophos Firewall Backup beschikbaar zijn.

De opdracht wordt uitgevoerd in de Device Console, niet in de Advanced Shell:

system diagnostics utilities arp ping source <alias-ip> interface <interface> <target-ip>

Voorbeeld:

system diagnostics utilities arp ping source 198.51.100.21 interface Port2 198.51.100.1

In dit voorbeeld is 198.51.100.21 de betreffende alias-IP op Port2. 198.51.100.1 is een bereikbaar doel in hetzelfde Layer-2-segment, meestal de upstream-gateway of de provider-CPE. Hierdoor genereert de firewall ARP-verkeer met de juiste bron-IP via de juiste interface.

Als SSH nog niet is ingesteld, beschrijft Sophos Firewall per SSH verbinden hoe men de Device Console bereikt. Bij migraties moet SSH niet permanent breed vanuit het WAN worden toegestaan. Beter is een tijdelijke, beperkte administratieve toegang vanuit een vertrouwd netwerk.

Aanbevolen procedure

1. Betreffende IP-adressen verzamelen

Eerst wordt gedocumenteerd welke IP-adressen werken en welke niet. Bij alias-IP-adressen moet men de lijst direct met de interfaceconfiguratie vergelijken.

Noteren:

Interface, bijvoorbeeld Port2
Hoofd-IP en alias-IP-adressen
Upstream-gateway of provider-CPE
Betreffende NAT- of WAF-regels
Resultaat van ping, poorttest en Packet Capture

2. ARP-probleem afbakenen

Vanuit een extern testsysteem de betreffende openbare IP controleren. Parallel op de Sophos Firewall Packet Capture op de WAN-interface starten.

Interpretatie:

Geen pakketten komen aan op de WAN-interface: Upstream, ARP, provider-routing of voorgeschakeld apparaat controleren.
Pakketten komen aan, maar worden verworpen: Firewall-regel, NAT, zone of dienst controleren.
Pakketten komen aan en gaan intern verder, antwoord ontbreekt: Retourroute, interne server, SNAT of server-firewall controleren.
Alleen alias-IP getroffen, hoofd-IP werkt: ARP-cache of aliasconfiguratie gericht controleren.

3. ARP-ping per getroffen alias-IP uitvoeren

Voor elke getroffen alias-IP wordt de ARP-ping met de passende bron-IP en de juiste interface uitgevoerd. Daarna moet men niet meteen meerdere andere dingen veranderen, maar eerst testen of het gedrag verandert.

Voorbeeld met placeholders:

system diagnostics utilities arp ping source <betroffen-alias-ip> interface <wan-interface> <upstream-gateway>

Als meerdere alias-IP-adressen getroffen zijn, wordt de opdracht afzonderlijk per adres uitgevoerd. Dit maakt de controle inzichtelijk en voorkomt dat men aan het eind niet meer weet welke maatregel heeft geholpen.

4. Bereikbaarheid valideren

Na de ARP-ping moet men dezelfde test herhalen:

Ping of TCP-poorttest van extern.
Packet Capture op de WAN-interface.
Log Viewer filteren op het betreffende doel-IP.
NAT- en firewall-regel controleren, als pakketten nu aankomen.

Als de upstream de ARP-informatie correct opnieuw leert, zouden pakketten voor de alias-IP nu bij de nieuwe firewall moeten aankomen. Of de gepubliceerde dienst daarna werkt, hangt daarnaast af van NAT, firewall-regels, interne server en retourweg.

Als de ARP-ping niet helpt

Als de ARP-ping geen verbetering brengt, moet men niet willekeurig verdere opdrachten proberen. Dan is een gestructureerde afbakening zinvol.

Verdere controles:

Upstream-apparaat kan verouderde ARP-items nog vasthouden.
Provider moet ARP-cache of CPE opnieuw laden.
Alias-IP ligt op de verkeerde interface of in een verkeerd netwerk.
Openbare IP wordt door de provider gerouteerd in plaats van direct in het lokale segment via ARP geleerd.
DNAT-regel wijst naar het verkeerde openbare adres.
Firewall-regel staat het verkeer niet toe.
Interne server antwoordt via een andere gateway terug.
Bij HA of hardwarewissel werd het verkeerde MAC-adres verwacht.

Een herstart van de provider-CPE of een voorgeschakelde router kan ARP-caches legen, maar zou niet de eerste maatregel moeten zijn. In productieve omgevingen is het schoner om eerst bewijzen met Packet Capture en Log Viewer te verzamelen.

Provider of upstream gericht betrekken

Als op de WAN-interface geen pakketten voor het betreffende openbare IP aankomen, moet de aanvraag aan provider of upstream-verantwoordelijken zo concreet mogelijk zijn. Een algemene melding zoals “de firewall is niet bereikbaar” leidt vaak tot onnodige rondes. Beter is een kort technisch bewijs dat laat zien welk IP getroffen is en wat op de Sophos Firewall is gecontroleerd.

Nuttige gegevens:

Betreffende openbare IP of alias-IP: De provider kan gericht de ARP- of routing-item controleren.
WAN-interface en nieuw MAC-adres: Toont welke toewijzing na de migratie wordt verwacht.
Upstream-gateway of CPE-adres: Beperkt in welk buurapparaat het adres moet leren.
Tijdstip van de ARP-ping-test: Vergemakkelijkt de afstemming met provider-logs of CPE-status.
Packet-Capture-resultaat: Bewijst of pakketten de Sophos Firewall überhaupt bereiken.
Gecontroleerde DNAT- en firewall-regel: Voorkomt dat de zaak te snel als lokaal regelprobleem wordt ingedeeld. Het MAC-adres van de WAN-interface kan in de WebAdmin-interface onder Network > Interfaces worden gedocumenteerd. Als de provider een ARP-cache moet legen of een CPE opnieuw moet laden, moet dit betrekking hebben op het specifieke IP of de betreffende interface. Een algemene herstart van alle betrokken apparaten is alleen zinvol als verantwoordelijkheid, onderhoudsvenster en impact duidelijk zijn.

Checklist

Betreffende hoofd- en alias-IP-adressen gedocumenteerd.
Interface, zone, gateway en aliasconfiguratie gecontroleerd.
NAT- en firewall-regels voor het betreffende IP gecontroleerd.
Packet Capture toont of pakketten op de WAN-interface aankomen.
ARP-ping alleen met correcte bron-IP, interface en doel-IP uitgevoerd.
Externe bereikbaarheid na elke wijziging opnieuw getest.
Indien nodig provider of upstream-verantwoordelijken met concreet IP, MAC-adres, testtijdstip en Packet-Capture-observatie gecontacteerd.

FAQ

Moet men na elke firewall-migratie ARP handmatig bijwerken?

Nee. In veel omgevingen leren buurapparaten het nieuwe MAC-adres automatisch. Handmatige ARP-maatregelen zijn vooral relevant als bepaalde IP-adressen na de wissel niet bereikbaar zijn, hoewel de firewall-configuratie correct lijkt.

Is dit een NAT-probleem of een ARP-probleem?

Als pakketten in de Packet Capture helemaal niet op de WAN-interface aankomen, is NAT op de Sophos Firewall nog niet de eerste verdachte. Als pakketten aankomen, maar niet worden doorgeleid, moet men NAT, firewall-regels, zones en interne retourwegen controleren.

Waarom werkt het hoofd-IP, maar een alias-IP niet?

De upstream kan per IP-adres verschillende ARP-items hebben geleerd. Daarom kan een IP al correct naar het nieuwe MAC-adres wijzen, terwijl een andere nog naar de oude firewall verwijst.

Moet men routers of switches gewoon opnieuw starten?

Alleen als de ingreep operationeel verantwoord is en de verantwoordelijkheid duidelijk is. Beter is eerst een gerichte controle: Packet Capture op de Sophos Firewall, ARP-status op het upstream-apparaat en, indien mogelijk, gericht legen van de ARP-cache op het getroffen apparaat.

Heb je hiervoor de Advanced Shell nodig?

Nee. De getoonde ARP-ping wordt uitgevoerd in de Sophos Firewall Device Console. Advanced Shell is hiervoor niet nodig en moet voor eenvoudige migratiecontroles worden vermeden.