Publicera en server via DNAT på Sophos Firewall

Med DNAT publiceras en intern server via en publik IP-adress eller port. Sophos Firewall vidarebefordrar sedan inkommande trafik till den interna målservern. Typiska exempel är webbservrar, reverse proxy-servrar, VPN-gateways och andra tjänster i en DMZ.

För det bredare hardening-sammanhanget passar hubben Sophos Firewall Hardening: best practices för säker konfiguration.

Artikeln förklarar vad som ska kontrolleras före och efter att en DNAT-regel skapas och hur publiceringen begränsas och säkras så långt som möjligt.

Planering innan publicering

Innan en tjänst publiceras via DNAT ska det vara klart om publik åtkomst verkligen behövs och vilken teknisk variant som passar bäst. God planering förhindrar onödigt öppna portar, dubbla NAT-regler och svårspårade returvägar.

Krav

• Offentlig IP-adress eller WAN-gränssnitt
• Intern server med fast IP-adress
• Känd tjänst och port, till exempel TCP 443
• Lämplig brandväggsregel
• Valfritt: IPS, webbserverskydd eller omvänd proxy beroende på tjänsten

⚠️ DNAT publicerar en intern tjänst mot omvärlden. Varje publicerad tjänst ökar attackytan. Endast det som verkligen behövs ska publiceras. Källa, port och destination ska begränsas så långt som möjligt.

Förtydliga i förväg

Följande frågor ska besvaras innan regeln konfigureras:

• Vilket offentligt IP- eller WAN-gränssnitt används?
• Vilken extern port ska vara tillgänglig?
• Vilken intern IP vidarebefordras till?
• Förblir porten densamma eller är den översatt?
• Bör åtkomst tillåtas överallt eller endast från vissa källnätverk?
• Måste Source NAT eller Reflexive NAT beaktas?
• Finns det ett behov av en Loopback-regel för interna klienter som använder den offentliga FQDN?
• Kommer endast en intern server att publiceras eller flera servrar med Load Balancing?
• Finns det redan en regel som använder samma port?
• Finns Sophos Firewall direkt på Internet eller bakom en leverantörsrouter?
• Behöver ytterligare regler öppnas i en Cloud Security Group?

Denna information förhindrar senare konflikter med befintliga NAT eller brandväggsregler.

Om termerna Original source, Original destination, Translated destination, Translated service, Loopback eller Reflexive Rule fortfarande är oklara bör du först läsa Förstå NAT på Sophos Firewall: SNAT, DNAT, MASQ, PAT. Den här sidan fokuserar på den specifika publiceringen av en intern tjänst.

DNAT, WAF, VPN eller ZTNA?

Inte alla offentligt tillgängliga tjänster bör publiceras automatiskt via DNAT. DNAT är tekniskt enkelt, men också väldigt direkt: Brandväggen vidarebefordrar en port till en intern destination. Om detta är vettigt beror på tjänsten, källorna och behovet av skydd.

• Icke-HTTP-tjänst med tydligt definierade källor: DNAT med snäva källbegränsningar, loggning och IPS kan passa.
• Offentlig HTTP- eller HTTPS-applikation: Kontrollera först Sophos Firewall WAF.
• Administrativ åtkomst som SSH eller RDP: Använd Clientless SSL VPN för enskilda fasta mål, annars VPN, ZTNA eller en fast käll-IP i stället för öppen DNAT.
• Endast åtkomst för ett fåtal partners eller platser: Föredra käll-IP-begränsning, VPN eller en site-to-site-anslutning.
• Applikationen bör vara tillgänglig internt och externt under samma namn: Kontrollera split DNS eller avsiktligt planerad Loopback regel.

För klassiska webbapplikationer är WAF ofta en bättre utgångspunkt eftersom värdnamn, certifikat, sökvägar, webbskyddsprofiler och eventuellt autentisering kan tas med i beräkningen. För administrativ åtkomst bör DNAT endast användas i undantagsfall. Om en intern tjänst egentligen inte behöver vara offentlig är VPN eller en ZTNA-arkitektur vanligtvis en renare lösning. De befintliga ZTNA grunderna finns i Hur man ställer in Sophos ZTNA och Skapa Sophos ZTNA gateway.

Om brandväggen ligger bakom en router

DNAT fungerar även om Sophos Firewall inte själv har den publika IP-adressen utan ligger bakom leverantörens NAT-router.

I det här fallet krävs två portvidarebefordringar:

1. På leverantörsroutern vidarebefordras den publika porten till Sophos Firewalls WAN-IP.
2. På Sophos Firewall vidarebefordras porten till den interna servern via DNAT.

Många leverantörsroutrar erbjuder klassisk portvidarebefordran eller en funktion som Exposed Host eller DMZ Host. Med en exponerad värdfunktion vidarebefordras ofta många eller alla inkommande portar till brandväggen. Detta kan vara praktiskt, men bör säkras medvetet eftersom den faktiska kontrollen då ligger helt hos Sophos Firewall.

Om det inte finns någon fast publik IP kan du använda DynDNS. Det är fortfarande viktigt: Portvidarebefordran på leverantörens router måste peka på Sophos Firewall.

Med en extra publik IPv4-adress i ett direkt anslutet WAN-segment kan den föregående ARP-upplösningen fortfarande saknas. Det separata förfarandet för att konfigurera Proxy ARP på Sophos Firewall passar endast när en capture bevisar förfrågan och brandväggens uteblivna svar; DNAT kräver inte detta manuella steg generellt.

Samma princip gäller i molnmiljöer. Med Azure räcker inte regeln DNAT på enbart Sophos Firewall. Dessutom måste lämpliga Inbound rules öppnas i Network Security Group, annars kommer trafiken inte att nå brandväggen alls.

Konfigurera DNAT och brandväggsregeln

En serverpublikation består alltid av två delar: NAT-regeln översätter destinationen eller porten, brandväggsregeln tillåter och styr trafiken.

Server Access Assistant eller manuell DNAT-regel?

Sophos Firewall erbjuder två sätt att publicera servrar:

• Server access assistant (DNAT): passar som ett snabbt standardalternativ för en enskild publicering. Guiden skapar automatiskt flera regler och placerar dem överst i regelbasen.
• Manuell DNAT-regel: passar mer komplexa miljöer med alias-IP, PAT, Load Balancing, särskilda källor eller en medveten regeldesign. Varje fält måste konfigureras och testas individuellt.

Guiden kan vara till hjälp eftersom den inte bara skapar en inkommande DNAT-regel, utan beroende på valet skapar den också en Loopback-regel, en reflexiv SNAT-regel och lämplig brandväggsregel. Detta sparar tid, men är ingen ersättning för att kontrollera de skapade reglerna.

⚠️ DNAT och Weighted Load Balancing kan inte konfigureras samtidigt för samma DNS-värdpost. Om DNS-värden redan används för viktad fördelning måste de två kraven planeras separat före publiceringen; guiden kombinerar inte båda funktionerna i en och samma regel.

Använd Server Access Assistant

Guiden är den snabbaste vägen till en första publicering. Det är särskilt användbart när en enskild intern server måste vara tillgänglig via en WAN-adress och en tydlig tjänst.

Nödvändiga anpassade tjänsteobjekt måste skapas innan guiden startas. Valet under Services konfigurerar ingen portöversättning: Translated source (SNAT) och Translated service (PAT) står först på Original i den genererade DNAT-regeln. För PAT redigeras den genererade NAT-regeln efter att den sparats, och PAT-fälten samt den matchande brandväggsregeln kontrolleras. Efter ändringen måste dess tjänster och övriga matchningskriterier åter passa NAT-regeln. En publik IP-adress under WAN IP address sätter Inbound interface i den genererade DNAT-regeln till Any; det är inte samma sak som att medvetet välja ett WAN-gränssnitt. Utöka inte externa källor till Any enbart för att få en automatisk loopback-regel.

När Original destination är en alias-IP använder assistenten det underliggande fysiska gränssnittet som Translated source i de genererade SNAT- och loopback-reglerna, inte automatiskt alias-IP-adressen. Om denna alias-IP ska vara den översatta källan, skapa en IP-värd för aliaset och välj den manuellt som Translated source i de berörda genererade reglerna. Detta är inget generellt SNAT-krav för varje publicering; behåll begränsningarna för inkommande källor. Kontrollera efter att reglerna sparats de genererade regel-ID:na och den faktiska Translated source, kontrollera förväntade källadresser med nya sessioner på nödvändiga loopback- och serverinitierade vägar och håll brandväggskriterierna konsekventa efter ändringar.

Procedur:

1. Öppna Rules and policies > NAT rules.
2. Välj IPv4 eller IPv6.
3. Välj Add NAT rule > Server access assistant (DNAT). Alternativt kan du starta assistenten under Rules and policies > Firewall rules > Add firewall rule.
4. Under Internal server IP address väljs den interna servern eller anges en IP-adress.
5. Under WAN IP address väljs WAN-gränssnittet eller den publika IP-adressen.
6. Under Services väljs den interna tjänsten, till exempel HTTPS.
7. Under External source networks and devices anges de tillåtna källorna. Any passar bara när tjänsten verkligen måste vara nåbar från hela Internet.
8. ⚠️ Save and finish aktiverar de genererade reglerna omedelbart och placerar dem överst i båda tabellerna: NAT och brandvägg. Slutför först förberedelserna för driftsättning: bekräfta den publika destinationen, tillåtna källor, tjänster, regelkonflikter och ordning samt den dokumenterade omfattningen av rollback. Granska först därefter inställningarna och reglerna och spara med Save and finish.

Efter denna förhandskontroll ska även en granskning göras efter att reglerna sparats: dokumentera de genererade reglerna och deras ID, kontrollera deras faktiska ordning i båda tabellerna och flytta dem medvetet vid behov. Validera sedan de nödvändiga vägarna med nya sessioner. En automatiskt genererad regel kan tekniskt sett fungera och fortfarande vara för bred, placerad för högt eller dåligt namngiven för drift.

För att en loopback-regel ska skapas automatiskt måste två villkor vara uppfyllda: välj ett brandväggsgränssnitt som WAN-mål och ställ in External source networks and devices på Any. Assistenten skapar ingen loopback-regel om en publik IP-adress anges eller de externa källorna begränsas. I många miljöer är Split DNS dessutom tydligare än Loopback NAT.

Efter att ha använt assistenten bör du alltid kontrollera:

• Är NAT och brandväggsregeln i rätt position?
• Är källan verkligen så smal som planerat eller är den fortfarande på Any?
• Skapades en Loopback-regel även om delad DNS skulle vara en renare lösning?
• Har en reflexiv regel skapats som inte behövs för utgående servertrafik?
• Matchar brandväggsregeln målzonen efter NAT och det publika målobjektet före NAT?

För produktiva miljöer är en manuellt namngiven och avsiktligt placerad DNAT-regel ofta lättare att förstå. Guiden är bra för en snabbstart, men reglerna som skapas hör hemma i samma granskning som manuellt skapade regler.

Skapa DNAT-regel

Ett typiskt manuellt DNAT-exempel publicerar TCP 443 externt till en intern webbserver i DMZ. Regeln översätter endast måladress och eventuellt målport. Detta ersätter inte en brandväggsregel.

Procedur:

1. Öppna Rules and policies > NAT rules.
2. Välj IPv4 eller IPv6.
3. Välj Add NAT rule > New NAT rule.
4. Ange ett beskrivande Rule name, till exempel DNAT_WEB_DMZ_HTTPS.
5. Välj Rule position så att specifika DNAT-regler kommer före allmänna regler.
6. Ställ in Original source på tillåtna externa källor. Använd endast Any för avsiktligt offentliga tjänster.
7. Ställ in Original destination till värdobjektet WAN, den offentliga IP-adressen eller lämpligt WAN-gränssnitt.
8. Ställ in Original service till den externt tillgängliga tjänsten, till exempel HTTPS.
9. Ställ in Translated destination (DNAT) till den interna servern eller servergruppen.
10. Lämna Translated service (PAT) till Original eller ställ in den interna målporten om portvidarebefordran är nödvändig.
11. Välj Inbound interface medvetet. För internetåtkomst är detta vanligtvis gränssnittet WAN; I speciella fall kan Any vara nödvändig.
12. Outbound interface vid DNAT på interna servrar bör normalt lämnas vid Any så att routing och målzon fungerar korrekt.
13. Loopback, reflexiv regel, lastbalansering och hälsokontroll aktiveras endast om de behövs för tekniska ändamål.
14. Spara och aktivera regeln.

