Feste öffentliche IP-Adresse: Wann erforderlich?

NETZWERK · IP-ADRESSIERUNG

Eine feste öffentliche IP-Adresse ist kein allgemeines Qualitätsmerkmal eines Internetanschlusses. Sie löst bestimmte Anforderungen an Erreichbarkeit und eindeutige Identifikation. Für gewöhnliche Cloudarbeit, Webzugriffe und Microsoft 365 ist sie meist nicht erforderlich.

Vor einer Bestellung muss klar sein, ob ein externer Dienst die öffentliche Quelladresse prüft, ob ein eigener Dienst aus dem Internet erreichbar sein soll oder ob eine VPN-Gegenstelle eine dauerhafte Adresse verlangt. Erst danach werden IPv4, IPv6, NAT, Providerübergabe und Ausfallweg geplant.

Dieser Leitfaden führt von der Anforderung über die technische Bestandsaufnahme bis zu Bestellung, Firewallregel, DNS, Migration und Abnahme. Er trennt die öffentliche Adresse am Internetanschluss von privaten Adressen im Büronetz und zeigt, welche Aufgaben auch mit einer festen Adresse ungelöst bleiben.

Kapitelübersicht

Begriffe Bedarf Bestand Provider Sicherheit DNS Migration Abnahme

1. Öffentlich, fest, privat und intern bezeichnen unterschiedliche Eigenschaften

Mehrere Begriffe werden im Alltag vermischt. Eine Adresse kann öffentlich und dynamisch, öffentlich und fest oder privat und statisch konfiguriert sein. Für die Entscheidung werden Erreichbarkeit, Änderungsverhalten und Adressfamilie getrennt beschrieben.

Adressbegriffe für den Büroanschluss
Begriff	Bedeutung	Praktische Folge
Öffentliche IPv4-Adresse	Im öffentlichen IPv4-Internet grundsätzlich eindeutig adressierbare Adresse	Kann als Quelladresse für Freigaben oder als Ziel für eingehende Verbindungen dienen.
Dynamische öffentliche IPv4-Adresse	Öffentliche Adresse, die der Provider neu zuweisen kann	Ausgehende Nutzung funktioniert; feste Gegenstellenfreigaben können nach einem Wechsel ausfallen.
Feste öffentliche IPv4-Adresse	Vom Produkt dauerhaft zugeordnete öffentliche Adresse	Freigaben, DNS und bestimmte VPN-Gegenstellen bleiben auf dieselbe Adresse bezogen.
Private IPv4-Adresse	Adresse aus 10.0.0.0/8, 172.16.0.0/12 oder 192.168.0.0/16	Ist nur im internen oder verbundenen privaten Netz eindeutig und wird im Internet nicht geroutet.
Shared Address Space	Providerinterner Bereich 100.64.0.0/10 für Carrier-Grade NAT	Der Kundenrouter besitzt keine direkt erreichbare öffentliche IPv4-Adresse.
Öffentliches IPv6-Präfix	Vom Provider gerouteter Bereich für mehrere IPv6-Adressen im Kundennetz	Endgeräte können global adressierbar sein; die Firewall muss eingehende Verbindungen dennoch blockieren.
Statische interne Adresse	Feste Adresse für Firewall, Drucker, Access Point oder Server im LAN	Verbessert interne Zuordnung, ist aber keine feste öffentliche Adresse.

Eine feste WAN-Adresse ersetzt keinen internen Adressplan

Am Internetanschluss kann eine feste öffentliche Adresse liegen, während alle Bürogeräte private Adressen verwenden. Die Firewall übersetzt ausgehende IPv4-Verbindungen typischerweise per NAT. Für einen internen Server wird zusätzlich eine gezielte Weiterleitung oder eine VPN-Verbindung konfiguriert. Drucker, Access Points und andere Verwaltungsgeräte erhalten weiterhin dokumentierte interne Adressen oder DHCP-Reservierungen.

Bei IPv6 erhalten interne Netze üblicherweise Adressen aus einem delegierten Präfix. Globale Adressierbarkeit bedeutet dabei nicht, dass ein Dienst automatisch erreichbar sein darf. Eine zustandsbehaftete Firewall verwirft unerwünschte eingehende Verbindungen. NAT ist keine Voraussetzung für diese Schutzwirkung.

2. Der konkrete Anwendungsfall entscheidet über den Bedarf

Die richtige Frage lautet nicht, ob Unternehmen grundsätzlich eine feste IP-Adresse brauchen. Zu prüfen ist, welche Gegenstelle welche Adresse in welcher Richtung und mit welchem Ausfallverhalten verwendet.

