ARP-problemen na een Sophos Firewall-migratie oplossen

Na een firewallwissel kan de nieuwe Sophos Firewall online zijn, terwijl afzonderlijke openbare alias-IP-adressen onbereikbaar blijven. Vaak kent de upstreamrouter deze adressen nog met het WAN-MAC-adres van de oude appliance. De pakketten bereiken de nieuwe firewall dan helemaal niet, ook al lijken de alias, DNAT en firewallregel correct.

Deze handleiding laat zien hoe u dit IPv4-probleem afbakent met een controle van de interface, Packet Capture en upstream-ARP. Pas wanneer de Layer 2-oorzaak is aangetoond, werkt u de ARP-cache gericht bij of voert u een ARP-ping uit via de Device Console. Voor de algemene hardwaremigratie is ook Sophos XG en XGS vergelijken relevant.

Wanneer ARP daadwerkelijk verdacht is

Het probleem doet zich meestal direct voor na de vervanging van een appliance, een restore of een overstap naar een andere fabrikant. Het openbare IP-adres blijft gelijk, maar het MAC-adres van de WAN-interface verandert.

Sterke aanwijzingen zijn:

Het primaire IP-adres van de WAN-interface werkt, maar een of meer alias-IP-adressen niet.
Een externe test bereikt een gepubliceerde service op bepaalde openbare IP-adressen niet.
In Packet Capture verschijnt geen inkomend pakket voor het betreffende IP-adres.
De service werkt na het verlopen van een upstreamcache plotseling zonder verdere firewallwijziging.
De upstreamrouter toont voor het openbare IP-adres nog het MAC-adres van de oude appliance.

ARP is niet automatisch de oorzaak. Als pakketten op de WAN-interface aankomen, controleert u vervolgens DNAT, de firewallregel, de zone, de interne server en de retourroute. Deze procedure geldt ook niet voor IPv6; daar verzorgt Neighbor Discovery de buurdetectie en adresresolutie.

Waarom alias-IP-adressen na een vervanging kunnen uitvallen

ARP koppelt een IPv4-adres aan een MAC-adres in het lokale Layer 2-segment. Een router slaat deze koppeling op in de ARP-cache. Na de vervanging moet de upstream het WAN-MAC-adres van de nieuwe firewall leren. Gebeurt dit niet voor een alias-IP-adres, dan stuurt de upstream de pakketten nog steeds naar de oude hardware.

Dit verklaart waarom het primaire IP-adres kan werken terwijl een alias-IP-adres uitvalt: de upstream houdt per IP-adres een afzonderlijk item bij. De ene koppeling kan al actueel zijn, terwijl een andere nog naar het oude MAC-adres verwijst.

Eerst moet echter duidelijk zijn hoe de provider de openbare adressen beschikbaar stelt:

Direct verbonden netwerk: De upstream lost primaire en alias-IP-adressen op via ARP. Verouderde items na een hardwarewissel zijn dan aannemelijk.
Gerouteerd openbaar blok: De provider routeert het blok naar het primaire WAN-IP-adres. In dat geval wordt niet noodzakelijk voor elk openbaar IP-adres een afzonderlijk ARP-item verwacht; de providerroute en de lokale alias- en NAT-configuratie zijn dan belangrijker.

Diagnose vóór de ingreep

De diagnose moet eerst aantonen waar de pakketstroom eindigt. Zo voorkomt u dat ARP, NAT en firewallregels tegelijkertijd worden gewijzigd.

Controleer onder Network > Interfaces de fysieke WAN-interface en de betrokken adressen. Een alias-IP-adres wordt via Add interface > Add alias aan de juiste fysieke interface gekoppeld; IP-versie, adres en subnetmasker moeten bij het ontwerp passen.
Als aliasadressen uit een ander subnet komen, controleert u of de upstream in dat subnet als gateway voor de firewall bereikbaar is. Meerdere afzonderlijke WAN-interfaces in hetzelfde subnet zijn geen nette oplossing en kunnen zelf ARP-problemen veroorzaken; afhankelijk van het ontwerp zijn daarvoor alias- of LAG-interfaces bedoeld.
Test vanaf een echt extern testsysteem hetzelfde openbare IP-adres en dezelfde service. Alleen een ping is niet voldoende, omdat ICMP geblokkeerd kan zijn; gebruik daarnaast bij voorkeur een test op een bekende TCP-poort.
Maak onder Diagnostics > Packet capture een capture op de WAN-interface. Filter voor de Layer 2-controle op de interface en Ethernet type: ARP; filter voor de service vervolgens op het betreffende doel-IP-adres en protocol.
Zoek pas wanneer IP-pakketten aankomen in Log viewer naar het doel-IP-adres, de service, Firewall Rule ID en NAT Rule ID. ARP zelf beoordeelt u met Packet Capture, niet via de normale logging van een firewallregel.

