Hoppa till innehållet
Avanet

Rätt tolkning av Sophos Firewall prestandadata

Prestandadata för en Sophos Firewall är viktiga för dimensionering, men läses ofta felaktigt. Den högsta brandväggsgenomströmningen i databladet är inte automatiskt den prestanda som en plats uppnår med IPS, Web Protection, TLS Inspection, VPN, NAT, rapportering och många samtidiga användare.

För att välja en modell bör man därför inte bara titta på en enda Gbit/s-siffra. Det som är avgörande är vilka skyddsfunktioner som är aktiva, vilken trafik som passerar genom brandväggen och vilka reserver miljön behöver i vardagen. Sophos Firewall Sizing Guide förklarar modellvalet; denna artikel förklarar hur man bedömer de underliggande prestandametrikerna.

Sophos Firewall XGS Appliance-serien tabell med prestandadata
Prestandadata är jämförelsevärden under definierade testförhållanden, inte en garanti för varje verklig miljö.

Kort regel för dimensionering

I praktiken är oftast inte den rena brandväggsgenomströmningen den bästa startpunkten.

  • Endast routing och enkla brandväggsregler: Beakta brandväggsgenomströmning och IMIX.
  • Normalt företagsnätverk med IPS och Application Control: Ge större vikt åt NGFW- eller Threat-Protection-värden.
  • Många HTTPS-anslutningar med avkodning: Planera för TLS-Inspection-prestanda och CPU-reserv.
  • Många VPN-anslutningar: Betrakta IPsec- eller fjärråtkomstkrav separat.
  • Virtuell brandvägg: Ta hypervisor, CPU, RAM, lagring och virtuella nätverkskort lika seriöst som Sophos-licensen.

Om det är oklart om hårdvara eller virtuell appliance passar bättre, hjälper Sophos Firewall - Hårdvara eller virtuell appliance? som beslutsstöd.

Varför databladvärden inte räcker rakt av

Prestandavärden bestäms under definierade laboratorieförhållanden. Detta är meningsfullt eftersom modeller därmed blir jämförbara. En produktiv miljö beter sig dock annorlunda:

  • Paketstorlekar är blandade.
  • Användare skapar parallella sessioner.
  • Säkerhetsprofiler granskar trafik på olika djup.
  • HTTPS-trafik kräver betydligt mer resurser vid TLS Inspection.
  • VPN, SD-WAN, NAT, loggning och rapportering körs parallellt.
  • WLAN, switchar, klienter, servrar och leverantörer påverkar den upplevda prestandan.

Ett databladvärde är därför ett jämförelsevärde, inte ett löfte för varje enskild flöde. För en solid dimensionering bör man planera med reserver och inte först efter köpet ta hänsyn till de senare driftfunktionerna.

Läs testvillkoren innan du jämför siffror

Fotnoterna i Sophos datablad hör till varje mätvärde. Sophos mäter maxvärdena med Keysight-Ixia BreakingPoint under idealiska förhållanden. Firewall Throughput använder HTTP-trafik med svar på 512 KB, medan Firewall IMIX blandar UDP-paket på 66, 570 och 1518 byte. IPS Throughput baseras på HTTP-trafik, IPS-standardregelverket och objekt på 512 KB. TLS Inspection mäts med aktiverad IPS, HTTPS-sessioner och olika chiffersviter. Threat Protection kombinerar brandvägg, IPS, Application Control och Malware Prevention med Enterprise Traffic Mix. NGFW Throughput mäts med aktiverad IPS och Application Control, HTTP-trafik och objekt på 512 KB. IPsec VPN använder HTTP-trafik via flera tunnlar med svar på 512 KB.

Villkoren gör att modeller kan jämföras på samma grund. Värdena ska däremot inte läggas ihop eller tolkas som ett löfte för den egna trafikmixen. Små paket, korta sessioner, andra chiffersviter och ytterligare tjänster kan förändra resultatet.

