pfSense Site-to-Site VPN: Homelab und Datacenter sicher verbinden

Site-to-Site VPN zwischen Homelab und Datacenter mit pfSense/OPNsense einrichten. WireGuard und IPsec im Vergleich, Routing, NAT und Troubleshooting.

Warum ein Site-to-Site VPN?#

Ein Site-to-Site (S2S) VPN verbindet zwei Netzwerke dauerhaft und transparent miteinander. Im Gegensatz zu Client-VPNs, bei denen einzelne Geräte Verbindungen aufbauen, kommunizieren die Gateways direkt miteinander — alle Geräte dahinter können ohne manuelle VPN-Einwahl auf Ressourcen des jeweils anderen Standorts zugreifen.

Typische Use-Cases für Homelabs:

  • Hybrid-Cloud: Homelab mit dediziertem Server im Rechenzentrum verbinden
  • Backup-Standort: Geo-redundante Backups ohne Cloud-Provider
  • Development/Production Split: Testumgebung zuhause, Produktion im Datacenter
  • Ressourcen-Sharing: Zentrale Dienste (DNS, Monitoring, Storage) standortübergreifend nutzen

In meinem Setup verbinde ich mein Homelab (Fritzbox-Uplink + LTE-Fallback) mit einem Hetzner-Server über pfSense. Das erlaubt mir, Services wie Nextcloud, Gitea oder Grommunio im Datacenter zu hosten, während ich von zuhause transparent darauf zugreife — und gleichzeitig interne Homelab-Dienste (Home Assistant, Proxmox) vom Server aus verwalten kann.

WireGuard vs. IPsec: Was ist besser für Site-to-Site?#

Beide Protokolle funktionieren hervorragend für S2S-VPNs, haben aber unterschiedliche Stärken:

WireGuard#

Vorteile:

  • Einfache Konfiguration: Keine komplexen Phase-1/Phase-2-Wizards
  • Modern & schnell: Schlanker Code, hohe Performance
  • NAT-freundlich: Überlebt Reconnects und IP-Wechsel problemlos
  • Low Overhead: ~60 Byte Header vs. ~73 Byte bei IPsec (ESP)
  • Stateless: Keine Session-Tracking-Probleme bei Reboots

Nachteile:

  • Keine dynamischen IPs: Peer-Endpoint muss konfiguriert sein (Workaround: DynDNS + Persistent Keepalive)
  • Neuere Technologie: Weniger Enterprise-Support, nicht überall verfügbar

IPsec#

Vorteile:

  • Ausgereift & standardisiert: Jahrzehntelange Erfahrung, breite Kompatibilität
  • Dynamic Routing: Unterstützung für OSPF/BGP über VPN
  • Flexible Authentication: Pre-Shared Keys, Zertifikate, XAUTH

Nachteile:

  • Komplexe Konfiguration: Phase 1 (IKE), Phase 2 (ESP), Encryption/Hash-Algorithmen
  • NAT-Probleme: Erfordert NAT-T bei doppeltem NAT
  • Overhead: Mehr CPU-Last bei verschlüsselten Tunnels

Meine Empfehlung: Für Homelab-Szenarien mit dynamischen IPs (z. B. Fritzbox) und modernen pfSense/OPNsense-Versionen ist WireGuard die bessere Wahl. Es ist schneller eingerichtet, robuster bei Verbindungsabbrüchen und braucht weniger Ressourcen.

Voraussetzungen#

Bevor wir loslegen, stelle sicher, dass du:

  • Zwei pfSense/OPNsense-Instanzen hast (virtuell oder Hardware)
  • Beide Firewalls Zugriff auf’s Internet haben
  • Mindestens eine Seite eine statische IP oder DynDNS-Hostname hat
  • Unterschiedliche LAN-Subnetze verwendest (z. B. 192.168.66.0/24 vs. 192.168.77.0/24)