Anwendungsfälle und technische Anforderungen
Anwendungsfall	Feste öffentliche IP?	Begründung und bessere Alternative
Microsoft 365, Web und SaaS aus dem Büro nutzen	Meist nein	Die Sitzungen werden ausgehend aufgebaut. Identität, Gerätezustand und Mehrfaktor-Authentifizierung sind belastbarere Kontrollen als eine Büro-IP.
SaaS-Anbieter erlaubt Zugriff nur von hinterlegten Quelladressen	Oft ja	Die feste ausgehende NAT-Adresse wird beim Anbieter freigeschaltet. Ein Ausfallanschluss braucht eine zweite vorab registrierte Adresse.
Standort-zu-Standort-VPN mit klassischer IP-Gegenstelle	Häufig ja	Eine feste Zieladresse vereinfacht die Gegenstellenkonfiguration. Alternativ können FQDN, dynamisches DNS oder ein vermittelter Tunnel unterstützt werden.
Fernzugriff einzelner Mitarbeitender	Nicht zwingend	Cloudbasierter Zero-Trust-Zugriff oder ein VPN-Gateway mit FQDN kann ohne feste IPv4 auskommen. Die konkrete Lösung entscheidet.
Eigener Mailserver im Büro	Ja, aber meist unzweckmäßig	Zusätzlich sind Reverse DNS, Portfreigaben, Reputation, Zustellung, Redundanz und Betrieb erforderlich. Gehostete Mail ist für kleine Unternehmen regelmäßig belastbarer.
Eigene Website im Büro	Technisch häufig ja, betrieblich selten sinnvoll	Strom, Leitung, DDoS-Schutz, Zertifikate, Patchen und Verfügbarkeit bleiben eigene Aufgaben. Externes Hosting entkoppelt den Webauftritt vom Büro.
Überwachungskamera oder NAS aus der Ferne	Nein als erste Wahl	Direkte Portfreigaben vergrößern die Angriffsfläche. Herstellercloud, ausgehender Tunnel oder abgesichertes VPN werden geprüft.
VoIP oder Cloudtelefonie	Produktabhängig	Viele Cloudlösungen arbeiten mit ausgehenden Registrierungen. Eine feste Adresse kann für Providerfreigaben oder SBC-Szenarien relevant sein.
Eingehende Partnerverbindung	Häufig ja	Partner verlangen oft eine feste Gegenstelle und eindeutige Regeln. Protokoll, Ports, Authentisierung und Quellnetze werden zusätzlich vereinbart.
Bürodrucker und lokale Dateiablage	Nein	Diese Geräte benötigen stabile interne Adressen, aber keine öffentliche Erreichbarkeit.

Eine IP-Freigabe ist nur ein zusätzliches Merkmal

Wenn ein Geschäftspartner ausschließlich Verbindungen von einer bekannten Büro-IP zulässt, reduziert das den Kreis möglicher Quellen. Es beweist jedoch weder die Identität des Benutzers noch die Vertrauenswürdigkeit des Endgeräts. Zugangsdaten, Zertifikate, Mehrfaktor-Authentifizierung, minimale Rechte und Protokollierung bleiben erforderlich.

Ein Mitarbeiter im Homeoffice oder auf Geschäftsreise verlässt außerdem die freigegebene Büroadresse. Dann muss er zuerst über einen kontrollierten Unternehmenszugang arbeiten oder eine andere, identitätsbezogene Zugriffsmethode verwenden. Die Betriebsregel wird vor der technischen Freigabe festgelegt.

Entscheidung in zehn Fragen

Welche konkrete Anwendung oder Gegenstelle stellt die Anforderung?
Geht es um die Quelladresse einer ausgehenden Verbindung oder um ein eingehend erreichbares Ziel?
Unterstützt die Gegenstelle IPv4, IPv6, einen DNS-Namen oder nur eine einzelne IPv4-Adresse?
Kann die Anforderung mit Identität, Zertifikat oder ausgehendem Tunnel besser erfüllt werden?
Welche Ports und Protokolle sind tatsächlich erforderlich?
Muss der Dienst auch über den Ersatzanschluss funktionieren?
Kann beim Ersatzweg eine zweite Adresse hinterlegt werden?
Wer pflegt Firewall, DNS, Zertifikat und Gegenstellenfreigabe?
Welche Protokolle oder Geräte würden aus dem Internet erreichbar?
Wie wird die Funktion nach Adress-, Router- oder Anbieterwechsel getestet?

3. Eine feste Adresse ist häufig entbehrlich