Om endast ett fåtal externa käll-IP-adresser behöver åtkomst, bör den ursprungliga källan inte vara Any, utan bör vara begränsad till dessa källor.

För publiceringar i produktion är ett värdobjekt för den offentliga IP-adressen vanligtvis renare än att direkt välja ett WAN-gränssnitt. Objektet förblir spårbart om gränssnitt, aliasadresser eller leverantörsdetaljer ändras senare.

Förstå Original och Translated korrekt

För NAT-regler är skillnaden mellan Original och Translated viktig.

• Original source / destination / service beskriver trafiken när den anländer till Sophos Firewall.
• Translated source / destination / service beskriver trafiken när den lämnar Sophos Firewall efter översättning.

För en inkommande DNAT-regel betyder detta:

• Original destination är den offentliga IP-adressen eller WAN-adressen för brandväggen.
• Original service är den externa porten som klienten adresserar.
• Translated destination (DNAT) är den interna servern.
• Translated service (PAT) är den interna porten på målservern om porten ska översättas.
• Translated source (SNAT) stannar oftast på Original med normala DNAT-regler.

Portvidarebefordran och PAT

Port forwarding är tekniskt sett en tjänsteöversättning. På Sophos Firewall används Translated service (PAT) för detta.

Exempel:

• Externt: TCP 20120
• Internt: TCP 22

Den externa klienten ansluter till port 20120, men Sophos Firewall vidarebefordrar internt till SSH port 22. Detta kan vara användbart, men det ersätter inte åtkomstbegränsningar. Att ändra den externa porten kan minska en del oönskad bakgrundstrafik, men det gör inte en tjänst säker.

Viktigt: Protokollet måste förbli detsamma. TCP kan översättas till en annan TCP-port, UDP till en annan UDP-port. TCP till UDP är inte en giltig portöversättning.

När HTTPS publiceras måste du först under Administration > Admin and user settings dokumentera de faktiskt konfigurerade portarna för WebAdmin, User Portal och VPN Portal. Äldre NAT-exempel anger 4444 för WebAdmin och 443 för User Portal; detta bekräftar inte vilka portar som används i den installerade builden eller den egna konfigurationen. Lös om möjligt konflikter med en annan publicerad IP-adress eller en annan extern tjänsteport. Ändra inte administrationsportar som en genväg vid felsökning; om en ändring behövs, säkra först en oberoende administrationsåtkomst och kontrollera därefter portaler, VPN-klienter och extern DNAT-åtkomst separat.

Planera medvetet käll-IP och returväg

Vid en normal DNAT-publicering bör Translated source (SNAT) vanligtvis ligga kvar på Original. Den interna servern ser då den verkliga externa käll-IP-adressen. Det är viktigt för serverloggar, rate limits, Fail2Ban-liknande skydd, applikationsloggar, WAF- eller reverse proxy-analys och senare incidentutredning.

SNAT till brandväggen eller en intern adress kan fortfarande vara nödvändig om returvägen annars inte går via Sophos Firewall. Detta är möjligt, till exempel om den publicerade servern använder en annan standardgateway, är i ett främmande routingsegment eller har en asymmetrisk routingsituation.

Beslutet bör fattas medvetet:

• Källan förblir Original: Servern ser den verkliga externa IP-adressen. Returvägen måste då gå korrekt via brandväggen.
• Källan översätts med SNAT: Returvägen blir enklare att kontrollera. Servern ser då bara brandväggens eller SNAT-adressens IP, och den verkliga klient-IP-adressen går förlorad i serverloggen.

Om en tjänst bara fungerar med SNAT, bör du inte hålla fast vid den direkt och bocka av ämnet. Det är bättre att först kontrollera om gatewayen, rutten, VLAN, serverns brandvägg eller routingdesign kan korrigeras. SNAT kan vara en legitim lösning, men gör senare analyser svårare.

Vid test ska det alltid kontrolleras vilken käll-IP-adress servern faktiskt ser. Om endast brandväggens IP-adress visas i stället för den externa klientens IP måste det vara tydligt dokumenterat om detta är avsiktligt.

Kontrollera brandväggsregeln

En NAT-regel tillåter inte automatiskt trafik. Dessutom krävs en lämplig brandväggsregel.

Med DNAT är vyn i brandväggsregeln ovanlig eftersom brandväggen samtidigt måste känna till den ursprungliga åtkomsten utifrån och det översatta interna målet.

Den viktigaste tumregeln:

⚠️ För DNAT använder brandväggsregeln målzonen efter NAT, men målnätverket före NAT.

Ordningen är viktig: Vid inkommande trafik söker Sophos Firewall först efter den matchande DNAT-regeln och fastställer därmed den översatta destinationen. Därefter matchas brandväggsregeln. För Destination zone används zonen där den översatta destinationen finns. För Destination networks är däremot det ursprungliga målobjektet från DNAT-regeln fortfarande relevant.

Typisk tilldelning:

• Source zones: Vanligtvis WAN om åtkomsten kommer från Internet.
• Source networks and devices: Så begränsat som möjligt, till exempel enskilda IP-adresser, nätverk, länder eller grupper.
• Destination zones: Zon för den interna servern enligt DNAT, till exempel DMZ eller SERVER.
• Destination networks: Offentlig destinationsadress eller WAN värdobjekt från Original destination.
• Services: Utan PAT räcker tjänsten från Original service. Vid portöversättning måste brandväggsregeln innehålla både den externa originaltjänsten och den interna tjänsten från Translated service. Exemplet TCP 20120 till TCP 22 kräver därför båda tjänsteobjekten.
• Säkerhetsprofil: Beroende på tjänst, IPS, skanning av skadlig programvara, webbpolicy eller annan lämplig kontroll.
• Loggning: Aktivera för publicerade tjänster.

Utan en lämplig brandväggsregel avvisas trafik trots DNAT.

