Overlapping Subnets: Warum es bei M&A und VPNs so oft kracht

Overlapping Subnets sind einer der häufigsten Gründe, warum Netzwerk-Integration nach einer M&A-Transaktion (Merger & Acquisition) oder beim Zusammenschalten von VPN-Domänen so oft „kracht“. Auf dem Papier klingt es banal: Zwei Netze nutzen dieselben privaten IP-Bereiche, zum Beispiel 10.0.0.0/8 oder 192.168.0.0/16. In der Realität hat das aber weitreichende Folgen, sobald Sie Routing zwischen den Domänen zulassen: Routen werden unvorhersehbar, Policies werden unübersichtlich, Applikationen brechen, und selbst erfahrene Teams laufen in Blackholes, weil Longest Prefix Match und Summarisierung gegen sie arbeiten. Besonders tückisch ist, dass Overlaps nicht immer sofort auffallen: Solange die Netze getrennt sind, funktioniert alles. Erst wenn Site-to-Site VPNs, SD-WAN, MPLS L3VPN, Cloud-Interconnects oder zentrale Shared Services (DNS, AD, Monitoring, Identity) gemeinsam genutzt werden, kommt es zu kollidierenden Prefixen – und dann eskaliert die Komplexität schnell. Im Telco-Umfeld verschärft sich das Thema zusätzlich, weil Provider häufig Multi-Tenant-Services, VRFs, Partner-Interconnects und über Jahre gewachsene Adresspläne betreiben. Overlapping Subnets sind daher nicht nur ein „IT-Problem“, sondern ein architektonisches Risiko, das bei M&A-Projekten früh bewertet werden muss. Dieser Artikel erklärt, warum Overlaps so häufig sind, welche typischen Crash-Szenarien bei M&A und VPNs auftreten, wie sich die Risiken systematisch bewerten lassen und welche bewährten Lösungswege – von VRFs über NAT bis Renumbering – in der Praxis wirklich funktionieren.

Was sind Overlapping Subnets – und warum sind sie mehr als „gleiche IPs“?

Von Overlapping Subnets spricht man, wenn zwei Netze denselben IP-Adressraum (vollständig oder teilweise) verwenden, der über Routing miteinander verbunden werden soll. Das kann „voll“ sein (beide nutzen 10.0.0.0/8) oder „teilweise“ (ein Netz nutzt 10.10.0.0/16, das andere 10.10.20.0/24). Entscheidend ist: Sobald beide Domänen in einem gemeinsamen Routing-Kontext sichtbar werden, kollidieren sie.

• Vollständiger Overlap: identische Prefixe in beiden Netzen (z. B. 192.168.1.0/24 auf beiden Seiten).
• Teil-Overlap: ein Prefix umfasst den anderen (z. B. /16 auf Seite A, /24 auf Seite B).
• Funktionaler Overlap: unterschiedliche Netze nutzen gleiche IPs für kritische Systeme (DNS, AD, NTP, MGMT), wodurch die Auswirkung größer ist als „nur Routing“.

Besonders wichtig ist das Routing-Prinzip Longest Prefix Match: Die spezifischste Route gewinnt. Dadurch kann ein Teil-Overlap zu sehr überraschendem Verhalten führen, wenn ein /24 „plötzlich“ einen /16-Traffic überschreibt.

Warum Overlaps bei M&A fast unvermeidlich sind

Die meisten Unternehmen nutzen private RFC1918-Adressbereiche und wählen dabei oft ähnliche Muster: 10/8 „für alles“, 172.16/12 für Rechenzentren, 192.168/16 für Standorte. Das ist historisch gewachsen, in vielen Umgebungen kaum dokumentiert und oft ohne strikte Governance. Bei M&A treffen zwei unabhängige Historien aufeinander – und damit fast zwangsläufig auch zwei ähnliche Adressstrategien.