Packet Capture op Sophos Firewall gebruiken licht de weergave nader toe. Voor de controle van interface, zone en aliastoewijzing helpt Sophos Firewall-zones en -interfaces configureren.

De waarneming bepaalt de verdere richting:

Geen pakketten op WAN: Controleer upstream-ARP, providerrouting, CPE of een upstreamswitch.
Pakketten komen aan en worden geweigerd: Controleer firewallregel, DNAT, zone en service.
Pakketten worden intern doorgestuurd, maar het antwoord ontbreekt: Controleer de retourroute, interne server, SNAT en serverfirewall.
Alleen het alias-IP-adres is getroffen: Vergelijk de aliasconfiguratie en het upstreamitem specifiek voor dit IP-adres.

ARP-koppeling gericht bijwerken

Upstreamcache legen

De meest gerichte correctie vindt plaats op het apparaat dat het verkeerde item bijhoudt. Als u de upstreamrouter of het provider-CPE beheert, verwijdert u het ARP-item specifiek voor het betreffende IP-adres. Daarna moet de upstream het nieuwe WAN-MAC-adres leren.

Als gericht legen niet mogelijk is, kan een herstart van de verantwoordelijke router de cache eveneens vernieuwen. Plan dit in een onderhoudsvenster, omdat een herstart ook andere verbindingen onderbreekt. Bij providerapparatuur moet de provider het betreffende IP-adres, het oude en nieuwe MAC-adres en het verantwoordelijke CPE kennen, in plaats van zonder onderscheid het hele traject opnieuw te starten.

ARP-ping uitvoeren via de Device Console

Sophos Firewall biedt in de Device Console een ARP-diagnose. Met een ARP-ping vanaf het betreffende bron-IP-adres en via de WAN-interface kunt u een update op de direct verbonden upstream uitlokken.

Open na aanmelding via de console of SSH Option 4: Device Console en voer de opdracht met de werkelijke waarden uit:

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

Voorbeeld met documentatieadressen:

system diagnostics utilities arp ping source 198.51.100.21 interface Port2 198.51.100.1

198.51.100.21 is hier het betreffende alias-IP-adres op Port2; 198.51.100.1 is de rechtstreeks bereikbare upstream in hetzelfde Layer 2-segment. Bron-IP-adres, interface en doel moeten bij elkaar passen. Bij meerdere betrokken alias-IP-adressen test u elk adres afzonderlijk, zodat het effect traceerbaar blijft.

De opdracht vervangt noch een onjuiste aliasconfiguratie, noch de correctie van een statisch ARP-item bij de provider. Als de provider de adressen routeert en niet lokaal via ARP omzet, is de ARP-ping evenmin de juiste oplossing. Via SSH verbinding maken met Sophos Firewall beschrijft veilige toegang tot de Device Console.

Bereikbaarheid na de correctie valideren

Herhaal na precies één maatregel dezelfde test. Zo blijft duidelijk welke actie het probleem heeft opgelost.

Controleer op de upstream of het betreffende IP-adres nu naar het nieuwe WAN-MAC-adres verwijst.
Herhaal de externe ping- of TCP-poorttest met dezelfde bron en hetzelfde doel.
Controleer in Packet Capture of de pakketten nu op de WAN-interface aankomen.
Als de pakketten aankomen, controleert u de Firewall Rule ID en NAT Rule ID in Log Viewer.
Test de gepubliceerde service tot aan de interne server en via het retourpad.

Een bijgewerkt ARP-item bewijst alleen dat de upstream de pakketten naar de nieuwe firewall kan sturen. Of de service werkt, hangt nog steeds af van DNAT, de firewallregel, het interne doel en de retourroute. Een server publiceren via DNAT toont het volledige regelpad voor het publiceren van een server.