In meinem Setup:

  • Homelab (gw-tatooine): 192.168.66.1, LAN 192.168.66.0/24, WAN über Fritzbox + LTE-Fallback
  • Datacenter (gw-coruscant): 95.216.x.x (Hetzner), LAN 192.168.77.0/24, statische IP

Falls du noch kein Proxmox-Homelab hast, schau dir zuerst meinen Proxmox Homelab Einrichten Guide an.

WireGuard auf pfSense/OPNsense einrichten#

1. WireGuard Tunnel auf Server-Seite (Datacenter)#

Logge dich in deine pfSense-Instanz im Datacenter ein (die mit der statischen IP).

VPN > WireGuard > Tunnels

  1. Add Tunnel klicken
  2. Konfiguration:
    • Description: wg-homelab-s2s
    • Listen Port: 51820 (Standard)
    • Interface Keys: Klicke “Generate” — Public/Private Key werden erstellt
    • Tunnel Address: 10.255.255.1/30 (separates /30-Subnetz für den Tunnel)
  3. Save

Notiere dir den Public Key — den brauchst du gleich auf der Homelab-Seite.

2. Peer auf Server hinzufügen (Homelab als Peer)#

VPN > WireGuard > Peers

  1. Add Peer klicken
  2. Konfiguration:
    • Tunnel: wg-homelab-s2s (soeben erstellt)
    • Description: Homelab-gw-tatooine
    • Dynamic Endpoint: ✅ aktivieren (weil Homelab dynamische IP hat)
    • Endpoint: leer lassen (wird automatisch erkannt)
    • Keep Alive: 25 Sekunden (wichtig bei NAT/dynamischen IPs!)
    • Public Key: [wird gleich vom Homelab eingetragen]
    • Allowed IPs: 192.168.66.0/24,10.255.255.2/32 (Homelab-LAN + Tunnel-IP)
  3. Save

3. WireGuard Tunnel auf Homelab-Seite#

Logge dich jetzt in deine Homelab-pfSense ein.

VPN > WireGuard > Tunnels

  1. Add Tunnel
  2. Konfiguration:
    • Description: wg-datacenter-s2s
    • Listen Port: 51820
    • Interface Keys: “Generate”
    • Tunnel Address: 10.255.255.2/30 (andere IP aus dem /30-Block)
  3. Save

Kopiere den Public Key und trage ihn auf der Datacenter-Seite unter dem Peer ein.

4. Peer auf Homelab hinzufügen (Datacenter als Peer)#

VPN > WireGuard > Peers

  1. Add Peer
  2. Konfiguration:
    • Tunnel: wg-datacenter-s2s
    • Description: Datacenter-gw-coruscant
    • Endpoint: 95.216.x.x:51820 (statische IP des Datacenters)
    • Keep Alive: 25
    • Public Key: [Public Key vom Datacenter-Tunnel]
    • Allowed IPs: 192.168.77.0/24,10.255.255.1/32 (Datacenter-LAN + Tunnel-IP)
  3. Save

5. WireGuard Interface aktivieren#

Auf beiden Seiten:

VPN > WireGuard > Settings

  • Enable WireGuard: ✅
  • Save + Apply Changes

Gehe zu Interfaces > Assignments und füge das WireGuard-Interface hinzu (z. B. tun_wg0). Dann:

Interfaces > WG0 (oder wie es heißt)

  • Enable: ✅
  • Description: WG_S2S_HOMELAB bzw. WG_S2S_DATACENTER
  • Save + Apply

Firewall-Regeln einrichten#

Ohne Firewall-Regeln kommt kein Traffic durch!

Auf dem Datacenter (Server)#

Firewall > Rules > WAN

  1. Add (oben, damit die Regel vor anderen kommt)
  2. Konfiguration:
    • Action: Pass
    • Interface: WAN
    • Source: Any
    • Destination: WAN address, Port 51820
    • Description: Allow WireGuard from Homelab
  3. Save + Apply

