Å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 specifikt eller så utlöses en ARP-ping via Device Console. För den allmänna maskinvarumigreringen passar även Jämför Sophos XG och XGS.

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.

1. 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.
2. Om alias-adresserna kommer från ett annat subnät ska man kontrollera att upstream-enheten i detta subnät kan nås som gateway för brandväggen. Flera separata WAN-gränssnitt i samma subnät är ingen ren lösning och kan själva orsaka ARP-problem. Beroende på designen används alias- eller LAG-gränssnitt för detta.
3. 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.
4. Fånga trafik på WAN-gränssnittet under Diagnostics > Packet capture. Filtrera efter gränssnitt och Ethernet type: ARP för lager 2-kontrollen och därefter efter berörd mål-IP och protokoll för tjänsten.
5. 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:

• Inga paket på WAN: Kontrollera upstream-ARP, leverantörsrouting, CPE eller upstream-switch.
• Paketen kommer fram och släpps: Kontrollera brandväggsregel, DNAT, zon och tjänst.
• Paketen vidarebefordras internt 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 specifikt

Töm upstream-cachen

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 kan en omstart av den berörda routern också förnya cachen. Det ska göras under ett underhållsfönster eftersom en omstart avbryter fler anslutningar. För leverantörsenheter bör leverantören få den berörda IP-adressen, den gamla och den nya MAC-adressen samt berörd CPE, i stället för att hela sträckan startas om utan avgränsning.

Utlös ARP-ping via Device Console

Sophos Firewall har en ARP-diagnos i Device Console. En ARP-ping kan med den berörda Source-IP-adressen och WAN-gränssnittet initiera en uppdatering hos den direktanslutna upstream-enheten.

Öppna Option 4: Device Console efter inloggning via konsol eller SSH och kör kommandot med de verkliga värdena:

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

Exempel med dokumentationsadresser:

system diagnostics utilities arp ping source 198.51.100.21 interface Port2 198.51.100.1

Här är 198.51.100.21 den berörda alias-IP-adressen på Port2, och 198.51.100.1 är den direkt nåbara upstream-enheten i samma lager 2-segment. Source-IP, Interface och mål måste passa ihop. Om flera alias-IP-adresser berörs testas varje adress separat så att effekten går att följa.

Kommandot ersätter varken en felaktig aliaskonfiguration eller korrigeringen av en statisk ARP-post hos leverantören. Om leverantören routar adresserna och inte slår upp dem lokalt via ARP är ARP-ping inte heller rätt lösning. Anslut till Sophos Firewall via SSH beskriver säker åtkomst till Device Console.

Validera åtkomsten efter korrigeringen

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

1. Kontrollera i upstream-enheten att den berörda IP-adressen nu pekar på den nya WAN-MAC-adressen.
2. Upprepa det externa ping- eller TCP-porttestet med identisk källa och identiskt mål.
3. Kontrollera i Packet Capture att paketen nu kommer fram till WAN-gränssnittet.
4. Om paketen kommer fram kontrollerar man Firewall Rule ID och NAT Rule ID i Log Viewer.
5. 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 förväntas fel virtuell eller fysisk MAC-adress.

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 ARP-ping,
• 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 ARP-ping har körts med rätt parametrar.
• 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