Hvorfor firewalls og VPN ofte skaber både ydeevne- og sikkerhedsudfordringer

Når en VPN er involveret, ændrer trafikken sin “rejse” gennem netværket. Du får kryptering og ofte en anden routingvej, men du får også ekstra overhead: pakker skal krypteres/dekrypteres, der kan opstå head-of-line blocking, og nogle gange påvirkes MTU og pakkestørrelser. Oven i dette kan en firewall være både en beskyttelse og en potentiel flaskehals, hvis reglerne er for stramme, hvis tilstanden (state) bliver belastet, eller hvis NAT/portmapping håndteres anderledes end forventet.

Sikkerhed handler samtidig om mere end at “have en VPN”. Hvis firewallpolitikkerne er for brede, hvis systemer er svage (forældede softwarekomponenter, manglende opdateringer) eller hvis adgangsstyring og logging er utilstrækkelig, kan VPN’en blot flytte angrebsfladen. Den vigtigste begrænsning er derfor: du optimerer ikke kun hastighed; du skal også sikre, at netværkskontrollerne stadig afspejler den faktiske trafik, som VPN’et skaber.

Et enkelt model til at placere problemet

Brug en praktisk mental model med fire led: (1) klienten, (2) VPN-gatewayen/tunnelen, (3) firewall og NAT-kontrollen, (4) destinationen (service/server) samt DNS og routing.

Når noget går galt, så spørg: Hvilket led “ser” trafikken først, og hvor sker tab/afvisning?

  • Hvis forbindelsen etableres, men bliver ustabil: kig mod timeouts, stateful firewall, MSS/MTU og pakkefragmentering.
  • Hvis der er hurtige fejl eller afvisninger: kig mod firewall-regler (porte/protokoller), NAT/portmapping og eventuelle adgangsfiltre.
  • Hvis hastigheden falder markant: kig mod krypterings-/hardwareaccelerationsvalg, belastning på gateway, og om routing tvinges gennem en længere eller mere overbelastet vej.
  • Hvis “noget virker, men ikke alt”: kig mod DNS, split routing (hvis det er relevant), og om visse netværk ender uden for tunnelens rækkevidde.

Denne model hjælper dig med at undgå at behandle symptomer som årsag. Den kan ikke garantere, at du altid rammer rigtigt, men den gør fejlsøgning mere struktureret.

Typiske problemer og målrettede løsninger

1) Ydeevne: throughput falder efter VPN

Hyppige årsager er krypteringsoverhead, CPU-belastning på gatewayen, dårlig udnyttelse af hardwareaccelerering, eller at MTU ikke passer til tunnelens overhead. Hvis pakkestørrelser bliver for store, kan du få fragmentering eller “black hole”-lignende adfærd (hvor bestemte pakker ikke når frem).

Løsningens retning:

  • Sammenlign hastighed før og efter VPN på samme tidspunkt og med samme kilde/destination.
  • Overvej om gatewayen er overbelastet (CPU/memory/netværk) i perioder med lav throughput.
  • Arbejd med MTU/MSS-tilpasning på tværs af tunnel og relevante netværksled, så store pakker kan passere.

Usikkerhed at tage højde for: den nøjagtige effekt afhænger af protokolvalg, klient-/gatewayhardware og netværkets fysiske forhold.

2) Forbindelse: timeouts, “kan ikke nå” eller intermitterende adgang

Når en firewall og en VPN kombineres, kan små forskelle i forventede porte eller routing medføre afvisninger. NAT kan også være en kilde til problemer: hvis portmapping ikke matcher det, VPN’et forventer, kan nogle flows mislykkes, selv om andre fungerer.

Løsningens retning:

  • Identificér hvilke destinationer der fejler (IP vs. domæne, bestemte tjenester vs. alt).
  • Verificér firewall-regler for de relevante protokoller og porte samt at session/stateful filtrering håndterer tunnel-trafikken korrekt.
  • Kontrollér NAT/portmapping-logikken, så returtrafik kan finde tilbage.

Afgrænsning: “Virker i én retning” eller “virker fra én klient men ikke en anden” peger ofte på regel-/routingforskelle mellem segmenter.