Cloudanwendungen benötigen überwiegend stabile ausgehende Internetverbindungen, keine eingehende Erreichbarkeit des Büros. Eine feste IP-Adresse sollte deshalb nicht aus Gewohnheit bestellt oder als Sicherheitsfunktion verkauft werden.

Anforderung ohne feste Büro-IP lösen
Ausgangslage	Geeigneter Ansatz	Zu prüfen
Mitarbeitende greifen auf SaaS zu	Identitätsbasierte Anmeldung mit MFA und Gerätekontrolle	Notfallzugang, Rollen und Sitzungsrichtlinien
Fernwartung eines verwalteten Geräts	Ausgehend aufgebauter, autorisierter Supportkanal	Freigabe, Protokollierung und Beendigung der Sitzung
Zugriff auf einzelne interne Anwendung	Vermittelter Zero-Trust-Zugang oder VPN mit FQDN	Clientzustand, Authentisierung und minimale Netzreichweite
Dynamische öffentliche Adresse vorhanden	Dynamisches DNS, sofern Gegenstelle FQDN akzeptiert	Aktualisierungsintervall, DNS-TTL und Verhalten nach Wechsel
CGNAT verhindert eingehendes IPv4	Öffentliches IPv6, ausgehender Tunnel oder anderes Providerprodukt	IPv6-Verfügbarkeit an allen Gegenstellen und Firewallkonzept
Dateiaustausch mit Kunden	Berechtigte Cloudfreigabe statt offenem Dateiserver	Ablaufdatum, Empfängerprüfung und Widerruf
Website und E-Mail	Externes Hosting beziehungsweise Microsoft 365	Domaininhaberschaft, Export und Administrationszugang

Dynamisches DNS macht eine wechselnde öffentliche Adresse unter einem gleichbleibenden Namen auffindbar. Es beseitigt jedoch weder CGNAT noch fehlende Portfreigaben und garantiert keine unterbrechungsfreie Aktualisierung. Bei Gegenstellen, die ausschließlich numerische IP-Adressen akzeptieren, hilft ein DNS-Name ebenfalls nicht.

Eine feste IP wird auch dann nicht zum Hochverfügbarkeitsmerkmal. Fällt Leitung, Providerrouter, Strom oder Gebäudetrasse aus, bleibt die unveränderte Adresse wirkungslos. Ausfallsicherheit entsteht aus einem getesteten Ersatzweg und einer Anwendung, die diesen Weg technisch unterstützt.

4. Der vorhandene Anschluss wird vor jeder Bestellung untersucht

Die sichtbare Adresse auf einer Internetseite allein reicht nicht. Benötigt werden WAN-Status des Routers, Providerprodukt, Adressfamilien, NAT-Verfahren und das Verhalten nach einer kontrollierten Neueinwahl.

Bestandsaufnahme in achtzehn Schritten

Provider, Tarif, Kundennummer und Anschlussart erfassen.
Vertrag und Leistungsbeschreibung auf feste IPv4, IPv6-Präfix und Routermodus prüfen.
WAN-Statusseite von Router oder Firewall öffnen.
Zugewiesene IPv4-Adresse, Präfixlänge und Gateway dokumentieren.
Prüfen, ob die WAN-Adresse aus privatem oder Shared Address Space stammt.
Von einem Bürorechner die öffentlich sichtbare IPv4-Adresse bestimmen.
WAN-Adresse und sichtbare Adresse vergleichen.
IPv6-Verfügbarkeit und delegiertes Präfix erfassen.
Bestehende Portweiterleitungen und eingehende Firewallregeln exportieren.
Dynamische DNS-Einträge und Aktualisierungsclient ermitteln.
Standort-VPNs, Remotezugänge und Partnerfreigaben inventarisieren.
Nach Anwendungen suchen, die eine externe IP fest eingetragen haben.
Öffentliche DNS-Einträge der Unternehmensdomains prüfen.
Reverse-DNS-Anforderungen vorhandener Dienste ermitteln.
Ersatzanschluss und dessen Adressierung dokumentieren.
Geplanten Routermodus und mögliche Doppel-NAT-Strecke skizzieren.
Wartungsfenster für eine kontrollierte Neueinwahl festlegen.
Vorher-nachher-Werte und betroffene Funktionen protokollieren.

