Konfigurera Sophos Firewall Site-to-Site IPsec VPN

En Site-to-Site IPsec VPN kopplar ihop två platser, eller en Sophos Firewall med en tredjepartsbrandvägg, via en krypterad tunnel. I praktiken misslyckas en sådan tunnel sällan på grund av en enda kryssruta i gränssnittet. Oftare beror det på otydliga nät, olika IPsec-profiler, saknade brandväggsregler, särskilda NAT-fall eller en returväg som har glömts på ena sidan.

Den här artikeln förklarar hur man bygger en ren Site-to-Site IPsec-tunnel på Sophos Firewall. Fokus ligger på planering, genomförande och acceptanstest. Om en befintlig tunnel redan är grön men ingen trafik går igenom är Sophos Firewall IPsec VPN Troubleshooting den bättre fortsättningsartikeln.

När den här artikeln passar

Artikeln passar klassiska platsförbindelser, till exempel:

• Huvudkontor till filial
• Sophos Firewall till Sophos Firewall
• Sophos Firewall till tredjepartsbrandvägg
• Sophos Firewall till cloud gateway när ingen särskild cloud-assistent används
• Migrering från enkla gamla policy-based tunnlar till en dokumenterad aktuell konfiguration

Den avser inte Remote Access för enskilda användare. För det passar artiklarna Konfigurera Sophos Connect på Sophos Firewall, Sophos Connect eller SSL VPN: vilken Remote Access-lösning passar? och Migrera legacy Remote Access IPsec före SFOS 22 MR1.

Policy-based eller route-based IPsec

Före konfigurationen måste man bestämma om tunneln ska byggas som policy-based eller route-based. I aktuella SFOS-versioner är dessa begrepp tydligare separerade än i äldre instruktioner, som delvis fortfarande talar om Site-to-Site eller Tunnel Interface.

För små, stabila förbindelser är policy-based IPsec ofta snabbast att förstå. För större eller dynamiska platsnät är route-based IPsec oftast renare, eftersom routing och VPN-förhandling separeras bättre. Om flera nät, SD-WAN, BGP, OSPF eller cloudnät är inblandade bör route-based IPsec kontrolleras först.

Förutsättningar

Före konfiguration bör denna information dokumenteras:

⚠️ Site-to-Site VPN bör inte implementeras utan dokumenterad returväg. Om den lokala brandväggen skickar trafik in i tunneln, men motparten inte känner till vägen tillbaka eller förväntar sig NAT annorlunda, ser tunneln ofta frisk ut trots att applikationer inte fungerar.

Planera före konfigurationen

Håll näten entydiga

Lokala nät och fjärrnät får inte överlappa oavsiktligt. Särskilt problematiska är vanliga standardnät som 192.168.0.0/24, 192.168.1.0/24 eller återanvända filialnät. Om nät överlappar krävs en medveten NAT-design. Att bara använda samma adressområde på båda sidor och senare översätta det “på något sätt” skapar tunnlar som är svåra att underhålla.

För nya platser lönar det sig därför med ett rent IP-adresskoncept. Om VLANs eller zones ännu inte är tydligt modellerade hjälper konfigurera Sophos Firewall zones och interfaces.

Stäm av IPsec-profilen

Båda sidor måste använda kompatibla parametrar för Phase 1 och Phase 2. Det omfattar kryptering, autentisering, DH group, PFS och lifetime. Vid anslutningar till tredjepartsbrandväggar är det ofta enklast att först dokumentera en gemensam profil skriftligt och därefter konfigurera båda sidor.

Om en tunnel inte kommer upp är NO_PROPOSAL_CHOSEN, ID-fel eller autentiseringsfel typiska indikationer. Den strukturerade analysen finns i Sophos Firewall IPsec VPN Troubleshooting.

Glöm inte brandväggsregler

En IPsec-tunnel ger ännu ingen produktiv åtkomst. Trafik genom tunneln behöver fortfarande passande brandväggsregler. Vid policy-based anslutningar är det oftast regler mellan LAN och VPN eller mellan egna zones. Vid route-based design beror det på vilken zone XFRM-interfacet eller den relevanta vägen är tilldelad.

Vid införandet bör Log firewall traffic aktiveras i berörda regler. Annars saknas senare exakt den information som visar vilken regel som tillät eller blockerade ett test. Det allmänna kontrollflödet finns i testa brandväggsregel med Log Viewer, Policy Test och Packet Capture.

Kontrollera automatiskt skapade regler medvetet

När en Site-to-Site IPsec-anslutning skapas kan alternativet Create firewall rule hjälpa till att skapa en första regeluppsättning. Det ersätter inte en säkerhetskontroll. Sophos Firewall skapar dessa regler överst i listan över brandväggsregler. I aktuella SFOS-versioner skapas separata regler för inkommande och utgående trafik med prefixen Incoming och Outgoing.

För driften är därför viktigt:

