Netzwerk & WAN
GRE
GRE (Generic Routing Encapsulation) ist ein einfaches Tunnel-Protokoll, das beliebige Pakete in IP verpackt und so eine Punkt-zu-Punkt-Strecke schafft.
- Generische Kapselung (Proto 47)
- Multicast & dynamisches Routing
- Ohne IPsec unverschlüsselt
- Rund 24 Byte Overhead
- Punkt-zu-Punkt-Tunnel
GRE (Generic Routing Encapsulation, RFC 2784) ist eine generische Tunnel-Kapselung: Sie packt ein beliebiges Netzwerkprotokoll in ein IP-Paket und transportiert es als Punkt-zu-Punkt-Tunnel über ein dazwischenliegendes IP-Netz. GRE nutzt IP-Protokollnummer 47 und ist bewusst schlank.
Dieser Artikel erklärt, was GRE kann (und was IPsec allein nicht kann), den Header und Overhead samt MTU-Folgen, die übliche Kombination GRE-over-IPsec, warum GRE selbst nichts verschlüsselt, die Fallstricke Keepalive und Recursive Routing sowie die Abgrenzung zur Mehrpunkt-Variante mGRE.
1. Was GRE kann, was IPsec allein nicht
Reines IPsec im Tunnel-Modus transportiert nur Unicast. Routing-Protokolle wie OSPF oder EIGRP arbeiten aber mit Multicast, und auch andere Layer-3-Protokolle sollen manchmal mit. Genau hier kommt GRE ins Spiel: Es kapselt Multicast und beliebige L3-Nutzlasten und macht so dynamisches Routing über einen Tunnel überhaupt möglich.
Daraus folgt das verbreitete Muster GRE-over-IPsec: GRE übernimmt Kapselung und Routing-Fähigkeit, IPsec liefert die Verschlüsselung. Beides zusammen ergibt einen routbaren, verschlüsselten Tunnel.
2. Header, Overhead und MTU
Der GRE-Header ist minimal 4 Byte groß; mit dem äußeren IPv4-Header ergeben sich rund 24 Byte Overhead pro Paket (optionale Key-/Sequence-Felder nach RFC 2890 erhöhen das). Bei 1500 Byte Außen-MTU bleibt eine Tunnel-MTU von etwa 1476 Byte. Da GRE selbst keine Path-MTU-Discovery erzwingt, ist MSS-Clamping (typisch 1436) die robuste Lösung gegen still verworfene große Pakete.
Cisco IOS: GRE-Tunnel mit MTU/MSS und Keepalive
interface Tunnel0
ip address 10.0.0.1 255.255.255.252
ip mtu 1476
ip tcp adjust-mss 1436
tunnel source GigabitEthernet0/0
tunnel destination 203.0.113.2
keepalive 10 33. GRE schützt nichts: Verschlüsselung über IPsec
GRE transportiert seine Nutzlast im Klartext. Es bietet weder Verschlüsselung noch Authentifizierung; der optionale GRE-Key ist ausdrücklich kein Sicherheitsmerkmal (RFC 2890), sondern dient nur der Flow-Unterscheidung. Über das öffentliche Internet ist ein nacktes GRE daher unsicher.
Über das Internet immer mit IPsec
Wo Vertraulichkeit zählt, gehört GRE mit IPsec kombiniert (GRE-over-IPsec). Wird kein Multicast und kein dynamisches Routing über den Tunnel gebraucht, ist unter Linux route-based IPsec (VTI- bzw. XFRM-Interface, etwa mit strongSwan) die schlankere Alternative ganz ohne GRE-Header. In rein internen, physisch kontrollierten Netzen kann GRE auch ohne IPsec vertretbar sein; im WAN nicht.
4. Keepalive und Recursive Routing
GRE ist von Haus aus zustandslos: Ein Tunnel-Interface bleibt oben, auch wenn die Gegenstelle weg ist. Ein GRE-Keepalive erkennt das und legt das Interface bei Ausfall down. Eine klassische Falle ist Recursive Routing: Wird die Tunnel-Zieladresse plötzlich über den Tunnel selbst geroutet, entsteht eine Schleife, und das Interface flappt (auf Cisco die Meldung %TUN-5-RECURDOWN).
Recursive Routing vermeidet man, indem das Tunnel-Ziel nie über den Tunnel erreichbar ist: eine spezifische statische Host-Route (/32) für die Tunnel-Zieladresse über das physische Interface, und die Tunnel-Endpunkt-Adressen nicht durch den Tunnel ankündigen. In größeren Designs trennt man Underlay- und Overlay-Routing.
5. Abgrenzung zu mGRE
Klassisches GRE ist Punkt-zu-Punkt: Jede Gegenstelle braucht ein eigenes Tunnel-Interface mit fester Zieladresse. Sollen viele Standorte über eine Schnittstelle bedient werden, kommt die Mehrpunkt-Variante mGRE zum Einsatz, die wiederum die Basis für DMVPN bildet. Beides ist als eigenes Thema beschrieben.
6. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Transportiert Multicast und beliebige L3-Protokolle (dynamisches Routing über Tunnel) | Keine Verschlüsselung und keine Authentifizierung von sich aus |
| Einfach und herstellerübergreifend verfügbar | Punkt-zu-Punkt: je Gegenstelle ein Interface (bei vielen Standorten unhandlich) |
| Geringer, kalkulierbarer Overhead (~24 Byte) | MTU-Overhead erfordert MSS-Clamping/PMTU-Behandlung |
| Ideale Ergänzung zu IPsec (GRE-over-IPsec) | Recursive-Routing-Falle bei unsauberem Routing |
| Basis für mGRE/DMVPN | GRE-Keepalive und IPsec-Tunnelschutz nicht in jeder Konstellation kombinierbar (z. B. VRF-aware auf Cisco) |
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
GRE 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.