Åtgärda ARP-problem efter migrering av Sophos Firewall

Efter ett brandväggsbyte kan den nya Sophos Firewall vara online samtidigt som enskilda offentliga alias-IP-adresser fortfarande inte går att nå. Ofta känner upstream-routern fortfarande till dessa adresser med WAN-MAC-adressen för den gamla enheten. Paketen når då inte alls den nya brandväggen, även om alias, DNAT och brandväggsregel ser korrekta ut.

Den här guiden visar hur man avgränsar detta IPv4-problem genom att kontrollera gränssnitt, Packet Capture och upstream-ARP. Först när orsaken på lager 2 är bekräftad uppdateras ARP-cachen på enheten som har den inaktuella posten. För den allmänna maskinvarumigreringen passar även Jämför Sophos XG och XGS Appliance.

När ARP faktiskt är misstänkt

Felbilden börjar vanligtvis direkt efter ett enhetsbyte, en återställning eller ett tillverkarbyte. Den offentliga IP-adressen förblir densamma, men WAN-gränssnittets MAC-adress ändras.

Tydliga tecken är:

WAN-gränssnittets huvud-IP fungerar, men en eller flera alias-IP-adresser gör det inte.
Ett externt test når inte en publicerad tjänst på vissa offentliga IP-adresser.
Inget inkommande paket för den berörda IP-adressen visas i Packet Capture.
Tjänsten börjar plötsligt fungera när en upstream-cache löper ut, utan ytterligare ändringar i brandväggen.
Upstream-routern visar fortfarande den gamla enhetens MAC-adress för den offentliga IP-adressen.

ARP är inte automatiskt orsaken. Om paket når WAN-gränssnittet är nästa kontrollpunkt DNAT, brandväggsregel, zon, intern server eller returväg. Detta förfarande gäller inte heller för IPv6, där Neighbor Discovery hanterar grannupplösningen.

För att i stället kontrollera Sophos Firewalls lokala ARP- eller NDP-cache, se Kontrollera ARP- och NDP-granncachen. Där förklaras också när cachen bör tömmas och när problemet fortfarande finns hos operatören eller upstream-enheten.

Varför alias-IP-adresser kan sluta fungera efter ett byte

ARP kopplar en IPv4-adress till en MAC-adress i det lokala lager 2-segmentet. En router sparar denna koppling i ARP-cachen. Efter bytet ska upstream-enheten lära sig den nya brandväggens WAN-MAC-adress. Om det inte sker för en alias-IP skickar den fortfarande paketen till den gamla maskinvaran.

Det förklarar varför huvud-IP-adressen kan fungera medan en alias-IP inte gör det: upstream-enheten har en separat post för varje IP-adress. En koppling kan redan vara aktuell medan en annan fortfarande pekar på den gamla MAC-adressen.

Först måste man dock klargöra hur leverantören tillhandahåller de offentliga adresserna:

Direktanslutet nät: Upstream-enheten slår upp huvud- och alias-IP-adresser via ARP. Gamla poster är rimliga efter ett maskinvarubyte.
Routat offentligt block: Leverantören routar blocket till den primära WAN-IP-adressen. Då förväntas inte nödvändigtvis en separat ARP-post för varje offentlig IP-adress; leverantörens route och den lokala alias-/NAT-konfigurationen är viktigare.

Diagnos före åtgärd

Diagnosen ska först visa var paketflödet upphör. På så sätt undviker man att ändra ARP, NAT och brandväggsregler samtidigt.

