Använd globala VPN-inställningar i Sophos Firewall säkert

Sophos Firewall Device Console innehåller under set vpn globala inställningar för VPN-failover, IPsec-bearbetning och de äldre protokollen L2TP och PPTP. De påverkar inte bara anslutningen som undersöks. Ett ospecifikt test kan påverka andra tunnlar, ta bort befintliga sessioner eller försvaga en skyddsfunktion.

Inget allmänt prestandarecept: sätt inte förebyggande ipsec-max-workqueue-items, anti-replay-fönstret eller use-resolved-ip-address till större värden eller enable. Sophos beskriver dem som avancerade inställningar som ska användas för ett konkret nätverksbehov eller på råd från Sophos Support.

Vid vanliga tunnelproblem används först IPsec VPN-troubleshooting. Där kontrolleras IKE, Child SA, routing, NAT, regler och det verkliga paketflödet. De globala inställningarna i den här artikeln blir relevanta först när symptomet exakt motsvarar deras syfte.

Dokumentera utgångsläget före varje ändring

Kommandona körs under 4. Device Console. Dokumentera SFOS-version och build, tidpunkt, berörda tunnlar, förväntat testflöde och en oberoende administrationsväg innan ett värde sätts. Läs de befintliga värdena separat:

show vpn conn-remove-on-failover
show vpn conn-remove-tunnel-up
show vpn ipsec-performance
show vpn configuration

show vpn ipsec-performance visar bland annat workqueue- och replayvärden. show vpn configuration gäller den aktuella L2TP- och PPTP-konfigurationen. Om ett värde inte visas i den installerade builden får det inte härledas från ett antaget defaultvärde. Ta med en konfigurationsbackup och Sophos Support i ändringen innan en global avancerad inställning ändras.

Rollback använder alltid det faktiska värdet som lästes från appliance. default är inte dokumenterat som en universell återställning för dessa VPN-kommandon och ska inte användas på antagande.

Sessioner vid tunnel- och WAN-övergångar

conn-remove-tunnel-up avgör om befintliga anslutningar tas bort när en IPsec-tunnel kommer upp. Det kan vara viktigt om ett flöde började över en annan väg och ligger kvar på fel väg efter att tunneln etablerats. Borttagningen kan samtidigt avbryta produktionssessioner. Nya konfigurationer använder disable som default sedan SFOS 19.0, medan migrerade system kan behålla ett äldre värde.

set vpn conn-remove-tunnel-up enable
set vpn conn-remove-tunnel-up disable

conn-remove-on-failover styr den globala rensningen vid failover och failback. all påverkar alla anslutningar, medan non-tcp begränsar rensningen till icke-TCP-trafik som UDP eller ICMP. Rätt värde är därför inte bara ett VPN-beslut: VoIP, videokonferenser, DNS och andra UDP-applikationer måste observeras i samma testfönster.

set vpn conn-remove-on-failover all
set vpn conn-remove-on-failover non-tcp

Sophos ändrade dessa defaultvärden i SFOS 19.0 för nya konfigurationer för att minska flapping av icke-TCP-anslutningar när IPsec-tunnlar kommer upp eller går ned. Ändringen tillämpades medvetet inte generellt vid uppgraderingar och migreringar. I SFOS 22 är därför den aktuella enhetsutmatningen avgörande, inte ett antaget fabriksvärde.

I HA ska det också beaktas att Sophos Firewall inte lämnar över VPN- och icke-TCP-sessioner till peer på samma sätt som vanliga vidarebefordrade TCP-sessioner. De två conn-remove-*-inställningarna ersätter varken HA-designen eller ett kontrollerat failovertest.

IPsec-prestanda och skyddsfunktioner

Gruppen ipsec-performance innehåller fyra mycket olika funktioner. Namnet kan uppmuntra till tuningexperiment, trots att bara en funktion direkt anger storleken på en arbetskö.

Ändra workqueue endast vid en bevisad flaskhals

ipsec-max-workqueue-items accepterar värden från 1024 till 10240. Kön innehåller arbete för IPsec-bearbetning. Ett större värde garanterar inte högre throughput och löser inte Packet Loss, MTU-problem, svaga single-stream-resultat eller en mättad WAN-länk.

set vpn ipsec-performance ipsec-max-workqueue-items <1024-10240>

En ändring är bara meningsfull när ett reproducerbart belastningstest, systemutnyttjande och Sophos-diagnostik pekar på exakt denna flaskhals. Kontrollera först separat MTU och MSS, latency, Packet Loss, krypteringsprofil, IPsec Acceleration och parallella testströmmar. Återställ det dokumenterade utgångsvärdet utan förbättring.

Anti-replay-fönstret är en säkerhetsfunktion

IPsec registrerar inom replayfönstret vilka paket som redan har setts under dekrypteringen. Upprepade paket kan därmed upptäckas och kasseras. SFOS 22 accepterar 0, 32, 64, 128, 256, 512, 1024, 2048 och 4096; dokumenterat default är 1024.