WAN-Adresse richtig bewerten
Beobachtung	Wahrscheinliche Einordnung	Nächster Prüfschritt
Router-WAN liegt in 10/8, 172.16/12 oder 192.168/16	Vorgeschalteter Router oder privates Providernetz	Gerätekette und zweite NAT-Ebene prüfen.
Router-WAN liegt in 100.64.0.0/10	Shared Address Space für Carrier-Grade NAT möglich	Provider nach öffentlicher IPv4 und eingehender Erreichbarkeit fragen.
Router-WAN weicht von öffentlich sichtbarer IPv4 ab	Weitere Adressübersetzung vor dem Router	Provider- oder vorgeschaltete NAT-Schicht bestimmen.
Router-WAN entspricht öffentlich sichtbarer IPv4	Öffentliche IPv4 liegt am eigenen Gateway	Prüfen, ob sie vertraglich fest oder nur aktuell dynamisch ist.
IPv6-Präfix vorhanden	Global adressierbares IPv6-Netz kann verfügbar sein	Präfixstabilität, Firewall und Gegenstellenunterstützung prüfen.
Adresse bleibt nach Neustart gleich	Noch kein Beweis für vertraglich feste Adresse	Produktunterlagen oder schriftliche Providerbestätigung verlangen.

Den Test ohne Betriebsstörung vorbereiten

Ein Routerneustart kann Telefonie, VPN, Kartenzahlung, Cloudzugriff und laufende Sitzungen unterbrechen. Vor dem Test werden betroffene Personen informiert, Konfiguration gesichert und der Rückweg festgelegt. Bei einem Providergerät darf kein Werksreset durchgeführt werden, nur um eine Adressänderung zu provozieren.

Bleibt die IPv4-Adresse nach einer Neueinwahl gleich, kann sie trotzdem aus einem dynamischen Pool stammen. Maßgeblich ist die vertragliche Zusage. Umgekehrt kann ein festes IPv6-Präfix getrennt von einer dynamischen IPv4 geliefert werden. Beide Adressfamilien werden einzeln dokumentiert.

5. Das Providerprodukt muss zur geplanten Topologie passen

„Feste IP inklusive“ sagt noch nicht, ob die Adresse am Providerrouter genattet, an die eigene Firewall geroutet oder als nutzbares Subnetz übergeben wird. Vor der Bestellung wird die tatsächliche Übergabeform geklärt.

Typische Übergabeformen
Übergabe	Aufbau	Planungsfolge
Feste öffentliche IPv4 am Providerrouter	Providergerät nutzt öffentliche Adresse und übersetzt auf private LAN-Adressen	Portweiterleitungen und gegebenenfalls Exposed-Host-Funktion liegen am Providergerät. Doppel-NAT vermeiden.
Bridge- oder Modembetrieb	Eigene Firewall erhält die öffentliche Adresse direkt	Authentisierung, VLAN, Routerunterstützung und Providerfreigabe müssen geklärt sein.
Geroutetes öffentliches IPv4-Subnetz	Providerrouter routet nutzbare Adressen zur Kundenfirewall oder zu einem Übergabenetz	Netzadresse, Gateway, nutzbare Adressen und Firewallzonen exakt dokumentieren.
Feste IPv4 plus delegiertes IPv6-Präfix	IPv4 und IPv6 werden parallel bereitgestellt	Regeln, DNS, Monitoring und Tests für beide Protokolle durchführen.
Feste Adresse nur auf Hauptweg	Mobilfunk- oder Ersatzweg verwendet andere Adressierung	Partnerfreigaben und VPN müssen den zweiten Weg ausdrücklich unterstützen.

Zwanzig Fragen an Anbieter und IT-Verantwortliche

Ist die IPv4-Adresse öffentlich und vertraglich dauerhaft zugeordnet?
Wird eine einzelne Adresse oder ein geroutetes Subnetz geliefert?
Welche Adressen im Subnetz sind Netz, Gateway, Broadcast und tatsächlich nutzbar?
Liegt die Adresse am Providerrouter oder an der eigenen Firewall?
Ist Bridge-, Modem- oder Passthrough-Betrieb unterstützt?
Welche Zugangsdaten, VLANs oder Anschlusskennungen werden benötigt?
Bleibt die Adresse bei Tarifwechsel, Umzug und Technologiewechsel erhalten?
Wie wird die feste Adresse aktiviert und ab welchem Zeitpunkt gilt sie?
Wird ein festes IPv6-Präfix bereitgestellt und mit welcher Präfixlänge?
Bleibt das IPv6-Präfix nach Neueinwahl und Routertausch stabil?
Kann Reverse DNS eingerichtet oder selbst verwaltet werden?
Welche eingehenden Ports filtert der Provider unabhängig von der Kundenfirewall?
Welche Routermodelle und Firmwarestände unterstützen die Übergabe?
Ist eigene Hardware erlaubt und welche Supportgrenze gilt dann?
Welche Adresse nutzt der automatische Mobilfunk- oder Festnetzersatz?
Kann der Ersatzweg dieselben festen Adressen übernehmen?
Welche Entstör- und Änderungswege gelten für die Adressoption?
Entstehen einmalige oder laufende Zusatzkosten?
Wie lange dauert eine Adressänderung oder ein Reverse-DNS-Auftrag?
Welche technische Dokumentation wird vor der Umschaltung geliefert?