De viktigaste metrikerna

  • Firewall Throughput: Hjälper till att jämföra enkel bearbetning på lager 3/lager 4. Ett vanligt fel är att läsa värdet som verklig internetgenomströmning med alla säkerhetsfunktioner aktiva.
  • Firewall IMIX: Använder en mer realistisk blandning av paketstorlekar. Värdet förbises ofta trots att produktionsnät inte enbart transporterar stora paket.
  • IPS Throughput: Beskriver trafik med Intrusion Prevention. Det blir viktigt när IPS inspekterar en stor del av trafiken.
  • NGFW Throughput: Beskriver prestanda med ytterligare funktioner som IPS och Application Control. Det ska inte förväxlas med ren brandväggsgenomströmning.
  • Threat Protection: Ligger närmare en miljö med flera aktiva skydd. Det är fortfarande ett jämförelsevärde, inte ett garanterat minimum.
  • TLS Inspection: Gäller dekryptering och inspektion av HTTPS. Denna potentiellt höga belastning glöms ofta bort vid dimensionering.
  • IPsec VPN: Gäller krypterad trafik mellan platser. Motpart, paketstorlekar, kryptografiska inställningar och CPU är lika viktiga som internetanslutningen.
  • Concurrent Connections: Anger hur många anslutningar brandväggen kan följa samtidigt. Det är en kapacitetsgräns, inte ett genomströmningsvärde.
  • New Connections per second: Anger hur många nya anslutningar brandväggen kan behandla per sekund. Många korta webb-, API- eller DNS-anslutningar kan belasta gränsen även när bandbredden är låg.

Brandväggsgenomströmning och IMIX

Den rena brandväggsgenomströmningen beskriver en relativt enkel bearbetning av trafik. Detta värde är användbart när en brandvägg främst routar, gör NAT och bearbetar klassiska brandväggsregler.

IMIX ligger närmare verklig nätverksbelastning eftersom olika paketstorlekar blandas. Detta är viktigt eftersom små paket belastar en brandvägg annorlunda än stora nedladdningar. I företagsnätverk finns det sällan bara en ren stor dataström. Webbåtkomst, DNS, VoIP, molnapplikationer, uppdateringar och filöverföringar skapar olika mönster.

För platser med normal användartrafik är IMIX därför ofta mer talande än det vackraste maxvärdet.

IPS, NGFW och Threat Protection

Så snart IPS, Application Control, Web Protection eller malware-granskning är aktiva måste brandväggen göra mer än att bara vidarebefordra paket. Brandväggen måste klassificera trafik, känna igen mönster, tillämpa regler och beroende på policy granska innehåll.

Begreppen blandas ofta:

  • IPS bedömer trafik baserat på signaturer och regler för kända angreppsmönster.
  • NGFW beskriver brandväggsprestanda med ytterligare funktioner som IPS och Application Control.
  • Threat Protection är ett starkare approximationsvärde för miljöer där flera skyddsfunktioner är aktiva samtidigt.

För ett företag som faktiskt använder Sophos Firewall som ett säkerhetsgateway är NGFW- och Threat-Protection-värden oftast mer relevanta än den rena brandväggsgenomströmningen.

Planera TLS Inspection realistiskt

TLS Inspection är en av de största prestandafaktorerna. Brandväggen dekrypterar HTTPS-anslutningar, granskar innehållet och krypterar anslutningen igen. Detta skapar CPU-belastning och kan beroende på chifferuppsättning, målserver, klient, undantag och policy vara märkbart.

TLS Inspection bör därför inte aktiveras i förbifarten. En stegvis utrullning med pilotgrupp, undantag, övervakning och tydlig felsökning är meningsfull. Artikeln Införa Sophos Firewall TLS Inspection korrekt beskriver den operativa processen.

Även CA-certifikatet måste distribueras korrekt. För klienter är Installera Sophos Firewall CA-certifikat för HTTPS-skanning den lämpliga starten.