Firewall > Rules > WG_S2S_HOMELAB (das WireGuard-Interface)

  1. Add
  2. Konfiguration:
    • Action: Pass
    • Source: 192.168.66.0/24 (Homelab-LAN)
    • Destination: 192.168.77.0/24 (Datacenter-LAN)
    • Description: Allow Homelab to Datacenter LAN
  3. Save + Apply

Auf dem Homelab#

Firewall > Rules > WAN

  1. Add
  2. Regel analog zum Datacenter (UDP 51820 erlauben)

Firewall > Rules > WG_S2S_DATACENTER

  1. Add
  2. Konfiguration:
    • Source: 192.168.77.0/24
    • Destination: 192.168.66.0/24
    • Description: Allow Datacenter to Homelab LAN

Optional: Firewall > Rules > LAN — erlaube LAN-Geräten, auf das Datacenter-Netz zuzugreifen (standardmäßig oft schon erlaubt, falls “LAN to Any” Regel existiert).

Routing konfigurieren#

Damit pfSense weiß, dass Traffic für das entfernte Netz durch den Tunnel soll:

Auf beiden Seiten#

System > Routing > Static Routes

Datacenter (Ziel: Homelab)#

  • Destination network: 192.168.66.0/24
  • Gateway: WG_S2S_HOMELAB (Interface als Gateway wählen)
  • Description: Route to Homelab via WireGuard

Homelab (Ziel: Datacenter)#

  • Destination network: 192.168.77.0/24
  • Gateway: WG_S2S_DATACENTER
  • Description: Route to Datacenter via WireGuard

Wichtig: Bei WireGuard kannst du das Interface direkt als Gateway nutzen — keine “WireGuard-Gateway-IP” nötig (im Gegensatz zu IPsec).

Save + Apply.

NAT-Ausnahmen (Outbound NAT)#

Standardmäßig NATet pfSense ausgehenden Traffic. Für S2S-VPN willst du das nicht — sonst kommen Pakete mit der WAN-IP statt der LAN-IP beim anderen Standort an.

Auf beiden Seiten#

Firewall > NAT > Outbound

  1. Wechsel von “Automatic” zu “Hybrid Outbound NAT” (oder “Manual” wenn du alle Regeln selbst verwalten willst)
  2. Save + Apply
  3. Add (oben, BEVOR die automatischen Regeln kommen)
  4. Konfiguration (Beispiel für Datacenter):
    • Interface: WAN
    • Source: 192.168.77.0/24 (lokales LAN)
    • Destination: 192.168.66.0/24 (Homelab-LAN)
    • NAT Address: None (NO NAT) — wichtig!
    • Description: No NAT for Homelab S2S VPN
  5. Save + Apply

Wiederhole das auf der Homelab-Seite (Source: 192.168.66.0/24, Destination: 192.168.77.0/24).

DNS über VPN#

Wenn du zentrale DNS-Server im Datacenter oder Homelab hast, kannst du sie über VPN nutzen.

Methode 1: DNS-Resolver mit Domain Overrides#

Auf der Seite, die DNS-Queries ans andere Netz schicken soll:

Services > DNS Resolver > General Settings > Domain Overrides

Beispiel: Homelab soll .darkside.local an Datacenter-DNS (192.168.77.1) forwarden:

  • Domain: darkside.local
  • IP: 192.168.77.1
  • Description: Forward internal domain to Datacenter DNS

Tipp: Wenn du Active Directory im Homelab hast, kannst du pfSense als Primary DNS konfigurieren und nur AD-Queries (_msdcs.domain.local, domain.local) an den DC forwarden — so bekommst du pfBlockerNG-Filterung für alle Clients, während AD-Dienste weiterhin funktionieren.

Methode 2: DHCP DNS-Server anpassen#

Services > DHCP Server > LAN

  • DNS Servers: Trage die IP des entfernten DNS-Servers ein (z. B. 192.168.77.1)
  • Clients bekommen beim DHCP-Lease automatisch den Remote-DNS

