Jamie van der Pijll

Firewall, VPN en branch-observability: hoe ik het nuttig houd in plaats van rumoerig

Written by

in

,

3 mei 2026 · Door Jamie van der Pijll · 7 min leestijd

Observability wordt pas echt irritant als alles tegelijk om aandacht vraagt. Firewalls, VPN’s en branches kunnen eindeloos veel signalen uitstorten, maar daar wordt een operator zelden rustiger van. Ik probeer daarom niet meer te verzamelen dan nodig is, maar vooral sneller te zien wat er echt toe doet.

Als een omgeving al rumoerig voelt, lost extra monitoring dat zelden op. Dan groeit de tooling sneller dan het begrip. Daarom kijk ik eerst naar de operationele vragen zelf. Is er echt een storing? Waar wijkt het pad af? En welk signaal vertrouw ik genoeg om er meteen op te handelen?

Kort antwoord

Ik wil bij firewall-, VPN- en branch-observability eerst drie dingen kunnen onderscheiden: is er echt een storing, waar zit het padprobleem en welk signaal is betrouwbaar genoeg om op te handelen. Alles wat dat verschil niet scherper maakt, probeer ik kleiner of stiller te maken.

Wat een operator onder druk nodig heeft

Onder druk wil ik geen twintig panelen interpreteren. Ik wil een eerste antwoord op drie vragen: leeft het pad nog, waar wordt het afwijkend, en gaat het hier om transport, policy, identity of gewoon lokale ellende?

Zodra een dashboard die vragen niet sneller beantwoordt, is het voor mij decoratie geworden. Dan ziet het er misschien compleet uit, maar helpt het niet echt meer bij incidentwerk.

Wat ik bij firewalls als eerste wil zien

  • CPU, geheugen, sessiedruk en interface-errors in trendvorm, niet alleen als momentopname;
  • policy-denies, auth-failures en HA-events die operationeel echt iets verklaren;
  • verkeershotspots en afwijkende oost-west of north-south-patronen waar flow-data echt iets toevoegt.

Wat ik juist niet wil, is elk device-event behandelen alsof het automatisch belangrijk is. Firewalls kunnen veel vertellen. Dat betekent nog niet dat alles even hard moet praten.

Hoe ik VPN-signalen kleiner probeer te maken

  • Tunnelbeschikbaarheid: leeft de tunnel nog en hoe stabiel is dat over tijd?
  • Prestatie: zie ik latency, loss of jitter die hem functioneel waardeloos maken terwijl hij formeel nog up is?
  • Toegang/context: zit het probleem eigenlijk in identity, policy, DNS of client posture in plaats van in de tunnel zelf?

Dat onderscheid scheelt eindeloos turen naar de verkeerde laag. Een tunnel die “up” is maar onbruikbaar presteert, is gewoon nog steeds een incident. Andersom geldt hetzelfde: als identity of policy de boel blokkeert, heb je weinig aan nog een extra tunnelgrafiek.

Wat bij branches vaak nuttiger is dan nog een statuslampje

  • welke uplink of transportlaag daadwerkelijk afwijkend is;
  • of de hele branch geraakt wordt, of alleen een specifiek applicatiepad;
  • of de oorzaak lokaal, provider-gerelateerd, policy-gerelateerd of centraal lijkt te zitten.

Voor branches helpt een dashboard pas als het het aantal hypotheses kleiner maakt. Anders vertelt het vooral dát iets rood is. Daar koop je in een war room weinig voor.

Waar ik meestal signalen weggooi

  • events die bijna nooit actie vragen maar wel continu aandacht trekken;
  • statusmetingen zonder baseline of context;
  • alerts die hetzelfde probleem op drie plekken nog een keer melden;
  • dashboards die mooie totalen tonen maar niets zeggen over padlogica.

Daar zit in de praktijk vaak de echte winst. Minder duplicatie, minder pseudo-severity en een kleinere set signalen die operators ook echt leren vertrouwen. Als niemand een alert vertrouwt, is het geen observability meer maar achtergrondruis.

Mijn volgorde

  1. Maak health en trend betrouwbaar voor firewalls, tunnels en branch-uplinks.
  2. Voeg alleen events toe die helpen verklaren waarom gedrag veranderde.
  3. Gebruik flow en padlogica waar status alleen te plat blijft.
  4. Verwijder dubbele of theatrale signalen voordat je weer nieuwe tooling of alerts toevoegt.

Validatie en grenzen

Dit werkt het best als tijdsynchroonheid, labeling en exports van metrics, logs en flow enigszins op orde zijn. Zonder die basis verzamel je vooral sneller rommel. En natuurlijk blijft context allesbepalend: een simpele branch met één uplink vraagt iets anders dan een omgeving met meerdere transports, SD-WAN-keuzes en lokale afhankelijkheden.

De hoofdvraag blijft voor mij hetzelfde: helpt de zichtbaarheid operators echt om het probleem kleiner te maken?

Verder lezen

Conclusie

Firewall-, VPN- en branch-observability wordt bruikbaar zodra je niet meer alles tegelijk probeert te tonen. Ik wil eerst weten of er echt iets stuk is, waar het pad afwijkt en welk signaal betrouwbaar genoeg is om op te handelen.

Alles wat daar niet aan bijdraagt, probeer ik kleiner te maken. Dat is meestal de snelste route van rumoer naar bruikbaarheid.

More posts