Konfigurera SSL Site-to-Site VPN på Sophos Firewall

En SSL Site-to-Site VPN kopplar ihop de interna näten bakom två Sophos Firewalls via en krypterad tunnel. Till skillnad från IPsec har båda sidor en fast roll: klientbrandväggen upprättar alltid anslutningen och serverbrandväggen tar emot den.

Det passar särskilt bra när en filial har en dynamisk publik IP-adress eller när IPsec får problem i ett överordnat nät. Huvudkontoret med en statisk adress eller stabil FQDN blir server och filialen blir klient. För växande nät, dynamisk routing, redundans eller en motpart från en annan leverantör är route-based IPsec vanligtvis mer flexibelt; för en liten anslutning mellan två Sophos-brandväggar kan SSL Site-to-Site vara enklare.

Instruktionen använder följande konkreta exempel:

Huvudkontor, server: vpn.example.com, lokalt nät 10.10.0.0/24
Filial, klient: dynamisk publik IP-adress, lokalt nät 10.20.0.0/24
Anslutning: HQ-to-Branch
SSL VPN-port: 8443

vpn.example.com, objektnamnen och båda näten är platshållare som ska ersättas med värdena i den egna miljön. 8443 är standardporten; den lämnas oförändrad endast om portanvändningen och säkerhetsdesignen passar för det.

Det korta arbetsflödet är: fastställ roller och nät, kontrollera de globala SSL VPN-värdena, tillåt SSL VPN i serverns WAN-zon, skapa serveranslutningen, exportera .apc-filen, importera den på klientbrandväggen och kontrollera därefter routes, regler och verklig användartrafik.

⚠️ De globala SSL VPN-inställningarna används även av Remote Access SSL VPN. Ändra därför inte port, protokoll, certifikat, adresspool eller kryptografi enbart för den här tunneln. Kontrollera först konsekvenserna för befintliga användaranslutningar och profiler.

Planera roller, nät och publik åtkomst

Serverbrandväggen bör vara den stabilare och, om modellerna skiljer sig åt, den kraftfullare enheten. Om bara ena sidan har en statisk publik IP-adress ska den sidan ha serverrollen. Klienten kan stå bakom NAT eller använda en anslutning med dynamisk adress, så länge den kan nå servern.

Följande måste vara fastställt före konfigurationen:

serverbrandväggens publika IP-adress eller FQDN;
protokoll och port för SSL VPN;
huvudkontorets lokala nät och filialens lokala nät;
unika adressområden som inte överlappar;
nödvändiga tjänster och tillåtna anslutningsriktningar;
returväg på båda sidor;
alternativ administrativ åtkomst för ändringen;
aktuell SFOS-version på båda brandväggarna.

Om näten överlappar räcker inte den här standardkonfigurationen. Då krävs en medveten design för adressöversättning och routing. I praktiken lämpar sig IPsec med planerad NAT vanligtvis bättre för det.

Kontrollera kompatibiliteten före ändringen

Konfigurationsstegen har jämförts med de sparade hjälptexterna för SFOS 22 och 23, inte testats på en brandvägg. Båda hjälpversionerna innehåller fortfarande migreringsvarningen för SFOS 20.0 MR1: SFOS 20.0 MR1 och senare versioner upprättar inte SSL Site-to-Site-anslutningar till SFOS 18.5 eller tidigare, eller till UTM 9. Varningen är inte en fullständig kompatibilitetsmatris för alla senare byggen. Kontrollera den specifika kombinationen före en uppgradering; för en berörd anslutning ska båda Sophos-brandväggarna använda kompatibla versioner med support, eller också ska IPsec eller en RED-tunnel planeras. UTM 9 kan inte bara uppdateras genom att tillämpa en SFOS-uppgradering.

Kontrollera globala SSL VPN-inställningar

De gemensamma inställningarna finns på den blivande serverbrandväggen under:

Remote access VPN > SSL VPN > SSL VPN global settings

