Netzwerk & WAN
ADVPN
ADVPN (Auto Discovery VPN) bezeichnet VPN-Lösungen, die dynamisch direkte Verbindungen zwischen Standorten aufbauen, ohne sie vorab zu konfigurieren.
- Dynamische On-Demand-Shortcuts
- Hub-Spoke statt Vollmasche
- IKEv2-basiert, ohne GRE
- Fortinet ADVPN 1.0 / 2.0
- RFC 7018 (Problem Statement)
ADVPN (Auto Discovery VPN) erweitert ein klassisches Hub-and-Spoke-IPsec-Overlay um die Fähigkeit, bei Bedarf direkte Tunnel zwischen Spokes aufzubauen (Shortcuts). Statt allen Querverkehr über den Hub zu zwingen, erkennt der Hub die Kommunikation zweier Spokes und vermittelt ihnen einen direkten Tunnel; bei Inaktivität wird er wieder abgebaut.
Dieser Artikel erklärt das Konzept und seinen Standardisierungsstand (RFC 7018), die Abgrenzung zu DMVPN, die Umsetzungen verschiedener Hersteller (Fortinet, Juniper, H3C/HPE), wie ein Shortcut zustande kommt, den Routing- und SD-WAN-Bezug, das Verhältnis zu IPsec/IKEv2 und NAT, typische Einsatzfelder sowie die ehrliche Einordnung zur Interoperabilität.
1. Das Prinzip: Shortcuts on demand
Die Grundkonfiguration bleibt Hub-and-Spoke, das hält das Provisioning einfach und neue Spokes brauchen keine Änderung an bestehenden. Sobald zwei Spokes Verkehr austauschen, signalisiert der Hub ihnen die nötigen Informationen, und sie handeln einen direkten IPsec-Tunnel aus. Danach läuft der Datenverkehr ohne Hub-Umweg, was Hub-Last und Latenz senkt. Der Hub bleibt als Vermittler und Fallback erhalten.
2. Standardisierung und Abgrenzung zu DMVPN
RFC 7018 (2013) beschreibt nur das Problem und die Anforderungen an Auto-Discovery-VPNs, es ist bewusst kein Protokollstandard. Konkrete Protokoll-Drafts wurden nie zu einem RFC. Praktisch heißt das: Die Implementierungen (Fortinet, Juniper, weitere) folgen demselben Konzept, sind aber untereinander nicht kompatibel.
Gegenüber DMVPN ist der Hauptunterschied: Die IKEv2-basierten Umsetzungen (Fortinet, Juniper) kommen ohne GRE aus und signalisieren die Shortcuts direkt über IKEv2-Nachrichten, statt über mGRE plus NHRP. Das spart den GRE-Overhead; DMVPN punktet dafür mit langjährig erprobter, breit dokumentierter Cisco-Reife.
3. Implementierungen: Fortinet, Juniper, H3C
ADVPN ist ein Konzept, kein einheitliches Protokoll. Mehrere Hersteller setzen es um, mit unterschiedlicher Mechanik. Die wichtigsten:
| Hersteller | Ansatz und Besonderheit |
|---|---|
| Fortinet | am breitesten dokumentiert; ADVPN 1.0/2.0, IKE-signalisierte Shortcuts (Informational), tiefe SD-WAN-Integration |
| Juniper | IKEv2-basiert; der Hub agiert als Shortcut-Suggester über bestehende IKEv2-SAs |
| H3C / HPE | MSR-Router mit zentralem VAM-Server (VPN Address Management) zur Adressauflösung; GRE- oder UDP-Kapselung mit IPsec-Sicherung, Spoke-zu-Spoke-Shortcuts per Hub-Redirect |
Nicht untereinander kompatibel
Weil es keinen verbindlichen Protokoll-Standard gibt (RFC 7018 ist nur ein Problem Statement), funktioniert ADVPN jeweils nur innerhalb einer Herstellerwelt. Ein Fortinet-Spoke bildet keinen ADVPN-Shortcut mit einem H3C- oder Juniper-Hub. In gemischten Umgebungen gehört das früh eingeplant.
4. ADVPN 1.0 und 2.0 bei Fortinet
ADVPN 1.0 unterstützt IKEv1 und IKEv2 und entdeckt Shortcuts über IKE-Informational-Nachrichten: Der Hub ist Auto-Discovery-Sender, die Spokes sind Empfänger. ADVPN 2.0 (ab FortiOS 7.4.2, nur IKEv2) bringt Edge-Discovery und Pfad-Management: Ein Spoke kann nach eigener Pfadentscheidung gezielt einen Shortcut zu einem entfernten Spoke anfragen, tauscht dabei WAN-Link-Informationen aus (Adresse, Transport-Gruppe, Linkqualität, Kosten) und aktualisiert diese fortlaufend. So fließt die gemessene Link-Güte direkt in die SD-WAN-Pfadwahl ein.
Fortinet: ADVPN am Hub (Phase-1, Auszug)
config vpn ipsec phase1-interface
edit "HUB"
set type dynamic
set auto-discovery-sender enable
set add-route disable
next
end5. Wie ein Shortcut entsteht
Der Ablauf in Kurzform (Offer/Query/Reply): Spoke A sendet Verkehr an Spoke B, zunächst über den Hub. Der Hub erkennt den Transit und bietet Spoke A einen Shortcut an (Offer). Spoke A fragt über den Hub die Erreichbarkeitsdaten von Spoke B ab (Query), Spoke B antwortet über den Hub zurück an Spoke A (Reply), und beide Spokes handeln dann direkt einen IPsec-Tunnel aus. Sobald das dynamische Routing den kürzeren Pfad bevorzugt, fließt der Verkehr direkt.
Erstpakete laufen über den Hub
Bis der Shortcut ausgehandelt ist, nimmt der Verkehr den Weg über den Hub. Der direkte Pfad entsteht also mit kurzer Verzögerung, nicht sofort beim ersten Paket. Für die meisten Anwendungen ist das unkritisch.
6. Routing und SD-WAN-Integration
ADVPN setzt dynamisches Routing zwingend voraus, statische Routen können auf Shortcut-Verfügbarkeit nicht reagieren. Üblich ist iBGP mit dem Hub als Route-Reflector (stabile Router-ID über ein Loopback), alternativ OSPF. In Fortinet-Umgebungen verzahnt sich ADVPN 2.0 mit SD-WAN: Performance-SLAs entscheiden, ob ein Shortcut genutzt wird, und Link-Qualität fließt in die Pfadwahl ein.
7. Verhältnis zu IPsec und IKEv2
ADVPN bringt keine eigene Verschlüsselung mit, sondern ist eine Steuerebene über IPsec (siehe IPsec): Sowohl die dauerhaften Hub-Spoke-Tunnel als auch die dynamischen Shortcuts sind vollwertige IPsec-SAs mit IKEv2-Authentifizierung und ESP-Verschlüsselung. Der Shortcut-Aufbau nutzt die bestehende Hub-Spoke-SA als Signalisierungskanal; die eigentliche Direktverbindung wird dann separat per IKEv2 ausgehandelt. ADVPN automatisiert also die IKE-Aushandlung, es ersetzt sie nicht.
8. NAT-Traversal und seine Grenzen
Spokes sitzen in der Praxis oft hinter NAT (DSL, LTE). Sitzt ein Spoke hinter NAT, lösen die Implementierungen den direkten Shortcut per UDP-Hole-Punching. Sitzen beide Spokes hinter NAT, ist das Verhalten herstellerabhängig: Fortinet unterstützt auch dieses Szenario per Hole-Punching, sofern beide NAT-Geräte Endpoint-Independent Mapping (RFC 4787) bieten; bei Juniper kommt dann kein direkter Shortcut zustande, der Verkehr bleibt über den Hub. Das gehört ins Standortdesign eingeplant.
9. Best Practices und typische Fehler
- Interface-/route-based, nicht policy-based ADVPN setzt route-based IPsec voraus.
- Routen dem Routing-Protokoll überlassen die automatische IPsec-Routeneintragung deaktivieren (bei Fortinet add-route disable), sonst kollidiert sie mit BGP/OSPF nach dem Shortcut-Aufbau.
- Stabile Router-ID Loopback als BGP-Router-ID, sonst instabile Sessions.
- Kein NAT in der Hub-Policy maskiert der Hub die Spoke-Adressen, scheitert der Shortcut, obwohl der Verkehr über den Hub läuft.
- IKEv2 verwenden ADVPN 2.0 erfordert IKEv2; für neue Setups ohnehin gesetzt.
10. Typische Einsatzfelder
- Viele Filialen mit Querverkehr Sprache, Video und direkte Datei-/Anwendungszugriffe zwischen Außenstellen profitieren von direkten Pfaden statt Umweg über die Zentrale.
- Latenzempfindliche Echtzeit-Dienste VoIP und Video gewinnen durch den kürzeren direkten Pfad spürbar an Qualität.
- SD-WAN über mehrere Provider in Fortinet-Umgebungen wählt ADVPN 2.0 den Shortcut nach gemessener Linkqualität und entlastet so den Hub.
11. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Dynamische Spoke-zu-Spoke-Tunnel ohne dauerhafte Vollvermaschung | Kein interoperabler Standard: Herstellerumsetzungen inkompatibel |
| Kein GRE-Overhead bei den IKEv2-Umsetzungen (Fortinet/Juniper) | Erstpakete laufen über den Hub, bis der Shortcut steht |
| Nahezu Zero-Touch für neue Spokes | Erfordert dynamisches Routing; Fehlkonfiguration verhindert den Nutzen |
| Tiefe SD-WAN-Integration (Fortinet ADVPN 2.0) | Beide Spokes hinter NAT: Shortcut herstellerabhängig (Fortinet ja, Juniper nein) |
| Nur IPsec/IKEv2 als Unterbau, keine Zusatzprotokolle | Hub bleibt zentraler Vermittler (Dual-Hub als Absicherung) |
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
ADVPN im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.