Betrakta VPN-prestanda separat

VPN-prestanda beror inte bara på brandväggsmodellen. Relevanta faktorer är också motpart, internetanslutning, latens, paketstorlekar, MTU/MSS, krypteringsparametrar, routing och parallella tunnlar.

För plats-till-plats-anslutningar bör man realistiskt uppskatta de planerade dataströmmarna: filöverföringar, säkerhetskopior, ERP, VoIP, RDP, övervakning och replikering beter sig olika. För fjärråtkomst tillkommer dessutom klientenhet, WLAN, leverantör och VPN-klient.

Om en VPN-sträcka verkar långsam bör man inte bara kontrollera databladvärdet. Ett definierat sträcktest med iPerf är oftast mer talande än ett webbläsarhastighetstest.

Vad som påverkar den verkliga prestandan

I praktiken verkar flera faktorer samtidigt:

  • aktiva säkerhetsprofiler per brandväggsregel
  • TLS Inspection och undantag
  • IPS-policy och signaturomfång
  • Web Protection, Application Control och malware-granskning
  • NAT, DNAT, serverpublicering och WAF
  • IPsec, SSL VPN, Sophos Connect och plats-till-plats-tunnlar
  • Loggning, rapportering, Central Reporting och Syslog
  • många små sessioner istället för färre stora nedladdningar
  • Brandväggsacceleration, FastPath, IPsec-acceleration och trafik som inte kan offloadas
  • HA-drift, firmwareversion och hotfixar
  • virtuella resurser vid mjukvaru- eller molnappliances

Därför bör man alltid granska prestanda i kontexten av den specifika policyn. En brandväggsregel utan säkerhetsprofiler beter sig annorlunda än en regel med IPS, webbfilter, Application Control och TLS Inspection.

Förstå FastPath och Offloading korrekt

Moderna Sophos-brandväggar bearbetar inte varje dataström lika. Beroende på appliance, firmware, regel, säkerhetsprofil och trafiktyp kan trafik delvis accelereras eller granskas i en långsammare bearbetningsväg. Viktiga begrepp för detta är FastPath, brandväggsacceleration, PKI-acceleration och IPsec-acceleration.

Den första klassificeringen sker fortfarande i SlowPath: kärnan och, när det är aktuellt, DPI Engine granskar anslutningen. När TCP-handshaken är klar eller ett paket har passerat i vardera riktningen kan SFOS lägga ett kvalificerat flöde i FastPaths anslutningscache. FastPath är därför ingen oinspekterad bypass; den bearbetar endast det tillstånd som kärnan har programmerat. Protokoll som inte kvalificerar sig, till exempel IP-in-IP, stannar i SlowPath.

För dimensionering är detta viktigt, eftersom ett snabbt test inte bevisar att varje produktionsflöde använder samma väg. Sophos anger Firewall och IPsec Acceleration för alla XGS Appliances. Dedikerad PKI Acceleration för certifikatbearbetning av inspekterade TLS-flöden är endast dokumenterad för XGS 4300, 4500, 5500, 6500, 7500 och 8500. Desktopmodellerna Gen. 2 XGS 88/88w, 108/108w, 118/118w och 128/128w använder Virtual FastPath i x86-kärnan i stället för en dedikerad Xstream Flow Processor.

För virtuella och software-appliances är gränserna ännu snävare. Enligt SFOS 22-hjälpen stöds Virtual FastPath endast med VMware ESXi och NIC-drivrutinerna igc, e1000, e1000e och vmxnet3. På andra hypervisors, i cloud-deployments eller med drivrutiner som inte stöds stängs VFP av automatiskt. Brandväggen fortsätter att fungera, men utan denna FastPath-förbättring. För e1000 och e1000e anger Sophos en maximal MTU på 3500 byte, och för de övriga drivrutiner som stöds maximalt 9000 byte. Detta är plattformsgränser, inte ett skäl att aktivera jumbo frames utan ett end-to-end-test.