I exemplet kontrolleras framför allt följande värden:

Protocol: UDP är vanligtvis det effektivare förstahandsvalet; TCP kan hjälpa i restriktiva nät.
SSL server certificate: måste vara giltigt. Importera ett externt certifikat med den privata nyckeln under Certificates > Certificates; för en extern certifikatkedja laddas även mellanliggande CA och rot-CA upp. Om en publik FQDN används bör certifikatet matcha det namnet.
Override hostname: vpn.example.com om klienterna ska använda exakt denna FQDN.
Port: 8443, såvida ingen annan portdesign har planerats medvetet.
Assign IPv4 addresses: får inte kollidera med de två platsnäten eller andra VPN-pooler.
Cryptographic settings: ändra inte befintliga värden utan kompatibilitets- och driftstest.

Om serverbrandväggen står bakom en överordnad router måste routern vidarebefordra vald port och valt protokoll till brandväggen. FQDN pekar då på routerns publika adress. WAF och SSL VPN får inte använda samma kombination av WAN-IP, port och protokoll.

Om Port, Protocol, SSL server certificate eller Override hostname senare ändras måste serverkonfigurationen hämtas igen och importeras på nytt på klientbrandväggen. Den befintliga .apc-exporten känner inte till de nya värdena.

De fullständiga beroendena för de globala inställningarna beskrivs i SSL VPN Remote Access på Sophos Firewall. Där planeras ändringar med hänsyn till befintliga användarprofiler, leasepooler, DNS och publikt åtkomliga tjänster.

Tillåt SSL VPN för serverns WAN-zon

På serverbrandväggen tillåts den lokala SSL VPN-tjänsten för den inkommande zonen:

Administration > Device access

Om klientbrandväggen har en dynamisk publik adress eller en adress som inte kan begränsas meningsfullt aktiveras SSL VPN för WAN under VPN services. Det tillåter bara att tunneln upprättas till brandväggen; det ersätter inte en brandväggsregel för användartrafiken mellan platserna.

Den här behörigheten behövs bara på serverbrandväggen. Klientbrandväggen upprättar tunneln utgående, så aktivera inte SSL VPN för WAN i Device Access där som en förebyggande åtgärd.

Om de publika källnäten på klientsidan är stabila och kända lämnas SSL VPN avstängt i WAN-matrisen. I stället skapas ett riktat Accept Local Service ACL Exception med Source zone WAN, kända Source Networks/Hosts, serverns WAN-adress som Destination host och tjänsten SSL VPN. Ett Accept-undantag begränsar inte en WAN-matrisåtkomst som redan är aktiv. Planeringen beskrivs i Konfigurera Device Access säkert på Sophos Firewall.

Skapa serveranslutningen på huvudkontoret

Först skapas båda näten som IP-hostobjekt på serverbrandväggen:

Hosts and services > IP host

HQ-LAN: 10.10.0.0/24
Branch-LAN: 10.20.0.0/24

Därefter skapas serveranslutningen:

Öppna Site-to-site VPN > SSL VPN.
Klicka på Add i området Server.
Ange HQ-to-Branch som namn.
Välj HQ-LAN under Local networks.
Välj Branch-LAN under Remote networks.
Aktivera Use static virtual IP address endast om det finns ett motiverat behov och välj en ledig adress utanför de globala statiska och dynamiska SSL VPN-poolerna som inte krockar med någon annan privat IP-adress.
Spara med Save.

Local networks är ur serverbrandväggens perspektiv näten på huvudkontoret. Remote networks ligger bakom klientbrandväggen. Perspektivet är viktigt: om objekten byter plats kan tunneln bli grön trots att routes och regler inte stämmer med den avsedda anslutningen.

Utan Use static virtual IP address tilldelar brandväggen automatiskt klienten en adress från leasepoolen i SSL VPN global settings. Vid en fast tilldelning anges den valda adressen i Static peer IP; det är klientens virtuella tunneladress, inte filialens LAN.