VPN-Verbindung testen#

1. Status prüfen#

Status > WireGuard

Beide Peers sollten als “Latest Handshake” eine aktuelle Zeit anzeigen (< 2 Minuten). Wenn “Never” oder sehr alte Timestamps: VPN kommt nicht zustande.

2. Ping-Test#

Öffne eine Shell auf dem Datacenter-pfSense:

ping -c 4 192.168.66.1

Sollte antworten. Vom Homelab aus:

ping -c 4 192.168.77.1

3. Traceroute#

traceroute 192.168.77.10

Sollte direkt über die 10.255.255.x Tunnel-IPs gehen — wenn du Umwege über WAN-IPs siehst, stimmt das Routing nicht.

4. LAN-zu-LAN Test#

Versuche, von einem Homelab-Client (z. B. 192.168.66.50) einen Datacenter-Host (192.168.77.4) zu erreichen:

ping 192.168.77.4
ssh root@192.168.77.4

Funktioniert das: Glückwunsch, S2S-VPN steht! 🎉

Performance-Optimierung#

MTU-Anpassung#

WireGuard hat 60 Byte Overhead. Bei Standard-Ethernet (MTU 1500):

  • Optimale WireGuard MTU: 1420 (1500 - 60 - 20 IP-Header)

Trage auf beiden Seiten unter Interfaces > WG0 > MTU den Wert 1420 ein.

Bei PPPoE-Uplinks (z. B. DSL) ist die MTU oft 1492 — dann:

  • WireGuard MTU: 1412 (1492 - 60 - 20)

MSS Clamping (für TCP): Firewall > Rules > WG_S2S_xxx

  • Bei den Pass-Regeln: Advanced Options > Max MSS auf 1380 setzen (MTU - 40)

Persistent Keepalive#

Wichtig bei NAT/Firewalls, die idle Connections schließen:

  • 25 Sekunden ist ein guter Wert (bereits in der Peer-Config oben gesetzt)
  • Verhindert, dass NAT-Mappings ablaufen

QoS für VPN-Traffic#

Falls dein Uplink limitiert ist (z. B. Homelab mit Fritzbox):

Firewall > Traffic Shaper > Limiters

  1. Add zwei Limiters (Upload/Download)
  2. Prioritize VPN-Traffic (z. B. ToS 0x08 für WireGuard)

Troubleshooting#

VPN steht, aber kein Traffic#

Checklist:

  1. ✅ Firewall-Regeln auf WireGuard-Interfaces?
  2. ✅ NAT-Ausnahmen konfiguriert?
  3. ✅ Static Routes gesetzt?
  4. ✅ Asymmetrisches Routing? (Rückweg über andere Route)

Packet Capture: Diagnostics > Packet Capture

  • Interface: WG0
  • Host: Remote-LAN-IP
  • Start Capture

Versuch einen Ping — siehst du Pakete in beide Richtungen?

Handshake schlägt fehl#

Mögliche Ursachen:

  • Falsche Public Keys (copy/paste-Fehler)
  • Port 51820 UDP nicht erreichbar (Firewall, ISP-Block)
  • Endpoint falsch (IP/DynDNS stimmt nicht)

Test: Führe auf der Homelab-Seite aus:

nc -u -v 95.216.x.x 51820

Wenn “Connection refused” oder Timeout: WAN-Firewall blockiert.

LTE-Fallback bricht VPN ab#

Problem: Wenn dein Homelab von DSL auf LTE-Failover wechselt, ändert sich die WAN-IP — WireGuard muss neu handshaken.

Lösung 1: Persistent Keepalive (bereits gesetzt)

  • WireGuard schickt alle 25s Pakete → Datacenter lernt die neue IP

Lösung 2: DynDNS auf Homelab

  • Richte DynDNS für dein Homelab ein (z. B. homelab.dyndns.org)
  • Datacenter-Peer-Endpoint: homelab.dyndns.org:51820 statt statischer IP
  • Bei IP-Wechsel: DNS Update → WireGuard reconnected