• Beliebte Standardbereiche: 10.0.0.0/8 wird besonders häufig global verwendet.
• Fragmentierte Adresspläne: viele „Ausnahmen“ und regionale Eigenlösungen erhöhen Overlap-Wahrscheinlichkeit.
• Shadow IT: Cloud-VPCs, Labs, Partnernetze oder OT-Segmente sind oft nicht im zentralen IPAM.
• Geschwindigkeit der Integration: Business will schnell verbinden (SSO, E-Mail, Fileshares), IP-Renumbering dauert.

Warum es bei VPNs so oft kracht: VPN verbindet Routing-Domänen, nicht nur „Standorte“

VPNs – ob klassisches IPsec Site-to-Site, SD-WAN Tunnels oder Cloud VPN – bringen Routinginformationen zusammen. Sobald beide Seiten Routen austauschen oder statische Routen setzen, werden Overlaps operativ: Ein Paket an 10.10.20.5 kann auf beiden Seiten „lokal“ sein. Das Netz muss dann entscheiden, wohin es geht – und diese Entscheidung ist häufig nicht das, was Sie erwarten.

• Ambiguität: dieselbe Ziel-IP existiert in beiden Netzen – Routing kann nicht „raten“.
• Policy-Breakage: Firewall-Regeln und ACLs greifen unerwartet, weil Traffic in falsche Zone/VRF läuft.
• Asymmetrie: Hinweg nimmt eine Route, Rückweg eine andere; stateful Firewalls/NAT brechen Sessions.
• Summaries im Core: zusammengefasste Routen (z. B. 10.0.0.0/8) machen Overlap-Auswirkungen größer.

Typische Crash-Szenarien bei M&A und VPN-Integration

Overlaps zeigen sich in der Praxis in wiederkehrenden Mustern. Wenn Sie diese Muster erkennen, finden Sie die Root Cause deutlich schneller und können gezielter entscheiden, welche Lösung passt.

• „Nur ein Teil der Standorte ist erreichbar“: Teil-Overlap durch unterschiedliche Präfixlängen; ein /24 überschreibt das /16 in einem Teilnetz.
• „DNS/AD funktioniert sporadisch“: kritische Server-IP existiert in beiden Domänen; Clients erreichen manchmal die „falsche“ Instanz.
• „Nach SD-WAN Rollout bricht alles“: SD-WAN verteilt Summaries oder default routes; Overlaps werden plötzlich global sichtbar.
• „VPN steht, aber Applikation bricht“: Routing ist „da“, aber Rückweg ist asymmetrisch oder NAT/Firewall stateful blockiert.
• „Cloud VPC kollidiert“: Cloud-Netze nutzen gleiche RFC1918-Bereiche wie On-Prem; Peering/VPN wird schwierig.

Diagnose: Wie Sie Overlapping Subnets schnell nachweisen

Ein schneller Nachweis ist entscheidend, bevor Sie komplexe Gegenmaßnahmen bauen. Ziel ist, exakt zu bestimmen, welche Prefixe kollidieren und in welchem Routing-Kontext (global oder VRF) sie gleichzeitig sichtbar sind.

• Prefix-Inventur: Export aus IPAM/CMDB plus Live-Routing-Tabellen beider Seiten (inkl. VRFs).
• Overlap-Check: systematisch prüfen, welche Prefixe sich schneiden (voll/teilweise).
• Longest Prefix Analyse: für betroffene Ziel-IPs prüfen, welche Route tatsächlich gewinnt.
• Trace in beide Richtungen: Traceroute/Ping von beiden Seiten, um Asymmetrie zu erkennen.
• Critical Systems markieren: welche IPs sind DNS/AD/NTP/Management? Overlaps hier sind besonders kritisch.

Lösungsweg 1: VRFs als saubere Isolation bei Provider- und Multi-Tenant-Designs