Hjälptexterna anger högst 1024 värdar för vart och ett av fälten Local networks och Remote networks. De förklarar inte här hur nätobjekt räknas jämfört med enskilda IP-adresser. Det går därför inte att dra slutsatsen att det finns en generell gräns för subnätets storlek eller att uppdelning av samma nät är en lösning. För en konfiguration nära gränsen ska objektval och sparande kontrolleras på det specifika bygget och räknemetoden klargöras före produktionsändringen.

Exportera serverkonfigurationen säkert

Välj Download för HQ-to-Branch i serverlistan. Exporten har filändelsen .apc och innehåller anslutningsuppgifterna för klientbrandväggen.

För en säker överföring, aktivera Encrypt configuration file, ange och bekräfta ett starkt tillfälligt lösenord och klicka sedan på Download. Fil och lösenord överförs via separata kanaler. .apc-filen hör inte hemma i ett offentligt ärende, en oskyddad chatt eller en permanent nedladdningskatalog.

Importera konfigurationen på klientbrandväggen

På filialens brandvägg sker importen under samma menysökväg:

Öppna Site-to-site VPN > SSL VPN.
Klicka på Add i området Client.
Ange Branch-to-HQ som namn.
Klicka på Choose file och välj den exporterade .apc-filen.
Ange lösenordet om exporten är krypterad.
Aktivera Use HTTP proxy server endast om filialen verkligen når servern via en explicit HTTP-proxy. Ange då den godkända proxyservern och dess faktiska lyssningsport. Aktivera Proxy requires authentication endast om den proxyn kräver inloggning; använd det avsedda proxyanvändarnamnet och tillhörande lösenord. Anta inte en port och ändra inte globala proxyinställningar som en workaround.
Ange Override peer hostname endast om serveradressen i exporten inte kan routas eller lösas upp från klientnätet. I exemplet lämnas fältet tomt eftersom vpn.example.com redan exporteras globalt.
Spara med Save och aktivera anslutningen.

Lösenordet för importen av den krypterade .apc-filen dekrypterar filen; det är inte proxylösenordet. Override peer hostname anger servermotparten, inte proxyn. Håll båda lösenorden hemliga och ta inte med dem i skärmbilder, loggar eller ärenden. Öppna klientposten igen efter att den sparats och jämför proxyserver, port, autentiseringsalternativ och motpart med de godkända värdena utan att röja hemligheter; kontrollera sedan tunnel och applikationstrafik enligt beskrivningen nedan.

För automatisering via XML API visar de sparade Add/Edit-exemplen för SFOS 22 och 23 ProxyServer, ProxyPort och ProxyAuthentication endast när HttpProxyServer = Enable, och Username och Password endast när proxyautentisering är aktiverad. FilePassword hör till ServerConfigurationFile; PeerHost/HostName är en separat gren. Tabellen markerar proxyserver och port som obligatoriska trots att exemplet visar dem villkorligt, och anger standardvärdet OFF för proxyautentisering men de tillåtna värdena Disable/Enable. Härled inte någon serialiserare eller giltig begäran ur detta: om det är oklart vilka fält som ska ingå eller hur värden ska representeras, avstå från automatiseringen, använd den stödda vägen i gränssnittet och klargör schemat för det specifika bygget med Sophos Support.

Statusen blir grön så snart klientbrandväggen når servern och tunneln har upprättats. En grön status bekräftar bara själva anslutningen, inte åtkomsten till servrar, DNS eller applikationer.

Kontrollera routes och brandväggsregler

Näten som valts under Local networks och Remote networks börjar gälla för tunnelroutingen. De tillhör routingklassen static och måste stämma med den övriga routingkonfigurationen. En mer specifik statisk route, SD-WAN-route eller VPN-route kan annars leda till en annan väg än väntat. Ordningen beskrivs i Förstå och ändra routingprioritet på Sophos Firewall.

Brandväggsregler för användartrafiken skapas medvetet på båda brandväggarna eller jämförs med befintliga regler. I exemplet, där filialen initierar anslutningar till huvudkontoret, krävs minst:

på filialens brandvägg en begränsad regel från LAN till VPN för Branch-LAN till de nödvändiga målen i HQ-LAN;
på serverbrandväggen en matchande regel från VPN till LAN för Branch-LAN till dessa mål;
endast nödvändiga tjänster, till exempel DNS, RDP och HTTPS;
Log firewall traffic för acceptanstestet;
ingen SNAT- eller MASQ-regel som ändrar platstrafiken utan saklig anledning.

Dessa två regler täcker den nya anslutningen som filialen initierar och dess stateful returtrafik; flödet kräver inte ytterligare två spegelvända regler. Kopiera inte zonerna från en IPsec-instruktion. I Log Viewer eller Packet Capture måste testflödet gå från LAN till SSL VPN-tunneln på filialens brandvägg och från SSL VPN-tunneln till LAN på serverbrandväggen. Om observerad zon, Out interface eller Rule ID avviker korrigeras först routing och regelmatchning i stället för att regeln breddas till Any.

Om huvudkontoret också ska kunna initiera nya anslutningar till filialen tillåts motriktningarna separat. En bred Any-regel är inte en färdig säkerhetsdesign. Testa brandväggsregel visar hur regelposition, Rule ID och Packet Capture kontrolleras tillsammans.

Planera failover och rollback

En SSL Site-to-Site-tunnel ingår inte i en IPsec-failovergrupp. .apc-filen ger klienten den exporterade serveranslutningen. En FQDN eller flera WAN-vägar ger inte i sig avbrottsfri redundans: vid ett WAN-byte bryts den befintliga sessionen och klienten måste åter nå den konfigurerade servern via den nya vägen. Använd route-based IPsec när automatisk tunnelfailover mellan flera definierade anslutningar krävs.

Vid ett enkelt WAN-failovertest ska serverns aktiva FQDN förbli upplösningsbart och nåbart via reservvägen; överordnad NAT och port forwarding måste tillhandahålla samma SSL VPN-protokoll och port där. Kontrollera därefter att klienten återansluter och att både tillåten och blockerad användartrafik fortfarande hanteras enligt designen. En grön tunnel är inte heller här ett tillräckligt acceptanskriterium.

Dokumentera före ändringen tidigare globala SSL VPN-värden, Device Access-behörigheter, server- och klientposter, regler samt den senast fungerande .apc-filen. Vid rollback inaktiveras först de nya reglerna och anslutningarna, därefter återställs tidigare globala värden och Device Access-inställningar och den gamla .apc-filen importeras på klienten. Ta bort nya objekt först när tunnel, positivt test och negativt test fungerar igen.

Före en godkänd borttagning under Site-to-site VPN > SSL VPN, välj exakt sparat anslutningsnamn, brandvägg och rollen Client eller Server, kontrollera beroende motparter och regler i produktion och behåll den fungerande exporten och återställningsvägen. De sparade XML-Delete-sidorna för SFOS 22 och 23 markerar Name som valfritt men innehåller inget exempel på en Delete-begäran. Det tillåter inte borttagning utan mål eller med bred omfattning och gör inte klient- och serveroperationer utbytbara. Utför ingen XML-borttagning om identiteten eller schemat är oklart: behåll den stödda vägen i gränssnittet och begär ett förtydligande för det specifika bygget. Kontrollera efter borttagningen det operationsspecifika svaret och det faktiska tillståndet för exakt målpost; kontrollera även övriga produktionsanslutningar och deras tillåtna och blockerade trafik igen.

Verifiera tunnel och användartrafik

Testet börjar med en specifik klient och ett specifikt mål. I exemplet ansluter en enhet från 10.20.0.0/24 till en tillåten server i 10.10.0.0/24.