⚠️ Automatiskt skapade brandväggsregler är en startpunkt, inte en färdig säkerhetsdesign. Särskilt vid platstunnlar till servernät bör services, källor och mål reduceras efter första testet.

Vid route-based IPsec med Any-to-Any-subnät måste man arbeta särskilt noggrant. För sådana route-based designer kan inga automatiska brandväggsregler skapas. Vid dual IP-versioner ska IPv4- och IPv6-regler planeras separat. I dessa scenarier bör brandväggsregler, XFRM-interface, routes och tester byggas upp medvetet för hand.

Konfigurera policy-based IPsec

Policy-based IPsec är den klassiska varianten för enkla Site-to-Site-anslutningar. De lokala näten och fjärrnäten definieras direkt i IPsec-anslutningen.

1. Kontrollera eller skapa IPsec-profil

Menu path:

Profiles > IPsec profiles

Kontrollera först om en befintlig profil passar motparten. Om en egen profil behövs bör den namnges tydligt, till exempel IPsec_IKEv2_AES256_G14. Namnet måste fortfarande vara begripligt senare när flera tunnlar och motparter finns.

Dokumentera minst:

• IKE-version
• Phase 1 Encryption och Authentication
• DH Group
• Phase 2 Encryption och Authentication
• PFS
• Key lifetime

Vid tredjepartsbrandväggar bör motparten bekräfta samma värden skriftligt. En skärmbild ensam räcker ofta inte, eftersom enskilda fält kan heta olika beroende på tillverkare.

2. Lägg till IPsec-anslutning

Menu path:

Site-to-site VPN > IPsec

Skapa en ny IPsec-anslutning och välj Policy-based som Connection type. Ange sedan grunddata:

• Tunnelns namn, till exempel branch-zurich
• Local gateway respektive Listening interface
• Remote Gateway som IP-adress eller FQDN
• Authentication type: Preshared Key eller certifikat
• Local ID och Remote ID om det behövs
• IPsec profile
• Local subnet
• Remote subnet

För Preshared Keys bör en stark och unik nyckel användas och dokumenteras säkert. En gammal standardnyckel som delas mellan flera platser är en onödig driftsrisk.

3. Aktivera tunneln

Vid sparandet kan Activate on save sättas. I produktionsmiljöer bör det ske i ett definierat underhållsfönster, när motparten är nåbar och båda sidor kan kontrollera loggar.

Efter sparandet visar listan två relevanta tillstånd:

• om anslutningen är aktiv
• om tunneln faktiskt är established

En aktiv post är inte automatiskt en etablerad tunnel. Vid flera lokala nät eller fjärrnät kan det dessutom finnas flera Security Associations.

Konfigurera route-based IPsec

Route-based IPsec separerar VPN-förhandling och routing tydligare. Sophos Firewall skapar då ett XFRM-interface. Därefter avgör statiska routes, SD-WAN Routes eller dynamisk routing vilken trafik som går genom tunneln.

1. Skapa anslutningen som route-based

Menu path:

Site-to-site VPN > IPsec

Välj Route-based (Tunnel interface) för anslutningen. Parametrarna för gateway, autentisering, IDs och IPsec-profil måste fortfarande passa motparten. Dessutom måste man förstå vilket XFRM-interface som skapas och hur det routas.

Sophos visar det skapade XFRM-interfacet under det använda fysiska interfacet i:

Network > Interfaces

Beroende på design behöver XFRM-interfacet en IP-adress. Särskilt vid Any-to-Any-design, dual IP-version eller mer komplexa routingscenarier bör interface-adresseringen planeras rent.

När Any-to-Any används avgör inte längre Tunnel Selector ensam vilken trafik som går genom tunneln. Routes och brandväggsregler blir då central styrning. Det är flexibelt, men också felkänsligt: en för bred regel kan tillåta mer trafik än avsett, en saknad route kan få tunneln att se grön ut utan att användartrafik går igenom.

2. Sätt routing

Vid route-based VPN räcker IPsec-anslutningen ensam inte. Det behövs en route till fjärrnätet:

• statisk route till XFRM-interfacet
• SD-WAN Route med passande gateway eller profil
• dynamisk route via BGP eller OSPF om designen är byggd för det

För enkla setups räcker ofta en statisk route. Om flera WAN-förbindelser, SLA-kontroller eller failovervägar används är en SD-WAN Route mer lämplig. Den allmänna kontexten för SD-WAN, Reply Packets och systemgenererad trafik finns i kontrollera Sophos Firewall SD-WAN routing för Reply Packets och System Traffic.

3. Beakta XFRM och MTU

Route-based VPNs är mer känsliga för missförstånd kring routing, MTU och MSS. Om små tester fungerar men större överföringar fastnar bör man inte direkt ändra IPsec-profilen. Kontrollera först MTU, MSS, fragmentering och den verkliga vägen. Rätt procedur finns i kontrollera Sophos Firewall MTU och MSS vid VPN-problem.