Den här punkten är en vanlig felkälla: Om den interna servern anges som destinationsnätverk trots att regeln förväntar sig det offentliga WAN-objektet matchar regeln inte. Den exakta logiken förklaras mer utförligt i artikeln Förstå NAT på Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Ordningsföljden gäller även NAT-regler. Sophos kontrollerar dem uppifrån och ned och använder den första matchande regeln. En alltför generell NAT-regel högre upp kan därför hindra den specifika DNAT-regeln från att träffa.

Befintliga anslutningar behåller sin NAT-översättning även om NAT-regeln senare ändras. Testa därför med nya sessioner eller avsluta gamla anslutningar korrekt; annars kan resultatet fortfarande återspegla det tidigare tillståndet.

Avancerade NAT-alternativ

Dessa alternativ blir bara relevanta när interna klienter använder offentliga namn, retursökvägar måste översättas specifikt eller flera målservrar är inblandade.

Loopback, Reflexive och Linked NAT Rules

Sophos Firewall erbjuder flera NAT-alternativ som lätt kan förväxlas:

• Loopback regel: Hjälper när interna klienter ska nå en intern server via den offentliga IP-adressen eller offentliga DNS-namnet.
• Reflexive-regel: skapar en speglad SNAT-regel för nya anslutningar som initieras av den publicerade servern. Den behövs inte för svarstrafiken i en befintlig inkommande DNAT-session, eftersom brandväggen hanterar sessionen tillståndsbaserat.
• Länkad NAT-regel: Skapad från en brandväggsregel och är en länkad SNAT-regel. En länkad NAT-regel är inte samma sak som en inkommande DNAT-regel för en publicerad server.

Inte heller dessa NAT-regler ger åtkomstbehörighet. För nödvändig loopback-åtkomst kontrolleras en befintlig, tillräckligt snävt avgränsad regel under Rules and policies > Firewall rules, eller så skapas en matchande regel vid behov:

• Source zones: Klientens faktiska zon, till exempel LAN.
• Source networks and devices: Endast det interna klientsubnät som behövs.
• Destination zones: Den översatta serverns zon, till exempel DMZ.
• Destination networks: Ursprunglig publik destination från Original destination, inte serverns interna IP-adress.
• Services: Vid PAT båda tjänsteobjekten från Original service och Translated service (PAT); i det befintliga exemplet TCP 20120 och TCP 22.

För anslutningar som servern självständigt initierar måste brandväggsregeln tillåta serverns faktiska zon under Source zones och dess interna IP-adress eller lista med server-IP-adresser under Source networks and devices. Begränsa Destination zones, Destination networks och Services till nödvändiga destinationer och tjänster i stället för att slentrianmässigt kopiera Any. En befintlig, tillräckligt snävt avgränsad regel kan räcka; en ny regel behövs inte alltid. Tillståndsbaserade svar på inkommande DNAT-sessioner kräver varken en reflexiv NAT-regel eller ny utgående behörighet. Kontrollera NAT-ordning och returväg separat, aktivera loggning och testa de nödvändiga interna och serverinitierade vägarna var för sig med nya sessioner.

För klassiska serverpublikationer är vanligtvis en oberoende DNAT-regel plus en lämplig brandväggsregel den tydligaste. Linked NAT Rules kan vara användbart om en brandväggsregel direkt kräver en speciell SNAT-översättning. Men i allmänna miljöer tenderar fristående, tydligt namngivna NAT-regler att förbli lättare att förstå och underhålla.

Viktigt: Loopback och reflexiva regler härleds från den ursprungliga DNAT-regeln. Om den ursprungliga DNAT-regeln senare ändras, bör man kontrollera de härledda reglerna separat. Annars kan det hända att den externa åtkomsten har justerats korrekt, men interna Loopback-åtkomster eller utgående servertrafik fortsätter att köras enligt den gamla logiken.

Detta är inte en kosmetisk detalj. Sophos skapar Loopback och reflexiva regler med hänvisning till namn och ID för den ursprungliga DNAT-regeln, men efterföljande ändringar av den ursprungliga regeln uppdaterar inte automatiskt de härledda reglerna. Efter ändringar av den offentliga IP-adressen, målservern, tjänsten eller källorna bör dessa regler därför medvetet öppnas och jämföras.

Load Balancing och Health Check

Om flera interna servrar publiceras bakom en offentlig IP kan DNAT också användas för Load Balancing eller failover.

Möjliga metoder är till exempel:

• Round-robin
• First alive
• Random
• Sticky IP
• One-to-one

Om du vill att brandväggen ska upptäcka om en målserver är tillgänglig måste Health check konfigureras. Utan Health Check kan brandväggen även vidarebefordra trafik till en server som inte kan nås.

Rulla ut DNAT-publiceringar via XML API

XML API kan skapa eller ändra den planerade publiceringen med NATRule. Det ersätter varken den separata brandväggsbehörigheten eller verifieringen av dataflödet. Den fullständiga NAT-modellen och den allmänna objektstrukturen beskrivs i Förstå NAT på Sophos Firewall; här ligger fokus på en säker ändring för en publicerad server. Förbered först åtkomst, TLS-verifiering, tjänstekonto, hemligheter och explicita skrivoperationer enligt Säkra åtkomsten till XML API.

Överför det planerade dataflödet till begäran

För det befintliga HTTPS-exemplet beskriver OriginalSourceNetworks med sina Network-poster de tillåtna externa källorna, OriginalDestinationNetworks den publika destinationen och OriginalServices med Service den externa tjänsten. TranslatedDestination hänvisar till den interna servern; utan PAT ligger TranslatedService kvar på Original, annars anger det den interna tjänsten. För normal DNAT utan medvetet planerad SNAT ligger även TranslatedSource kvar på Original. Original-fälten begränsar det inkommande flödet, medan Translated-fälten bestämmer hur det översätts. Läs först befintliga värd- och tjänsteobjekt inklusive adressfamilj och jämför dem med ändringen; förutsätt inte att exempelnamn motsvarar verkliga objekt. Brandväggsregeln måste fortfarande omfatta målzonen efter NAT, den publika destinationen före NAT och, vid PAT, båda tjänsterna.

