Skapa och testa en Custom Gateway på Sophos Firewall

En Custom Gateway beskriver på Sophos Firewall ett next hop på ett befintligt interface. Objektet är särskilt användbart för MPLS-, RED-, GRE- och adresserade XFRM-vägar eftersom det kan få en egen Health Check och zon och sedan användas i en SD-WAN-route.

Snabbt svar

En Custom Gateway skapas här:

Routing > Gateways > Add

För en MPLS-väg via Port4 anges exempelvis:

• Name: MPLS_Zurich_GW
• Gateway IP: 192.0.2.2
• Interface: Port4-192.0.2.1
• Zone: MPLS
• Health check: On
• Monitoring condition: PING till 10.20.0.10

Därefter måste gatewayen väljas i en passande SD-WAN-route och testas med brandväggsregeln, returvägen, Log viewer och verklig trafik. En grön statusikon bekräftar bara Health Check, inte att hela anslutningen fungerar.

⚠️ En Custom Gateway är inte en ytterligare fysisk WAN-gateway. Den visas inte under Network > WAN link manager och deltar inte i WAN-Load Balancing, inte ens om zonen WAN tilldelas.

Skilj mellan Custom Gateway, route och interface

Flera objekt har olika uppgifter i en fungerande väg:

• Ett interface ansluter brandväggen till transitnätet, exempelvis Port4, RED eller XFRM.
• Gateway IP är den direkt nåbara nästa routern på den här vägen.
• En Custom Gateway kombinerar Gateway IP, interface, zon och en valfri Health Check i ett återanvändbart objekt.
• En SD-WAN-route avgör vilken trafik som använder gatewayen.
• En brandväggsregel tillåter de planerade zonerna, näten och tjänsterna.
• Fjärrsidan behöver en passande returväg.

En vanlig statisk route kan innehålla Gateway IP direkt och behöver inget separat gatewayobjekt. En Custom Gateway blir användbar när SFOS ska övervaka vägen, välja den i en SD-WAN-route eller klassificera den säkerhetsmässigt med en gatewayzon.

Fysiska WAN-gateways skapas däremot automatiskt när ett WAN-interface konfigureras och hanteras som Active eller Backup i WAN link manager. Den här separationen förhindrar att en intern MPLS- eller tunnelväg av misstag behandlas som en internetanslutning.

Planera exempeltopologin

Det genomgående exemplet ansluter ett klientnät till ett fjärrservernät via en MPLS-router:

• Lokalt klientnät: 10.10.0.0/24
• Testklient: 10.10.0.10
• Brandväggsinterface: Port4 med 192.0.2.1/30
• MPLS-router: 192.0.2.2
• Fjärrnät: 10.20.0.0/24
• Stabil övervaknings- och testhost: 10.20.0.10
• Testtjänst: TCP 443
• Egen zon: MPLS av typen LAN

192.0.2.0/24 är ett dokumentationsnät och används inte i produktion. I den verkliga miljön ersätts interface-IP och Gateway IP tillsammans med det faktiska transitnätet. Fjärrnätet och övervakningshosten måste verkligen ligga bakom gatewayen. Zonen MPLS skapas i förväg under Network > Zones och skyddas enligt vägens tillitsnivå. Grunderna förklaras i zoner och interface på Sophos Firewall.

Före ändringen dokumenteras den befintliga routen, brandväggsreglerna, NAT-förväntningen och returvägen. En fjärrändring kräver dessutom en konfigurationsbackup, ett underhållsfönster och en oberoende administrationsväg.

Skapa en Custom Gateway

Ange gatewayens grundvärden

1. Öppna Routing > Gateways.
2. Klicka på Add under IPv4.
3. Ange MPLS_Zurich_GW som Name. Namnet kan väljas fritt men bör identifiera plats och väg.
4. Ange 192.0.2.2 som Gateway IP. Det är den direkt nåbara MPLS-routern, inte fjärrmålnätet.
5. Välj Port4-192.0.2.1 som Interface. Gateway IP och interface måste höra till samma nåbara transitväg.
6. Välj MPLS som Zone.

Sophos Firewall prioriterar gatewayzonen framför interfacezonen. Den tillämpas dock bara på trafik när gatewayen är vald i en matchande SD-WAN policy route. Med enbart en statisk route måste därför zonbeteendet testas separat. Zonen VPN kan inte tilldelas en Custom Gateway.

Gatewayzonen gäller inte för SD-WAN policy routes som migrerats från SFOS 18.0 MR1 eller äldre. I det fallet visar ett synligt zonfält inte i sig att en befintlig regel är korrekt. Testa först routen, zonmatchningen och verklig trafik i ett underhållsfönster.

Välj en Health Check som representerar vägen

Health check är avstängd som standard. För en övervakad MPLS-, RED- eller XFRM-väg aktiveras den och man börjar med de dokumenterade standardvärdena:

• Interval: 60 sekunder
• Time-out: 2 sekunder
• Retries: 3
• Protocol: PING
• IP address: 10.20.0.10

