Inhaltsverzeichnis

VPN-Standortanbindung: DHCP-Relay und zentrale Dienste für 100+ Clients
#

Die Verbindung von Außenstandorten über Site-to-Site-VPNs ist eine klassische Enterprise-Aufgabe. Doch wenn 100+ Clients an einem entfernten Standort zentrale Dienste wie DHCP und DNS nutzen sollen, reicht ein einfacher VPN-Tunnel nicht aus. Dieser Artikel beleuchtet die architektonischen Grundlagen und vergleicht führende Firewall-Plattformen.

🏗️ Grundlegendes Design
#

Getrennte Subnetze pro Standort
#

Ein häufiger Fehler: Beide Standorte verwenden das gleiche Subnetz. Das führt unweigerlich zu Routing-Problemen.

Standort	Subnetz	Gateway
Zentrale	`192.168.10.0/24`	`192.168.10.1`
Außenstelle	`192.168.20.0/24`	`192.168.20.1`

Warum getrennte Subnetze?

✅ Eindeutiges Routing (keine Überlappungen)
✅ DHCP-Scopes klar trennbar
✅ Broadcast-Domänen isoliert
✅ Einfacheres Troubleshooting

⚠️ Achtung: Bei Subnetz-Überlappungen hilft nur NAT – was wiederum Komplexität und Fehlerquellen einführt.

Routenbasiertes VPN vs. Policy-basiertes VPN
#

Für Standortanbindungen mit mehreren Diensten ist routenbasiertes VPN die richtige Wahl:

Eigenschaft	Routenbasiert	Policy-basiert
Routing-Entscheidung	Routing-Tabelle	Access Control Lists (ACLs)
Mehrere Subnetze	✅ Einfach	❌ Komplex
Dynamische Routen	✅ Möglich (BGP, OSPF)	❌ Nicht möglich
DHCP-Relay	✅ Transparent	⚠️ Eingeschränkt
Skalierbarkeit	✅ Hoch (viele Standorte)	❌ Gering

🔌 DHCP über das VPN realisieren
#

Das Broadcast-Problem
#

DHCP-Requests werden als Broadcast (255.255.255.255) gesendet. Router und VPN-Gateways leiten Broadcasts standardmäßig nicht weiter – aus gutem Grund:

┌─────────────────────┐         ┌─────────────────────┐
│  Außenstelle        │         │  Zentrale           │
│  192.168.20.0/24    │         │  192.168.10.0/24    │
│                     │         │                     │
│  Client: "DHCPDISCOVER"       │  DHCP-Server        │
│  (Broadcast ❌)     │───VPN───►│  (erreicht Request  │
│                     │         │   nicht!)           │
└─────────────────────┘         └─────────────────────┘

Lösung: DHCP-Relay-Agent (auch: IP Helper)

DHCP-Relay-Agent (RFC 1542)
#

Der Relay-Agent fängt Broadcasts ab und leitet sie als Unicast an den zentralen DHCP-Server weiter:

┌─────────────────────┐         ┌─────────────────────┐
│  Außenstelle        │         │  Zentrale           │
```│  192.168.20.0/24    │         │  192.168.10.0/24    │
│                     │         │                     │
│  Client ──► Relay   │         │  DHCP-Server        │
│  (Broadcast)        │───VPN───►│  (Unicast ✅)       │
│  (192.168.20.1)     │         │  (192.168.10.10)    │
└─────────────────────┘         └─────────────────────┘

Konfigurationsschritte:

Relay-Agent aktivieren auf der Firewall/dem Router der Außenstelle
Ziel-IP eintragen: IP des zentralen DHCP-Servers (z.B. 192.168.10.10)
Interface auswählen: LAN-Interface der Außenstelle (192.168.20.1)
DHCP-Scope anlegen: Zentraler Server benötigt Scope für 192.168.20.0/24

DHCP-Scope für Außenstelle
#

Der zentrale DHCP-Server muss wissen, welches Subnetz er bedient:

Beispiel (Windows Server DHCP):

Parameter	Wert
Scope-Name	`Außenstelle_192.168.20.0`
IP-Bereich	`192.168.20.100 - 192.168.20.200`
Subnetzmaske	`255.255.255.0`
Router (Option 003)	`192.168.20.1` (lokales Gateway)
DNS-Server (Option 006)	`192.168.10.10, 192.168.20.1`
Domain-Name (Option 015)	`firma.local`

⚠️ Wichtig: Option 003 (Router) muss das lokale Gateway der Außenstelle sein – nicht das der Zentrale! Sonst läuft Internet-Traffic über die Zentrale (unnötige Latenz).

🌐 DNS-Konfiguration
#

Zentrale Namensauflösung
#

Clients in der Außenstelle sollten den zentralen DNS-Server (oder Domain Controller) verwenden:

Vorteile:

✅ Einheitliche Namensauflösung für interne Ressourcen
✅ Active Directory-Integration (bei Windows-Umgebungen)
✅ Zentrale DNS-Policies und Filtering

Konfiguration via DHCP (Option 006):

Primärer DNS:   192.168.10.10  (Zentraler DC/DNS)
Sekundärer DNS: 192.168.20.1   (Lokale Firewall)

Ausfallsicherheit bei VPN-Trennung
#

Was passiert, wenn der VPN-Tunnel abbricht?

Szenario	Verhalten
Nur zentraler DNS	❌ Keine Namensauflösung, Internet funktioniert nicht
Sekundärer DNS lokal	✅ Internet bleibt erreichbar (via DNS-Forwarding)
Lokaler DNS-Cache	✅ Kurzfristige Auflösung weiterhin möglich

Empfehlung: Die Firewall der Außenstelle sollte als sekundärer DNS-Server konfiguriert werden und DNS-Anfragen per Conditional Forwarding in die Zentrale weiterleiten:

Client ──► Lokale Firewall (DNS-Proxy)
              │
              ├─► Bei VPN up: ──► Zentraler DNS
              │
              └─► Bei VPN down: ──► Öffentliche DNS (8.8.8.8, 1.1.1.1)

📊 Komplettes Netzwerk-Design
#

┌─────────────────────────────────────────────────────────────────────┐
│  ZENTRALE (192.168.10.0/24)                                         │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐                 │
│  │ Firewall    │  │ DHCP-Server │  │ DNS/DC      │                 │
│  │ 192.168.10.1│  │ 192.168.10.10│ │ 192.168.10.10│                │
│  └──────┬──────┘  └─────────────┘  └─────────────┘                 │
│         │                                                           │
│         │ IPsec/WireGuard Site-to-Site                              │
└─────────┼───────────────────────────────────────────────────────────┘
          │
          │ VPN-Tunnel
          │
┌─────────▼───────────────────────────────────────────────────────────┐
│  AUSSENSTELLE (192.168.20.0/24) – 100 Clients                       │
│  ┌─────────────┐                                                    │
│  │ Firewall    │  ◄── DHCP-Relay: 192.168.10.10                    │
│  │ 192.168.20.1│  ◄── DNS-Forwarding bei VPN-Down                  │
│  └──────┬──────┘                                                    │
│         │                                                           │
│    ┌────┴────┬─────────────┬─────────────┐                         │
│    │         │             │             │                         │
│  Client    Client       Client        Client  (1-100)              │
│  .100      .101         .102          .200                         │
└─────────────────────────────────────────────────────────────────────┘

🔧 Plattform-spezifische Hinweise im Vergleich
#

pfSense/OPNsense (Open Source)
#

# DHCP-Relay (WebUI)
Services → DHCP Relay → New
- Interface: LAN
- Destination Server: 192.168.10.10
- Relay Agent Port: 67

# IPsec Site-to-Site
VPN → IPsec → Tunnel Addition
- Type: Route-based
- Local Network: 192.168.20.0/24
- Remote Network: 192.168.10.0/24

Kriterium	Bewertung
DHCP-Relay	✅ Kostenlos, einfach
Routenbasiertes VPN	✅ Kostenlos
DNS-Forwarding	✅ Über DNS Resolver
GUI-Qualität	⭐⭐⭐⭐ Gut
CLI-Verfügbarkeit	⭐⭐⭐ Basis (FreeBSD)

Fortinet FortiGate (Enterprise)
#

# DHCP-Relay (CLI)
config system dhcp
    edit "relay-outside"
        set server-ip "192.168.10.10"
        set selected-interface "lan"
    next
end

# IPsec (WebUI)
VPN → IPsec Tunnels → Create New
- Type: Route-based
- Interface: wan1
- Remote Gateway: [Zentrale IP]

Kriterium	Bewertung
DHCP-Relay	✅ Inklusive
Routenbasiertes VPN	✅ Inklusive
DNS-Forwarding	✅ Über DNS-Proxy
GUI-Qualität	⭐⭐⭐⭐⭐ Exzellent
CLI-Verfügbarkeit	⭐⭐⭐⭐⭐ Vollständig

Sophos Firewall (Mittelstand)
#

# DHCP-Relay (WebUI)
Services → DHCP → Relay → Add
- Interface: LAN
- Server: 192.168.10.10
- Enable: ✓

# IPsec VPN
VPN → Site-to-Site → Add Connection
- Type: Route-based
- Local Zone: LAN
- Remote Network: 192.168.10.0/24

Kriterium	Bewertung
DHCP-Relay	✅ Inklusive
Routenbasiertes VPN	✅ Inklusive
DNS-Forwarding	✅ Inklusive
GUI-Qualität	⭐⭐⭐⭐⭐ Sehr intuitiv
CLI-Verfügbarkeit	⭐⭐⭐ Basis

Clavister NetWall (Enterprise)
#

# DHCP-Relay (CLI)
cc:/> add DhcpRelay dhcprelay-lan
cc:/> set DhcpRelay dhcprelay-lan Interface=if-lan
cc:/> set DhcpRelay dhcprelay-lan ServerIP=192.168.10.10
cc:/> set DhcpRelay dhcprelay-lan Status=Enabled

# IPsec (WebUI)
Objects → IPsec Tunnels → New
- Type: Route-based
- Local Network: 192.168.20.0/24
- Remote Network: 192.168.10.0/24

Kriterium	Bewertung
DHCP-Relay	✅ Inklusive, pro Interface
Routenbasiertes VPN	✅ Tunnel-Interface
DNS-Forwarding	✅ Über DNS-Proxy
GUI-Qualität	⭐⭐⭐⭐ Gut
CLI-Verfügbarkeit	⭐⭐⭐⭐⭐ Vollständig
Besonderheit	⚠️ IPsec-Lizenzen prüfen

Palo Alto Networks PAN-OS (Enterprise Premium)
#

Palo Alto Firewalls gehören zur Premium-Klasse im Enterprise-Segment. Die Konfiguration ist mächtig, aber komplexer als bei der Konkurrenz.

# DHCP-Relay (WebUI)
Network → DHCP → DHCP Relay
- Add Relay Interface: ethernet1/1 (LAN)
- DHCP Server: 192.168.10.10
- Option 82: Enabled (für Client-Information)

# Alternativ (CLI)
configure
set network dhcp-relay interface ethernet1/1 server 192.168.10.10
commit

# IPsec Tunnel (WebUI)
Network → Network Profiles → IKE Crypto
Network → IPSec Tunnels → Add
- Type: Site-to-Site
- Interface: tunnel.1
- Peer IP: [Zentrale IP]
- Local/Remote Subnets: 192.168.20.0/24 ↔ 192.168.10.0/24

# Routing (Critical!)
Network → Virtual Routers → default
- Static Routes: 192.168.10.0/24 → tunnel.1

Kriterium	Bewertung
DHCP-Relay	✅ Inklusive, Option 82 Support
Routenbasiertes VPN	✅ Tunnel-Interface
DNS-Forwarding	✅ Über DNS-Proxy
GUI-Qualität	⭐⭐⭐⭐⭐ Exzellent, aber komplex
CLI-Verfügbarkeit	⭐⭐⭐⭐⭐ Vollständig (Panorama)
Besonderheit	🔴 App-ID, User-ID, Content-ID erfordern tiefes Wissen

Palo Alto-spezifische Hinweise:

Feature	Hinweis
Virtual Router	🔴 Zwingend erforderlich für Routing zwischen Zonen
Security Zones	🔴 Traffic muss explizit zwischen Zonen erlaubt werden
Security Policies	🔴 Separate Regeln für VPN-Traffic nötig
GlobalProtect	✅ Integrierte Remote-Access-Lösung
Panorama	✅ Zentrale Verwaltung mehrerer Firewalls
Lizenzierung	🔴 Threat-Prevention, URL-Filtering, etc. separat

⏱️ Konfigurationsaufwand im Vergleich
#

Plattform	DHCP-Relay	IPsec Site-to-Site	DNS-Forwarding	Gesamtzeit*	Schwierigkeit
pfSense	5 Min.	15 Min.	5 Min.	~25 Min.	⭐⭐ Einfach
Sophos	5 Min.	15 Min.	5 Min.	~25 Min.	⭐⭐ Einfach
FortiGate	10 Min.	20 Min.	10 Min.	~40 Min.	⭐⭐⭐ Mittel
Clavister	10 Min.	20 Min.	10 Min.	~40 Min.	⭐⭐⭐ Mittel
Palo Alto	15 Min.	30 Min.	15 Min.	~60 Min.	⭐⭐⭐⭐ Komplex

*Zeitangaben für erfahrene Administratoren beim ersten Setup. Bei Folgekonfigurationen deutlich schneller.

Detaillierte Aufschlüsselung
#

pfSense/Sophos (Geringster Aufwand)
#

✅ Intuitive WebUI
✅ Wizards für VPN-Setup
✅ DHCP-Relay in wenigen Klicks
✅ Wenige Abhängigkeiten

FortiGate/Clavister (Mittlerer Aufwand)
#

⚠️ CLI für manche Schritte nötig
⚠️ Mehr Konfigurationsoptionen
⚠️ Lizenzierung prüfen (FortiGate)

Palo Alto (Höchster Aufwand)
#

🔴 Virtual Router muss konfiguriert werden
🔴 Security Zones und Policies separat
🔴 Tunnel-Interface + Routing manuell
🔴 Commit erforderlich nach jeder Änderung
🔴 Steile Lernkurve, aber mächtig im Betrieb

⚠️ Häufige Fehler und Lösungen
#

Fehler	Symptom	Lösung
Falscher Router (Option 003)	Kein Internet in Außenstelle	Lokales Gateway eintragen (`192.168.20.1`)
DHCP-Scope fehlt	Clients bekommen keine IPs	Scope für `192.168.20.0/24` anlegen
Relay nicht aktiv	DHCP-Requests kommen nicht an	Relay-Agent auf Firewall aktivieren
DNS nur zentral	Kein Internet bei VPN-Down	Sekundären DNS lokal eintragen
Subnetz-Überlappung	Routing funktioniert nicht	Subnetze trennen oder NAT verwenden
Security Policy fehlt (Palo Alto)	VPN steht, Traffic geht nicht	Security Policy zwischen Zonen erstellen
Virtual Router fehlt (Palo Alto)	Kein Routing über Tunnel	Static Route im Virtual Router anlegen

📈 Skalierung auf mehrere Außenstellen
#

Das gleiche Design lässt sich auf mehrere Standorte erweitern:

Standort	Subnetz	DHCP-Relay Ziel	Empfohlene Firewall
Zentrale	`192.168.10.0/24`	–	Palo Alto / FortiGate
Außenstelle A	`192.168.20.0/24`	`192.168.10.10`	pfSense / Sophos
Außenstelle B	`192.168.30.0/24`	`192.168.10.10`	pfSense / Sophos
Außenstelle C	`192.168.40.0/24`	`192.168.10.10`	Clavister / FortiGate

Wichtig: Jeder Standort benötigt:

Eigenes Subnetz
Eigenen DHCP-Scope auf dem zentralen Server
Eigene VPN-Verbindung (oder Hub-and-Spoke)

🎯 Plattform-Empfehlungen nach Anwendungsfall
#

Anwendungsfall	Empfehlung	Begründung
Kleine Außenstellen (1-50 Clients)	pfSense / Sophos	Geringer Aufwand, kostenlos/günstig
Mittelstand (50-200 Clients)	FortiGate / Clavister	Gute Balance Features/Komplexität
Enterprise (200+ Clients)	Palo Alto / FortiGate	Skalierbarkeit, Advanced Features
Bestehende Infrastruktur	Passende Plattform	Konsistenz im Management
Geringes Budget	pfSense	Open Source, keine Lizenzkosten
Compliance-Anforderungen	Palo Alto	Umfassende Logging/Reporting-Features
Einfache Bedienung	Sophos	Intuitivste WebUI

🎯 Fazit
#

Für die Anbindung von 100+ Clients an einen zentralen Server über Site-to-Site-VPN gilt:

Komponente	Empfehlung
VPN-Typ	Routenbasiertes IPsec oder WireGuard
Subnetze	Getrennt pro Standort
DHCP	Zentraler Server + Relay-Agent vor Ort
DNS	Zentral primär, lokal sekundär (Ausfallsicherheit)
Hardware	pfSense, FortiGate, Sophos, Clavister, Palo Alto

Plattform-Wahl nach Priorität:

Priorität	Plattform
Einfachheit	Sophos > pfSense > FortiGate > Clavister > Palo Alto
Features	Palo Alto > FortiGate > Clavister > Sophos > pfSense
Kosten	pfSense > Sophos Home > Clavister > FortiGate > Palo Alto
Enterprise-Ready	Palo Alto > FortiGate > Clavister > Sophos > pfSense

Der DHCP-Relay-Agent ist der Schlüssel, um Broadcast-basierte Dienste über VPN-Grenzen hinweg nutzbar zu machen – ohne lokale Server-Infrastruktur in jeder Außenstelle.

Weiterführende Links:

Haftungsausschluss: Alle Konfigurationsbeispiele sollten in einer Testumgebung validiert werden. Der Autor übernimmt keine Verantwortung für Konfigurationsfehler oder Netzwerkausfälle. Preis- und Lizenzangaben können sich geändert haben.

VPN-Standortanbindung: DHCP-Relay und zentrale Dienste für 100+ Clients#

🏗️ Grundlegendes Design#

Getrennte Subnetze pro Standort#

Routenbasiertes VPN vs. Policy-basiertes VPN#

🔌 DHCP über das VPN realisieren#

Das Broadcast-Problem#

DHCP-Relay-Agent (RFC 1542)#

DHCP-Scope für Außenstelle#

🌐 DNS-Konfiguration#

Zentrale Namensauflösung#

Ausfallsicherheit bei VPN-Trennung#

📊 Komplettes Netzwerk-Design#

🔧 Plattform-spezifische Hinweise im Vergleich#

pfSense/OPNsense (Open Source)#

Fortinet FortiGate (Enterprise)#

Sophos Firewall (Mittelstand)#

Clavister NetWall (Enterprise)#

Palo Alto Networks PAN-OS (Enterprise Premium)#

⏱️ Konfigurationsaufwand im Vergleich#

Detaillierte Aufschlüsselung#

pfSense/Sophos (Geringster Aufwand)#

FortiGate/Clavister (Mittlerer Aufwand)#

Palo Alto (Höchster Aufwand)#

⚠️ Häufige Fehler und Lösungen#

📈 Skalierung auf mehrere Außenstellen#

🎯 Plattform-Empfehlungen nach Anwendungsfall#

🎯 Fazit#