6. Öffentliche Erreichbarkeit wird mit einer minimalen Firewallregel hergestellt

Eine feste Adresse öffnet noch keinen Port. Erst eine Firewallregel, Weiterleitung oder geroutete Freigabe erlaubt eingehenden Verkehr. Jede solche Regel wird als eigener, begründeter Zugriff behandelt.

Pflichtfelder einer eingehenden Freigabe
Feld	Beispiel	Prüfung
Geschäftszweck	Partner überträgt signierte Dateien an SFTP-Gateway	Gibt es eine ausgehend initiierte oder gehostete Alternative?
Quelle	Dokumentierte Partnernetze	Keine Freigabe aus dem gesamten Internet, wenn feste Quellen möglich sind.
Ziel	Separates Gateway in eigener Netzwerkzone	Kein direkter Zugriff auf Arbeitsplatz oder NAS-Verwaltung.
Protokoll und Port	TCP 22 für SFTP	Nur technisch erforderliche Dienste erlauben.
Authentisierung	Individueller Schlüssel und gesperrtes Passwortlogin	Schlüsselwechsel und Entzug festlegen.
Zeit und Eigentümer	Unbefristet mit quartalsweiser Prüfung, verantwortlich: Fachprozess	Verwaiste Regeln vermeiden.
Protokollierung	Erfolgreiche und abgewiesene Verbindungen	Aufbewahrung, Alarmierung und Datenschutz klären.
Patch- und Backupweg	Systemverantwortlicher, Updatefenster, Restoretest	Exponierter Dienst bleibt wartbar und wiederherstellbar.

Freigabe in sechzehn Einzelschritten

Anwendungszweck und Datenfluss schriftlich beschreiben.
Ausgehend initiierte oder extern gehostete Alternative bewerten.
Quelladressen und Gegenstellenverantwortlichen bestätigen lassen.
Zielsystem in eine geeignete, getrennte Netzwerkzone stellen.
Betriebssystem und Anwendung vollständig aktualisieren.
Unnötige Dienste und Standardkonten deaktivieren.
Starke, individuelle Authentisierung konfigurieren.
Firewallregel auf Quelle, Ziel, Protokoll und Port begrenzen.
NAT-Weiterleitung nur auf das vorgesehene Ziel setzen.
Interne Weiterbewegung aus der Zielzone einschränken.
Protokollierung und Alarmkriterien aktivieren.
Verbindung von der echten Partnerquelle testen.
Abweisung von einer nicht erlaubten Quelle testen.
Dienstneustart und Zertifikatswechsel prüfen.
Regel, Eigentümer und Ablaufdatum dokumentieren.
Wiederkehrende Prüfung und sichere Außerbetriebnahme terminieren.

Routerverwaltungen, Remote Desktop, SMB-Dateifreigaben und Druckeroberflächen gehören nicht ungeschützt ins Internet. Auch ein ungewöhnlicher Port macht einen Dienst nicht sicher. Für administrative Zugriffe wird ein abgesicherter Zugangsweg mit starker Authentisierung, minimaler Reichweite und nachvollziehbarer Protokollierung eingerichtet.

7. DNS, Reverse DNS und Freigabelisten werden getrennt verwaltet

Ein öffentlicher DNS-Name zeigt auf eine Adresse. Reverse DNS ordnet einer Adresse einen Namen zu. Eine Gegenstellenfreigabe erlaubt einer bekannten Quelladresse den Zugang. Diese drei Funktionen erfüllen unterschiedliche Zwecke.

DNS-bezogene Aufgaben
Element	Richtung	Typischer Einsatz
A-Record	Name zeigt auf IPv4-Adresse	Erreichbarer VPN- oder Anwendungsendpunkt
AAAA-Record	Name zeigt auf IPv6-Adresse	IPv6-erreichbarer Dienst
PTR/Reverse DNS	Adresse zeigt auf Namen	Bei Mailservern und bestimmten Gegenstellen relevant; meist durch Provider verwaltet
Dynamisches DNS	Client aktualisiert A/AAAA nach Adresswechsel	Alternative bei dynamischer Adresse, sofern kurze Unterbrechung akzeptabel ist
IP-Allowlist	Gegenstelle erlaubt Verbindungen von festgelegter Quelladresse	Zugang zu Partner- oder Administrationssystemen zusätzlich begrenzen
Firewallregel	Gateway erlaubt definierten Datenfluss	Tatsächliche Netzfreigabe unabhängig vom DNS-Namen

