Introduktion Site-to-site VPN er ikke blot en teknisk fiks idé — for mange virksomheder er det et fundamentalt krav for at sikre sammenhængende, private netværk mellem kontorer, datacentre og cloud-miljøer. Når filialer, hjemmearbejdspladser eller partnerlokationer skal udveksle følsomme data, er en ordentlig site-to-site-løsning ofte den eneste realistiske måde at opretholde konfidensialitet, integritet og netværkssynlighed på tværs af geografier.

I denne guide gennemgår vi de konkrete krav, der typisk gør en site-to-site VPN nødvendig, hvilke tekniske komponenter der skal være på plads, compliance- og driftshensyn, samt hvordan du vælger den rette løsning og undgår almindelige faldgruber.

Hvorfor kræves en site-to-site VPN?

  • Sikker kommunikation mellem faste lokationer: Hvis to eller flere kontorer udveksler forretningskritiske data (økonomi, HR, kundeinformation), er krypteret tunnelkommunikation ofte et internt krav i virksomhedens sikkerhedspolitik.
  • Ensartet netværksarkitektur: Mange applikationer og services forventer private IP-ranges og ruteadgang, som kun kan leveres pålideligt via permanente, kontrollerede forbindelser.
  • Adgangskontrol og segmentering: Site-to-site VPN gør det muligt at håndhæve netværkspolicyer centralt (firewall-regler, VLAN-segmentering) uden at åbne op for usikre, offentlige forbindelser.
  • Lav latenstid og forudsigelighed: I modsætning til brugercentrerede VPN-forbindelser (remote access) er site-to-site normalt optimeret for stabilitet og throughput mellem faste endepunkter.
  • Regulatoriske krav og databeskyttelse: Branchekrav (fx finans, sundhed) kan kræve kryptering og kontrolleret datatransport mellem lokationer.

Hvilke formelle og tekniske krav udløser et site-to-site behov?

  1. Forretningskrav og compliance
  • Krav om kryptering i transit (fx AES-256) for at beskytte persondata eller følsomme kundedata.
  • Logging- og revisionskrav, hvor forbindelser mellem systemer skal kunne dokumenteres, men uden at kompromittere datakonfidensialitet.
  • Krav om datalokation eller bestemte routing-regler mellem datacentre og kontorer.
  1. Netværksarkitektur og routing
  • Behov for transit mellem private subnets: Hvis services i filial A skal adresseres direkte fra filial B uden NAT-komplikationer, kræves site-to-site routing.
  • Statiske eller dynamiske routingprotokoller (BGP, OSPF) hvis netværksskalaen kræver automatisk ruteudveksling.
  1. Kryptering og autentificering
  • Stærk kryptering (f.eks. AES-256) og moderne IKEv2 eller IKEv2/IPsec som standard.
  • Certifikatbaseret autentificering eller præ-delte nøgler afhængig af sikkerhedsniveauet.
  • Key rotation og håndtering af nøgler skal være indbygget i driftsprocedurer.
  1. Høj tilgængelighed og failover
  • Redundante internetlinks, multiple VPN-gateways og automatisk failover for at undgå single points of failure.
  • SLA-krav for opkoblingstid og throughput mellem kritiske lokationer.
  1. Performance og QoS
  • Krav om båndbreddegarantier og QoS-mærkning for at sikre ydeevne til latenskritiske applikationer (VoIP, videomøder).
  • Overvej trafikkompression eller dedikerede forbindelser for tunge datamigreringer.
  1. Administration og overvågning
  • Central håndtering af konfigurationer, logs og sikkerhedsalarmer.
  • Integreret monitoring af tunnelstatus, throughput og fejl med klare eskaleringsprocedurer.

Teknologivalg: IPSec, TLS- eller SD-WAN-baseret?

  • IPSec site-to-site er den mest udbredte klassiske løsning: robust, bredt understøttet i netværksenheder og velegnet til krypteret routing.
  • TLS-baserede løsninger (OpenVPN, WireGuard-lignende varianter for tunnels) kan være enklere at administrere for visse enviroments, men standardiseret routing kræver ekstra arbejde.
  • SD-WAN kombinerer ofte kryptering med central policy-styring og trafikoptimering; relevant når flere links (MPLS, bredbånd, LTE) skal orkestreres og når business continuity er kritisk.

Sikkerhedsprincipper og bedste praksis

  • Minimér blast radius: Brug segmentering og mindst privilegium til at begrænse adgang mellem lokationer.
  • Certifikatstyring: Brug PKI og automatiser certifikatfornyelse for at undgå misbrug af udløbne nøgler.
  • Hardened endepunkter: VPN-gateways skal være opdaterede, ikke-overflødige services og med begrænset adgang til management-interface.
  • Overvåg trafik for anomalier: Usædvanlig east-west-trafik kan indikere kompromitterede systemer.
  • Inventar og dokumentation: Hold en opdateret oversigt over alle tunneler, gateways og ansvarlige personer.