InboundInterfaces och OutboundInterfaces innehåller var för sig Interface-poster och begränsar matchningen. De är inte den gränssnittsspecifika källöversättningen: endast när denna faktiskt behövs används OverrideInterfaceNATPolicy med Enable och den tillhörande InterfaceNATPolicyList. Dess Override-poster kopplar specific_interface till en specific_translatedsourceid. Aktivera inte detta specialfall i förebyggande syfte för en normal serverpublicering. Kommentaren i det dokumenterade exemplet anger avvikande OverrideInterfaceDefaultNATPolicy, medan XML-elementet heter OverrideInterfaceNATPolicy. Dra inte slutsatsen att det finns en andra inställning eller en giltig alternativ tagg; om Override-syntaxen är oklar, stoppa begäran och använd API help för den installerade builden eller kontakta supporten.

Infogningspositionen är ett separat beslut: Position erbjuder top, bottom, after och before. Vid after anges namnet på den befintliga referensregeln under After > Name, vid before under Before > Name; i exemplet är dessa referenselement avsedda för Set-begäranden. Ange inte båda riktningarna samtidigt och förväxla inte referensnamnet med den egna regelns NATRule-namn. Läs referensregeln före skrivningen och kontrollera konflikter högre upp; kontrollera den faktiska positionen efter skrivningen. NAT-ordningen och brandväggsordningen ligger fortfarande i två separata tabeller. I exemplet är LinkedFirewallrule endast avsett för att skapa Linked NAT i en Set-begäran, inte som automatisk brandväggsbehörighet för en inkommande DNAT-regel.

Gör inte valfri fördelning obligatorisk

För en enkel publicering till en server är lastbalansering och hälsokontroll inte obligatoriska. Enligt objektbeskrivningen gäller HealthCheck endast när fördelning är aktiverad. Kontrollvärdena under LoadBalance hör till den aktiverade hälsokontrollen: ProbeMethod är ICMP eller TCP; Port behövs endast för TCP och ligger mellan 1 och 65535. Parametertabellen anger 5 till 65535 sekunder för ProbeInterval, standardvärde 60, 1 till 10 sekunder för ResponseTimeOut, standardvärde 2, och 1 till 10 försök för DeactivateHostAfter, standardvärde 3. Mandatory-markeringarna för kontrollvärdena där innebär inte att de är obligatoriska för varje NAT-begäran. Bekräfta lämplig metod, aktiverad kontroll och giltiga värden i API help för den build som används; bifoga inte en fullständigt ifylld lastbalanseringsmall till varje DNAT-ändring. Ett lyckat ICMP-test bekräftar dessutom inte att applikationstjänsten fungerar.

Skriv, läs tillståndet och verifiera publiceringen

1. Dokumentera det avsedda flödet, tillåtna källor, publik och intern tjänst, NAT-/brandväggs-ID:n och positioner. Säkra det befintliga tillståndet och kontrollera beroenden, inklusive separat skapade loopback- och reflexiva regler. Använd det befintliga förfarandet för driftsättning och rollback även för automatiseringen.
2. Kör den ofarliga läsfrågan från den avsedda automatiseringsvärden. Använd därefter endast den explicita Set-operation som har bekräftats för NATRule och den installerade builden. Förutsätt varken att ett utelämnat operationsvärde fungerar eller ett generiskt upsert-beteende; om den konkreta nyttolasten fortfarande är oklar, skriv inte. Ange IPFamily och Status medvetet i stället för att acceptera en oväntad IPv4-regel eller omedelbar aktivering från ett standardvärde.
3. Spara svaret och den objektspecifika XML-statusen, rensa bort hemligheter och läs den sparade regeln igen eller öppna den under Rules and policies > NAT rules. Jämför Original-/Translated-värden, gränssnitt, status, ID och faktisk position med planen. Kontrollera även den separata brandväggsregeln och nödvändiga härledda regler var för sig; dra inte slutsatsen att de har skapats eller uppdaterats enbart utifrån en NATRule-begäran.
4. Genomför först därefter det planerade aktiveringssteget och kontrollera med nya sessioner den tillåtna externa källan och en kontrollerad otillåten extern källa, nödvändig intern åtkomst samt nödvändiga serverinitierade anslutningar. Log Viewer, NAT Rule ID, Firewall Rule ID, Capture och serverlogg måste stämma med det planerade flödet och den förväntade käll-IP-adressen. Ett sparat objekt eller en XML-status bekräftar ännu inte en säker och fungerande publicering.
5. Upprepa inte blint vid avvikelser. Jämför först det faktiska tillståndet med svaret; återkalla sedan endast nya exklusiva regler eller återställ ändrade delade regler till det dokumenterade tillståndet och deras tidigare position. Hantera separat skapade regler separat, stäng inte av delade behörigheter i sin helhet och verifiera återställningen med nya sessioner.

Tolka NATRule-svar objektspecifikt

Dokumentationen för SFOS 22 och 23 anger följande kopplingar mellan operation, kod och symbol. Message.* är meddelandenycklar som inte har slagits upp på dokumentationssidan, inte svarstexter som har slagits upp här eller verifierade körningsresultat. Behandla inte koderna som HTTP-status och dra inte slutsatser om en entydig felorsak, lyckad lagring eller regel för återförsök enbart utifrån symbolnamnet.

Att 548 och 549 har samma nyckel innebär just att de inte kan skiljas åt entydigt med hjälp av denna etikett. NATRule-kopplingen för 503 och 504 får inte heller ersättas med generiska förklaringar av API-koder. Vid ett oväntat svar, dokumentera det fullständiga svaret efter att hemligheter har rensats bort, operationen, den installerade builden och det lästa regeltillståndet; använd den objektspecifika Status Message Information och kontakta supporten vid behov. Den centrala API-säkerhetsguiden förklarar hur partiell framgång, varningar och läskontroller hanteras före ett nytt skrivförsök.

Säkerhet och driftsättning

En publicerad tjänst blir omedelbart en del av den publika attackytan. Därför ingår snävt begränsad åtkomst, loggning, säkerhetsprofiler och en tydlig rollback i driftsättningen.

Planera driftsättning och rollback