PKI Acceleration accelererar inte all TLS-bearbetning. För TLS 1.2- och TLS 1.3-flöden som granskas av DPI Engine offloadas endast omsigneringen av X.509-servercertifikat med RSA-autentisering upp till 4096 bitar. Symmetrisk kryptering, web proxy-trafik och SSL VPN-anslutningar som termineras på brandväggen drar inte nytta av den.

Vissa funktioner eller trafiktyper kan begränsa eller förhindra offloading, till exempel:

  • SSL VPN
  • WAF och proxy-trafik
  • QoS och DoS
  • Trådlöst, RED, LAG och PPPoE
  • Fragmenterad IP-trafik
  • Vissa brygg-, HA- eller virtualiseringsscenarier

För IPsec offloadar XFRM-stacken ESP-inkapsling, kryptering, dekapsling och dekryptering baserat på fas 2-SA. SA:er med 3DES, BlowFish eller MD5, SA:er på virtuella gränssnitt som VLAN och IPsec-trafik över VLAN- eller trådlösa gränssnitt offloadas inte. Tunneln kan ändå fungera, men använder då mer värd-CPU.

Säkerhetspolicyer utesluter inte offloading generellt. En regel utan IPS, web filtering, antivirus eller application control kan växla efter handshaken eller de första paketen; med application control anger Sophos att beslutet sker efter ungefär åtta paket. För STARTTLS med Don’t decrypt sker det efter ungefär 15 paket. De första paketen kan därför fortfarande synas i SlowPath trots att det senare flödet accelereras.

Praktisk regel: Offloading är inget säkerhetsmål. Skyddsprofiler och inspektion tas inte bort enbart för att nå FastPath. Det som är avgörande är det skydd som krävs och reproducerbara mätningar av throughput, CPU och applikation.

Vid HA måste man titta extra noga. Active-Active HA stöder inte Firewall Acceleration. Sophos stöder däremot IPsec Acceleration i Active-Active och Active-Passive HA på den primära noden; i Active-Passive är även Firewall Acceleration begränsad till den primära noden. Vid HA-dimensionering ska laboratorievärden för en fristående enhet därför inte automatiskt överföras till båda noderna.

Även felsökning kan påverka mätningar. Vid Packet Capture eller iftop skickar SFOS som standard tillfälligt trafiken via SlowPath. Om offloading förblir aktivt under inspelningen kan en vanlig Packet Capture inte registrera FastPath-trafik. Ett paket som saknas bevisar därför inte att brandväggen inte har bearbetat flödet; Sophos hänvisar till Support när en FastPath-inspelning krävs. Prestandamätningar och capture-resultat dokumenteras alltid med tidpunkt, testmetod, firmwareversion, gränssnittstyp och aktiv policy.

Accelerationerna är aktiva som standard på plattformar som stöds. Att slå på eller av Firewall eller PKI Acceleration startar om IPS-tjänsten (DPI Engine); en ändring av IPsec Acceleration startar om alla IPsec-tunnlar. Sådana ändringar hör hemma i ett underhållsfönster, inte i ett improviserat prestandatest. Först bekräftas misstanken med Log Viewer, Packet Capture, IPsec Troubleshooting och ett tydligt testfall.

Läsa och styra PKI Acceleration korrekt

Det konfigurerade tillståndet och det faktiska tillståndet är inte samma sak. Läs inställningen med:

show ips-settings

PKI Acceleration är aktiverad som standard på XGS Appliance-modeller som stöds. enabled är endast aktivt när Firewall Acceleration också körs. Om PKI Acceleration är aktiverad men Firewall Acceleration är avstängd visar SFOS enabled (inactive). På SFOS-versioner eller modeller som inte stöds visas disabled; en ändring i CLI kan inte ersätta saknat hårdvaru- eller plattformsstöd.

Den globala inställningen ändras via IPS-kommandoträdet:

set ips pki-acceleration disable
set ips pki-acceleration enable

