Ein stabiler IPv4- und IPv6-Tunnel über Hetzner

Multi-WAN ohne Prefix-Chaos mit PFSENSE und HETZNER

Sobald im Heimnetz zwei verschiedene Internetanschlüsse zusammenkommen, entsteht ein Problem, das sich bei IPv4 elegant durch NAT versteckt, bei IPv6 aber offen zutage tritt. Beide Leitungen liefern unterschiedliche globale Präfixe, die jeweils an das jeweilige Provider-Netz gebunden sind. Ein Gerät, das ein IPv6-Paket über die erste Leitung verschickt, muss den Rückverkehr zwingend über genau diese Leitung empfangen. Diese strikte Bindung an den Ursprungs-Prefix gehört zum Kernprinzip von IPv6, das ohne NAT auskommt und den globalen Routingpfad offenlegt.

Sobald jedoch zwei WANs mit zwei verschiedenen Präfixen gleichzeitig aktiv sind, beginnt sich das Netz selbst zu widersprechen. Ein Client bekommt mehrere globale IPv6-Adressen aus beiden Präfixen, und die pfSense kann zwar entscheiden, welcher Upstream aktuell aktiv ist, aber sie darf das dazugehörige Präfix nicht dynamisch ersetzen. Die von den Clients verwendeten Adressen bleiben für viele Stunden gültig. Ein schnelles Wegschalten ist im IPv6-Standard nicht vorgesehen, da Router Advertisements große Zeitfenster haben und Adressen nicht spontan wegfallen sollen. Damit verliert der Rückweg den Bezug zur Quelle, und Verbindungen brechen ab, sobald die pfSense bei Ausfall eines WANs auf den anderen umschaltet.

Diese Situation lässt sich nicht mit Routenregeln, Gateway-Gruppen oder Failover-Mechanismen umgehen, da das Problem auf der Adresslogik selbst beruht. IPv6 verlangt für stabile Rückwege einen klaren, konsistenten Präfix-Ursprung. Genau deshalb scheitert klassisches Multi-WAN mit wechselnden Präfixen, während IPv4 dank NAT unbeeindruckt bleibt und einfach die Quelladresse umschreibt, sodass der Rückweg immer passt.

Die Lösung besteht darin, sich einen stabilen, unabhängigen Punkt zu schaffen, von dem der globale IPv6-Präfix kommt. Ein kleiner Hetzner-Server übernimmt diese Rolle. Er trägt das IPv6-Präfix dauerhaft und übersetzt gleichzeitig IPv4. Die pfSense verbindet sich nur noch per WireGuard-Tunnel mit ihm, und beide lokalen WANs dienen lediglich als Transportweg. Damit wird das gesamte Netz stabil, unabhängig davon, welche Leitung gerade aktiv ist.

1. Hetzner-Server vorbereiten

Debian 13 Mini, WireGuard und Prefix-Weitergabe

Der Server bildet den ruhenden Pol in der Architektur. Er hält die IPv6-Adresszone bereit und sorgt dafür, dass IPv4 sauber ins Internet übersetzt wird, unabhängig davon, welche Leitung zuhause aktiv ist.

WireGuard installieren und konfigurieren

Unter /etc/wireguard/wg0.conf:

[Interface]
Address = 10.0.1.1/24,fc00:1::1/64
ListenPort = 51820
PrivateKey = *****

[Peer]
PublicKey = SvJSW0lqfyrGTpMrYKkrF6WSMSy+WpoI6k9OOk4IO1U=
AllowedIPs = 192.168.1.0/24,10.0.1.2/32,fc00:1::2/128,2a01:<...hetzner präfix...>::/64

Das interne Tunnelnetz (10.0.1.0/24 und fc00:1::/64) verbindet den Server klar mit der pfSense. Zusätzlich wird das globale IPv6-/64 dem Peer bekannt gemacht.

ND-Proxy einrichten

Da Hetzner nur eine /128 am Interface vergibt, übernimmt ndppd die Antwort auf Neighbor-Discovery-Anfragen für das gesamte Präfix:

Konfiguration in /etc/ndppd.conf:

route-ttl 30000
proxy eth0 {
    rule 2a01:4f8:c010:8b3a::/64 {
        static
    }
}

Damit können alle Adressen aus dem Präfix verwendet werden, ohne dass sie direkt am Interface liegen.

IPv6-Adresse auf /128 setzen

In /etc/network/interfaces:

iface eth0 inet6 static
    address 2a01:4f8:c010:8b3a::1/128

Der Server hat so eine klare, feste Adresse, während das Präfix selbst durch ndppd verwaltet wird.

IPv4-Masquerading aktivieren

Damit das gesamte IPv4-LAN über den Tunnel sauber ins Internet gelangt, wird NAT in Richtung Hetzner-Interface aktiviert:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Die Regel bleibt dauerhaft aktiv und sorgt dafür, dass der Rückverkehr immer beim Server endet, unabhängig vom Zustand der heimischen WANs.

Damit ist der Server fertig.

2. pfSense vorbereiten

Zwei WANs, ein Tunnel, kein eigenes NAT mehr