Övervakningshosten ligger medvetet bakom gatewayen. Om man bara kontrollerade direkt anslutna Gateway IP skulle routern kunna svara trots att MPLS- eller tunnelvägen längre bort är avbruten. För Custom Gateways på route-based VPN, RED och MPLS anger Sophos uttryckligen en host bakom gatewayen som testmål.

Alternativt kan TCP med en bestämd port användas. Det är lämpligt när kontrollen ska omfatta både IP-nåbarhet och en stabilt svarande tjänst. En TCP-kontroll på port 443 markerar dock gatewayen som otillgänglig när webbtjänsten fallerar, även om routingen fortfarande fungerar. Testmålet och protokollet måste därför representera den avsedda failoversignalen.

Med flera Monitoring Conditions gäller:

• AND: Alla villkor måste vara uppfyllda. Det är strikt, men ett enda otillgängligt mål kan orsaka en onödig omkoppling.
• OR: SFOS kontrollerar villkoren uppifrån och ned tills ett uppfylls. Det minskar falsklarm men kan dölja ett partiellt avbrott.

Interval, Time-out och Retries ska inte förkortas utan mätdata. Mät först normal latens och kortvarig paketförlust på den verkliga vägen. Alltför aggressiva värden kan få statusen att pendla mellan aktiv och inaktiv.

Efter att konfigurationen sparats visar Routing > Gateways med en statusikon om Health Check bedömer gatewayen som aktiv eller inaktiv.

Använd gatewayen i routingdesignen

Skapa en SD-WAN-route för exempeltrafiken

Ett gatewayobjekt vidarebefordrar inte trafik på egen hand. För exemplet skapas en SD-WAN-route:

1. Öppna Routing > SD-WAN routes > IPv4 > Add.
2. Ange Clients_to_Branch_MPLS som Name.
3. Välj det interna interfacet som Incoming interface.
4. Ange 10.10.0.0/24 under Source networks.
5. Ange 10.20.0.0/24 under Destination networks.
6. Välj först endast HTTPS, alltså TCP 443, under Services.
7. Använd Primary and backup gateways under Link selection settings.
8. Välj MPLS_Zurich_GW som Primary gateway.
9. Ange endast en verklig backupväg om den är fullständigt konfigurerad och testad.
10. Ställ in Route only through specified gateways medvetet: när alternativet är aktiverat kasserar SFOS trafiken om ingen angiven väg är tillgänglig; när det är avstängt kan en annan SD-WAN-route eller standardrouten ta över.
11. Spara routen och kontrollera dess position. Den första matchande SD-WAN-routen vinner.

Näten och tjänsten är miljöspecifika värden. En bred route med Any som källa, destination och tjänst kan matcha mycket mer trafik än planerat. För det första testet hålls matchningen därför snäv och utökas medvetet först efter godkänd verifiering.

Lägg till brandväggsregel och returväg

För den vidarebefordrade strömmen skapas en loggad regel från klientnätets källzon till gatewayzonen MPLS. Källa, destination och tjänst motsvarar SD-WAN-routen:

• Source zone: LAN
• Source network: 10.10.0.0/24
• Destination zone: MPLS
• Destination network: 10.20.0.0/24
• Services: HTTPS
• Log firewall traffic: aktiverat

Gatewayzonen ersätter inte en brandväggsregel. Omvänt framtvingar inte en regel i sig MPLS-vägen. Båda måste stämma överens med SD-WAN-routen. Skapa och testa Sophos Firewall-regler säkert förklarar den allmänna regelstrukturen.

Routern bakom fjärrnätet behöver en returväg till 10.10.0.0/24. Vid normal routing mellan platser behålls vanligtvis klientens ursprungliga IP. En bred MASQ-regel skulle dölja den och kan se ut att reparera returvägen men försämra routingdesignen.

Skilj XFRM, GRE och andra tunnelvägar

Med route-based IPsec i Any-to-Any får XFRM-interfacet en överförings-IP. En Custom Gateway använder då motpartens XFRM-IP som Gateway IP, lokalt XFRM som Interface och en stabil host i fjärrnätet som Monitoring Target. Den fullständiga tunnelkonfigurationen finns kvar i Konfigurera en site-to-site IPsec VPN.

Route-based IPsec med specifika traffic selectors fungerar annorlunda: SFOS skapar routen automatiskt och XFRM får varken en egen IP eller en manuell route. Tillämpa inte en gatewayprocedur för Any-to-Any på den här varianten utan kontroll.

En GRE-väg börjar inte heller med gatewayobjektet. Först valideras de yttre slutpunkterna, tunnel-IP-adresserna och GRE-funktionen enligt Konfigurera och testa en GRE-tunnel på Sophos Firewall. Om leverantörsdesignen därefter kräver ett SD-WAN-val använder Custom Gateway motpartens tunnel-IP som Gateway IP. Zon, Health Check och regelmatchning måste passa den konkreta designen; zonen VPN kan fortfarande inte väljas för Custom Gateways.

Verifiera gateway och trafik

Kontrollera status och användning

