Publicera intern server via DNAT på Sophos Firewall
Med DNAT publicerar man en intern server via en publik IP-adress eller en publik port. Sophos Firewall vidarebefordrar då inkommande trafik till den interna målservern. Typiska exempel är webbservrar, reverse proxies, VPN-gateways eller andra tjänster i en DMZ.
Den här guiden visar vilka punkter man bör kontrollera före och efter en DNAT-regel och hur publiceringen kan säkras så snävt som möjligt.
Förutsättningar
- Publik IP-adress eller WAN-interface
- Intern server med fast IP-adress
- Känd tjänst och port, till exempel TCP 443
- Passande firewall-regel
- Valfritt: IPS, Webserver Protection eller Reverse Proxy beroende på tjänst
⚠️ DNAT publicerar en intern tjänst utåt. Varje publicerad tjänst ökar attackytan. Publicera bara det som verkligen behövs och begränsa källa, port och mål så snävt som möjligt.
Klargör i förväg
Innan regeln skapas bör man besvara dessa frågor:
- Vilken publik IP eller vilket WAN-interface används?
- Vilken extern port ska vara nåbar?
- Till vilken intern IP ska trafiken vidarebefordras?
- Förblir porten densamma eller översätts den?
- Ska åtkomst tillåtas från överallt eller bara från specifika källnät?
- Måste Source NAT eller Reflexive NAT beaktas?
- Behövs en loopback-regel för interna klienter som använder den publika FQDN:en?
- Publiceras bara en intern server eller flera servrar med Load Balancing?
- Finns redan en regel som använder samma port?
- Sitter Sophos Firewall direkt mot internet eller bakom en provider-router?
- Måste ytterligare regler öppnas i en Cloud Security Group?
Denna information förhindrar senare konflikter med befintliga NAT- eller firewall-regler.
När brandväggen står bakom en router
DNAT fungerar även när Sophos Firewall inte själv har den publika IP-adressen, utan står bakom en NAT-router hos providern.
I detta fall krävs två vidarebefordringar:
- På provider-routern vidarebefordras den publika porten till WAN-IP:n på Sophos Firewall.
- På Sophos Firewall vidarebefordras porten via DNAT till den interna servern.
Många provider-routrar erbjuder klassisk port forwarding eller en funktion som Exposed Host respektive DMZ Host. Med en Exposed-Host-funktion vidarebefordras ofta mycket många eller alla inkommande portar till brandväggen. Det kan vara praktiskt, men bör säkras medvetet eftersom den egentliga kontrollen då helt ligger på Sophos Firewall.
Om ingen fast publik IP finns kan man använda DynDNS. Sophos Firewall kan konfigurera Dynamic DNS så att ett DNS-namn alltid pekar på aktuell publik IP. Viktigt ändå: port forwarding på provider-routern måste peka till Sophos Firewall.
I cloud-miljöer gäller samma princip. I Azure räcker DNAT-regeln på Sophos Firewall inte ensam. Dessutom måste rätt Inbound rules öppnas i Network Security Group, annars når trafiken aldrig brandväggen.
Skapa DNAT-regel
Ett typiskt DNAT-exempel:
- Original source:
Anyeller definierade källnät - Original destination: WAN-IP eller WAN-interface
- Original service:
HTTPS - Translated destination: intern server
- Translated service: oförändrad eller intern målport
Gör så här:
- Öppna Rules and policies.
- Gå till området NAT rules.
- Skapa en ny NAT-regel.
- Definiera Original Source, Destination och Service.
- Sätt Translated Destination till den interna servern.
- Ange eventuellt Translated Service.
- Spara och aktivera regeln.
Om bara få externa käll-IP-adresser behöver åtkomst bör Original Source inte vara Any, utan begränsas till dessa källor.