Die pfSense verwendet ihre beiden WANs nur noch dazu, den Tunnel aufrechtzuerhalten. Der eigentliche Internetverkehr wird durch WireGuard transportiert. Alle Schritte beziehen sich auf das Menü der pfSense.

WAN-Konfiguration

Richtet die beiden WAN Schnittstellen ein. Bei mir WAN1 WAN2. Lasst die IPv6 Config einfach leer. Nutzen wir nicht. Dann auf:

Ort: System → Routing → Gateways

Beide WAN-Gateways werden auf IPv4 gestellt. Der Haken „Kill states when gateway is down“ sorgt dafür, dass Sessions beim Umschalten direkt sauber neu aufgebaut werden.

Gateway-Gruppe

Ort: System → Routing → Gateway Groups

Eine Gruppe mit beiden WANs, z. B. WAN1 als Tier 1 und WAN2 als Tier 2. Diese Gruppe wird später die Default-Route der pfSense. Damit springt der Tunnel automatisch auf die gerade funktionierende Leitung.

NAT deaktivieren

Ort: Firewall → NAT → Outbound

Outbound-Modus auf „Disabled“ setzen.
Die pfSense übernimmt kein NAT mehr, da das Hetzner-System diese Rolle zuverlässig übernimmt.

3. WireGuard auf pfSense

Tunnel aufbauen und als neues Gateway nutzen

Erst unter Packages “Wireguard” installieren.

Tunnel konfigurieren

Ort: VPN → WireGuard → Tunnels

Ein neues Tunnelinterface anlegen, z. B. WG-Hetzner, mit diesen Adressen:

  • 10.0.1.2/24
  • fc00:1::2/64

Das Gegenstück zeigt auf die externe IPv4 vom Hetzner-Server.

WireGuard-Interface erzeugen

Ort: Interfaces → Assignments

Das WG-Interface hinzufügen und aktivieren. IPs eintragen. Speichern.
Gateways hinzufügen.

Gateways definieren

Ort: System → Routing → Gateways

  • IPv4-Gateway: 10.0.1.1
  • IPv6-Gateway: fc00:1::1

Beide auf „Unmonitored“ stellen, damit pfSense sie nicht fälschlich als offline erkennt.

Default-Route auf den Tunnel legen

Ort: System → Routing → Routes

Die pfSense selbst nutzt das IPv6-Gateway des Tunnels als Default-Route.
Damit läuft der gesamte Systemverkehr (Updates, DNS, Checks) über Hetzner.

4. LAN-Traffic durch den Tunnel schicken

IPv4 über den Tunnel

Ort: Firewall → Rules → LAN

Die bestehende IPv4-Regel auf das Gateway 10.0.1.1 umstellen.
Damit geht sämtlicher IPv4-Verkehr über WireGuard.

IPv6 über den Tunnel

In der IPv6-Regel das Gateway fc00:1::1 auswählen.

Damit ist klar, dass das globale IPv6-Präfix über Hetzner zurückgeführt wird.

5. WireGuard-Interface erlauben

Ort: Firewall → Rules → WG-Interface

Eine einfache „Any to Any“-Regel erzeugen, da der gesamte Verkehr durch dieses Interface läuft.

6. IPv6 im LAN verteilen

Ort: Interfaces → LAN → Static IPv6
und
Ort: Services → Router Advertisements

Das globale Hetzner-Präfix im LAN hinterlegen, z. B.:

2a01:4f8:c010:8b3a::2/64

Router Advertisements aktivieren, damit Clients sofort gültige IPv6-Adressen erhalten. In diesem Fall “Assisted” auswählen. IPv4 bleibt klassisch über DHCP, z. B. 192.168.1.1.

7. Ergebnis genießen

Die Kombination aus Tunnel, statischem IPv6-Präfix und zentralem IPv4-NAT ergibt ein äußerst stabiles Netz. Die beiden heimischen WANs dienen nur noch dazu, den Tunnel erreichbar zu halten. Da WireGuard bei Leitungswechseln kaum empfindlich ist, entstehen meist nur wenige verlorene Pakete, bevor der Verkehr transparent weiterläuft. Da Absender und Ziel gleich bleiben, verliert man in der Regel keine Verbindung. IPv6 bleibt dauerhaft gültig und verliert nie sein Präfix. IPv4 ist dank Hetzner-NAT unabhängig von lokalen Providerwechseln.

Damit entsteht ein kleines, robustes Hybridmodell, das die Vorteile eines Rechenzentrums mit einem dynamischen Heimnetz kombiniert.

Edit: Und wer jetzt keine Pakete durchbekommt, hat vermutlich das Offensichtliche vergessen. Auf dem Debian-Server muss natürlich IP-Forwarding aktiviert werden, sonst bleibt alles schön im Kernel stecken.

# IPv4 Forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

# IPv6 Forwarding
echo 1 > /proc/sys/net/ipv6/conf/all/forwarding

Dauerhaft geht es in /etc/sysctl.conf:

net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1

Speichern, sysctl -p und plötzlich lebt das Netz…