En ändring startar om IPS-tjänsten (DPI-motorn) och hör därför hemma i ett underhållsfönster. Dokumentera först det aktuella värdet och statusen för Firewall Acceleration. Kontrollera därefter show ips-settings, status för IPS och DPI samt ett verkligt TLS-flöde som dekrypteras av DPI-motorn. Endast då går det att bekräfta att omsignering av certifikat, latens, CPU och applikation fortfarande fungerar som förväntat. Om den förväntade effekten uteblir återställs det tidigare dokumenterade värdet.

Kontrollera IPsec Acceleration under kontrollerade former

Läs först den globala statusen:

system ipsec-acceleration show

IPsec Acceleration är enabled som standard och flyttar kvalificerade fas 2-SA från SlowPath. En aktiverad global status bevisar inte att en viss SA är offloaded. 3DES, BlowFish och MD5 är undantagna, och de gränser för interface och plattformar som beskrivs ovan gäller fortfarande.

En ändring gäller hela brandväggen och startar om alla IPsec-tunnlar. disable är därför inte ett test för en enda tunnel. Om ett tydligt fel motiverar ett A/B-test ska tunnelstatus, SA, CPU, throughput och testtrafik först dokumenteras. Dessa två motsatta ändringar är tillgängliga i underhållsfönstret:

system ipsec-acceleration disable
system ipsec-acceleration enable

Efter varje ändring som faktiskt utförs kontrolleras show, tunnelupprättande, fas 2-SA, routing, brandväggsregler och verklig trafik i båda riktningarna på nytt. Återställ ursprungsvärdet om ingen reproducerbar förbättring syns. Behåll inte en föråldrad kryptografisk profil enbart för att möjliggöra en prestandajämförelse.

Växla Firewall Acceleration endast i ett underhållsfönster

Läs först aktuellt läge i Device Console:

system firewall-acceleration show

På plattformar som stöds är Firewall Acceleration som standard enable. Enligt Sophos orsakar varje ändring ett avbrott och startar om IPS-tjänsten (DPI-motorn). disable är därför inget enkelt A/B-test under produktion. Brandväggen fortsätter att behandla all trafik, men utan prestandafördelarna med FastPath.

Följande två kommandon är tillgängliga för en planerad ändring. De ska inte köras direkt efter varandra som ett testblock, eftersom varje övergång kan avbryta trafiken igen:

system firewall-acceleration disable
system firewall-acceleration enable

Efter varje faktiskt nödvändig övergång kontrolleras show, IPS- och DPI-status, nya sessioner, publicerade tjänster, VPN, genomströmning, CPU och Log Viewer igen. Ett visat disabled ska inte blint skrivas över med enable: DoS, active-active HA, FastPath som inte laddas eller en kombination av VM, hypervisor eller NIC-drivrutin som inte stöds kan också förhindra acceleration. enable kan inte framtvinga ett fungerande FastPath på en tekniskt ej stödd plattform.

Kontrollera prestanda i drift

Databladvärden hjälper före köpet. I drift behöver man andra verktyg. Det är viktigt att skilja på begreppen: Control Center visar inte databladsprestanda, utan aktuella driftindikatorer. Performance-rutan baseras på load average över CPU-kärnor. Värden över antalet tillgängliga kärnor betyder att mer arbete väntar än systemet kan bearbeta vid just den tidpunkten.

Rutans färg följer fasta Sophos-trösklar: Normal vid load average under 2, Warning från 2 till 5 och Alert över 5 CPU-kärnor. Trafikljuset är en snabb indikation, men motsvarar inte appliance-modellens individuella överbelastningsgräns. Därför bör rutans status, det faktiska antalet kärnor och tidsförloppet tolkas tillsammans.

