Sophos Firewall-prestaties correct testen met iPerf3

iPerf3 meet de TCP- of UDP-doorvoer tussen twee gedefinieerde eindpunten. Daarmee kunt u controleren of een traject tussen VLAN’s, via een Sophos Firewall of door een VPN-tunnel langzamer is dan verwacht. Een afzonderlijke hoge of lage waarde bewijst echter nog niet dat er een firewallprobleem is.

Voor een betrouwbare test is eerst een baseline nodig zonder het verdachte pad. Daarna wordt dezelfde meting via de firewall herhaald. Richting, duur, protocol, streams, firewallregel en Security Profiles moeten worden gedocumenteerd, anders worden resultaten vergeleken die technisch niet vergelijkbaar zijn.

⚠️ Belastingstest plannen: iPerf3 kan een verbinding volledig belasten. Productietests horen in een onderhoudsvenster thuis of worden bewust onder de beschikbare bandbreedte uitgevoerd. Maak de server nooit onnodig bereikbaar vanaf internet.

Wat iPerf3 meet

iPerf3 bestaat uit een server en een client. Standaard stuurt de client de testgegevens naar de server. Met -R wordt de richting omgekeerd. De meetwaarde geldt altijd alleen voor precies deze eindpunten, dit pad en deze parameters.

De drie belangrijkste testtypen beantwoorden verschillende vragen:

iPerf3 meet geen applicatieprestaties. SMB, RDP, VoIP of een webapplicatie kunnen ondanks goede iPerf-waarden traag zijn. Omgekeerd kan één TCP-stream op een traject met hoge latentie onder de beschikbare verbindingscapaciteit blijven, hoewel de firewall en WAN-verbinding correct werken.

Voor een internettest rechtstreeks vanuit het perspectief van de appliance is Internetsnelheidstest via SSH op Sophos Firewall het geschiktere artikel. iPerf3 is krachtiger wanneer twee gecontroleerde eindpunten en het pad ertussen moeten worden onderzocht.

Testpad en baseline plannen

Vóór het eerste commando worden de client, server en het te controleren traject vastgelegd. Een zinvolle meetreeks bestaat uit drie stappen:

1. Baseline van de eindpunten: Test client en server in hetzelfde lokale netwerk of via een bekende snelle switch. Is deze waarde al slecht, onderzoek dan eerst client, server, NIC, hostfirewall, hypervisor of WLAN.
2. Firewallpad: Test dezelfde eindpunten via de geplande VLAN’s of zones en de daadwerkelijke Sophos Firewall-regel.
3. WAN- of VPN-pad: Herhaal de test pas daarna via de provider, SD-WAN, Site-to-Site VPN of Remote Access.

Bekabelde eindpunten zijn geschikter voor een uitspraak over de firewall dan WLAN-clients. Op beide systemen moeten energiebesparende functies, CPU-belasting, virtuele NIC’s en parallel verkeer bekend zijn. Server en client moeten indien mogelijk dezelfde hoofdversie van iPerf3 gebruiken; iPerf2 en iPerf3 zijn niet compatibel.

Firewallregel voorbereiden

iPerf3 gebruikt standaard poort 5201. Voor een TCP-test is TCP 5201 vereist. Bij een UDP-test lopen de testgegevens via UDP 5201, maar de besturingsverbinding blijft TCP. Een Sophos-servicegroep voor UDP-tests moet daarom TCP en UDP 5201 bevatten.

De tijdelijke regel onder Rules and policies > Firewall rules mag alleen het concrete bron-IP-adres, doel-IP-adres en de iPerf-service toestaan. Schakel Log firewall traffic in en noteer de Rule ID. Maak geen brede Any-regel en stel de service niet open voor internet om de test alleen maar sneller te kunnen starten.

Controleer na het opslaan in Log viewer of precies deze regel wordt toegepast. Bij een onduidelijke toewijzing helpt Sophos Firewall-regels gericht testen.

iPerf3 installeren en de server beveiligen

De officiële projectdocumentatie en bronpakketten staan bij ESnet iPerf3. ESnet noemt Ubuntu Linux, FreeBSD en macOS als officieel ondersteunde platforms. Windows-binaire pakketten zijn in de praktijk vaak afkomstig van derden; iPerf.fr biedt een bekend overzicht.

Start de server als volgt op het doelsysteem:

iperf3 -s

Het is veiliger om het proces aan het test-IP-adres te koppelen en het na één clientverbinding automatisch te beëindigen:

iperf3 -s -B 10.10.10.50 -1

-B bindt iPerf3 aan het opgegeven adres. -1 accepteert maximaal één clientverbinding en beëindigt daarna de server. Voor elke volgende afzonderlijke test moet het commando opnieuw worden gestart. Als een andere poort wordt gebruikt, moet deze aan beide zijden identiek worden opgegeven:

iperf3 -s -B 10.10.10.50 -p 5200 -1

Ook de lokale hostfirewall op de server kan de poort blokkeren. Beperk deze vrijgave eveneens tot de testbron en de benodigde duur.

TCP in beide richtingen testen

De eerste test gebruikt één TCP-stream en duurt 30 seconden:

iperf3 -c 10.10.10.50 -t 30

Standaard stuurt de client gegevens naar de server. Controleer daarna met dezelfde eindpunten de tegenovergestelde richting:

iperf3 -c 10.10.10.50 -t 30 -R

Als beide richtingen sterk verschillen, zijn asymmetrische WAN-bandbreedte, routing, SD-WAN, interfacefouten, VPN-parameters of een eindpunt waarschijnlijker dan een algemene doorvoerlimiet.

Pas na de Single-Stream-test volgt indien nodig een vergelijking met vier parallelle streams:

iperf3 -c 10.10.10.50 -t 30 -P 4

Als -P 4 duidelijk sneller is, kan één TCP-flow worden beperkt door latentie, het TCP-venster of de prestaties van het eindpunt. Het resultaat is niet automatisch de snelheid die één applicatie bereikt. --bidir belast beide richtingen tegelijk en is eerder geschikt als gerichte stresstest dan voor een zuivere vergelijking van de richtingen.

UDP gecontroleerd testen

Voor een UDP-test is altijd een realistische doelbandbreedte nodig. Zonder -b gebruikt iPerf3 standaard slechts 1 Mbit/s; daarmee kan geen traject van 100 Mbit/s of een gigabittraject worden beoordeeld.

Voorbeeld met 100 Mbit/s:

iperf3 -c 10.10.10.50 -u -b 100M -t 30

Begin niet meteen met de theoretische verbindingssnelheid. Test bijvoorbeeld eerst 60 tot 80 procent van de verwachte bruikbare bandbreedte en verhoog de doelwaarde daarna stapsgewijs. Bij een VPN moet bovendien rekening worden gehouden met de protocol- en encryptie-overhead.

Voor UDP zijn drie waarden bepalend:

• Bitrate: daadwerkelijk bereikte gegevenssnelheid.
• Jitter: variatie in de looptijd tussen de pakketten.
• Lost/Total Datagrams: door de ontvanger vastgesteld pakketverlies.

Een bewust te hoog ingestelde doelbandbreedte veroorzaakt zelf pakketverlies. Dat is een grenstest, maar geen bewijs voor een defecte firewall. Ook bij UDP wordt de tegenovergestelde richting afzonderlijk met -R getest.

Sophos Firewall tijdens de test controleren

Een iPerf-resultaat wordt pas betekenisvol wanneer het in de tijd aan de firewall wordt gekoppeld. Tijdens de test van 30 seconden moeten de volgende punten zichtbaar zijn:

• In Log viewer komen Firewall Rule ID, bron, doel, service en toegestane verbinding overeen.
• In Control center tonen CPU, Memory, Bandwidth en Sessions of de appliance tijdens de test een limiet bereikt.
• Onder Diagnostics > System graphs worden in de Interface graphs Bits, Drops, Errors en Collisions op de betrokken interfaces gecontroleerd.
• Onder Diagnostics > Packet capture kan een strak filter op client, server en poort 5201 aantonen of pakketten worden verwijderd of door onverwachte modules worden verwerkt.

Packet Capture toont onder andere het firewallregelnummer en de nummers van Web-, Application- en IPS-policies. Houd de capture kort, filter strikt en stop deze na de test. Het artikel Packet Capture op Sophos Firewall beschrijft de analyse nauwkeuriger.

Security Profiles isoleren

Als de baseline van de eindpunten goed is en alleen het firewallpad traag is, wordt niet alles tegelijk uitgeschakeld. Documenteer eerst de regel die daadwerkelijk wordt toegepast en de bijbehorende Security Profiles. Wijzig daarna in een onderhoudsvenster precies één variabele en herhaal dezelfde test.

Een diagnostische regel zonder aanvullende controle mag alleen strikt worden beperkt tot de testbron, het testdoel en de iPerf-service. Schakel deze na de vergelijkende meting onmiddellijk uit of verwijder deze. Zo kunt u vaststellen of IPS, Application Control, Traffic Shaping of een andere policy betrokken is, zonder het overige verkeer onbeschermd te laten.

Resultaten correct interpreteren

Bij TCP zijn de samenvattingen voor sender en receiver en de retransmits belangrijk. Veel retransmits wijzen op verlies of een verstoord traject, niet automatisch op onvoldoende firewall-CPU. Een goede lokale baseline en een slechte waarde via de firewall bakenen het onderzoek af, maar benoemen nog niet de oorzaak.

Typische patronen:

• Al traag binnen hetzelfde LAN: Controleer eindpunten, NIC-stuurprogramma’s, virtueel platform, hostfirewall of WLAN.
• Alleen traag via de firewall: Onderzoek regel, Security Profiles, Traffic Shaping, interfacefouten en systeembelasting.
• Alleen traag via VPN: Controleer WAN-kwaliteit, latentie, encryptieprofiel, tunnelroute en MTU en MSS.
• Slechts één richting traag: Vergelijk Reverse-test, interfacetellers, asymmetrische routing en provider-upstream.
• Single Stream traag, meerdere streams snel: Beoordeel latentie, TCP-venster en prestaties van het eindpunt voordat u een firewalllimiet veronderstelt.
• Slechts één openbare server traag: Belasting, afstand of peering van de externe server kan het resultaat beperken.

Openbare iPerf-servers zijn hooguit geschikt voor een globale internetvergelijking. Voor firewall-, VPN- of locatiediagnoses is een eigen gecontroleerde server aan de andere kant betrouwbaarder.

Meting documenteren en configuratie terugdraaien

Om een vergelijking voor en na een wijziging later te kunnen reconstrueren, worden ten minste datum, client, server, richting, commando, Rule ID, Security Profiles, VPN- of WAN-pad en het sender-/receiver-resultaat vastgelegd. Wijzig tijdens een foutanalyse altijd slechts één variabele tussen twee runs.

Na afloop:

1. Beëindig de iPerf3-server.
2. Verwijder de vrijgave uit de hostfirewall.
3. Schakel de tijdelijke Sophos Firewall-regel en testservice uit of verwijder deze wanneer ze niet meer nodig zijn.
4. Zet gewijzigde Security Profiles terug naar de beoogde toestand.
5. Controleer Log viewer en interfacetellers nogmaals op Drops of fouten.

FAQ