En DNAT-publicering ska behandlas som en mindre produktionsändring. Så snart regeln är aktiv kan tjänsten bli nåbar från Internet. Före driftsättningen ska det därför vara dokumenterat vilken regel som aktiveras, hur åtkomsten testas och hur rollback genomförs vid problem.

Kontrollera före driftsättningen:

• Säkerhetskopiera den aktuella brandväggskonfigurationen eller åtminstone dokumentera de berörda NAT och brandväggsreglerna.
• Dokumentera ID för alla DNAT-, loopback-, reflexiva NAT- och brandväggsregler som hör till ändringen; för ändrade befintliga regler ska tidigare aktiveringsstatus och position noteras.
• Kontrollera befintliga NAT-regler för samma publika IP, extern port och WAN-gränssnitt.
• Matcha leverantörens router, molnsäkerhetsgrupp eller uppströms brandväggsregler med Sophos-konfigurationen.
• Överväg DNS-TTL när ett värdnamn pekar om till den publicerade adressen.
• Förbered en testkälla utanför din egen LAN, till exempel mobiltelefon, extern plats eller kontrollerat onlineporttest.
• Ange förväntade loggplatser: Log Viewer, NAT Rule ID, brandvägg Rule ID, Packet Capture och serverlogg.
• Definiera återställningskriterier, till exempel fel tjänst tillgänglig, servern svarar inte, certifikatfel, säkerhetsprofilen blockerar legitim trafik eller oväntad käll-IP på servern.

Vid återställning kontrolleras först om varje dokumenterad regel delas med andra publiceringar. Inaktivera endast nya regler som hör till ändringen, inklusive separat genererade loopback- och reflexiva NAT-regler. Återställ ändrade befintliga regler till dokumenterad status och tidigare position i stället för att slentrianmässigt inaktivera en delad brandväggsregel. Kontrollera sedan de nödvändiga externa, interna och serverinitierade vägarna med nya sessioner; inaktivering garanterar inte att befintliga anslutningar avslutas omedelbart. Om en gammal publikation har ersatts bör det framgå om den gamla regeln kan återaktiveras eller om leverantörsportvidarebefordran, DNS eller övervakning måste återställas först.

För kritiska tjänster bör du inte ändra flera saker samtidigt. Om DNS, leverantörsrouter, NAT-regel, brandväggsregel och serverkonfiguration justeras samtidigt, kommer ett fel att vara svårt att tillskriva senare. En kort process med tydliga steg är bättre: förbered, aktivera, testa externt, kontrollera loggar, kontrollera servrar, dokumentera resultat.

Begränsa åtkomsten så snävt som möjligt

Alla publicerade tjänster behöver inte vara tillgängliga från hela Internet. Om möjligt bör tillgången begränsas.

Användbara begränsningar:

• Tillåt endast definierade käll-IP-adresser.
• Tillåt endast kända FQDN-värdar om fjärrplatsen använder dynamiska IP-adresser.
• Tillåt endast vissa länder.
• Blockera uttryckligen vissa länder.
• Tillåt endast åtkomst via VPN.
• Använd en ZTNA-lösning i stället för direkt publicering.

För administrativa tjänster som SSH, RDP eller interna administratörsportaler är DNAT vanligtvis inte den bästa lösningen. Om åtkomsten inte behöver vara offentlig är VPN eller ZTNA nästan alltid ett bättre val.

Förbättra säkerheten

För publicerade tjänster bör du kontrollera:

• Är servern för närvarande patchad?
• Finns det ett alternativ för WAF eller omvänd proxy?
• Är IPS aktiv på brandväggsregeln?
• Är bara nödvändiga portar öppna?
• Loggas tjänsten?
• Finns det geo-IP, hot feed eller käll-IP-begränsningar?
• Är MFA möjligt om det är en portal?

För webbapplikationer kan Web Server Protection / WAF också vara vettigt istället för ren DNAT.

Bots och Threat Feeds

Offentliga portar som HTTP, HTTPS, SSH eller RDP är ständigt i fokus för bots. Så fort en port är tillgänglig på Internet ser du ofta snabbt anslutningsförsök, skanningar, inloggningsförsök eller exploit-trafik i Log Viewer.

Detta betyder inte automatiskt att servern äventyras. Men det visar att tjänsten är en del av den offentliga attackytan. Vi rekommenderar därför att ytterligare säkra publicerade tjänster med IPS, loggning, smala källor och tredjeparts Threat Feeds.

Threat Feeds förser ständigt brandväggen med aktuella indikatorer på kompromiss, till exempel skadliga IP-adresser eller domäner. Detta gör att brandväggen kan blockera kända angripare, botnät eller skannrar innan de når den publicerade tjänsten.

Mer information finns i Sophos Firewall Threat Feeds.

Testa

När du har sparat DNAT-regeln:

• Testa från ett externt nätverk, inte från samma LAN.
• Kontrollera endast den förväntade publika porten och skanna inte brett mot främmande adresser.
• Kontrollera Firewall Rule ID, NAT Rule ID, källa, ursprunglig destination, översatt destination och status för tillåten eller nekad trafik i Log Viewer.
• Jämför Packet Capture med extern källa, offentlig destination och intern destination
• Kontrollera serverloggar
• Kontrollera synlig käll-IP på målsystemet

Om testet ska utföras från den interna LAN till den offentliga IP-adressen kan ytterligare Hairpin NAT eller en intern DNS lösning behövas.

Testmatris för DNAT-publiceringar

Ett enda porttest räcker sällan för en DNAT-publicering i produktion. En liten testmatris som skiljer tillåtna och oönskade vägar åt är bättre. Den visar inte bara om tjänsten är nåbar, utan också om begränsningar, loggning och returväg fungerar korrekt.

Användbara testkällor:

• Extern tillåten källa: Testa anslutning från mobiltelefon, extern plats eller partnernätverk för offentlig IP och extern port. Förväntade Firewall Rule ID och NAT Rule ID måste visas i Log Viewer.
• Extern otillåten källa: Om publiceringen är begränsad till vissa källor ska ett test från en otillåten källa avsiktligt misslyckas. Annars är källbegränsningen för bred.
• Intern klient med internt DNS namn: Kontrollera om interna användare löser direkt till den interna serverns IP. Detta är ofta renare än Loopback NAT.
• Intern klient med offentlig FQDN: Testa bara om denna åtkomst verkligen behövs. Om det misslyckas, kontrollera först split DNS och lägg inte till Loopback NAT automatiskt.
• Målservern själv: Kontrollera serverlogg, lokal brandvägg, bunden tjänst, certifikat och synlig käll-IP. På så sätt kan du se om servern ser den verkliga externa IP-adressen eller en SNAT-adress.
• Övervakning eller extern Health Check: Verifiera att testet använder samma URL, port och källlogik som verklig övervakning.

Utvärdera en kontrollpunkt i taget efter varje test: når trafiken Sophos Firewall, matchar den förväntade NAT-regeln, matchar den förväntade brandväggsregeln, når paketet servern och kommer ett svar tillbaka? Om flera saker ändras samtidigt är det annars svårt att identifiera nästa fel.

Ett rent DNAT-test jämför tre synvinklar:

• Extern klient: Anslutning till offentlig IP och extern port fungerar eller är avsiktligt blockerad.
• Sophos Firewall: Log Viewer visar förväntat Firewall Rule ID och NAT Rule ID.
• Intern server: Tjänsten ser förväntad käll-IP, svarar via rätt gateway och loggar åtkomsten.

Om endast ett av dessa perspektiv undersöks förblir typiska fel oupptäckta. Till exempel, ett framgångsrikt externt porttest säger ännu inte om loggning, IPS, källbegränsningar eller serverägare är korrekt dokumenterade.

Felsökning och drift

Efter driftsättningen räcker det inte att kontrollera om tjänsten är nåbar. Log Viewer, NAT Rule ID, Firewall Rule ID, serverloggar och regelbundna granskningar av äldre publiceringar är också viktiga.

Felsökning

Vanliga misstag:

• Brandväggsregel saknas
• Fel WAN IP vald
• Portvidarebefordran på leverantörens router saknas
• Azure Network Security Group blockerar porten
• Tjänsten körs inte internt
• Servergateway pekar inte på Sophos Firewall
• NAT-regeln är under en annan som träder i kraft i förväg
• Brandväggsregeln använder fel destinationsnätverk för DNAT
• Porten används redan av en annan tjänst
• Loopback saknas när interna klienter använder den offentliga FQDN
• Health Check saknas eller är felaktig när Load Balancing används
• Testning sker från det interna nätverket och inte externt
• Målservern svarar tillbaka via en annan gateway
• En säkerhetsprofil blockerar trafik men söks inte efter i rätt logg

Log Viewer är den viktigaste utgångspunkten vid DNAT-problem. Där syns om trafik anländer, vilken brandväggsregel och NAT-regel som träffar samt om trafiken tillåts eller nekas. Om träffen inte motsvarar förväntningarna hjälper Sophos Firewall-regeln träffar inte: kontrollera orsaker med den fortsatta avgränsningen.

För djupare felsökning bör du inte bara titta på Sophos Firewall. Om Log Viewer tillåter trafik och Packet Capture visar att paket fortsätter till servern, är orsaken ofta på målsystemet: lokal brandvägg, felaktig standardgateway, tjänst obunden, certifikatproblem, program som lyssnar på en annan port eller uppströms omvänd proxy svarar inte som förväntat.

En snabb klassificering hjälper så att du inte letar på fel ställe:

• Ingen träff visas i Log Viewer: Trafiken når inte brandväggen eller så är fel WAN IP adresserad. Kontrollera leverantörens router, molnsäkerhetsgrupp, offentlig IP och Packet Capture till WAN.
• Brandvägg Rule ID matchar, NAT Rule ID saknas: NAT-regeln matchar inte eller är för låg. Kontrollera Original destination, Original service, Inkommande gränssnitt och NAT sekvens.
• NAT Rule ID matchar, tjänsten svarar inte: Destinationsservern eller returvägen är inte korrekt. Kontrollera serverns brandvägg, standardgateway, routing och Packet Capture mot servern.
• Det fungerar externt, men inte internt via FQDN: Split DNS eller Loopback saknas. Kontrollera intern DNS-upplösning och lägg bara till medvetet Loopback.
• Efter att ha ändrat guiden, fungerar bara en del felaktigt: Härledd Loopback eller reflexiv regel gäller inte längre. Kontrollera genererade NAT och brandväggsregler individuellt.

SMTP via DNAT efter uppgradering till SFOS 22

Om inkommande e-post efter en uppgradering till SFOS 22 sporadiskt försenas eller inte levereras alls kan NC-184583 vara orsaken. Sophos anger uttryckligen SFOS 22.0 GA Respin Build 411 som berörd version, men beskriver problemet mer allmänt för uppgraderingar till v22.x. MR1 och MR2 anges inte separat som vare sig berörda eller åtgärdade. Som enda fix anges SFOS 23.0 EAP0 Build 275 – en EAP-version som inte bör ses som en generell rekommendation för produktionssystem. Det finns ingen offentligt dokumenterad workaround; Sophos hänvisar till supporten.

Separat från detta listar versionsinformationen för SFOS 22.0 MR3 Build 576 från den 16 oktober 2026 det åtgärdade felet NC-180464: SMTP-trafik via DNAT avvisades felaktigt efter en uppgradering. Detta andra issue-ID bevisar inte att även NC-184583 är åtgärdat i MR3. Vid ett motsvarande felmönster bör båda ID:na, den installerade builden och tidigare observationer stämmas av med Sophos Support innan en fix utlovas för det egna systemet.

Ett porttest av TCP 25 räcker inte vid detta felmönster. Flera kontrollerade verkliga meddelanden bör skickas och UTC-tid, avsändare, mottagare och Message-ID noteras. Därefter jämförs avsändarens kö eller bounce med kön och Transport Log på den interna e-postservern. Underlaget till supporten bör innehålla firmware-build, tidsstämplar, Rule IDs, fwlog.log, firewall_rule.log, nat_rule.log och e-postserverns loggar. Loggsökvägarna och hämtningen av Consolidated Troubleshooting Report beskrivs i Kontrollera tjänster och loggar i Sophos Firewall via CLI. I supportärendet bör NC-184583 anges uttryckligen.