CPU, minne, bandwidth, sessions, Decryption Capacity och Decrypt Sessions är också relevanta. Särskilt vid TLS Inspection är Decryption Capacity användbart eftersom det visar hur starkt aktuell SSL/TLS-dekryptering använder den tillgängliga dekrypteringskapaciteten. Decryption details uppdateras inte som sekundexakt live-mätning, utan normalt var femte minut. Dessa värden bör alltid läsas tillsammans med policy, regel, säkerhetsprofil, tidpunkt och trafiktyp.

Använda System Graphs som tidslinje

Under Diagnostics > System graphs kan CPU Usage, Memory Usage, Load Average, Disk Usage, Live Users, Data Transfer Speed through WAN Zone och enskilda gränssnitt jämföras över olika tidsperioder. Välj först perioden för incidenten och därefter endast de grafer som motsvarar den berörda funktionen.

En topp är en korrelation, ännu inte en orsak. CPU, minne eller load average bör därför jämföras med gränssnittstrafik, antal användare, loggar, policy och exakt testtidpunkt. Tidslinjen hjälper särskilt till att skilja en kort avvikelse från återkommande eller varaktigt hög belastning; den bevisar inte ensam att appliance-modellen är för liten eller att en viss tjänst är felaktig.

Läs enheter och aggregering korrekt

CPU-grafen skiljer användning av användarprocesser, systemkomponenter och återstående inaktiv tid. Memory visar Used, Free och Total i MB. Load Average är däremot inte ett procenttal: de tre kurvorna representerar medelvärden över en, fem och femton minuter. Det måste därför läsas tillsammans med antalet tillgängliga CPU-kärnor.

Disk Usage visar procentuellt hur mycket utrymme som används av signaturer, konfigurationsfiler, rapporter och tillfälliga data. Det är en funktionell uppdelning i grafen och inte samma vy som partitionerna från df -kh eller rapporternas watermark. Live Users räknar användare som varit anslutna till internet under den valda perioden och visar även minimum, maximum och genomsnitt. Det är inte antalet konfigurerade användarkonton.

För WAN-zonen finns separata grafer för upload och download, den kombinerade totala hastigheten och hastigheten per gateway. Beroende på vy visas aktuellt, minimalt, maximalt och genomsnittligt värde. Sophos dokumenterar ett viktigt märkningsfel: WebAdmin visar KBps, men värdena är i själva verket kbit/s. Om visningen läses som kilobyte per sekund blir felet en faktor åtta.

Viktigt för VLAN: Separata gränssnittsgrafer finns för fysiska gränssnitt, Wireless LAN, WAN-gränssnitt och VLAN-gränssnitt i WAN-zonen. VLAN i andra zoner kombineras i grafen med sitt fysiska överordnade gränssnitt. En topp på den överordnade porten kan därför inte tillskrivas ett enda internt VLAN utan ytterligare mätning.

Gränssnittsgraferna visar mottagna och skickade bitar samt drops, fel och kollisioner. Upplösningen aggregeras för längre perioder: idag och igår använder femminutersmedelvärden, veckan 15 minuter, månaden sex timmar och året en dag. Korta toppar kan därför försvinna i en månads- eller årsvy; börja med den smalaste lämpliga perioden för en incident.

Praktiskt förlopp:

  1. Kontrollera Control Center: Observera CPU, RAM, gränssnittsbelastning och varningar.
  2. Öppna Log Viewer: Träffar den förväntade brandväggsregeln och är loggning aktiverad?
  3. Kontrollera policy och säkerhetsprofiler: Vilka funktioner påverkar den berörda trafiken?
  4. Använd Packet Capture: Ser man paket, svarspaket, NAT och droppar?
  5. Utför sträcktest: Kontrollera med iPerf eller en definierad nedladdning vilken väg som verkligen är långsam.
  6. Notera offloading-kontekst: Gränssnittstyp, HA-läge, VPN-typ, PPPoE, WAF, SSL VPN eller Packet Capture kan påverka mätningen.
  7. Notera tidpunkt: Belastningstoppar, säkerhetskopior, uppdateringar eller rapporter kan förvränga resultaten.