1. Under Routing > Gateways måste MPLS_Zurich_GW visas som aktiv.
2. Uppdatera Object usage och kontrollera att den förväntade SD-WAN-routen använder gatewayen.
3. Kontrollera återigen matchningskriterier, position och gateway i SD-WAN-routen.
4. Kontrollera modulen SD-WAN i Log viewer för gateway-, Health Check- och routehändelser.
5. Använd dgd.log som logg för Dead Gateway Detection vid djupare diagnostik. Sophos Firewall-tjänster och loggfiler förklarar sammanhanget.

En aktiv gatewaystatus bevisar bara att övervakningshosten svarar enligt det valda villkoret. Object Usage bevisar bara konfigurationsreferensen. Först nästa verkliga test bekräftar datavägen.

Testa ett verkligt trafikflöde

1. Starta en ny HTTPS-anslutning från testklienten 10.10.0.10 till 10.20.0.10.

2. Kontrollera källa, destination, tjänst, Firewall Rule ID, eventuellt NAT Rule ID och använd gateway i Log viewer.

3. Kontrollera Traffic Count för SD-WAN-routen.

4. Använd ett snävt BPF-filter under Diagnostics > Packet capture:

   host 10.20.0.10 and tcp port 443
   

5. Kontrollera att begäranden lämnar via Port4 och att svaren återkommer via samma planerade väg.

6. Kontrollera den verkliga käll-IP-adressen och returvägen på målsystemet.

Policy tester tar inte hänsyn till SD-WAN-routes. Det kan testa en matchning av en brandväggsregel men inte vilken gateway som faktiskt användes. Testa en Sophos Firewall-regel med Log Viewer och Packet Capture beskriver den kombinerade verifieringen.

Genomför bara ett failovertest med en separat verifierad backupväg, i ett underhållsfönster och med en oberoende administrationsväg. Ta inte bort den refererade produktionsgatewayen som testmetod. Efter det kontrollerade vägavbrottet testas en ny anslutning, gatewaystatus, offentlig eller privat käll-IP, returväg och failback på nytt. En avbrottsfri övergång förutsätts inte.

Avgränsa fel systematiskt

Gatewayen förblir inaktiv

• Gateway IP och interface måste beskriva samma direkt nåbara transitväg.
• Övervakningshosten måste verkligen ligga bakom gatewayen och svara tillförlitligt.
• Kontrollera med PING att ICMP tillåts längs hela vägen.
• Kontrollera med TCP rätt port och en tjänst som verkligen körs.
• Använd Packet Capture för att kontrollera att sonden och svaret använder förväntat interface.
• Ändra Interval, Time-out och Retries först efter kontroll av vägen.

Gatewayen är aktiv men programtrafiken fungerar inte

• SD-WAN-routen kan saknas, ligga för långt ned eller matcha andra värden för källa, destination eller tjänst.
• Brandväggsregelns Source zone och gatewayzon måste stämma med det verkliga flödet.
• Kontrollera Route Precedence, NAT och returvägen separat.
• Övervakningshosten kan vara nåbar även om en annan målhost eller tjänst ligger nere.
• En aktiv XFRM-gateway bevisar inte automatiskt att IPsec-SA, brandväggsregel och fjärrroute är korrekta.

Gatewayzonen verkar ignoreras

• Kontrollera att gatewayen verkligen är vald i den matchande SD-WAN policy route.
• Kontrollera interfacezonen och den brandväggsregel som faktiskt matchar när endast en statisk route används.
• Gatewayzonen gäller inte för en SD-WAN-route som migrerats från SFOS 18.0 MR1 eller äldre. Dölj inte vägen med en bred regel, utan modernisera routen och zonmodellen kontrollerat.
• Zonen VPN kan inte väljas för en Custom Gateway. Ett XFRM-interface är ändå ett VPN-interface och kräver en medveten regel- och routingdesign.

Statusen växlar onödigt mellan aktiv och inaktiv

• Kontrollera Probe Target avseende verklig tillgänglighet och rate limits.
• Mät normal latens och paketförlust innan värden ändras.
• Med AND kan ett enda mål göra hela gatewayen inaktiv.
• Med OR kan ett nåbart reservmål dölja ett partiellt avbrott.
• Använd inte kortare intervall eller Time-outs som en allmän stabilitetslösning.

Återställ säkert och hantera gatewayen

Före återställningen dokumenteras Object Usage, den ursprungliga routen och de ursprungliga brandväggsreglerna. Därefter:

1. Inaktivera den nya SD-WAN-routen eller återställ den tidigare vägen.
2. Kontrollera med en ny klientanslutning att den ursprungliga vägen fungerar igen.
3. Ta bort brandväggs- eller NAT-regler som bara skapades för testet när inga beroenden återstår.
4. Uppdatera Object Usage.
5. Ta bort Custom Gateway först när ingen route eller profil längre använder den.

Dokumentera i driften ansvarig person, Gateway IP, interface, zon, Probe Targets, protokoll, Interval, Time-out, Retries, routes som använder gatewayen och senaste failovertest. Efter ändringar av MPLS, RED, XFRM, zoner, SD-WAN eller övervakningshosten testas både status och verklig trafik på nytt.

FAQ