Skapa brandväggsregler

Efter IPsec-konfigurationen behövs regler för produktiv trafik. Utan passande regler kan tunneln visserligen vara grön, men applikationer fungerar inte.

Menu path:

Rules and policies > Firewall rules

Typiska regler:

God praxis:

• Regelnamn med tunnel eller plats, till exempel LAN_to_Branch_Zurich.
• Sätt Source och Destination så snävt som möjligt.
• Definiera Services konkret.
• Aktivera logging under införande och troubleshooting.
• Kontrollera regelposition.
• Sätt skyddsfunktioner medvetet i stället för att ta över dem av en slump.

Om internettrafik från en filial ska ledas via huvudkontoret behövs dessutom ett medvetet NAT- och säkerhetskoncept. Det är en annan design än en enkel platsförbindelse för interna nät.

Planera NAT medvetet

NAT är inte förbjudet med IPsec, men det måste vara tydligt motiverat. Typiska fall är överlappande nät, cloudkrav eller tredjepartsaktörer som bara accepterar vissa källadresser.

Menu path:

Rules and policies > NAT rules

Före en NAT-regel bör dessa frågor vara besvarade:

• Förväntar sig motparten ursprungliga IP-adresser eller översatta adresser?
• Finns det överlappande nät?
• Löses NAT i IPsec-anslutningen eller via separata NAT-regler?
• Är returriktningen dokumenterad?
• Visar Log Viewer efter NAT förväntad Source och Destination?

För policy-based specialfall med NAT kan en manuell IPsec Route på Sophos Firewall bli relevant. Det är dock inget standardsteg för varje tunnel.

Device Access och WAN-åtkomst

För inkommande IPsec-förfrågningar måste brandväggen kunna ta emot IPsec-trafik på rätt WAN-zone. Det löses inte via en vanlig LAN-to-WAN-regel, utan via brandväggens lokala services.

Menu path:

Administration > Device access

Där måste IPsec vara tillåtet för den nödvändiga zone. Samtidigt bör man kontrollera om andra lokala services som WebAdmin, SSH, User Portal eller VPN Portal är onödigt brett nåbara. För härdning av dessa lokala services är säkra åtkomst till Sophos Firewall: konfigurera Device Access rätt den centrala artikeln.

Testa tunneln

Ett bra acceptanstest kontrollerar inte bara grön status. Det kontrollerar det faktiska dataflödet.

1. Kontrollera status

I WebAdmin-gränssnittet:

Site-to-site VPN > IPsec

Kontrollera:

• Anslutningen är aktiv.
• Tunnelstatus är established.
• Vid flera nät är alla förväntade Child SAs etablerade.
• Inga återkommande reconnects eller fel syns.

2. Kontrollera Log Viewer

Menu path:

Log viewer

Generera testtrafik med tydlig Source, Destination och Service. Kontrollera sedan i Log Viewer vilken brandväggsregel som matchar och om NAT, Webfilter, IPS eller andra moduler påverkar trafiken.

3. Använd Packet Capture

Om Log Viewer inte räcker bör Packet Capture användas med ett snävt filter:

Diagnostics > Tools > Packet capture

Filterexempel:

host 172.16.10.25 and host 10.20.30.15

Vid VPN-troubleshooting är det viktigt att kontrollera båda riktningarna. Endast utgående paket utan svar visar oftast ett returvägs-, NAT- eller motpartsproblem.

4. Använd CLI bara målinriktat

För djupare analys kan Advanced Shell användas via SSH:

ipsec statusall

Intressant är bland annat:

• IKE SA established
• Child SA installed
• lokala nät och fjärrnät
• byte-räknare i båda riktningar
• återkommande rekey- eller disconnect-meddelanden

Om SSH ännu inte är förberett hjälper ansluta till Sophos Firewall via SSH.

Typiska fel

Checklista

Före ändringen:

• Lokala nät och fjärrnät är entydiga.
• Policy-based eller route-based valdes medvetet.
• IPsec-profilen är avstämd med motparten.
• Preshared Key eller certifikat är säkert dokumenterade.
• Brandväggsregler är planerade, inklusive riktning, regelposition, logging och services.
• Vid Create firewall rule är det klart vilka automatiskt skapade regler som måste efterbearbetas.
• Vid route-based Any-to-Any är manuella brandväggsregler och routes planerade.
• NAT är antingen uteslutet eller medvetet dokumenterat.
• Device Access för IPsec är kontrollerat.
• Underhållsfönster, motpart och fallbackväg är kända.

Efter ändringen:

• Tunnelstatus är established.
• Log Viewer visar den förväntade brandväggsregeln.
• Packet Capture visar utgående och återgående riktning.
• Intern DNS- och applikationsåtkomst har testats.
• Byte-räknare stiger i båda riktningar.
• NAT och returväg är avstämda med motparten.
• Ändringen är införd i nätverksdokumentationen.

Vanliga frågor