Tipp aus meinem LTE-Troubleshooting: FreeBSD (pfSense-Basis) hat manchmal Probleme mit LTE-Modems nach Reboots:

# In /boot/loader.conf
loader_delay="40"

Das gibt dem Modem Zeit zum Initialisieren. Überprüfe auch PPP-Logs:

clog -f /var/log/ppp.log

Falls “Invalid dial init string” auftaucht: SIM-Karte nicht erkannt, pfSense neu starten.

MTU-Probleme (“Verbindung bricht ab”)#

Symptom: Pings funktionieren, aber Webseiten laden nicht / SSH freezed.

Test:

ping -c 4 -M do -s 1400 192.168.77.1

Wenn das durchgeht, aber -s 1450 nicht: MTU-Problem.

Fix: Siehe “MTU-Anpassung” oben — WireGuard-Interface auf 1420 setzen + MSS Clamping aktivieren.

APN prüfen: Falsche APN = schlechte Performance. Für Tele2 (Schweden) z. B. 4g.tele2.se statt internet.tele2.se.

AT Commands zur Diagnose (auf pfSense-Shell):

cu -l /dev/cuaU0.2
AT+CSQ

Signal Strength sollte >15 sein (ideal: 25-31). Bei <10: Antenne prüfen.

QoS/Traffic Shaping: Limitiere nicht-essentiellen Traffic — VPN-Keepalives müssen durchkommen, auch wenn LTE überlastet ist.

Sicherheitshinweise#

  • Firewall-Regeln minimal halten: Erlaube nur, was wirklich gebraucht wird (z. B. nicht “Any to Any”)
  • WireGuard-Interface per default deny: Nur explizit erlaubte Verbindungen zulassen
  • Keys schützen: Private Keys bleiben auf der pfSense, niemals per Mail/Chat teilen
  • Updates: WireGuard entwickelt sich schnell — pfSense/OPNsense regelmäßig updaten
  • Monitoring: Richte Alerts für “WireGuard Peer down” ein (z. B. mit Zabbix)

🛒 Empfohlene Hardware & Services#

🖥️

Hetzner Dedicated Server

Site-to-Site VPN zum Datacenter? Hetzner Dedicated Server mit fester IP und voller Root-Kontrolle. Hetzner ausprobieren →

Fazit#

Ein Site-to-Site VPN mit WireGuard auf pfSense verbindet Homelab und Datacenter transparent und sicher. Die Konfiguration ist deutlich einfacher als IPsec, Performance ist hervorragend, und auch mit dynamischen IPs (Fritzbox, LTE-Fallback) läuft es stabil — solange Persistent Keepalive aktiviert ist.

Key Takeaways:

  • WireGuard > IPsec für moderne Homelab-Setups
  • NAT-Ausnahmen sind essentiell (sonst funktioniert Rückverkehr nicht)
  • MTU anpassen, um Fragmentierung zu vermeiden
  • DNS-Forwarding erlaubt zentrale Namensauflösung
  • LTE-Fallback braucht DynDNS + Persistent Keepalive

Falls du pfSense auf Proxmox virtualisiert hast, schau dir auch meinen Proxmox Homelab Guide an — dort erkläre ich VM-Netzwerk-Setup und Best Practices für virtualisierten Routing.

Fragen? Probleme? Schreib mir in den Kommentaren — ich helfe gerne weiter! 🚀

Einige Links auf dieser Seite sind Affiliate-Links. Wenn du über diese Links einkaufst, erhalte ich eine kleine Provision — für dich ändert sich am Preis nichts. So unterstützt du diesen Blog und ermöglichst weitere kostenlose Tutorials. Danke! 🙏

[« Vorherige]
LVM Volumes im laufenden Betrieb erweitern und verkleinern — Praxis-Guide