Wenn Sie die Domänen nicht sofort umnummerieren können, ist VRF-Isolation oft der sauberste technische Schritt: Jede Domäne behält ihren Adressraum, aber Routingtabellen bleiben getrennt. Kommunikation wird nur über kontrollierte Inter-VRF-Mechanismen erlaubt.

• Vorteil: Overlaps sind technisch möglich, weil jede VRF ihre eigene Routing-Tabelle hat.
• Vorteil: Policies (Firewall/Route Leaks) sind kontrollierbar und auditierbar.
• Nachteil: Shared Services müssen bewusst angebunden werden (DNS, AD, Logging).
• Nachteil: Betriebskomplexität steigt, wenn VRF-Governance fehlt.

Lösungsweg 2: NAT als „Brücke“ – schnell, aber mit Kosten

NAT wird bei M&A und VPNs häufig als schnelle Umgehung eingesetzt: Eine Seite wird in einen nicht überlappenden Translationsraum übersetzt (z. B. 10.10.0.0/16 → 100.64.10.0/16 oder 172.31.0.0/16). Das kann Integration beschleunigen, bringt aber Nebenwirkungen.

• Vorteil: schnelle Connectivity ohne sofortiges Renumbering.
• Vorteil: gezielte Übersetzung nur für bestimmte Netze/Services möglich.
• Nachteil: Applikationen mit IP-Literal oder gegenseitiger IP-Prüfung können brechen.
• Nachteil: Troubleshooting und Logging werden komplexer (Original vs. translated IP).
• Nachteil: NAT kann asymmetrische Pfade und stateful Abhängigkeiten verschärfen.

Best Practice: NAT als Übergangslösung mit Sunset-Plan

Wenn NAT eingesetzt wird, sollte von Anfang an klar sein: Welche Services werden übersetzt, wie wird geloggt, wie wird getestet – und wann wird NAT wieder entfernt (Renumbering/Architekturziel).

Lösungsweg 3: Renumbering – langfristig am saubersten, kurzfristig am teuersten

Langfristig ist Umnummerierung (Renumbering) oft die robusteste Lösung: Eine Domäne migriert auf einen neuen, nicht kollidierenden Adressraum. Das ist aufwändig, aber es reduziert langfristig Komplexität, NAT-Last und Sonderregeln.

• Vorteil: klare, eindeutige Adressräume ohne technische Workarounds.
• Vorteil: Policies, Monitoring, Logging und Security werden einfacher.
• Nachteil: Aufwand hoch (DHCP, statische IPs, ACLs, App-Konfigurationen, Zertifikate, Firewalls).
• Nachteil: benötigt saubere Versionierung, Change-Plan und Parallelbetrieb.

Lösungsweg 4: Proxy-/Gateway-Ansätze für einzelne Shared Services

Manchmal müssen Sie nicht „Netze verbinden“, sondern nur bestimmte Dienste gemeinsam nutzen: DNS, AD, Monitoring, Ticketsysteme, Repository-Zugänge. Dann kann es sinnvoll sein, Service-Gateways zu nutzen statt voller L3-Konnektivität. Das reduziert Overlap-Risiko.

• DNS Forwarder/Resolver: statt vollem Routing zwischen Domänen.
• Identity Federation: SSO/IdP-Kopplung statt direkter Netzwerkfusion.
• Application Proxies: Zugriff auf einzelne Anwendungen über Proxies/WAF statt IP-Full-Mesh.
• Monitoring Relays: lokale Collector, die Daten zentral weiterleiten, statt Geräte in fremde Netze zu routen.

Warum Overlaps bei Telco-VPN-Produkten besonders häufig sind

Provider bieten L3VPN-Services, SD-WAN und Partner-Interconnects häufig für viele Kunden an. Kunden bringen dabei ihre eigenen RFC1918-Pläne mit – und Overlaps sind die Regel, nicht die Ausnahme. Deshalb sind VRFs im Provider-Umfeld so zentral: Sie erlauben Overlaps per Design. Probleme entstehen oft erst, wenn Kunden oder Provider versuchen, VRFs zu „verbinden“ (Extranet, Shared Services, Partnernetze).