Änderungen mit TTL und Verantwortlichkeit planen

Vor einer Migration wird die DNS-Lebensdauer rechtzeitig abgesenkt, sofern ein öffentlicher Endpunkt umzieht. Nach der Umschaltung werden A- und AAAA-Einträge von mehreren Resolvern geprüft. Erst nach stabiler Beobachtung wird die TTL wieder auf den Betriebswert gesetzt. Alte Einträge bleiben nicht unkontrolliert bestehen.

Bei IP-Allowlists braucht jede Gegenstelle einen erreichbaren fachlichen und technischen Kontakt. Die neue Adresse wird vor der Umschaltung ergänzt, wenn dies möglich ist. Nach erfolgreicher Abnahme wird die alte Adresse entfernt. Eine Tabelle mit Gegenstelle, Ticket, Freigabedatum, Test und Rückbau verhindert, dass ein vergessener Partnerzugang den Wechsel blockiert.

Gegenstellenregister für eine Adressänderung
Gegenstelle	Abhängigkeit	Vorbereitung	Abnahme	Rückbau
SaaS-Fachanwendung	Quell-IP-Allowlist	Neue Haupt- und Ersatz-IP freigeben	Anmeldung und Kernvorgang	Alte IP nach Beobachtungsfrist löschen
Standort-VPN	Peer-Adresse	Zweiten Peer oder FQDN vorbereiten	Tunnel, Routing und Fachanwendung	Alte Peer-Konfiguration entfernen
Partner-SFTP	Quell- oder Zieladresse	Firewall, DNS und Schlüssel abstimmen	Datei in beide Richtungen	Alte Regel und DNS-Eintrag entfernen
Fernwartung	Zugangs-Gateway	Neue Adresse und Zertifikat prüfen	Autorisierte Sitzung	Verwaiste Freigabe schließen
Monitoring	Überwachtes Ziel	Neue Sensoradresse ergänzen	Alarm und Erholung simulieren	Alten Sensor archivieren

8. Der Wechsel einer öffentlichen Adresse ist ein eigenes Migrationsprojekt

Die Internetleitung kann technisch funktionieren, während VPN, Partnerzugriffe oder Monitoring wegen der neuen Adresse ausfallen. Deshalb werden Netzumschaltung und Adressmigration als zusammenhängender, rückfallfähiger Ablauf geplant.

Migration in vierundzwanzig Schritten

Alle Anwendungen und Partner mit IP-Abhängigkeit inventarisieren.
Aktuelle öffentliche IPv4, IPv6-Präfixe, DNS-Einträge und Regeln sichern.
Technische Übergabe des neuen Providerprodukts bestätigen.
Neue Adressen, Gateway, Präfixlängen und Routermodus dokumentieren.
Eigene Firewallkonfiguration offline vorbereiten.
Adresskonflikte und Überschneidungen mit internen oder VPN-Netzen prüfen.
DNS-TTL rechtzeitig vor dem Wechsel reduzieren.
Neue Hauptadresse bei Partnern zusätzlich freischalten lassen.
Adresse des Ersatzwegs ebenfalls registrieren, sofern nötig.
Zertifikate auf DNS-Namen statt auf wechselnde Adresse ausrichten.
Monitoring für neue Leitung und Endpunkte vorbereiten.
Parallelbetrieb beider Anschlüsse herstellen.
Neuen Anschluss zunächst mit einem getrennten Testnetz prüfen.
IPv4- und IPv6-Konnektivität sowie DNS testen.
Ausgehende öffentliche Quelladresse verifizieren.
Eingehende Freigaben von erlaubten Quellen testen.
Standort-VPNs und Remotezugänge aufbauen.
Partneranwendungen mit echten Arbeitsvorgängen prüfen.
Telefonie, Cloudzugriff und Monitoring abnehmen.
Produktivverkehr im angekündigten Fenster umschalten.
Fehlerprotokoll und Rückfallentscheidung während der Beobachtung führen.
Alten Anschluss bis zum Ende der vereinbarten Frist betriebsbereit halten.
Alte DNS-, Firewall- und Partnerfreigaben kontrolliert entfernen.
Netzdokumentation und Notfallblatt mit dem Endstand aktualisieren.

Der Rückfall wird vor der Umschaltung definiert

Ein Rückfall ist nur möglich, wenn der alte Anschluss, seine Firewallkonfiguration und die alten Partnerfreigaben noch funktionieren. Vor Beginn wird festgelegt, welche Fehler den Abbruch auslösen, wer entscheidet und wie lange die Rückkehr dauern darf. Nicht jede einzelne Warnmeldung verlangt einen Rückfall; der Ausfall eines priorisierten Geschäftsprozesses ohne kurzfristige Behebung dagegen schon.

