Ein /56 IPv6 per IPsec auf alle Edge-Standorte verteilen

Ein vom Provider delegiertes /56 soll sauber auf mehrere Außenstandorte aufgeteilt werden – jeder Edge bekommt sein eigenes /64, erreichbar über verschlüsselte IPsec-Tunnel. Der Clou: Zwischen den Tunnelendpunkten routen wir mit ULA-Adressen. So bleibt das öffentliche Präfix sauber und das Underlay stabil. Diese Anleitung zeigt den Aufbau Schritt für Schritt auf Palo Alto PAN-OS.

Das Szenario

In der Zentrale (HQ) terminiert das vom Provider delegierte Präfix 2001:db8:5600::/56. Drei Außenstandorte (Edge-A, Edge-B, Edge-C) hängen über je einen IPsec-Tunnel am Hub. Jeder Edge soll ein eigenes /64 aus dem /56 betreiben – und alle Geräte dahinter sollen miteinander und mit der Zentrale kommunizieren können.

Warum ULA als Underlay?

Man könnte die Tunnel-Interfaces auch mit GUA-Adressen aus dem /56 nummerieren. Doch das vermischt zwei Dinge, die man besser trennt: das Transport-Routing zwischen den Firewalls und die produktiven Netze. ULA-Adressen (fd00::/8) lösen das elegant:

• Stabilität: Ändert der Provider das delegierte /56, bleiben die Tunnel-Next-Hops gleich – die Routing-Logik muss nicht angefasst werden.
• Sauberkeit: Das knappe, öffentliche /56 wird ausschließlich für produktive Geräte verwendet, nicht für Punkt-zu-Punkt-Links.
• Eindeutigkeit: Ein zufällig gewähltes ULA-Präfix (RFC 4193) kollidiert praktisch nie mit anderen Netzen – ideal für ein privates Underlay.
• Trennung: Underlay (ULA) und Overlay (GUA) lassen sich unabhängig voneinander filtern, überwachen und dokumentieren.

Adressplan

Zwei Adressräume, klar getrennt: das GUA-/56 für die Standortnetze und ein ULA-/48 für die Tunnel.

1.Crypto-Profile

Zuerst moderne Phase-1- und Phase-2-Profile. Wir verwenden IKEv2, eine starke DH-Gruppe und AES-GCM:

# Phase 1 (IKE) and Phase 2 (IPsec)
set network ike crypto-profiles ike-crypto-profiles IKE-AES256 dh-group group20 hash sha384 encryption aes-256-cbc lifetime hours 8
set network ike crypto-profiles ipsec-crypto-profiles IPSEC-GCM esp encryption aes-256-gcm lifetime hours 1

2.IKE-Gateways

Pro Edge ein IKE-Gateway. Der Transport (das Underlay des Tunnels) läuft hier über das IPv4-Internet – das verschlüsselte IPv6 reist später darin. Adressen aus den Doku-Bereichen sind Beispiele:

set network ike gateway GW-Edge-A protocol version ikev2
set network ike gateway GW-Edge-A local-address interface ethernet1/1
set network ike gateway GW-Edge-A peer-address ip 203.0.113.10
set network ike gateway GW-Edge-A authentication pre-shared-key key "super-geheimer-psk"
set network ike gateway GW-Edge-A protocol ikev2 ike-crypto-profile IKE-AES256
# Edge-B and Edge-C analogously (peer-address 203.0.113.11 / .12)

3.Tunnel-Interfaces mit ULA

Jetzt das Herzstück: Die Tunnel-Interfaces bekommen ihre ULA-Adresse. Sie ist später der Next-Hop, über den die GUA-Netze erreicht werden. Die MTU senken wir gleich für den IPsec-Overhead ab:

set network interface tunnel units tunnel.1 ipv6 enabled yes
set network interface tunnel units tunnel.1 ipv6 address fd00:abcd:51:a::1/64
set network interface tunnel units tunnel.1 mtu 1400
# Hub side ::1, Edge-A side ::2 — one ULA /64 per tunnel

4.IPsec-Tunnel & Proxy-IDs

Der IPsec-Tunnel verbindet Gateway, Crypto-Profil und Tunnel-Interface. Da wir route-based arbeiten, lassen wir die Proxy-ID (den Traffic-Selector) für IPv6 offen – geroutet wird über die Routing-Tabelle:

set network tunnel ipsec TUN-Edge-A auto-key ike-gateway GW-Edge-A
set network tunnel ipsec TUN-Edge-A auto-key ipsec-crypto-profile IPSEC-GCM
set network tunnel ipsec TUN-Edge-A tunnel-interface tunnel.1
# Route-based: leave the traffic selector open (all IPv6)
set network tunnel ipsec TUN-Edge-A auto-key proxy-id-v6 ANY local ::/0 remote ::/0

5.Statisches Routing

Nun verbinden wir GUA und ULA: Auf dem Hub zeigt jedes Edge-/64 auf die ULA-Adresse des passenden Tunnels als Next-Hop:

set network virtual-router VR-Default routing-table ipv6 static-route Edge-A-LAN destination 2001:db8:5601::/64 nexthop ipv6-address fd00:abcd:51:a::2
set network virtual-router VR-Default routing-table ipv6 static-route Edge-B-LAN destination 2001:db8:5602::/64 nexthop ipv6-address fd00:abcd:51:b::2
set network virtual-router VR-Default routing-table ipv6 static-route Edge-C-LAN destination 2001:db8:5603::/64 nexthop ipv6-address fd00:abcd:51:c::2

Auf jedem Edge das Gegenstück: das gesamte /56 (Hub und – via Hub – die anderen Standorte) zurück über die Hub-ULA. Das lokale /64 bleibt „connected“ und gewinnt dank längstem Präfix automatisch:

set network virtual-router VR-Default routing-table ipv6 static-route To-HQ destination 2001:db8:5600::/56 nexthop ipv6-address fd00:abcd:51:a::1
# Edge-A reaches Edge-B/-C via the hub (hub-and-spoke).

6.Skalieren mit BGP

Bei vielen Standorten werden statische Routen mühsam. Dann übernimmt MP-BGP über die ULA-Tunneladressen: Jeder Edge kündigt sein /64 an, der Hub fasst zum /56 zusammen. Neue Standorte bringen sich selbst ein – ganz ohne Hand an der Routing-Tabelle:

set network virtual-router VR-Default protocol bgp enable yes
set network virtual-router VR-Default protocol bgp local-as 65000
set network virtual-router VR-Default protocol bgp peer-group SPOKES peer Edge-A peer-as 65000
set network virtual-router VR-Default protocol bgp peer-group SPOKES peer Edge-A local-address interface tunnel.1 ip fd00:abcd:51:a::1/64
set network virtual-router VR-Default protocol bgp peer-group SPOKES peer Edge-A peer-address ip fd00:abcd:51:a::2
set network virtual-router VR-Default protocol bgp peer-group SPOKES peer Edge-A address-family-profile ipv6-unicast

7.Zonen & Security-Policy

Routing allein reicht nicht – die Firewall muss den Verkehr auch erlauben. Die Tunnel-Interfaces kommen in eine VPN-Zone, dann geben wir den Standort-zu-Standort-Verkehr für das /56 frei:

set zone Z-VPN network layer3 [ tunnel.1 tunnel.2 tunnel.3 ]
set rulebase security rules Allow-Sites-v6 from Z-VPN to Z-VPN source 2001:db8:5600::/56 destination 2001:db8:5600::/56 application any service application-default action allow
commit

8.Verifizieren

Nach dem commit prüfen wir Tunnel, Routen und Erreichbarkeit im operativen Modus:

# Phase 1 / Phase 2 state
show vpn ike-sa
show vpn ipsec-sa

# Show only the static IPv6 routes
show routing route type static afi ipv6

# Test the forwarding decision and check reachability
test routing fib-lookup virtual-router VR-Default ip 2001:db8:5602::1
ping source 2001:db8:5600::1 host 2001:db8:5601::1

Die Routing-Tabelle sollte für jedes Edge-/64 die ULA-Adresse als Next-Hop über das richtige Tunnel-Interface zeigen:

2001:db8:5601::/64   fd00:abcd:51:a::2   tunnel.1   static
2001:db8:5602::/64   fd00:abcd:51:b::2   tunnel.2   static
2001:db8:5603::/64   fd00:abcd:51:c::2   tunnel.3   static

Best Practices

• MTU & TCP-MSS: Tunnel-MTU senken (z. B. 1400) und MSS-Clamping aktivieren – IPsec plus IPv6-Header kosten Overhead, sonst droht Fragmentierung.
• Summarization: Der Hub kündigt nach außen nur das /56 an, nicht jedes einzelne /64 – das hält Routing-Tabellen klein.
• Tunnel-Monitoring: Tunnel-Monitor mit ULA-Ziel einrichten, damit ausgefallene Tunnel erkannt und Routen sauber zurückgezogen werden.
• Redundanz: Für Ausfallsicherheit zweite Tunnel pro Edge und ECMP oder BGP-Pfadpräferenzen nutzen.
• ULA sauber wählen: Die 40 Bit Global-ID nach RFC 4193 zufällig erzeugen – nicht fd00:: für alles verwenden.
• Dokumentation: GUA-Plan und ULA-Plan getrennt führen; das erleichtert Audits und spätere Erweiterungen.

Troubleshooting

Häufige Fragen

Quellen

Externe Quellen, Stand August 2026 (öffnen in einem neuen Tab):

• Palo Alto Networks – Set Up an IPSec Tunnel (Tunnel Mode)
• Palo Alto Networks – Site-to-Site VPN mit statischem Routing
• Palo Alto Networks – BGP-Peer mit MP-BGP für IPv4-/IPv6-Unicast
• Palo Alto Networks – Advanced Routing: Logical Router konfigurieren
• IETF – RFC 4193: Unique Local IPv6 Unicast Addresses (ULA)

Dieser Beitrag dient der allgemeinen Information. Adressen (Doku-Präfixe), Namen und Befehle sind Beispiele und an Ihre Umgebung sowie Ihre PAN-OS-Version anzupassen. Stand: August 2026.