Kontrollera det fysiska WAN-gränssnittet och de berörda adresserna under Network > Interfaces. En alias-IP kopplas till rätt fysiskt gränssnitt via Add interface > Add alias; IP-version, adress och nätmask måste stämma med designen. Om det finns fler än tre alias visar SFOS först bara tre adresser. Håll pekaren över en synlig adress och bläddra i listan innan ett alias som verkar saknas skapas på nytt.
Om alias-adresserna kommer från ett annat subnät måste interna värdar använda Sophos Firewall som standardgateway, och upstream-enheten måste ha en adress i varje aliassubnät som fungerar som en nåbar gateway för brandväggen. Enligt Sophos orsakar flera separata WAN-gränssnitt i samma subnät ARP-problem och onåbara gateways; använd alias- eller LAG-gränssnitt beroende på designen.
Testa samma offentliga IP-adress och samma tjänst från ett verkligt externt testsystem. Enbart ping räcker inte eftersom ICMP kan vara blockerat; komplettera helst med ett test mot en känd TCP-port.
Aktivera infångningen under Diagnostics > Packet capture och öppna Display filter. Välj Interface name och Ethernet type: ARP för lager 2-kontrollen. För tjänsten väljer du Ethernet type: IPv4, berörd Destination IP och vid behov Destination port. Utan Wrap capture buffer once full stoppas infångningen när bufferten på 2048 KB är full; klicka på Clear och upprepa sedan det reproducerbara testet. Med alternativet aktiverat fortsätter infångningen från buffertens början och skriver över äldre paket.
Först när IP-paket kommer fram söker man i Log viewer efter mål-IP, tjänst samt Firewall Rule ID och NAT Rule ID. ARP bedöms med Packet Capture, inte via en vanlig logg för en brandväggsregel.

Använd Packet Capture på Sophos Firewall förklarar visningen mer ingående. För kontroll av gränssnitt, zon och aliaskoppling hjälper Konfigurera zoner och gränssnitt på Sophos Firewall.

Observationen pekar ut en tydlig riktning:

Inget IPv4-paket på WAN: Kontrollera upstream-ARP, leverantörsrouting, CPE eller upstream-switch.
Status Incoming eller Violation: Paketet når brandväggen. Vid Violation ger Reason, brandväggsregel, DNAT, zon och tjänst nästa ledtrådar.
Status Forwarded, men svar saknas: Kontrollera returväg, intern server, SNAT och serverbrandvägg.
Endast alias-IP berörs: Jämför aliaskonfigurationen och upstream-posten specifikt för denna IP-adress.

Uppdatera ARP-kopplingen på upstream-enheten

Den renaste korrigeringen görs på enheten som innehåller den felaktiga posten. Om man administrerar upstream-routern eller leverantörens CPE tar man bort ARP-posten specifikt för den berörda IP-adressen. Därefter måste upstream-enheten lära sig den nya WAN-MAC-adressen.

Om posten inte kan tas bort specifikt anger Sophos en omstart av den berörda routern som alternativ. Det ska göras under ett underhållsfönster eftersom en omstart avbryter andra anslutningar och inte kan ångras. Att ta bort en dynamisk post kräver ingen konfigurationsåterställning: routern lär sig den på nytt. Om migreringen återställs tar du bort posten igen efter att den gamla enheten har anslutits, så att den gamla MAC-adressen kan läras in. För leverantörsenheter ska leverantören få den berörda IP-adressen, den gamla och den nya MAC-adressen samt berörd CPE.

Ingen ytterligare Device Console-kommandorad behövs för den här korrigeringen. Den aktuella SFOS 22-hjälpen anger uttryckligen att routercachen ska tömmas eller routern startas om för inaktuella ARP-poster för alias. Om leverantören routar adresserna i stället för att slå upp dem lokalt via ARP har båda åtgärderna på en aliaspost ingen effekt; kontrollera då leverantörens route och den lokala alias- eller NAT-konfigurationen.

Validera åtkomsten efter korrigeringen

Efter exakt en åtgärd upprepas samma test. Då går det att se vad som löste felet.

Kontrollera i upstream-enheten att den berörda IP-adressen nu pekar på den nya WAN-MAC-adressen.
Upprepa det externa ping- eller TCP-porttestet med identisk källa och identiskt mål.
Kontrollera i Packet Capture att paketen nu kommer fram till WAN-gränssnittet.
Om paketen kommer fram kontrollerar man Firewall Rule ID och NAT Rule ID i Log Viewer.
Testa den publicerade tjänsten hela vägen till den interna servern och tillbaka.

En uppdaterad ARP-post bevisar endast att upstream-enheten kan skicka paketen till den nya brandväggen. Om tjänsten fungerar beror fortfarande på DNAT, brandväggsregel, internt mål och returväg. Publicera en server via DNAT visar hela regelflödet för serverpublicering.