Wenn ein Provider die alte Adresse bei Aktivierung der neuen Option sofort entzieht, muss der Ablauf anders geplant werden. Dann werden DNS, Partner und Firewall vorab soweit wie möglich vorbereitet und ein separates Wartungsfenster mit erreichbaren Ansprechpartnern vereinbart.

9. Die Abnahme prüft nicht nur, ob eine Webseite lädt

Eine feste Adresse gilt erst als nutzbar, wenn Adresszuweisung, Firewall, DNS, Gegenstellen und Ersatzweg mit repräsentativen Arbeitsvorgängen geprüft wurden.

Abnahmeprotokoll für feste IP-Adressen
Prüfung	Soll	Nachweis
Vertragliche Zuordnung	Adresse oder Subnetz entspricht Providerdokumentation	Auftragsunterlage und WAN-Status
Ausgehende IPv4	Sichtbare Quelladresse entspricht der vorgesehenen festen Adresse	Abruf über zwei unabhängige Ziele
IPv6-Präfix	Delegiertes Präfix und Firewallverhalten entsprechen Planung	Routerstatus und externe Verbindungstests
Neustart	Adresse bleibt nach kontrollierter Neueinwahl erhalten	Vorher-nachher-Protokoll
DNS	A/AAAA zeigen auf richtige Endpunkte	Abfrage über mehrere Resolver
Reverse DNS	PTR entspricht beauftragtem Namen, falls benötigt	Externe PTR-Abfrage
Eingehender Dienst	Nur erlaubte Quelle erreicht genau den vorgesehenen Port	Positiv- und Negativtest
Ausgehende Allowlist	Partner erkennt die freigegebene Quelladresse	Echter Fachvorgang
VPN	Tunnel, Routing und Namensauflösung funktionieren	Zugriff auf freigegebene Zielsysteme
Ersatzweg	Priorisierte Funktionen arbeiten mit alternativer Adresse	Kontrollierte Umschaltung und Rückkehr
Monitoring	Ausfall und Wiederkehr werden erkannt	Testalarm mit Zeitstempel
Dokumentation	Betriebsblatt, Kontakte und Sicherungen sind aktuell	Freigegebener Endstand

Abweichungen der richtigen Ebene zuordnen

Erhält die Firewall nicht die dokumentierte Adresse, wird zuerst Providerübergabe, Authentisierung und Routermodus geprüft. Ist die Adresse korrekt, aber ein eingehender Dienst unerreichbar, folgen Providerfilter, Firewallregel, NAT, lokaler Dienst und Rückweg. Funktioniert der Dienst per IP, aber nicht per Name, liegt die Prüfung bei DNS, TTL und Adressfamilie.

Ein erfolgreicher Test aus dem Büro auf die eigene öffentliche Adresse kann durch Hairpin-NAT anders verlaufen als ein echter externer Zugriff. Die Abnahme erfolgt deshalb zusätzlich über ein unabhängiges Netz, etwa Mobilfunk. Negativtests bestätigen, dass nicht erlaubte Quellen und Ports tatsächlich abgewiesen werden.

10. Drei typische Entscheidungen im kleinen Unternehmen

Die technische Antwort hängt vom Geschäftsprozess ab. Dieselbe Unternehmensgröße kann deshalb zu unterschiedlichen Ergebnissen führen.

Praxisfälle mit begründetem Ergebnis
Ausgangslage	Bewertung	Ergebnis
Hausverwaltung mit Microsoft 365, Cloud-Fachanwendung und fünf Arbeitsplätzen	Alle Dienste werden ausgehend genutzt; kein Partner verlangt eine Quell-IP.	Dynamische öffentliche Adressierung genügt. MFA, Backup und Ersatzinternet sind relevanter.
Planungsbüro mit Standort-VPN zu einer Partnerorganisation	Partnerfirewall akzeptiert nur numerische feste IPv4-Peers; täglicher Datenaustausch ist kritisch.	Feste IPv4 für Hauptanschluss, zweite freigegebene Ersatzadresse und getesteter Failover.
Kleine Agentur mit NAS-Fernzugriff	Wunsch entsteht aus Bequemlichkeit; direkte Weboberfläche wäre aus dem Internet exponiert.	Keine Portfreigabe. Zugriff über abgesichertes VPN oder vermittelten Zugang; feste IP nur, falls die gewählte VPN-Technik sie verlangt.
Praxis mit externer Abrechnungsplattform	Anbieter verlangt feste Quell-IP als zusätzliche Zugriffsbedingung.	Feste ausgehende NAT-Adresse, dokumentierte Allowlist und Prozess für Providerwechsel.
Büro mit eigenem Mailserver aus Altbestand	Feste Adresse vorhanden, aber Zustellung, Reputation, Redundanz und Patchbetrieb sind schwach.	Mailmigration zu einem betriebenen Dienst statt Begründung des Eigenbetriebs allein durch die feste IP.

