Åtgärda ARP-problem efter migrering av Sophos Firewall
Efter en brandväggsmigrering kan det hända att den nya Sophos Firewall i grunden är online, men att vissa offentliga IP-adresser eller alias-IP-adresser ändå inte är nåbara. Detta är särskilt vanligt efter ett byte från en annan tillverkare till Sophos Firewall eller efter en migrering från XG till XGS-hårdvara. IP-adresserna förblir desamma, men MAC-adressen på WAN-gränssnittet ändras.
Om en upstream-router, en leverantörs-CPE eller en switch fortfarande har gamla ARP-poster i cachen, skickar den paket till den tidigare MAC-adressen. Det verkar då som om endast vissa alias-IP-adresser, DNAT-mål eller ping-test inte fungerar. För allmän migrationsplanering passar även artikeln Vad är skillnaden mellan en XG och XGS Firewall?.
Typiska symtom
ARP-problem efter en omställning visar sig oftast direkt efter bytet eller efter en återställning på ny hårdvara.
Typiska indikationer:
- WAN-gränssnittet på Sophos Firewall är online.
- Huvud-IP-adressen fungerar, men vissa alias-IP-adresser gör det inte.
- Ping till vissa offentliga IP-adresser misslyckas, medan andra IP-adresser på samma gränssnitt svarar.
- DNAT- eller WAF-regler verkar korrekt konfigurerade men når inte den interna servern.
- En tjänst är nåbar internt men störd externt endast på vissa offentliga IP-adresser.
- Efter en tid fungerar det plötsligt eftersom en ARP-cache automatiskt löper ut.
Det är viktigt att avgränsa: Inte varje åtkomstproblem efter en migrering är ett ARP-problem. Brandväggsregler, NAT-regler, zoner, alias-konfiguration, leverantörsrouting och returvägar måste också kontrolleras.
Varför ARP kan störa efter en migrering
ARP löser IPv4-adresser till MAC-adresser. I ett lokalt lager-2-segment frågar en enhet: Vilken MAC-adress hör till denna IP-adress? Svaret lagras i ARP-cachen så att inte varje paket behöver utlösa en ny ARP-förfrågan.
Vid en brandväggsmigrering förblir IP-adressen ofta densamma, men MAC-adressen ändras. Detta kan vara problematiskt:
- Leverantörsroutern känner fortfarande den offentliga IP:n med den gamla MAC-adressen.
- En upstream-switch eller router håller föråldrade ARP-poster.
- En alias-IP har korrekt skapats på den nya brandväggen, men grannen skickar fortfarande till den gamla hårdvaran.
- Endast en del av IP:erna har redan lärt sig på nytt, därför fungerar vissa adresser och andra inte.
För enskilda alias-IP-adresser är detta särskilt förvirrande eftersom grundanslutningen verkar fungera. Man tittar då snabbt på NAT, brandväggsregler eller routing, även om felet redan uppstår på lager 2.
Kontrollera innan CLI-kommandot
Innan man aktivt triggar ARP bör grundkonfigurationen vara korrekt. Annars kommer en ARP-ping bara att dölja ett annat problem.
Kontrollera:
- Under Network > Interfaces kontrollera om den berörda IP-adressen eller alias-IP-adressen ligger på rätt gränssnitt.
- Kontrollera zonen för gränssnittet, till exempel
WAN. - Kontrollera gateway, subnätmask och alias-nätlogik.
- Under Rules and policies > NAT rules kontrollera om DNAT-regeln pekar på rätt offentlig IP.
- Under Rules and policies > Firewall rules kontrollera om det finns en lämplig regel för trafiken.
- I Log Viewer kontrollera om paket överhuvudtaget når brandväggen.
- Vid behov, med Sophos Firewall Packet Capture i WebAdmin, kontrollera om inkommande paket är synliga på WAN-gränssnittet.
Om inga paket för den berörda offentliga IP:n kommer fram i Packet Capture, ligger problemet troligen före brandväggen: leverantörsrouter, upstream-switch, ARP-cache eller routing hos leverantören. Om paket kommer fram men slängs, bör man först kontrollera NAT, brandväggsregler och zoner. För gränssnitts- och zonlogik hjälper Konfigurera zoner och gränssnitt på Sophos Firewall.
Utföra ARP-ping via Device Console
Sophos Firewall kan utlösa en ARP-ping med definierad käll-IP och gränssnitt via Device Console. Detta är användbart när en alias-IP efter migreringen aktivt ska göras känd i nätverket.
Viktigt: Kommandot bör endast utföras när det är klart vilken käll-IP, vilket gränssnitt och vilket mål i det lokala segmentet som används. Felaktiga värden hjälper inte och kan förvränga analysen. Innan ändringar görs i en produktiv migrering bör en aktuell Sophos Firewall Backup finnas tillgänglig.
Kommandot utförs i Device Console, inte i Advanced Shell:
system diagnostics utilities arp ping source <alias-ip> interface <interface> <target-ip>
Exempel:
system diagnostics utilities arp ping source 198.51.100.21 interface Port2 198.51.100.1
I detta exempel är 198.51.100.21 den berörda alias-IP:n på Port2. 198.51.100.1 är ett nåbart mål i samma lager-2-segment, vanligtvis upstream-gateway eller leverantörs-CPE. Detta genererar ARP-trafik med rätt käll-IP över rätt gränssnitt.
Om SSH ännu inte är inställt, beskriver Anslut till Sophos Firewall via SSH hur man når Device Console. Vid migreringar bör SSH inte tillåtas brett från WAN permanent. Bättre är en tillfällig, begränsad administrativ åtkomst från ett betrott nätverk.
Rekommenderad procedur
1. Samla berörda IP-adresser
Först dokumenteras vilka IP-adresser som fungerar och vilka som inte gör det. För alias-IP-adresser bör listan direkt jämföras med gränssnittskonfigurationen.
Notera:
- Gränssnitt, till exempel
Port2 - Huvud-IP och alias-IP-adresser
- Upstream-gateway eller leverantörs-CPE
- Berörda NAT- eller WAF-regler
- Resultat av ping, porttest och Packet Capture
2. Avgränsa ARP-problem
Från ett externt testsystem, kontrollera den berörda offentliga IP:n. Starta parallellt Packet Capture på Sophos Firewall på WAN-gränssnittet.
Tolkning:
- Inga paket kommer till WAN-gränssnittet: Kontrollera upstream, ARP, leverantörsrouting eller upstream-enhet.
- Paket kommer fram men slängs: Kontrollera brandväggsregel, NAT, zon eller tjänst.
- Paket kommer fram och går vidare internt, svar saknas: Kontrollera returväg, intern server, SNAT eller server-brandvägg.
- Endast alias-IP berörd, huvud-IP fungerar: Kontrollera ARP-cache eller alias-konfiguration specifikt.
3. Utför ARP-ping för varje berörd alias-IP
För varje berörd alias-IP utförs ARP-ping med rätt käll-IP och rätt gränssnitt. Därefter bör man inte omedelbart ändra flera andra saker, utan först testa om beteendet ändras.
Exempel med platshållare:
system diagnostics utilities arp ping source <berörd-alias-ip> interface <wan-interface> <upstream-gateway>
Om flera alias-IP-adresser är berörda utförs kommandot individuellt per adress. Detta gör kontrollen spårbar och förhindrar att man i slutändan inte vet vilken åtgärd som hjälpte.
4. Validera åtkomst
Efter ARP-ping bör samma test upprepas:
- Ping eller TCP-porttest från extern.
- Packet Capture på WAN-gränssnittet.
- Filtrera Log Viewer på den berörda mål-IP:n.
- Kontrollera NAT- och brandväggsregel om paket nu kommer fram.
Om upstream lär sig ARP-informationen korrekt på nytt, bör paket för alias-IP:n nu nå den nya brandväggen. Om den publicerade tjänsten därefter fungerar beror också på NAT, brandväggsregler, intern server och returväg.
Om ARP-ping inte hjälper
Om ARP-ping inte ger någon förbättring bör man inte prova ytterligare kommandon godtyckligt. Då är en strukturerad avgränsning meningsfull.
Ytterligare kontroller:
- Upstream-enhet kan fortfarande hålla föråldrade ARP-poster.
- Leverantören måste ladda om ARP-cache eller CPE.
- Alias-IP ligger på fel gränssnitt eller i ett felaktigt nät.
- Offentlig IP routas av leverantören istället för att läras direkt i det lokala segmentet via ARP.
- DNAT-regel pekar på fel offentlig adress.
- Brandväggsregel tillåter inte trafiken.
- Intern server svarar via en annan gateway tillbaka.
- Vid HA eller hårdvarubyte förväntades fel MAC-adress.
En omstart av leverantörs-CPE eller en upstream-router kan tömma ARP-cachar, men bör inte vara den första åtgärden. I produktiva miljöer är det renare att först samla bevis med Packet Capture och Log Viewer.
Involvera leverantör eller upstream specifikt
Om inga paket för den berörda offentliga IP:n kommer till WAN-gränssnittet bör förfrågan till leverantör eller upstream-ansvariga vara så konkret som möjligt. En allmän rapport som “brandväggen är inte nåbar” leder ofta till onödiga loopar. Bättre är ett kort tekniskt bevis som visar vilken IP som är berörd och vad som har kontrollerats på Sophos Firewall.
Hjälpsamma uppgifter:
- Berörd offentlig IP eller alias-IP: Leverantören kan specifikt kontrollera ARP- eller routingposten.
- WAN-gränssnitt och ny MAC-adress: Visar vilken tilldelning som förväntas efter migreringen.
- Upstream-gateway eller CPE-adress: Begränsar vilket grannsystem som måste lära sig adressen.
- Tidpunkt för ARP-ping-test: Underlättar jämförelse med leverantörsloggar eller CPE-status.
- Resultat av Packet Capture: Bevisar om paket överhuvudtaget når Sophos Firewall.
- Kontrollerad DNAT- och brandväggsregel: Förhindrar att fallet snabbt kategoriseras som ett lokalt regelproblem. MAC-adressen för WAN-gränssnittet kan dokumenteras i WebAdmin-gränssnittet under Network > Interfaces. Om leverantören behöver tömma en ARP-cache eller ladda om en CPE bör detta relateras till den specifika IP:n eller det berörda gränssnittet. En generell omstart av alla inblandade enheter är endast meningsfull om ansvar, underhållsfönster och påverkan är tydliga.
Checklista
- Dokumenterade berörda huvud- och alias-IP-adresser.
- Kontrollerade gränssnitt, zon, gateway och alias-konfiguration.
- Kontrollerade NAT- och brandväggsregler för den berörda IP:n.
- Packet Capture visar om paket når WAN-gränssnittet.
- ARP-ping utförd endast med korrekt käll-IP, gränssnitt och mål-IP.
- Extern åtkomst testad igen efter varje ändring.
- Vid behov kontaktade leverantör eller upstream-ansvariga med specifik IP, MAC-adress, testtidpunkt och Packet Capture-observation.