Known Issue gäller den direkta DNAT-sökvägen till den interna e-postservern. I Sophos Firewall MTA Mode tar brandväggen själv emot meddelandet och vidarebefordrar det sedan. Sophos bekräftar dock varken att MTA Mode säkert inte påverkas av problemet eller att en övergång är den officiella workarounden.

Om samma direkta DNAT-väg ska skannas transparent visar Konfigurera Mail Protection i Legacy mode hur DNAT, SNAT, SMTP-regler och proxyskanning verifieras tillsammans. Detta är en reguljär design, inte en workaround för NC-184583.

När Black Hole DNAT också hjälper

Om en tjänst medvetet behöver förbli allmänt tillgänglig, men vissa källor måste fångas upp innan den faktiska publiceringen, kan en DNAT-regel för svart hål ovanför den produktiva DNAT-regeln vara vettig. Detta fungerar till exempel för kända dåliga IP-listor, permanent oönskade länder eller återkommande skannerkällor.

Tekniken ersätter inte en korrekt säkrad publicering. DNAT-regeln för produktion måste fortfarande vara snävt begränsad, loggning ska vara aktiv och den publicerade servern ska hållas uppdaterad. Black Hole DNAT lägger till ett blockeringslager framför publiceringen, men utgör inte själva säkerhetsarkitekturen.

Black Hole DNAT är särskilt användbar i dessa fall:

• Återkommande skannerkällor som träffar samma publicerade tjänst: Källorna kan fångas upp före den produktiva DNAT-regeln.
• Enskilda länder ska inte ha tillgång till portvidarebefordran: Blockregeln kan placeras ovanför den faktiska DNAT-regeln.
• En underhållen grupp med skadliga IP-adresser finns redan: Gruppen kan användas som Original source av regeln för svarta hål.
• En tjänst måste förbli offentlig, men bör ta emot mindre bottrafik: Den produktiva regeln behålls, oönskade källor fångas upp i förväg.

Black Hole DNAT är inte lämplig för lokala brandväggstjänster som WebAdmin, User Portal, VPN Portal eller SSH för själva brandväggen. Device Access och Local service ACL exception rules ansvarar för detta. För webbservrar över WAF bör du först kontrollera WAF-regeln, blockerade länder, autentisering och WAF-loggar.

Ordningen är viktig: Black Hole DNAT-regeln måste ligga över den produktiva DNAT-regeln. Kontrollera sedan i Log Viewer att blockerade källor träffar Black Hole-regeln medan tillåtna källor fortfarande använder de produktiva NAT- och brandväggsreglerna. Den exakta proceduren finns i Sophos Firewall: Blockera länder och skadliga IP-adresser.

Driftskontroll

DNAT-regler ska granskas regelbundet. Gamla publiceringar är en vanlig säkerhetsrisk eftersom tjänster ofta förblir nåbara efter att applikationen har flyttats, ersatts eller inte längre behövs.

För produktiva DNAT-regler bör följande åtminstone dokumenteras:

• Syfte med publiceringen: Dokumentationen ska visa varför tjänsten är publikt nåbar.
• Ansvarig person eller team: Utan ägare tas gamla publiceringar sällan bort.
• Offentlig IP och extern port: Underlättar granskning, övervakning och extern skanning.
• Intern målserver och målport: Viktigt för servermigreringar, Load Balancing och certifikatändringar.
• Förväntade källor: Hjälper till att avgöra om Any verkligen är nödvändigt.
• Skyddsåtgärder: IPS, WAF alternativ, MFA, Threat Feeds, loggning och patchstatus bör kunna spåras.
• Utgångsdatum eller granskningsdatum: Tillfälliga publiceringar behöver ett tydligt slutdatum.

En meningsfull granskning består inte bara av att titta på regeln. Du bör kontrollera externt om bara de förväntade portarna är öppna, kontrollera i Log Viewer vilka källor som faktiskt kommer åt och kontrollera på målservern om applikationen fortfarande underhålls. Om tjänsten endast behövs internt eller för ett fåtal partners bör VPN, ZTNA, en käll-IP-begränsning eller en WAF-regel omvärderas.

När du tar bort gamla DNAT-regler bör du inte bara ta bort NAT-regeln. Brandväggsregler, värdobjekt, tjänsteobjekt, Loopback-regler, Reflexive-regler, DNS-poster, övervakningskontroller eller vidarebefordran av leverantörsport beror ofta på det. En kort avvecklingsprocess är bättre:

1. Kontrollera de senaste åtkomsterna i Log Viewer.
2. Låt lämplig person eller avdelning bekräfta att tjänsten inte längre behövs.
3. Identifiera berörda DNAT-, separat genererade loopback- och reflexiva NAT- samt brandväggsregler med hjälp av deras ID och kontrollera andra användare och beroenden. Inaktivera först endast regler som uteslutande hör till den avvecklade publiceringen, uttryckligen även separat genererade regler som inte längre behövs. Utgå inte från att inaktivering av DNAT-regeln inaktiverar alla härledda regler; inaktivera exklusiva härledda regler som inte längre behövs separat. Inaktivera inte en delad brandväggsbehörighet i sin helhet: behåll den efter beroendegranskning eller ta försiktigt bort endast kriterierna för den avvecklade publiceringen.
4. Kontrollera med nya externa sessioner att den avvecklade porten inte längre är nåbar. Kontrollera även det planerade tillståndet för nödvändiga interna och serverinitierade vägar med nya sessioner, inklusive delade publiceringar som måste fortsätta vara tillgängliga. Befintliga sessioner bevisar inte att behörigheten har återkallats.
5. Kontrollera övervakning och serverloggar efter fel och följ effekterna under en observationsperiod.
6. Rensa först därefter upp bevisligen oanvända objekt, DNS-poster och leverantörsregler.

Om publiceringen fortfarande behövs ska granskningen avslutas med ett konkret resultat: behåll den oförändrad, begränsa den ytterligare, flytta den till WAF, placera den bakom VPN/ZTNA eller granska den igen före ett fastställt utgångsdatum.

FAQ