Die Hausverwaltung gewinnt keinen betrieblichen Vorteil, wenn sie eine feste Adresse bestellt, aber keinen Wiederanlaufplan besitzt. Das Planungsbüro braucht dagegen nicht nur die Adresse, sondern einen zweiten, beim Partner bekannten Weg. Beim NAS wird das eigentliche Ziel – sicherer Zugriff – ohne direkte Veröffentlichung erreicht. Die feste IP ist damit ein Baustein innerhalb einer Architektur, keine pauschale Aufwertung des Anschlusses.

Häufige Fragen zur festen öffentlichen IP-Adresse

Die folgenden Antworten fassen typische Entscheidungs- und Betriebsfragen zusammen.

Braucht Microsoft 365 eine feste IP-Adresse?

Für die normale Nutzung von Exchange Online, Teams, SharePoint und OneDrive wird keine feste öffentliche Büro-IP benötigt. Verbindungen werden ausgehend zu Microsoft-Diensten aufgebaut. Eine feste Quelladresse kann nur durch eine zusätzliche Unternehmensanforderung relevant werden, etwa eine IP-Freigabe bei einer anderen Fachanwendung. Microsoft veröffentlicht veränderliche Endpunktlisten; starre, manuell gepflegte Einzeladressen sind deshalb kein allgemeines Zugriffskonzept für Microsoft 365.

Ist eine feste IP-Adresse automatisch sicherer?

Nein. Sie kann eine Gegenstellenregel vereinfachen, schützt aber keinen Dienst. Sicherheit entsteht aus einer restriktiven Firewall, starker Authentisierung, aktuellen Systemen, Segmentierung, Protokollierung und einem kontrollierten Betriebsprozess. Weil die Adresse dauerhaft gleich bleibt, ist ein veröffentlichter Dienst auch dauerhaft unter demselben Ziel auffindbar.

Woran erkenne ich Carrier-Grade NAT?

Ein Hinweis ist eine WAN-Adresse aus 100.64.0.0/10 oder eine Abweichung zwischen Router-WAN und öffentlich sichtbarer IPv4. Auch private WAN-Adressen können auf eine vorgeschaltete Übersetzung hindeuten. Die endgültige Einordnung liefert der Provider. Eingehende IPv4-Verbindungen sind hinter CGNAT gewöhnlich nicht direkt bis zum Kundenrouter weiterleitbar.

Reicht dynamisches DNS als Ersatz?

Dynamisches DNS kann eine wechselnde öffentliche Adresse unter einem Namen erreichbar machen. Es funktioniert nur, wenn eine öffentlich erreichbare Adresse vorhanden ist und die Gegenstelle einen Namen akzeptiert. Aktualisierungsverzögerung, DNS-Caches, kurze Unterbrechungen und CGNAT bleiben zu berücksichtigen.

Benötigt jede feste IP-Adresse einen Reverse-DNS-Eintrag?

Nein. Reverse DNS ist nur für bestimmte Dienste oder Gegenstellen relevant. Besonders beim Betrieb eines Mailservers gehört es zu mehreren Zustellvoraussetzungen, reicht aber allein nicht aus. Für VPNs und Quell-IP-Freigaben wird üblicherweise die feste Adresse oder ein vorwärts auflösender DNS-Name verwendet.

Was passiert beim Ausfallanschluss?

Der Ersatzweg erhält meist eine andere öffentliche Adresse. Feste Hauptadressen werden nicht automatisch über Mobilfunk oder einen zweiten Standardanschluss übernommen. Partnerfreigaben, VPNs und DNS müssen deshalb den Ersatzweg kennen oder über eine Architektur geführt werden, die den Wechsel abstrahiert. Dies wird vor dem Ernstfall praktisch getestet.

Weiterführende Primärquellen

IP-Anforderung und Anschlussarchitektur sauber planen

fra.digital prüft den tatsächlichen Bedarf, die vorhandene Providerübergabe, Firewall- und VPN-Abhängigkeiten sowie den Ausfallweg. Das Ergebnis ist eine nachvollziehbare Konfiguration mit Abnahme- und Rückfallplan.

Anschluss und feste IP prüfen lassen