Om störningen kvarstår

Om IP-adressen fortfarande inte går att nå trots en uppdaterad ARP-post bör man inte prova fler shell-kommandon, utan byta hypotes.

Typiska alternativ är:

Alias-IP-adressen ligger på fel fysiskt gränssnitt eller använder fel nätmask.
Leverantören routar det offentliga blocket på ett annat sätt än förväntat.
En statisk ARP- eller MAC-post i upstream-enheten åsidosätter dynamisk inlärning.
En upstream-switch behåller en gammal MAC-koppling eller använder Port Security.
DNAT-regeln pekar på en annan offentlig IP-adress.
Brandväggsregeln tillåter inte källan, tjänsten eller zonen.
Den interna servern svarar via en annan gateway.
Vid HA svarar den primära enheten på ARP-förfrågningar med gränssnittets virtuella MAC-adress. Endast virtuella appliances där Use host or hypervisor-assigned MAC address har valts använder i stället MAC-adressen som tilldelats av värden eller hypervisorn.

Ett återkommande bortfall av ARP är inte heller ett fall för ett periodiskt eget kommando. Då måste leverantören, CPE, lager 2-designen och vid behov Sophos Support utreda orsaken.

Involvera leverantör eller upstream specifikt

Om paketinfångningen på WAN inte visar några paket för den berörda IP-adressen behöver leverantören ett precist resultat i stället för ett allmänt besked om att brandväggen inte går att nå.

Ha följande information till hands:

berörd huvud- eller alias-IP,
WAN-gränssnitt och ny MAC-adress,
upstream-gateway eller CPE,
tidpunkt för det externa testet och cachetömningen eller omstarten,
resultat från Packet Capture,
förväntad leverans som direktanslutet eller routat nät,
resultat för huvud-IP och övriga alias-IP-adresser.

Med denna information kan leverantören kontrollera den specifika ARP-posten, en statisk koppling eller rutten till det offentliga blocket. Känsliga konfigurationsuppgifter eller fullständiga Packet Captures ska endast överföras via en överenskommen supportkanal.

Kortfattad slutkontroll

Huvud- och alias-IP-adresser samt leveranssätt är dokumenterade.
Fysiskt gränssnitt, IP-version och nätmask har kontrollerats.
Externt TCP-test och Packet Capture har genomförts med identiska mål.
ARP- och IP-trafik har bedömts separat i diagnostiken.
Upstream-posten har tagits bort specifikt eller routern har startats om under ett samordnat underhållsfönster.
Den nya MAC-kopplingen har bekräftats i upstream-enheten.
DNAT, Firewall Rule ID, NAT Rule ID och returväg har kontrollerats i nästa steg.
Orsak och åtgärd har dokumenterats i ändrings- eller migreringsprotokollet.

FAQ

Måste ARP-cachen tömmas efter varje brandväggsmigrering?

Nej. Normalt lär sig upstream-enheten den nya MAC-adressen automatiskt. Man behöver ingripa först när en specifik post förblir inaktuell och Packet Capture visar att den berörda IP-adressen inte når den nya brandväggen.

Varför fungerar huvud-IP-adressen men inte en alias-IP?

Upstream-enheten sparar kopplingen per IPv4-adress. Huvud-IP-adressens post kan redan peka på den nya WAN-MAC-adressen medan en alias-IP fortfarande är kopplad till den gamla MAC-adressen.

Är detta ett problem med ARP, NAT eller brandväggsregeln?

Om inget paket når WAN-gränssnittet under det externa testet ligger orsaken före den lokala utvärderingen av DNAT och brandväggsregler. Om paketet kommer fram kontrolleras NAT Rule ID, Firewall Rule ID, internt mål och returväg.

Kan man helt enkelt starta om leverantörens CPE?

En omstart kan förnya ARP-cachen men avbryter även andra anslutningar. Det är bättre att ta bort den berörda posten specifikt. Om det inte är möjligt ska omstarten göras under ett samordnat underhållsfönster.