• Multi-Tenant Realität: gleiche IP-Bereiche in vielen Kunden-VRFs sind normal.
• Extranet-Risiko: sobald VRFs miteinander sprechen, kollidieren Overlaps und Policies werden komplex.
• Route-Leaks: zu breite Leaks („alles 10/8“) sind ein typischer Crash-Auslöser.
• Governance: ohne klare Leak-Allow-Listen und Ownership eskaliert Komplexität.

Best Practices, um Overlaps in M&A-Projekten früh zu entschärfen

• Frühe Inventur: IPAM-/Routing-Export beider Unternehmen, inklusive Cloud-Netze, Labs, OT, Partner.
• Klassifizierung: kritische Netze (Identity, DNS, Management, Security) priorisieren; Overlaps hier zuerst lösen.
• Design-Ziel definieren: VRF-Isolation als Zwischenziel, Renumbering als Endziel – oder bewusst dauerhaftes Multi-Domain-Modell.
• Leak-Disziplin: Inter-Domain-Verbindungen nur über Allow-Lists, keine Summaries als Default.
• Teststrategie: End-to-end Tests pro Serviceklasse (DNS, AD, VoIP, SaaS, Monitoring) vor breitem Rollout.

Best Practices, um Overlaps in VPN-Designs zu vermeiden oder zu beherrschen

• Adress-Governance: wenn möglich, eindeutige private Adressräume pro Domäne/Region/Partner.
• VRF/Segmentation: Overlaps durch VRF-Trennung abfangen; Extranet nur bewusst und minimal.
• NAT gezielt einsetzen: nur für klar definierte Services; Logging und Troubleshooting von Anfang an einplanen.
• Summaries vorsichtig: Summaries reduzieren Routingtabellen, können aber Overlaps verschärfen; nur mit sauberer Hierarchie.
• Dokumentation & Versionierung: Änderungen nachvollziehbar machen, damit Overlap-Folgen im Incident schnell erkennbar sind.

Praxis-Checkliste: Warum es bei Overlapping Subnets so oft kracht – und was Sie tun können

• Overlap-Typ bestimmen: voll, teilweise, funktional (kritische Systeme betroffen?).
• Routing-Kontext klären: global oder VRF? Werden Routen geleakt oder summarisiert?
• Longest Prefix Match analysieren: welche Route gewinnt für die betroffenen Ziele wirklich?
• Crash-Szenario zuordnen: DNS/Identity, Asymmetrie, Summaries, SD-WAN-Propagation, Cloud-Peering.
• Lösungsweg wählen: VRF-Isolation (sauber), NAT (schnell), Renumbering (langfristig), Proxy/Gateway (dienstbasiert).
• Governance aufsetzen: Leak-Allow-Listen, Ownership, Change-Review, Source of Truth für Prefixe.
• Sunset-Plan definieren: Übergangslösungen (NAT/Proxies) brauchen ein Endziel, sonst werden sie dauerhaft teuer.

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3

Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.

Meine Leistungen umfassen:

• Professionelle Konfiguration von Routern und Switches

• Einrichtung von VLANs, Trunks, Routing, DHCP, NAT, ACLs und weiteren Netzwerkfunktionen

• Erstellung von Topologien und Simulationen in Cisco Packet Tracer

• Aufbau, Analyse und Fehlerbehebung von Netzwerk-Labs in GNS3 und EVE-NG

• Automatisierung von Netzwerkkonfigurationen mit Python, Netmiko, Paramiko, NAPALM und Ansible

• Erstellung von Skripten für wiederkehrende Netzwerkaufgaben

• Dokumentation der Konfigurationen und Bereitstellung nachvollziehbarer Lösungswege

• Konfigurations-Backups, Optimierung bestehender Setups und technisches Troubleshooting

Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.