Firebox: nekad geolokalisering – hitta först steget i VPN-inträdet

Någon i ett annat land kan inte ansluta, och första instinkten är att titta på regeln som ger åtkomst till interna resurser. Den regeln körs efter admission, så den kan inte vara det som avvisar tunneln. Det blockerande steget finns någonstans i inträdesvägen, och Firebox har mer än en inträdesväg beroende på VPN-tjänsten. Gå igenom kontrollerna i ordning och stanna så snart en av dem förklarar avvisandet.

Kontroll 1: namnge den inkommande tjänsten

För Mobile VPN med SSL, Access Portal och BOVPN över TLS är det inkommande inträdet WatchGuard SSLVPN-policyn. Tillämpa den avsedda begränsningen där, på den faktiskt konfigurerade tjänsten, i stället för att härleda den från en regel för användaråtkomst som körs senare.

IPsec tar en annan väg. Den inbyggda IPSec-policyn tillåter extern IPsec-trafik till Firebox för de aktuella branch- och mobila VPN-tjänsterna, och den har företräde framför en manuellt skapad IPSec-policy. Om din klient är IKEv2 befinner du dig på den andra vägen, och SSLVPN-policyn är irrelevant.

Att göra fel här är den vanligaste bortkastade eftermiddagen inom det här området: att redigera en policy som aldrig ser paketet och sedan dra slutsatsen att begränsningen inte fungerar.

Kontroll 2: läs avvisandet, inte teorin

Gör ett kontrollerat tillåtet försök och korrelera fyra saker: klientens offentliga källadress, den inträdestjänst den träffade, policyn som matchade och eventuellt Deny-skäl i loggen. WatchGuards felsökningsvägledning för IKEv2 noterar att geolokalisering och standardhantering av paket kan neka trafik före den inbyggda policyns admission, vilket innebär att avvisandet du ser kan namnge ett steg du inte har övervägt.

Lands klassificering följer den observerade nätverkskällan. En roaminganvändare, en NAT uppströms eller en annan godkänd väg kan ändra vad Firebox ser, så bekräfta adressen i stället för användarens beskrivning av var hen befinner sig. Be om den offentliga adressen som klienten ser och jämför den med källan i Firebox-loggen. När de skiljer sig följer klassificeringen en väg som ingen nämnde.

Kontroll 3: äger den inbyggda policyn fortfarande vägen?

Om en manuell IPSec-policy verkar ignoreras, kontrollera om den inbyggda fortfarande är aktiverad. En manuell regel som skuggas av en inbyggd regel med högre prioritet och en manuell regel som är den enda admissionen är olika konfigurationer med ett likadant gränssnitt.

Bestäm vilken av dem som ska äga vägen. Är det den manuella policyn måste den inbyggda inaktiveras för den trafiken, och det är där nästa kontroll börjar.

Kontroll 4: planera ersättningen innan du inaktiverar

Att inaktivera den inbyggda IPSec-policyn tar bort dess admission för de berörda VPN-tjänsterna. Det omfattar branch-tunnlar som du kanske inte tänker på medan du lagar en mobil användares anslutning.

Planera den fullständiga ersättningen först: vilka tjänster som behöver admission, vilka källomfång de får och hur du hanterar boxen om ändringen går fel. Håll en oberoende hanterings- och återställningsväg öppen, eftersom ett misstag här kan ta bort tunneln du skulle använda för att fixa det. Anteckna återställningsstegen i ändringsloggen, inklusive hur du når boxen om VPN-vägen är borta. Testa sedan förnyelse, inte bara den första anslutningen.

Aktiv anslutning och senare omförhandling kan båda bero på admission. En ändring som fungerar för sessionen du testade men misslyckas vid nästa nyckelbyte är ett klassiskt utfall av att ersätta admission utan att testa förnyelse.

Kontroll 5: håll identitet åtskild från plats

Geolokalisering tillför kontext till ett inträdesbeslut. Den fastställer inte vem användaren är och bör inte ersätta gateway-identitetskontroller, kontobehörighet eller MFA.

Om affärskravet bara är godkända användare från godkända platser behöver du båda kontrollerna. En platsregel som släpper in ett helt land är ingen ersättning för autentisering, och en autentiserad användare i ett blockerat land är en policyfråga snarare än en bugg.

Kontroll 6: dokumentera det och verifiera båda vägarna

Skriv ned tjänsten, inträdespolicyn, det avsedda platsomfånget, undantagen och återställningsägaren. Testa sedan den mobila vägen och minst en platsväg efter ändringen, så att begränsningen förblir knuten till den tjänst den var avsedd att styra.

Läs till sist om avvisandet du började med. Har det ändrats från ett platsavvisande till ett autentiserings- eller behörighetsfel är inträdesproblemet löst och ett annat är nu synligt. WatchGuards vägledning för IKEv2-avvisanden är referensen för stegordningen som beskrivs ovan.