set vpn ipsec-performance anti-replay window-size <varde>

Ett större fönster kan vara relevant när paket omordnas kraftigt över parallella vägar. Det är ingen allmän throughputinställning. Värdet 0 tar bort anti-replay-skyddet och rekommenderas inte som lösning. Ett sådant test hör hemma i ett isolerat servicefönster med uttrycklig anvisning från Sophos Support och omedelbart tillgänglig rollback.

IKEv2-cookiegränsen skyddar halvöppna SA:er

Enligt Sophos är cookievalidering alltid aktiv och endast tillgänglig för IKEv2. cookie_threshold slår inte på eller av den. När antalet samtidiga halvöppna IKE SA:er överskrider gränsen begär respondern en cookie från initiatorn. Etableringstillståndet skyddas därmed mot DoS-belastning. Dokumenterat default är 30.

set vpn ipsec-performance cookie_threshold <nummer>

Ett lägre eller högre värde väljs endast utifrån verklig IKE-belastning och supportdiagnostik. Det åtgärdar inte saknade Child SA:er, avvikande proposals eller autentiseringsfel. Vid validering observeras nya IKEv2-anslutningar, strongswan.log, CPU-belastning och legitima samtidiga inloggningar.

Använd den upplösta peeradressen endast för det dokumenterade Charon-fallet

use-resolved-ip-address är avsett för många site-to-site IPsec-tunnlar med FQDN-peers och långsam DNS-upplösning. Enligt Sophos kan just den kombinationen blockera en charon-thread. Med enable använder brandväggen den redan upplösta adressen i stället för att initiera tunneln med en ny upplösning av remote FQDN.

set vpn ipsec-performance use-resolved-ip-address enable
set vpn ipsec-performance use-resolved-ip-address disable

FQDN måste redan ha lösts korrekt. Dokumenterat default är Off. Inställningen ersätter därför inte fungerande DNS, lämpliga TTL-värden eller nåbara resolvers. Korrelera upplösningstid, aktuella A- och AAAA-svar, antal tunnlar och charon.log före aktivering. Kontrollera efter ett DNS- eller providerbyte att brandväggen använder den nya peeradressen inom förväntad tid. Utan det beskrivna Charon-fallet lämnas inställningen avstängd.

L2TP-kompatibilitet, MTU och PPTP

set vpn innehåller även autentiseringsprotokoll för L2TP och PPTP samt global L2TP-MTU. Det gör inte PPTP lämpligt för nya miljöer. PPTP är föråldrat och ska inte införas på nytt. Även L2TP Remote Access förblir en kontrollerad kompatibilitetslösning, inte den föredragna standarden för nya hanterade klienter.

Läs först aktuell konfiguration med show vpn configuration. För L2TP och PPTP finns ANY, CHAP, MS_CHAPv2 och PAP:

set vpn l2tp authentication <ANY|CHAP|MS_CHAPv2|PAP>
set vpn pptp authentication <ANY|CHAP|MS_CHAPv2|PAP>

Välj inte värdet enbart efter det namn som låter starkast. Klient, autentiseringsserver och VPN-metod under Authentication > Services måste stödja samma protokoll. Särskilt med Active Directory kan den stödda kombinationen skilja sig från en RADIUS-väg. ANY är ingen säkerhetsförbättring utan breddar accepterade metoder och kräver därför ett medvetet riskbeslut.

L2TP-MTU kan ställas från 576 till 1460; dokumenterat default är 1410:

set vpn l2tp mtu <576-1460>

L2TP-MTU ändrar inte ett route-based eller policy-based site-to-site IPsec-interface. Justera det stegvis endast vid ett reproducerbart L2TP-fragmenteringsproblem. Stora och små överföringar, DNS, autentisering och återanslutning måste därefter fortsätta fungera.

Testa och återställ kontrollerat

Ändra exakt ett globalt värde per servicefönster. Använd samma tunnlar, testflöde och WAN- eller HA-övergång före och efter ändringen. För IPsec dokumenteras tunnelstatus, Child SA, bytecounters, strongswan.log, charon.log, CPU och Packet Loss. Vid sessionsrensning inkluderas VoIP, DNS och andra UDP-flöden.

En lyckad ping är inget fullständigt acceptanstest. Kontrollera minst ett befintligt flöde, en ny anslutning, båda trafikriktningarna och ett kontrollerat negativt test. Läs därefter målstatusen igen med motsvarande show vpn ...-kommando.

Om förväntad förbättring uteblir eller nya avbrott uppstår sätts exakt det värde som noterades före testet. Kontrollera sedan tunnel och trafik igen. Utan känt utgångsläge, oberoende administrationsväg och välgrundat symptom utförs ingen set vpn-ändring.

FAQ