Als de storing blijft bestaan

Als het IP-adres ondanks het bijgewerkte ARP-item onbereikbaar blijft, moet u niet meer shellopdrachten uitproberen, maar de hypothese wijzigen.

Typische alternatieven zijn:

Het alias-IP-adres bevindt zich op de verkeerde fysieke interface of gebruikt een onjuist subnetmasker.
De provider routeert het openbare blok anders dan verondersteld.
Een statisch ARP- of MAC-item op de upstream heeft voorrang op dynamisch leren.
Een upstreamswitch houdt een oude MAC-koppeling vast of gebruikt Port Security.
De DNAT-regel verwijst naar een ander openbaar IP-adres.
De firewallregel staat de bron, service of zone niet toe.
De interne server antwoordt via een andere gateway.
Bij HA wordt het verkeerde virtuele of fysieke MAC-adres verwacht.

Ook een permanent terugkerend ARP-verlies is geen reden voor een periodiek uitgevoerde zelfgeschreven opdracht. In dat geval moeten de provider, het CPE, het Layer 2-ontwerp en indien nodig Sophos Support de oorzaak onderzoeken.

Provider of upstream gericht inschakelen

Als de WAN-capture geen pakketten voor het betreffende IP-adres toont, heeft de provider een precieze bevinding nodig in plaats van de algemene melding dat de firewall niet bereikbaar is.

Houd de volgende gegevens bij de hand:

betrokken primair of alias-IP-adres,
WAN-interface en nieuw MAC-adres,
upstreamgateway of CPE,
tijdstip van de externe test en de ARP-ping,
resultaat van Packet Capture,
verwachte levering als direct verbonden of gerouteerd netwerk,
resultaat voor het primaire IP-adres en andere alias-IP-adressen.

Met deze gegevens kan de provider het specifieke ARP-item, een statische koppeling of de route naar het openbare blok controleren. Deel gevoelige configuratiegegevens of volledige Packet Captures uitsluitend via een afgesproken supportkanaal.

Beknopte eindcontrole

Primaire en alias-IP-adressen en de aanleveringswijze zijn gedocumenteerd.
Fysieke interface, IP-versie en subnetmasker zijn gecontroleerd.
Externe TCP-test en Packet Capture zijn met dezelfde doelen uitgevoerd.
ARP- en IP-verkeer zijn tijdens de diagnose afzonderlijk beoordeeld.
Het upstreamitem is gericht verwijderd of de ARP-ping is met de juiste parameters uitgevoerd.
De nieuwe MAC-koppeling is op de upstream bevestigd.
DNAT, Firewall Rule ID, NAT Rule ID en retourpad zijn aansluitend gecontroleerd.
Oorzaak en maatregel zijn vastgelegd in het change- of migratielogboek.

FAQ

Moet de ARP-cache na elke firewallmigratie worden geleegd?

Nee. Normaal gesproken leert de upstream het nieuwe MAC-adres automatisch. U hoeft pas in te grijpen wanneer een specifiek item verouderd blijft en Packet Capture laat zien dat het betreffende IP-adres de nieuwe firewall niet bereikt.

Waarom werkt het primaire IP-adres wel, maar een alias-IP-adres niet?

De upstream slaat de koppeling per IPv4-adres op. Het item voor het primaire IP-adres kan al naar het nieuwe WAN-MAC-adres verwijzen, terwijl een alias-IP-adres nog aan het oude MAC-adres is gekoppeld.

Is dit een ARP-, NAT- of firewallregelprobleem?

Als tijdens de externe test geen pakket op de WAN-interface aankomt, ligt de oorzaak vóór de lokale DNAT- en firewallevaluatie. Als het pakket wel aankomt, controleert u de NAT Rule ID, Firewall Rule ID, het interne doel en de retourroute.

Kan het provider-CPE gewoon opnieuw worden gestart?

Een herstart kan de ARP-cache vernieuwen, maar onderbreekt ook andere verbindingen. Het is beter om het betreffende item gericht te verwijderen; anders hoort de herstart thuis in een afgestemd onderhoudsvenster.

Heeft de ARP-ping de Advanced Shell nodig?

Nee. system diagnostics utilities arp ping wordt uitgevoerd in de Device Console. De Advanced Shell is hiervoor niet nodig.