Drifts- og omkostningsaspekter

  • Initial investering vs. løbende omkostninger: Hardware- eller softwarelicenser samt eventuelle SD-WAN-omkostninger.
  • Driftsarbejde: Tid til opsætning, opdatering og sikkerhedsscanninger; kræver ofte dedikerede netværksfolk.
  • Skalerbarhed: Forvent ændringer i forretningsbehov — vælg en løsning der kan vokse uden fuldstændig arkitekturændring.

Når er en enklere løsning tilstrækkelig?

  • Mindre teams med begrænset trafik og få lokationer kan ofte klare sig med krypteret transit via cloud-VPC-peering eller managed VPN-tjenester.
  • Hvis primært behov er fjernbrugere (remote access), dækker ikke nødvendigvis et site-to-site krav — vælg remote access VPN til mobile brugere.

Eksempler fra virkeligheden: tre relevante pointer fra nyhedsbilledet

  • Juridisk klarhed om VPN-brug: EU-diskussioner om VPNs lovlighed bekræfter, at værktøjer som VPN ikke i sig selv er kriminaliseret — men brugen påvirkes af nationale regler; det taler for, at virksomheder strukturerer VPN-brug som en kontrolleret, corporate service (kilde: clubic).
  • Regulatorisk pres og blokeringstiltag: Myndigheder kan begrænse eller regulere visse VPN-tiltag, fx ved at forhindre brug af privilegerede IP-adresser — virksomheder bør forholde sig til nationale restriktioner og vælge leverandører der overholder lokale regler (kilde: ufacitynews).
  • Politik og aldersbegrænsninger: Debatter om begrænsning af VPN-adgang for visse brugergrupper viser, at VPN-økosystemet er genstand for løbende politiske beslutninger; for virksomheder betyder det, at adgangen til VPN-tjenester og governance skal være klart dokumenteret (kilde: begeek).

Implementering: trin-for-trin tjekliste

  1. Kortlæg krav: Identificer hvilke subnets, applikationer og compliancekrav der kræver permanent forbindelser.
  2. Vælg protokol: IPSec for bred kompatibilitet; SD-WAN hvis trafikorchestrering og failover er afgørende.
  3. Design netværksarkitektur: IP-plan, routing, NAT-regler og sikkerhedsgrænser.
  4. Sikkerhedskonfiguration: Kryptering, autentificering, key rotation, firewall-regler.
  5. Test og failover: Simuler linknedbrud og valider performance under belastning.
  6. Drift: Implementér overvågning, opdateringsprocedurer og incident response playbooks.
  7. Dokumentation og uddannelse: Sørg for runbooks og træning af driftspersonale.

Typiske fejl at undgå

  • Manglende opdateringer af firmware og software på gateways.
  • Brug af svage præ-delte nøgler i stedet for certifikatbaseret autentificering.
  • Underspecificerede QoS-krav, som medfører dårlig brugeroplevelse for kritiske applikationer.
  • Ingen central logning eller manglende overvågning af tunnelstatus.

Valg af leverandør: hvad skal du spørge om?

  • Understøttede protokoller (IKEv2, AES-256, BGP).
  • SLA for opkobling og supportniveau.
  • Håndtering af IP-adresser og eventuelle juridiske begrænsninger i leverandørens jurisdiktion.
  • Mulighed for automatisk nøglehåndtering og integration med virksomhedens PKI.
  • Overvågning og integration med SIEM.

Konklusion For mange organisationer er site-to-site VPN et krav — ikke kun for at beskytte data, men for at sikre stabil forretningsdrift, overholdelse af love og forretningskritiske SLA’er. Kravet opstår typisk der, hvor decentraliserede lokationer skal fungere som ét sammenhængende netværk med høje krav til sikkerhed, tilgængelighed og ydeevne. Ved at følge principperne i denne guide kan IT-ledelse og netværksteams træffe informerede valg og bygge en robust, driftssikker løsning.

📚 Videre læsning

Her er tre relevante nyhedskilder, som belyser juridiske, tekniske og regulatoriske vinkler på VPN og netværkssikkerhed.

🔸 “Droit d’auteur : pourquoi la Cour de Justice de l’UE refuse de criminaliser les VPN”
🗞️ Kilde: clubic – 📅 2026-01-26
🔗 Læs artiklen

🔸 “Le Royaume-Uni veut interdire les VPN aux mineurs”
🗞️ Kilde: begeek – 📅 2026-01-26
🔗 Læs artiklen

🔸 “РКН обошел уловку VPN-сервисов – запретил аренду привилегированных IP”
🗞️ Kilde: ufacitynews – 📅 2026-01-26
🔗 Læs artiklen

📌 Ansvarsfraskrivelse

Dette indlæg kombinerer offentligt tilgængelig information med hjælp fra AI.
Det er ment som deling og diskussion — ikke en endelig, verificeret erklæring.
Hvis noget virker forkert eller mangelfuldt, kontakt os, så retter vi det.