För en snabb avgränsning av WAN-linjen hjälper Utföra Sophos Firewall Internet-hastighetstest via SSH. För end-to-end-tester mellan två system är Testa Sophos Firewall prestanda med iPerf bättre lämpad. Om en regel inte träffar som förväntat, passar Testa Sophos Firewall-regler specifikt.

Den dagliga administratörschecklistan för Sophos Firewall visar hur Control Center, System graphs, rapporter och administratörshändelser kombineras i en kort återkommande procedur.

Vanliga dimensioneringsfel

  • Endast den högsta brandväggsgenomströmningen jämförs.
  • TLS Inspection planeras men räknas inte in i prestandareserven.
  • VPN och fjärråtkomst bedöms utifrån antalet användare istället för verklig användning.
  • Internetanslutningen beaktas, men inte intern öst-väst-trafik.
  • Virtuella brandväggar körs på överbelastade värdar.
  • Rapportering, loggning och Central-anslutning beaktas först i efterhand.
  • Tillväxt, nya platser, ytterligare VLAN eller serverpublicering saknas i planeringen.
  • Ingen skillnad görs mellan laboratorievärde, verkligt värde och användarupplevelse.

Praktisk dimensioneringschecklista

Innan modellvalet bör dessa punkter klargöras:

  1. Internetbandbredd idag och planerad de kommande åren.
  2. Antal användare, enheter, servrar och platser.
  3. Andel av webbtrafik, molnapplikationer, VoIP, säkerhetskopior och filöverföringar.
  4. Planerade säkerhetsfunktioner per trafikgrupp.
  5. Omfattning av TLS-Inspection och nödvändiga undantag.
  6. Antal och användning av IPsec-, SSL-VPN- och Sophos-Connect-anslutningar.
  7. Behov av WAF, Mail Protection, RED, WLAN eller Central Reporting.
  8. Förväntade reserver för uppdateringar, tillväxt och belastningstoppar.
  9. Driftsmodell: XGS Appliance, virtuell appliance, moln eller HA-kluster.

FAQ

Vilken Sophos Firewall prestandavärde är viktigast för modellvalet?

Det beror på användningen. För enkla brandväggsregler är brandväggsgenomströmning relevant. För typiska företagsmiljöer med IPS, Web Protection och Application Control är NGFW- eller Threat-Protection-värden oftast mer talande.

Varför når en brandvägg inte det högsta databladvärdet?

Det högsta värdet uppstår under definierade testförhållanden. I verkligheten påverkar paketstorlekar, säkerhetsprofiler, TLS Inspection, VPN, NAT, loggning, parallella sessioner, klienter och motparter resultatet.

Måste TLS Inspection alltid inkluderas i dimensioneringen?

Ja, om TLS Inspection ska användas produktivt idag eller senare. HTTPS-avkodning är resurskrävande och bör planeras med reserv, pilotgrupp och en noggrann utrullning.

Hur kontrollerar man om brandväggen eller klienten är långsam?

Man jämför flera tester: Nedladdning direkt på brandväggen, test från en kabelansluten klient, iPerf mellan definierade ändpunkter, Log Viewer, Packet Capture och gränssnittsbelastning. En enskild mätning räcker sällan.

Är virtuella Sophos-brandväggar långsammare än hårdvaruappliances?

Inte automatiskt. Virtuella brandväggar kan fungera mycket bra om CPU, RAM, lagring och nätverk är noggrant planerade. Prestandan beror dock mer på virtualiseringsplattformen än på en dedikerad XGS Appliance.

Varför kan Packet Capture påverka en prestandamätning?

Packet Capture är ett analysverktyg, inte ett neutralt hastighetstest. Som standard flyttar SFOS trafik till SlowPath under en inspelning. Om offloading förblir aktivt ser en vanlig capture inte FastPath-trafiken. En utebliven träff används därför aldrig ensam som bevis för att trafik saknas.