Förstå Original och Translated korrekt
I NAT-regler är skillnaden mellan Original och Translated viktig.
- Original source / destination / service beskriver trafiken som den kommer in till Sophos Firewall.
- Translated source / destination / service beskriver trafiken som den lämnar Sophos Firewall efter översättningen.
För en inkommande DNAT-regel betyder det:
- Original destination är brandväggens publika IP eller WAN-adress.
- Original service är den externa porten som klienten ansluter till.
- 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) står vid normala DNAT-regler oftast kvar på Original.
Sophos beskriver fälten i den officiella guiden Add a NAT rule.
Port Forwarding och PAT
Port Forwarding är tekniskt sett en service-ö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. Det kan vara användbart, men ersätter inte åtkomstbegränsning. En ändrad extern port kan minska bakgrundsbrus något, men gör inte en tjänst säker.
Viktigt: protokollet måste vara 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.
Om HTTPS publiceras måste man dessutom kontrollera om det finns konflikter med WebAdmin eller User Portal på Sophos Firewall. Som standard använder adminkonsolen HTTPS-port 4444, User Portal HTTPS-port 443. Vid överlappningar måste brandväggens egna portar eller de publicerade tjänsterna separeras rent.
Loopback, Reflexive och Linked NAT Rules
Sophos har flera NAT-alternativ som lätt blandas ihop:
- Loopback rule: Hjälper när interna klienter ska nå en intern server via publik IP eller publikt DNS-namn.
- Reflexive rule: Skapar en speglad SNAT-regel till en DNAT-regel så att returtrafik eller vissa motriktningar översätts korrekt.
- Linked NAT rule: Skapas från en firewall-regel och är en länkad SNAT-regel. Den är inte samma sak som en inkommande DNAT-regel för en publicerad server.
För klassisk serverpublicering är oftast en fristående DNAT-regel plus passande firewall-regel mest överskådligt. Linked NAT Rules kan vara användbara när en firewall-regel direkt behöver en särskild SNAT-översättning. För generella miljöer rekommenderar Sophos dock att hålla NAT-regler så oberoende och enkla som möjligt i stället för att skapa onödigt många länkade NAT-regler per firewall-regel.
Load Balancing och Health Check
Om flera interna servrar publiceras bakom en publik 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 brandväggen ska känna igen om en målserver är tillgänglig måste en Health check konfigureras. Utan Health Check kan brandväggen även vidarebefordra trafik till en server som inte är nåbar.
Kontrollera firewall-regel
En NAT-regel tillåter inte automatiskt trafiken. Dessutom krävs en passande firewall-regel.
Firewall-regeln bör definiera:
- Source zone: oftast
WAN - Source network: så begränsat som möjligt
- Destination zone: zonen för den interna servern, till exempel
DMZ - Destination network: intern server
- Services: bara nödvändiga portar
- Security-profiler: beroende på tjänst IPS, Malware Scan eller Web Policy
- Logging: aktivera
Utan passande firewall-regel släpps trafiken trots DNAT.

Även för NAT-regler gäller ordningen. Sophos kontrollerar NAT-regler uppifrån och ned och använder den första matchande regeln. En för generell NAT-regel ovanför kan därför hindra den specifika DNAT-regeln från att träffa.
Begränsa åtkomsten så snävt som möjligt
Inte varje publicerad tjänst måste vara nåbar från hela internet. Om möjligt bör åtkomsten begränsas.
Lämpliga begränsningar:
- Tillåt bara enskilda käll-IP-adresser.
- Tillåt bara kända FQDN-hosts om motparten använder dynamiska IP-adresser.
- Tillåt bara vissa länder.
- Blockera vissa länder explicit.
- Gör åtkomst möjlig endast 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 admin-portaler är DNAT oftast inte den bästa lösningen. Om åtkomsten inte måste vara publik är VPN eller ZTNA nästan alltid det bättre valet.
Mer information:
Förbättra säkerheten
För publicerade tjänster bör man kontrollera:
- Är servern aktuell och patchad?
- Finns ett WAF- eller Reverse-Proxy-alternativ?
- Är IPS aktivt på firewall-regeln?
- Är bara nödvändiga portar öppna?
- Loggas tjänsten?
- Finns Geo-IP-, Threat Feed- eller käll-IP-begränsningar?
- Är MFA möjligt om det är en portal?
För webbapplikationer kan Web Server Protection vara mer lämpligt än enbart DNAT.
Bots och Threat Feeds
Publika portar som HTTP, HTTPS, SSH eller RDP står permanent i fokus för bots. Så snart en port är nåbar på internet ser man ofta mycket snabbt anslutningsförsök, scanningar, login-försök eller exploit-trafik i Log Viewer.
Det betyder inte automatiskt att servern är komprometterad. Det visar däremot att tjänsten är en del av den publika attackytan. Därför rekommenderar vi att publicerade tjänster dessutom skyddas med IPS, logging, snäva källor och Third-Party Threat Feeds.
Threat Feeds levererar fortlöpande aktuella Indicators of Compromise till brandväggen, till exempel skadliga IP-adresser eller domäner. Därmed kan brandväggen blockera kända angripare, botnät eller scanners innan de når den publicerade tjänsten.
Mer om detta: Sophos Firewall Threat Feeds
Test
Efter att DNAT-regeln har skapats:
- Testa från externt nät, inte från samma LAN
- Kontrollera portscan mot den publika IP:n
- Kontrollera Log Viewer för NAT- och firewall-events
- Kontrollera server-logs
- Kontrollera om klienten ser den förväntade käll-IP:n
Om testet ska göras från internt LAN mot den publika IP:n kan Hairpin NAT eller en intern DNS-lösning dessutom krävas.
Troubleshooting
Vanliga fel:
- Firewall-regel saknas
- fel WAN-IP vald
- port forwarding på provider-routern saknas
- Azure Network Security Group blockerar porten
- tjänsten kör inte internt
- serverns gateway pekar inte mot Sophos Firewall
- NAT-regeln ligger under en annan regel som träffar först
- porten används redan av en annan tjänst
- loopback saknas när interna klienter använder publik FQDN
- Health Check saknas eller är fel när Load Balancing används
- testet görs från det interna nätet och inte externt
Log Viewer är den viktigaste startpunkten vid DNAT-problem. Där ser man om trafik kommer fram, vilken regel som matchar och om trafiken tillåts eller nekas.
Rekommendation
DNAT-regler bör kontrolleras regelbundet. Gamla publiceringar är en typisk säkerhetsrisk. Bra dokumentation innehåller syfte, målserver, externa portar, ansvarig person, utgångsdatum och senaste granskning.