3) Sikkerhed: reglerne er brede, og logging mangler

Et klassisk sikkerhedsproblem er, at firewallpolitikker bliver for generøse for at “få VPN til at virke”. Det kan mindske effekten af segmentering og øge mulighederne ved kompromitterede konti eller enheder.

Løsningens retning:

  • Hold firewallreglerne mindst muligt brede for de nødvendige flows.
  • Sørg for at adgangskontroller og logning kan vise, hvem der gjorde hvad, og hvilke destinationer der blev forsøgt nået.
  • Opdater og styrk de underliggende systemer (både klienter og gateway), så kendte sårbarheder ikke kan udnyttes via VPN-adgang.

Begrænsning: Selv den bedste firewall kan ikke erstatte god adgangsstyring på identitetssiden og sikre klienter.

4) DNS og routing: “det virker, når vi bruger IP, men ikke domæner”

Hvis DNS-opslag ikke peger korrekt, eller hvis routing for bestemte domæner/netværk ikke følger den forventede sti, kan du få uensartet adfærd. Det kan også ske, hvis klienten løser navne anderledes end gatewayen.

Løsningens retning:

  • Sammenlign DNS-opslag (hvad domænet resolver til) før og efter VPN.
  • Kontrollér om de resulterende IP-adresser faktisk kan nås gennem de firewall- og routingregler, som VPN’et etablerer.

Usikkerhed: DNS-fejl kan ligne firewall-afvisning, så du bør bekræfte både opløsning og netværkstilgængelighed.

Forskelle og grænser: hvad du realistisk kan optimere

  • Ydeevne og sikkerhed hænger sammen, men de optimeres ikke med samme greb. Flere sikkerhedslag kan øge overhead, mens aggressive ydeevnetiltag (f.eks. at løsne kontroller) kan forringe sikkerhed.
  • MTU/MSS og pakkeflow er ofte den “usynlige” bro mellem netværk og applikationer. En lille fejl kan give store symptomer.
  • Firewallens rolle afhænger af, om den er stateless eller stateful og hvordan den ser tunneltrafikken. Derfor kan samme regelopstilling opføre sig forskelligt i forskellige miljøer.

En vigtig undtagelse: hvis problemet primært ligger i destinationen (service, kapacitet, rate limits, upstream-båndbredde), vil ændringer i firewall/VPN kun give begrænset effekt. Derfor er det ofte nødvendigt at teste i begge ender.

Praktisk måde at kontrollere dine hypoteser på

  1. Fastlæg baseline: mål ydeevne og adgang før VPN for samme klient og samme destination.
  2. Bekræft tunnelens etablering og stabilitet, og notér hvilke destinationer der fejler.
  3. Isolér firewall/NAT: test om afvisninger eller manglende returtrafik kan forklare symptomerne.
  4. Isolér MTU/MSS: hvis symptomerne ligner pakkefragmentering, fokusér på tunnelens pakkestørrelsesadfærd.
  5. Isolér DNS: gentag test med både domæner og tilsvarende IP-adresser for at se, om problemet følger navneopslag eller selve connectivity.

Hvis flere tests peger i samme retning, bliver det lettere at vælge en løsning. Hvis de peger mod forskellige led, skal du acceptere, at der kan være en kombination af årsager (fx både MTU-problem og for stramme firewallregler).

Hvilke beslutninger skal du tage i stedet for “gæt og prøv”

Når du optimerer, så prioriter ændringer der reducerer usikkerhed:

  • Lav en liste over præcise symptomer (hastighed, stabilitet, hvilke tjenester, hvilke destinationer).
  • For hver hypotese (firewallregel, NAT, DNS, MTU, gateway-belastning) vælg én test, der kan skelne den fra de andre.
  • Dokumentér resultater, så du ikke mister sammenhængen mellem ændring og effekt.

Den største grænse er, at miljøer varierer: samme opskrift kan give andre resultater afhængigt af netværkstopologi, hardware og belastning. Derfor bør du behandle optimering som en kontrolleret proces—ikke som en engangsjustering.