Kontrollera grön status och ökande byte-räknare på båda brandväggarna.
Testa målet först via IP-adress och sedan via hostname.
Öppna en tjänst som verkligen är tillåten, till exempel HTTPS eller RDP.
Kontrollera förväntad Firewall Rule ID och oförändrade käll- och måladresser i Log Viewer.
Testa en otillåten tjänst eller ett ej godkänt mål och bekräfta att trafiken blockeras.
Kontrollera motriktningen separat om den ska vara tillåten av verksamhetsskäl.
Kontrollera efter en omstart eller ett WAN-byte att klientbrandväggen återupprättar tunneln.

En lyckad ping räcker inte. Den bevisar varken DNS eller den nödvändiga applikationstjänsten. För ett internt målsystem måste brandväggsregel, returväg och endpoint-brandvägg stämma för testet. Device Access är bara relevant om en adress på själva Sophos Firewall pingas.

Läs loggar vid fel

Under Site-to-site VPN > SSL VPN > Logs kan SSL VPN-loggningen öppnas direkt. För en djupare kontroll loggar man in via SSH, väljer 5. Device Management > 3. Advanced Shell och läser den aktuella serviceloggen:

tail -n 200 /log/sslvpn.log

Kommandot ändrar ingen konfiguration. Tidpunkt, anslutningsnamn och server-/klientsida dokumenteras tillsammans. Ytterligare OpenVPN-statusfiler kan beroende på antalet processer finnas som openvpn-status0.log, openvpn-status1.log och fler filer. Mappningen beskrivs i Sophos Firewall-serviceloggar.

Avgränsa vanliga fel systematiskt

Tunneln förblir röd: kontrollera publik FQDN, DNS, port forwarding, protokoll, certifikat och SSL VPN i Device Access för serverns WAN-zon. Läs därefter sslvpn.log för samma tidpunkt.
Tunneln upprättas inte efter en global ändring: exportera serverkonfigurationen på nytt och importera den igen på klienten. Framför allt port, protokoll, certifikat och Override hostname är exportberoende.
Tunneln är grön, men ingen trafik flödar: kontrollera tunnelrouting, routingprioritet, regler på båda brandväggarna, Rule ID, returväg, NAT och endpoint-brandvägg. Följ därefter ett enskilt flöde med Packet Capture.
Endast namn fungerar inte: testa åtkomst via IP, kontrollera DNS-server och sökdomän och säkerställ att DNS-servern kan nås och är tillåten via tunneln.
FQDN-hostobjektet pekar fortfarande på den gamla adressen: Från SFOS 20.0 kan FQDN-hosts och -grupper användas som Local networks och Remote networks. Jämför efter en DNS-ändring först adressen som brandväggen har slagit upp med förväntad IP-adress och kontrollera sedan valda objekt, route och ett applikationsflöde. Underlaget här visar inte att nedkoppling och återanslutning av en SSL Site-to-Site-tunnel uppdaterar dessa adresser; avbryt inte en fungerande tunnel enbart för att tvinga fram en DNS-uppdatering. Om routen fortfarande är inaktuell, dokumentera build, namnuppslagning, route och loggar för fortsatt utredning. Förväxla inte ett målobjekts FQDN med serverns FQDN: om den senare inte kan slås upp kan själva tunnelanslutningen förhindras.
Klienten når servern endast via en proxy: använd Use HTTP proxy server med de godkända proxyvärdena. Ange inte godtyckliga proxyuppgifter som en allmän workaround.
Fel efter migrering, med en motpart på SFOS 18.5 eller tidigare eller UTM 9: kontrollera först versionskombinationen mot varningen för SFOS 20.0 MR1 ovan innan port eller certifikat ändras. En berörd anslutning behöver kompatibla motparter eller ett planerat alternativ med IPsec eller RED.

Om tunneln fortfarande är oklar efter ett kontrollerat test sparas SFOS-version och build för båda brandväggarna, tidpunkt med tidszon, anslutningsnamn, sslvpn.log, Rule IDs och en kort Packet Capture. Först därefter bör regler, nät eller globala SSL VPN-värden ändras ytterligare.